From nobody Fri Jun 1 02:23:27 2018 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 225E51275AB; Fri, 1 Jun 2018 02:23:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia To: Cc: draft-ietf-cellar-ffv1.all@ietf.org, cellar@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152784500007.15152.9045057653501275171@ietfa.amsl.com> Date: Fri, 01 Jun 2018 02:23:20 -0700 Archived-At: Subject: [Cellar] Secdir early review of draft-ietf-cellar-ffv1-02 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 09:23:21 -0000 Reviewer: Liang Xia Review result: Ready The whole draft is in good shape and well written. Some nits: 1. every word should start with capital letter for the section title; 2. section 2.2.4: / ceil(a) the largest integer less than or equal to a / ceil(a) the smallest integer larger than or equal to a / 3. section 3.7.2: [ISO.15444-1.2016]? 4. section 12.1: [I-D.ietf-cellar-ffv1]? 5. section 12.2: should all the RFC move to the Normative References (section 12.1)? Issues for clarification: In Security Considerations, besides the DoS attacks brought by the malicious payloads, is there any other kinds of attack possibly? For example, virus or worm are hidden in the malicious payloads to attack the system for more damages? Does it make sense and what's the consideration? From nobody Fri Jun 1 05:59:48 2018 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3275012D7F2; Fri, 1 Jun 2018 05:59:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152785798115.15521.6229169188889537553@ietfa.amsl.com> Date: Fri, 01 Jun 2018 05:59:41 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-03.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 12:59:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : FFV1 Video Coding Format Version 0, 1, and 3 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-03.txt Pages : 41 Date : 2018-06-01 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ffv1-03 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jun 1 07:38:20 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B82B12D883; Fri, 1 Jun 2018 07:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y81H5uBOlKEp; Fri, 1 Jun 2018 07:37:57 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E665912D885; Fri, 1 Jun 2018 07:37:53 -0700 (PDT) Received: from [146.96.19.240] (port=20616 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fOlBe-000MvB-HD; Fri, 01 Jun 2018 10:37:52 -0400 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_71F82103-5CE2-45B9-B7B5-22D0629ED470" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 1 Jun 2018 10:37:49 -0400 In-Reply-To: <152784500007.15152.9045057653501275171@ietfa.amsl.com> Cc: secdir@ietf.org, draft-ietf-cellar-ffv1.all@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission , ietf@ietf.org To: Liang Xia References: <152784500007.15152.9045057653501275171@ietfa.amsl.com> X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-2.4 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Secdir early review of draft-ietf-cellar-ffv1-02 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 14:38:04 -0000 --Apple-Mail=_71F82103-5CE2-45B9-B7B5-22D0629ED470 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Thanks for this review. > On Jun 1, 2018, at 5:23 AM, Liang Xia = wrote: >=20 > Reviewer: Liang Xia > Review result: Ready >=20 > The whole draft is in good shape and well written. > Some nits: > 1. every word should start with capital letter for the section title; > 2. section 2.2.4: / ceil(a) the largest integer less than or equal to = a / > ceil(a) the smallest integer larger than or equal to a / 3. section = 3.7.2: > [ISO.15444-1.2016]? 4. section 12.1: [I-D.ietf-cellar-ffv1]? 5. = section 12.2: > should all the RFC move to the Normative References (section 12.1)? I added a pull request at https://github.com/FFmpeg/FFV1/pull/116 = that addresses many of these = issues. Regarding=20 > section 12.1: [I-D.ietf-cellar-ffv1]? I found that Media Type Definitions within RFC=E2=80=99s tend to be = self-referencing. Since there is no RFC number here on this draft, = I=E2=80=99ve used [I-D.ietf-cellar-ffv1] as a temporary self reference. > Issues for clarification: > In Security Considerations, besides the DoS attacks brought by the = malicious > payloads, is there any other kinds of attack possibly? For example, = virus or > worm are hidden in the malicious payloads to attack the system for = more > damages? Does it make sense and what's the consideration? I haven=E2=80=99t done any update for this. Nudge to Michael Niedermayer = and J=C3=A9r=C3=B4me Martinez. Best Regards, Dave Rice --Apple-Mail=_71F82103-5CE2-45B9-B7B5-22D0629ED470 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,
Thanks for this = review.

On Jun 1, 2018, at 5:23 AM, Liang Xia <frank.xialiang@huawei.com> wrote:

Reviewer: Liang Xia
Review result: Ready

The whole draft is in good shape and well = written.
Some nits:
1. every word should = start with capital letter for the section title;
2. = section 2.2.4: / ceil(a) the largest integer less than or equal to a = /
ceil(a) the smallest integer larger than or equal to a / = 3. section 3.7.2:
[ISO.15444-1.2016]? 4. section 12.1: = [I-D.ietf-cellar-ffv1]? 5. section 12.2:
should all the = RFC move to the Normative References (section 12.1)?

I = added a pull request at https://github.com/FFmpeg/FFV1/pull/116 that = addresses many of these issues.

Regarding 
section 12.1: [I-D.ietf-cellar-ffv1]?
I found = that Media Type Definitions within RFC=E2=80=99s tend to be = self-referencing. Since there is no RFC number here on this draft, = I=E2=80=99ve used [I-D.ietf-cellar-ffv1] as a temporary self = reference.

Issues for clarification:
In = Security Considerations, besides the DoS attacks brought by the = malicious
payloads, is there any other kinds of attack = possibly? For example, virus or
worm are hidden in the = malicious payloads to attack the system for more
damages? = Does it make sense and what's the consideration?

I = haven=E2=80=99t done any update for this. Nudge to Michael Niedermayer = and J=C3=A9r=C3=B4me Martinez.
Best = Regards,
Dave Rice

= --Apple-Mail=_71F82103-5CE2-45B9-B7B5-22D0629ED470-- From nobody Fri Jun 1 08:13:16 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE49E12D940 for ; Fri, 1 Jun 2018 08:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-Bb7emac3pn for ; Fri, 1 Jun 2018 08:13:03 -0700 (PDT) Received: from 5.mo7.mail-out.ovh.net (5.mo7.mail-out.ovh.net [178.32.120.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C7A412D942 for ; Fri, 1 Jun 2018 08:13:01 -0700 (PDT) Received: from player761.ha.ovh.net (unknown [10.109.105.124]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id A214CAED91 for ; Fri, 1 Jun 2018 17:12:58 +0200 (CEST) Received: from [192.168.2.120] (p5DDB54A6.dip0.t-ipconnect.de [93.219.84.166]) (Authenticated sender: jerome@mediaarea.net) by player761.ha.ovh.net (Postfix) with ESMTPSA id 2B22E480091; Fri, 1 Jun 2018 17:12:53 +0200 (CEST) To: Liang Xia Cc: secdir@ietf.org, draft-ietf-cellar-ffv1.all@ietf.org, cellar@ietf.org, ietf@ietf.org References: <152784500007.15152.9045057653501275171@ietfa.amsl.com> From: Jerome Martinez Message-ID: <29965bd1-ce37-d8a8-25c4-81f6d2ddff4b@mediaarea.net> Date: Fri, 1 Jun 2018 17:12:54 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <152784500007.15152.9045057653501275171@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Ovh-Tracer-Id: 7095984163828273286 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedthedrieeggdekvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Secdir early review of draft-ietf-cellar-ffv1-02 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 15:13:05 -0000 On 01/06/2018 11:23, Liang Xia wrote: > Issues for clarification: > In Security Considerations, besides the DoS attacks brought by the malicious > payloads, is there any other kinds of attack possibly? For example, virus or > worm are hidden in the malicious payloads to attack the system for more > damages? Does it make sense and what's the consideration? IMO transport of virus or worm is doable in the bitstream and could attack the system if there are buffer overflows in the decoding software, but not more dangerous than any other protocol or format (it depends on bugs in the decoding software). Checking e.g. Opus spec (I tried AV1 draft, but no security chapter right now if I well searched), I see generic sentences like: "It is extremely    important for the decoder to be robust against malicious payloads.    Malicious payloads must not cause the decoder to overrun its    allocated memory or to take an excessive amount of resources to    decode." "The reference implementation contains no known buffer overflow or    cases where a specially crafted packet or audio segment could cause a    significant increase in CPU load. " "The reference implementation was validated in the following    conditions: (...)" (note: we ran same tests on our side) We could add such sentences in FFV1 security section. About the reference decoder, there are some hard coded limitations (e.g. maximum 1024 slices per frame, arbitrary choice which is sometimes increased in the code) for dropping frames which could use too much memory, and the decoder tries to allocate memory for big frames (e.g. if you try to decode de 1,000,000x1,000,000 pixel frames, FFmpeg will try to allocate corresponding memory as for any other format, and rejects the frame because memory can not be allocated. I don't think it is worth it to put details about that in spec, as FFmpeg code may change, maybe the generic sentences are enough? Thank you for your review. Jérôme From nobody Fri Jun 1 08:25:20 2018 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2807412D88A; Fri, 1 Jun 2018 08:25:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ben@nostrum.com, cellar@ietf.org, cellar-chairs@ietf.org, mcr+ietf@sandelman.ca X-Test-IDTracker: no X-IETF-IDTracker: 6.81.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <152786671809.15477.5986717593636946466.idtracker@ietfa.amsl.com> Date: Fri, 01 Jun 2018 08:25:18 -0700 Archived-At: Subject: [Cellar] cellar - Not having a session at IETF 102 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 15:25:18 -0000 Michael Richardson, a chair of the cellar working group, indicated that the cellar working group does not plan to hold a session at IETF 102. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Fri Jun 1 10:16:53 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDDC12D962 for ; Fri, 1 Jun 2018 10:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBVCoPvp_kUS for ; Fri, 1 Jun 2018 10:16:49 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3222612D96D for ; Fri, 1 Jun 2018 10:16:49 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 51BB420093; Fri, 1 Jun 2018 13:29:57 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4DE9B1C6; Fri, 1 Jun 2018 13:16:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4AE5F1C5; Fri, 1 Jun 2018 13:16:15 -0400 (EDT) From: Michael Richardson To: Liang Xia cc: cellar@ietf.org In-Reply-To: <152784500007.15152.9045057653501275171@ietfa.amsl.com> References: <152784500007.15152.9045057653501275171@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] Secdir early review of draft-ietf-cellar-ffv1-02 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 17:16:51 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Thank you kindly for this review! =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxF/WoCLcPvd0N1lAQLwkwf8C85SiU2DrHjF6SIF4CWWjk2iNuAiP48T nJAOqpLvx5ETS3KgEtF+aECZbu2C7+0TjVdclE6B4KKMjO18r6o5aOn4+ofbkZwO AV6d0wV2qUupRXz7voqi3y3ozuinxQc5BJBmP4k9ucohWI3rWK7esdBb+Ll2z591 Zr7D9jel4kW4VeDFoRD58phj7ObfKogwUoKBSb6iUqrRGWxoXCdOL8ggIPa/gh4Z sAKL9vsNn5Ome7aYsyltumbIZjQMZyQ96FRWBsHzM/mI1zRdES0bmpGPqGmXB+O8 sVmZWZTEqfM2le3FAqEiRiIBC5YYXYIJFVnpsehul88i/LJDxrGFaQ== =NJ21 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 1 10:22:05 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3CD12D96B for ; Fri, 1 Jun 2018 10:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tzhr-IrTVxnv for ; Fri, 1 Jun 2018 10:22:01 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5288712D962 for ; Fri, 1 Jun 2018 10:22:01 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9213720093 for ; Fri, 1 Jun 2018 13:35:10 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8C6521C6; Fri, 1 Jun 2018 13:21:28 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 895B81C5 for ; Fri, 1 Jun 2018 13:21:28 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org In-Reply-To: <152785798115.15521.6229169188889537553@ietfa.amsl.com> References: <152785798115.15521.6229169188889537553@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] I-D Action: draft-ietf-cellar-ffv1-03.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 17:22:03 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable internet-drafts@ietf.org wrote: > Title : FFV1 Video Coding Format Version 0, 1, and 3 > Authors : Michael Niedermayer > Dave Rice > Jerome Martinez > Filename : draft-ietf-cellar-ffv1-03.txt > Pages : 41 > Date : 2018-06-01 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cellar-ffv1-03 Hi Authors, thanks for fixing the Intended Status. It appears that this document has itself as a (circular) Normative Referenc= e :-) I'm guessing this is intended for ffv1-v4 only. Please fix it in the source, but you don't need to repost it until there is something else more substantial. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxGAlYCLcPvd0N1lAQK5XAf6AhSWtPS0JU1lg64myJQNvZnZVe5B7nQB mOyYiO3VZ1ZjOu8qch9EIQd8UA5diDXCUUPfHYBoPrJQ3OP2BFsSKwm3PticeOZC Tvx8jFsofFoZGJ8pBpkCrdgnBxtP/aS/idS3at3A4BOA46LNcO3EcH/SWU2620o4 y0YgdC36wYJaW0X3+p+6nlg0nWnK5KuQmmxvV/35hdJEvywQ89KkXDO61pDcc+1t Q1Aa40vlFSXHzRyAFTbzB34VJ65+egcifmNEIjse72qgC96guafPZ7JcIkiuS/eQ HhgCyIEyq3Mvp0K8ueINmL3iyRdSAZXwApWZGuhhEJlBW/ogWphC0g== =pPd0 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jun 1 10:28:34 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C934612D9FF for ; Fri, 1 Jun 2018 10:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gtmJQipqA8Cf for ; Fri, 1 Jun 2018 10:28:31 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24DBD12D969 for ; Fri, 1 Jun 2018 10:28:31 -0700 (PDT) Received: from [146.96.19.240] (port=22844 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fOnqe-001vIW-Em; Fri, 01 Jun 2018 13:28:25 -0400 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F0CD51E0-7506-4249-9EDD-083AFA8EF716" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 1 Jun 2018 13:28:19 -0400 In-Reply-To: <21553.1527873688@localhost> Cc: cellar@ietf.org To: Michael Richardson References: <152785798115.15521.6229169188889537553@ietfa.amsl.com> <21553.1527873688@localhost> X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] I-D Action: draft-ietf-cellar-ffv1-03.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 17:28:33 -0000 --Apple-Mail=_F0CD51E0-7506-4249-9EDD-083AFA8EF716 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 1, 2018, at 1:21 PM, Michael Richardson = wrote: >=20 >=20 > internet-drafts@ietf.org wrote: >> Title : FFV1 Video Coding Format Version 0, 1, and 3 >> Authors : Michael Niedermayer >> Dave Rice >> Jerome Martinez >> Filename : draft-ietf-cellar-ffv1-03.txt >> Pages : 41 >> Date : 2018-06-01 >=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cellar-ffv1-03 >=20 > Hi Authors, thanks for fixing the Intended Status. > It appears that this document has itself as a (circular) Normative = Reference :-) > I'm guessing this is intended for ffv1-v4 only. Could you suggest what should be said under =E2=80=9CPublished = specification=E2=80=9D in the Media Type Definition. I see other RFC = documents, such as https://tools.ietf.org/html/rfc7587#section-6.1 = , which do include = circular self-references. Should the current =E2=80=9CPublished specification=E2=80=9D section be = changed to: Version 0,1,3 Published specification: none Version 4: Published specification: [@!I-D.ietf-cellar-ffv1] > Please fix it in the source, but you don't need to repost it until = there > is something else more substantial. >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh = networks [=20 > ] Michael Richardson, Sandelman Software Works | network = architect [=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [=20 > =09 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_F0CD51E0-7506-4249-9EDD-083AFA8EF716 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 1, 2018, at 1:21 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


internet-drafts@ietf.org wrote:
Title =           : FFV1 Video = Coding Format Version 0, 1, and 3
Authors =         : Michael Niedermayer
Dave Rice
Jerome Martinez
Filename =        : = draft-ietf-cellar-ffv1-03.txt
Pages =           : 41
Date =            : = 2018-06-01

A diff from the previous version is available = at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cellar-ffv1-03

Hi Authors, thanks for = fixing the Intended Status.
It appears that this document = has itself as a (circular) Normative Reference :-)
I'm = guessing this is intended for ffv1-v4 only.


Should the current =E2=80=9CPublished = specification=E2=80=9D section be changed to:

Version 0,1,3
Published specification: = none

Version 4:
Published = specification: [@!I-D.ietf-cellar-ffv1]

Please fix it in the source, but you don't need to repost it = until there
is something else more substantial.

--
] =             &n= bsp; Never tell me the odds! =             &n= bsp;   | ipv6 mesh networks [
] =   Michael Richardson, Sandelman Software Works =        | network architect  [ =
]     mcr@sandelman.ca =  http://www.sandelman.ca/ =        |   ruby on rails =    [

_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

= --Apple-Mail=_F0CD51E0-7506-4249-9EDD-083AFA8EF716-- From nobody Fri Jun 1 11:00:07 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F0412DA49 for ; Fri, 1 Jun 2018 11:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfEV-nxIWvGd for ; Fri, 1 Jun 2018 10:59:58 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDAB912DA68 for ; Fri, 1 Jun 2018 10:59:57 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C5F5920093; Fri, 1 Jun 2018 14:13:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A7A171C6; Fri, 1 Jun 2018 13:59:23 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A4DC41C5; Fri, 1 Jun 2018 13:59:23 -0400 (EDT) From: Michael Richardson To: Dave Rice cc: cellar@ietf.org In-Reply-To: References: <152785798115.15521.6229169188889537553@ietfa.amsl.com> <21553.1527873688@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] I-D Action: draft-ietf-cellar-ffv1-03.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jun 2018 18:00:06 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dave Rice wrote: >> It appears that this document has itself as a (circular) Normative R= eference :-) >> I'm guessing this is intended for ffv1-v4 only. > Could you suggest what should be said under =E2=80=9CPublished specif= ication=E2=80=9D > in the Media Type Definition. I see other RFC documents, such as > https://tools.ietf.org/html/rfc7587#section-6.1 > , which do include > circular self-references. That's not the kind of reference I mean. In the media type definition, referring to document-self is fine. If you look at the diff, at: >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cellar-ffv1-03 You'll see: 12.1. Normative References 12.1. Normative References [I-D.ietf-cellar-ffv1] [I-D.ietf-cellar-ffv1] And the diff is about how the version changed. That is, I-D.ietf-cellar-ffv1 is referenced by I-D.ietf-cellar-ffv1... It would make sense for I-D.ietf-cellar-ffv1-v4 to reference I-D.ietf-cella= r-ffv1. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxGJeICLcPvd0N1lAQLDMQgAuIabkf468/uzZVX6rFNrkb7gqluuZIl1 tLXiMqXoSEU/wEvexfWcDDTpeFnNVgA/ghGNIOWAIpQe4myge7aC7sEOers2HKJl DG4b0oU79nMlyrhaCBqLGb5Wiq2FJnr3SFYFpWjf7sNvEVI32KTxVYiiRkKAz+Cy cO8qCKjrSvwyckUBOIvgY9kX8BImPecle9UbcTStSnrfMAH0cZdVX19P3+Uduc8L UGzwwpk8O0e/OcakF7hGPbD/XkPRecOpofkVm+407LKlQlrCMVbr3r+lFJinaOrm 2zZ50lGyE8/MbtvDdIP3XRWoy2qvXbzPTzR/J/0DgDIgkyM6OxepXg== =vQ3v -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 3 06:55:49 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AA4127078 for ; Sun, 3 Jun 2018 06:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABqinnJsaLf1 for ; Sun, 3 Jun 2018 06:55:46 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 415A6126CD8 for ; Sun, 3 Jun 2018 06:55:46 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id k2-v6so13270471pgc.1 for ; Sun, 03 Jun 2018 06:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oFYchiD7b1pb6Ct8vLFh47HAafJwcrCaIY8gViDLTIQ=; b=M3T7wZcVxVpYpi7el++UsQeau5Feb1MJhLyZE2Faswq258a3/Pa8nPGeWT6ljwzHCK PtmsqbO5VUpbftoM3z+rCsVNlirzAcsiWKopse9Z6YUYloiWYwlwVt8fKiXC5Kl/Rea+ 9DJ7dPfh5r8LnTazIFlxyGXg6Y0KYf2yMHFQT6MQlVjtzZinNb9byotOTPUNIBI7Yc2p vQHU7wl8IiC5KjTY9mNXonWuUagBtWAQjecBK90dNeI8dKnlIiN6L9C21J5onZwfYxCD 7lO+ZsMgCzIac2vMBIQJU9i5rwZvchHmGfI36ekzUzUdj8aGRmProK9ypwwfVQX4hDhT Oz6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oFYchiD7b1pb6Ct8vLFh47HAafJwcrCaIY8gViDLTIQ=; b=JnMHIXf32s55qn4vmCPP6qu+iLiKVxrBdDgsAiLtaAhQJcQNCWsh5J/zd7fsHZ++P7 UeSuOA7PIuoHCwHZG2ZvR4h+s6VnHWoDyQWomiYmpR4d/VjAbbbeMWzULWCk0qcOmQuX ccfrV7tRZfrtbUwm/9DDJId/ZIHDh55U3cCsel6MBwR26wZcy09tAslIYVg01im+w0mx y8YNz5704JradKFcUCu0oLz8OIZVQZ9Xds2S4dCAvrqXL+wsICwVbMAQ9+wZwO9Ywv2J RIdb1fVlu2YKdlpIt5/4HFQixaJyFV4tyYw2/eV1BRAFQ9mQmSBnefIczmj4qbV6pU4I 3jDg== X-Gm-Message-State: ALKqPweNs46G8I0sEchhKEmrxWwgdKWWL2s7+ZBo6FbKWDq0mfdIu1bp tHJ9SVW5aqAZl/dJXYHLw1IxOraB9qq/KmqQuwExjA== X-Google-Smtp-Source: ADUXVKK7EeHMBxKizyeOzq86/pOPIlaAV+bHE7u9EN7qaZIHVA5N7f9z3jIbnwzr8wQU1u/agXlt9JFHNwugAHylYvs= X-Received: by 2002:a63:7741:: with SMTP id s62-v6mr14607190pgc.103.1528034145589; Sun, 03 Jun 2018 06:55:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9a5:0:0:0:0 with HTTP; Sun, 3 Jun 2018 06:55:45 -0700 (PDT) In-Reply-To: <17549.1527815580@localhost> References: <1ae2f2ce-3218-a19f-330e-0bd5407452a3@xiph.org> <87sh689wvq.fsf@bunkus.org> <4c930b01-194e-526f-818a-f4867a8dadb4@gmx.ch> <67075B43-2025-40C5-A470-73296F3DAE22@dericed.com> <28452.1527794172@localhost> <81640b13-51ec-6bc2-9825-da2dce6daabb@gmx.ch> <17549.1527815580@localhost> From: Steve Lhomme Date: Sun, 3 Jun 2018 15:55:45 +0200 Message-ID: To: Michael Richardson Cc: hubblec4 , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Call for adoption of three new WG items X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jun 2018 13:55:49 -0000 2018-06-01 3:13 GMT+02:00 Michael Richardson : > > hubblec4 wrote: > >> > Moving the tags section to a separate document wasn=E2=80=99t be= cause of its > >> > complexity but because it would likely need more frequent revisi= on as > >> > new metadata values are added. So the chapters descriptions are = still > >> > in draft-lhomme-cellar-matroska-04, see > >> > https://tools.ietf.org/html/draft-lhomme-cellar-matroska-04#sect= ion-10. > >> > >> Will the new tags materially affect processing of the old tags? > > > I say no. It is also possible to use own private (undefinded) Tags,= for > > example Mosu's Statistics Tags without break processing old Tags. > > All Tags work independently. > > So, new functionality can be in new documents and does not require revisi= ng > documents. Correct. > > Also new Tags elements must be safe for the old Tags elements. > > If there were new behaviours necessary for old tags, then we would have t= o > change the file version number, I think. Correct although breaking backward compatibility is not desired for now. > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Wed Jun 6 18:50:13 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A2F13107A for ; Wed, 6 Jun 2018 18:50:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzJa1f6YaQvq for ; Wed, 6 Jun 2018 18:49:59 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB3B130E16 for ; Wed, 6 Jun 2018 18:49:59 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AFC1720090 for ; Wed, 6 Jun 2018 22:03:25 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B9CB025C3; Wed, 6 Jun 2018 21:49:21 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B75C074 for ; Wed, 6 Jun 2018 21:49:21 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] VINT_DATA of all ontes X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 01:50:05 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable ebml says in section 7: Additionally, an "Element ID" with binary encoding of "1111 1111" is invalid since the "VINT_DATA" section is set to all one values, whereas an "Element ID" with binary encoding of "0100 0000 0111 1111" stores a semantically equal "VINT_DATA" and is the shortest possible "VINT" encoding. It seems that there is a prohibition on VINT_DATA that is all ones. I can't find a place in section 6 that says this. Is this a restriction on all VINT_DATA, or just ones used for Element ID? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxiMCICLcPvd0N1lAQK0DwgAk1iBaMBBX9vXgFxhl6RFCF93J+8qp860 rFQNpOvmj2bIhDeNoiIimW2uUkOLbEXXjXcOwRIUQNAkzIB9xq8V3Gd8SFz+U9ch trI2Qmjgelv2npBJjj4hS+gvHqU36HIozT75FfMxPwAla74VBGJ0qPcUfapbI/T/ LYqZfTe4Z3GtKe47zZsRIyvcz//a8zQVntDsOXsKDcHkXDpDbCG3eTr7jBlcfMx/ AQUwQZZx8ozuRUPTXHDw3DK8wBxGKvoaeVY6KhWsoH4cyCCVSSHrxJy14NIxh5Ez sMsfO6tNkr1fNLvKEpQH264GHrEOMWDt6klqkG631vvn2saX1+bqyw== =DvhL -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 6 18:54:36 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633A113107D for ; Wed, 6 Jun 2018 18:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id au3_HaJUrys8 for ; Wed, 6 Jun 2018 18:54:31 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD2F130E16 for ; Wed, 6 Jun 2018 18:54:31 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9C0E120090 for ; Wed, 6 Jun 2018 22:07:58 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A3A1925C3; Wed, 6 Jun 2018 21:53:54 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A13D574 for ; Wed, 6 Jun 2018 21:53:54 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] IANA Considerations for EBML X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 01:54:35 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I've made a pull request, https://github.com/Matroska-Org/ebml-specificatio= n/pull/179 but I include the text here so that we can discuss it on the list. I havne't gotten the references done correctly for mmark, so don't worry about that for now. Note: "Specification Required" does not imply IETF specification. It could be any SDO, and many other entities that might publish things. First Come/First Served requires no document at all... just ask IANA. RFC Required does not imply standards track. see https://tools.ietf.org/html/rfc8126 # IANA Considerations This document creates a new IANA Registry called "CELLAR EBML Element ID Registry". Element IDs are described in section {{#element-id}}. Element IDs are encoded using the VINT mechanism described in section {{#variable-sized-integer}} can be between one and five bytes long. Five byte long Element IDs are possible only if declared in the heade= r. One byte Element IDs are numbers between 1 and 126. These items are valuable because they short, and need to be used for commonly repeated elements. Values from 1 to 126 are to be allocated according to RFC Required. Two byte Element IDs are numbers between 127 and 16382. Numbers may be allocated within this range according to Specification Required. Three byte Element IDs are numbers between 16383 and 2097150. Numbers may be allocated within this range according to First Come First Served. Four byte Element IDs are numbers between 2097151 and 268435456. Four byte Element IDs are somewhat special in that they are useful for resynchronizing to major structures in the event of data corruption or loss. As such four byte Element IDs are split into two categories. Four byte Element IDs whose lower three bytes (as encoded) would make printable 7-bit ASCII values may be allocated only Specification Required. Sequential allocation of values is not required: specifications SHOULD include a specific request, and are encouraged to do early allocations. To be clear about the above category: Four Byte Element IDs always start with hex 0x10 to 0x1F, and that byte may be chosen so that the entire numb= er has some desirable property, such as a specific CRC. The other three bytes, when ALL having values between 33 (ASCII !) and 126 (ASCII ~), fall into this catgory. Other Four Byte Element IDs may be allocated by First Come First Served. Five Byte Element IDs (values from 268435457 upwards) are reserved for Experimental use. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxiQL4CLcPvd0N1lAQIZKgf+KJ01gv/cO/A6Ixw/l0GPPd8KwiDR7awj fEBRxkeTNMGCalKHeK6FgFDJQi/xIWrTYwLBiTpRps1Yd4Ll5D56oD/1ffneKw0d 8ta5fPeQWAt7tldvf0d8oUOvtFYlZOlurjKxCliYgNfrZV+tBz81aEfaMaf+l3sT 4qIUpVjabEchmF2cpAcaTKkUwM0kTY2SdyrMMl5X1xwmCwA4g6UAOtCLd7lOEeET fMcoP3IxeDVdrUGBsFvIA7Yg3H1neE44w7XTbJGri6AH3rOj5Kcqp5op+0X1PxZT MiNULCEDQ7iekjWUsbru8pl+5vXm8Nxaya8SEY5vtmGnHtTUH1TBnA== =47fd -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 7 07:50:35 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4BC130F2C for ; Thu, 7 Jun 2018 07:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5XYmJ2Asr5f for ; Thu, 7 Jun 2018 07:50:29 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E488130F23 for ; Thu, 7 Jun 2018 07:50:29 -0700 (PDT) Received: from [146.96.19.240] (port=47068 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fQwF5-000gbk-4u; Thu, 07 Jun 2018 10:50:28 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dave Rice In-Reply-To: <14348.1528336161@localhost> Date: Thu, 7 Jun 2018 10:50:21 -0400 Cc: cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <14348.1528336161@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] VINT_DATA of all ontes X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 14:50:31 -0000 > On Jun 6, 2018, at 9:49 PM, Michael Richardson = wrote: >=20 >=20 > ebml says in section 7: >=20 > Additionally, > an "Element ID" with binary encoding of "1111 1111" is invalid = since > the "VINT_DATA" section is set to all one values, whereas an = "Element > ID" with binary encoding of "0100 0000 0111 1111" stores a > semantically equal "VINT_DATA" and is the shortest possible > "VINT" encoding. >=20 > It seems that there is a prohibition on VINT_DATA that is all ones. > I can't find a place in section 6 that says this. Just before your quote, I see: "The VINT_DATA component of the Element ID MUST NOT be either defined or = written as either all zero values or all one values.=E2=80=9D > Is this a restriction on > all VINT_DATA, or just ones used for Element ID? This is specific to the Element ID. An all-one VINT_DATA in Element Data = Size (also a VINT) means that the size is unknown. See: An "Element Data Size" with all "VINT_DATA" bits set to one is reserved as an indicator that the size of the "EBML Element" is unknown. The only reserved value for the "VINT_DATA" of "Element Data Size" is all bits set to one. Dave= From nobody Thu Jun 7 09:58:43 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E335130F6D for ; Thu, 7 Jun 2018 09:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TU5vr13nDvGC for ; Thu, 7 Jun 2018 09:58:37 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC3C130F5E for ; Thu, 7 Jun 2018 09:58:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id E554520090; Thu, 7 Jun 2018 13:12:05 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5A0153033; Thu, 7 Jun 2018 12:57:59 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 5732B3032; Thu, 7 Jun 2018 12:57:59 -0400 (EDT) From: Michael Richardson To: Dave Rice , cellar@ietf.org In-Reply-To: References: <14348.1528336161@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] VINT_DATA of all ontes X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 16:58:42 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dave Rice wrote: >> Additionally, >> an "Element ID" with binary encoding of "1111 1111" is invalid since >> the "VINT_DATA" section is set to all one values, whereas an "Element >> ID" with binary encoding of "0100 0000 0111 1111" stores a >> semantically equal "VINT_DATA" and is the shortest possible >> "VINT" encoding. >>=20 >> It seems that there is a prohibition on VINT_DATA that is all ones. >> I can't find a place in section 6 that says this. > Just before your quote, I see: > "The VINT_DATA component of the Element ID MUST NOT be either defined > or written as either all zero values or all one values.=E2=80=9D Ah, my eyes missed that. Could we split this into three paragraphs, and can we add some explanation = of why all zeros and all ones is forbidden? >> Is this a restriction on >> all VINT_DATA, or just ones used for Element ID? Would the WG like to simply skip allocation of Element IDs values which would be all ones in the appropriate encoding? Clearly, one can go to the next bigger VINT size and express it, but it seems like skipping that value is simpler. I believe that my suggested IANA Considerations text on this value does that. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxlkFICLcPvd0N1lAQIRSwf9HWgqcCQF6F9D2tj4Cq1HHRve1NMXnB/p O9JhMTfeJVeOyDyOn2tvqSGSvRSg83c/zNzkOxrB8EgMM47qZERLsoQJXnl6GS8j 8wGMW4u4kUkWgYMtwSm8osmfOO535FdDSUrtVc89mAuu4Mn5iejES/gl4u0Kqu2l 8DiLCWx8hGIAn+MJyqFLOok9D2W1OKuWsg2A6mv1BwTiMAwCifwHVr0vCRoY9U+x Y5ohjFYPhk6ID8wGVsu3ZnW+90nlO+56lVLvhFWboggmVqoZPQOFjhPC0DXJfeCA dM0h7ZlrINAINnSqDkA8IJYz52oFIzH2CMk39BQp5jpkRNl+EODvyw== =gKag -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Jun 7 10:09:28 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88A8130FD7 for ; Thu, 7 Jun 2018 10:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8A5snxFs4Lr for ; Thu, 7 Jun 2018 10:09:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56788130F6F for ; Thu, 7 Jun 2018 10:09:22 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2B45620090; Thu, 7 Jun 2018 13:22:52 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8C5F63033; Thu, 7 Jun 2018 13:08:45 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8A1543032; Thu, 7 Jun 2018 13:08:45 -0400 (EDT) From: Michael Richardson To: Matroska-Org/ebml-specification CC: cellar@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] [Matroska-Org/ebml-specification] IANA considerations for Element ID allocation (#179) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2018 17:09:26 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am responding to comments in github by Dave Rice. I have fixed the backtick for references and the , for thousands. If you want to merge the paragraphs, I will do that once I'm finished editing, because I find it annoying to edit that way (and it makes for less understable diffs). I have fixed the off-by-one on 268,435,456. > Also perhaps these min/max values should be integrated into the table in > the {{#element-id}} section That's a good idea. > Should define the ascii range specifically here. For instance the lower > three bytes of the EBML Element are 0x45DFA3 which is extended ascii for > E=C3=9F=C2=A3 (~'ebml') If we permit other than 7-bit US-ASCII to be reserved, then the discussion will then be latin-1,latin-2,windows-XXXX, or UTF-8. If you want 0x45DFA3, then it's also available by First Come First Served, it's just not reserved. > perhaps this paragraph and the prior could be merged my opinion is that it more understandable this way. > +Other Four Byte Element IDs may be allocated by First Come First Served. > how? Please see https://tools.ietf.org/html/rfc8126#section-4.4 >+Five Byte Element IDs (values from 268435457 upwards) are reserved for >+Experimental use. > >that only leaves two available non-experimental five byte element ids. I don't think it leaves any: it's all experimental. Do we really need that any Five Byte Element IDs in specifications? =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWxlmmoCLcPvd0N1lAQJgeAf/ZSPgamXHtxGuJjNN1jQ8odnFSIfopWs3 qSA5VmMSz3VNlHybffiEPZTcEc9Mz73kXwBHL1mMvYpkzAZl9GeWsRemwYVW/Rfl Ii4EFq/7zjTgEGIzNhaRzJucvL7MCym6R6Rx2KNBgw8Gzt3R/drlIlnXKN685yAo akQU8QoE2YDJQgkAZ1Q+NsLq2CFYJffICxyJ5JmfEcAklm2dpdMRDyztoMDO+Dpa SGWvRUd+KGpUEd0Sj9YI/mZqLff7ql1UsPtVU46NGau+pjmbmkaDAWGNRlxC4cFT iYt2taCQfytoIFpT9umuiteIq/tPjEoBcko4wcoiTvhmJhMCT47Fgg== =doE5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jun 10 03:07:08 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A7A130E2D for ; Sun, 10 Jun 2018 03:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcc2O4Res3pt for ; Sun, 10 Jun 2018 03:07:05 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6B8130E2A for ; Sun, 10 Jun 2018 03:07:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2017070101; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=Zy40jnQnapYBLuewSEXX3ZpBpmQYKOte/3ILh5LKNYc=; b=QmFy78CSTOwM7yO5s47TjLEr8L7CjtQsDYE4h8r1Hfl6UahcqvVoJgbmwRtf1Yi6jfRHMP4DHYSGUXeChhYsPnnJ0KK9teBX2LBL6Sk8XmiFwGYoF0khbgZRNjqTe5faJgkEFF6nKwRer0kX6NP3usyUeT4I7K0UnDGKGzdv31nbJNZQLXwuRXmBo5Qs+0GGfVDPQUWVCIk3su9Ue4mBPTQt67JEAx/KhRzU298Nlfo4DHm9FovsLKbxP9ubyr1hTcgJ9b1jojukRT1EpGQcxg1f1dvSP1MiBf5hRm1CngWpcw80i/nSw93MzTtw4srwfsNBw19AEWE9jeBkEbdW10bEmUs9L0d1vwB5+nB9fKEnCxAYmNQ8VGEsU2tfxgaBjjBeW/B8IvofntgWDVOcPuSpBsp7JGXTqz5yQruUaSK8VVuv7FOx9B3BV0oZkzxHj8eWP/QKJgNWjOL/7y6JlY4/PGd6y7HCG4+lYMIqyXDEelhb6VrP+7SmwgQZYigTBLAGO8s4sOUqIpdgb6VAZrgDha0dyInjX2GuaDAToIjWv09Ts2hNuzYsOzgJkiXQzFgWBiR3PilezPNjZ3CbcytxMtdBuKOoXZucWfxJmiqTmYToW+xCBoBorNOkKz+A0c21gBHMo5SJP9aPIZ39J6SfRixXUOcTMI7WeZFlBpY=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:54252) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1fRxFP-0003AY-0y; Sun, 10 Jun 2018 12:06:55 +0200 X-Virus-Scanned: amavisd-new at bunkus.org Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 28AD065414A4; Sun, 10 Jun 2018 12:06:49 +0200 (CEST) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 7B0163A582AC; Sun, 10 Jun 2018 12:06:48 +0200 (CEST) User-agent: mu4e 1.0; emacs 26.1 From: Moritz Bunkus To: Cellar list , help Questions Date: Sun, 10 Jun 2018 12:06:48 +0200 Message-ID: <871sdfrm4n.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Cellar] MKVToolNix v24.0.0 released X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 10:07:07 -0000 Hey. time for MKVToolNix v24.0.0, a release that's on the smaller side regarding the number of changes: nothing major, a number of smaller bugs squashed, and a couple of enhancements. AV1 support hasn't changed as the bitstream format still hasn't been finalized. To my users on Debian and Ubuntu: just a friendly reminder that the layout of my APT repositories was changed in April. If you haven't done so, you'll have to update your `sources.list` entry accordingly. Read more about that in this blog post: https://www.bunkus.org/blog/2018/04/debian-ubuntu-apt-repository-changes/ Here are the usual links: =E2=80=A6to the source code: https://mkvtoolnix.download/source.html =E2=80=A6to the binaries: https://mkvtoolnix.download/downloads.html The Windows and macOS binaries are available already. The Linux binaries are still being built and will be available of the course of the next couple of hours. Here are the NEWS since the previous release: ------------------------------------------------------------ # Version 24.0.0 "Beyond The Pale" 2018-06-10 ## New features and enhancements * mkvmerge: MP4 reader: improved the detection of edit lists consisting of = two identical entries, each spanning the file's duration as given in the movie header atom. The second entry is ignored in such cases. See #2306. * mkvmerge: JSON identification: the "display unit" video track property is now reported as `display_unit`. The JSON schema has been bumped to v11 for this change. * mkvmerge, mkvextract: AVC/h.264: empty NALUs will now be removed. * mkvextract: VobSub extraction: empty SPU packets will now be dropped duri= ng extraction as other tools such as MP4Box cannot handle them correctly. Implements #2293. ## Bug fixes * mkvmerge: E-AC-3 parser: fixed determining the number of channels for streams that contain an AC-3 core with dependent E-AC-3 frames. Fixes #22= 83. * mkvmerge: Matroska reader: fixed mkvmerge buffering the whole file if a video track is multiplexed that consists of only one or a few frames. Fix= es #2304. * mkvmerge: the "display unit" video track property will now be kept if it = is set in the source file. Fixes #2317. * MKVToolNix GUI: multiplexer: when scanning playlists, all playlists were offered for selection regardless of the value of the "minimum playlist duration" setting. Fixes #2299. * MKVToolNix GUI: multiplexer: deriving track languages from file names: the regular sub-expressions for ISO 639-1 codes could match on empty strings, too, causing matches in wrong places and hence no language being recogniz= ed in certain situations. Fixes #2298. * MKVToolNix GUI: header editor: fixed a crash when saving the file fails (e.g. because it isn't writable). Fixes #2319. * MKVToolNix GUI: header editor: the editor was wrongfully claiming that mandatory elements with default values cannot be removed in the "status" text. Fixes #2320. * MKVToolNix GUI: preferences: on macOS & Linux the setting "enable copying tracks by their type" wasn't restored on program start. Fixes #2297. ## Other changes * Niels Lohmann's JSON library: the bundled version has been updated from v1.1.0 (git revision 54d3cab) to v3.1.1 (git revision g183390c1). * pugixml library: the bundled version has been updated from v1.8 to v1.9 (= git revision e584ea3). ------------------------------------------------------------ Have fun :) mosu From nobody Wed Jun 13 07:16:38 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17C35130E31 for ; Wed, 13 Jun 2018 07:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz_bFi5xJrLS for ; Wed, 13 Jun 2018 07:16:35 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8960130E30 for ; Wed, 13 Jun 2018 07:16:35 -0700 (PDT) Received: from [146.96.19.240] (port=11157 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fT6ZV-000MiO-37; Wed, 13 Jun 2018 10:16:29 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dave Rice In-Reply-To: <5086.1528391325@localhost> Date: Wed, 13 Jun 2018 10:16:23 -0400 Cc: Matroska-Org/ebml-specification , cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <541FED05-BFD2-4BF9-A054-0D241107CD0D@dericed.com> References: <5086.1528391325@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] [Matroska-Org/ebml-specification] IANA considerations for Element ID allocation (#179) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 14:16:37 -0000 > On Jun 7, 2018, at 1:08 PM, Michael Richardson = wrote: >=20 > I am responding to comments in github by Dave Rice. >=20 > I have fixed the backtick for references and the , for thousands. > If you want to merge the paragraphs, I will do that once I'm finished > editing, because I find it annoying to edit that way (and it makes for > less understable diffs). >=20 > I have fixed the off-by-one on 268,435,456. >=20 >> Also perhaps these min/max values should be integrated into the table = in >> the {{#element-id}} section >=20 > That's a good idea. >=20 >> Should define the ascii range specifically here. For instance the = lower >> three bytes of the EBML Element are 0x45DFA3 which is extended ascii = for >> E=C3=9F=C2=A3 (~'ebml') >=20 > If we permit other than 7-bit US-ASCII to be reserved, then the = discussion > will then be latin-1,latin-2,windows-XXXX, or UTF-8. If you want = 0x45DFA3, > then it's also available by First Come First Served, it's just not = reserved. Keeping it to the 7-bit ascii range is fine with me. Nudging Steve for = comment as he=E2=80=99s the one that originated use of element id easter = eggs outside of the 0x20 to 0x7E range. >> perhaps this paragraph and the prior could be merged >=20 > my opinion is that it more understandable this way. >=20 >> +Other Four Byte Element IDs may be allocated by First Come First = Served. >> how? >=20 > Please see https://tools.ietf.org/html/rfc8126#section-4.4 I suggest including an "[@!RFC8126]=E2=80=9D at the end of this sentence = to create a normative reference to RFC8126. >> +Five Byte Element IDs (values from 268435457 upwards) are reserved = for >> +Experimental use. >>=20 >> that only leaves two available non-experimental five byte element = ids. >=20 > I don't think it leaves any: it's all experimental. This may be related to the off by one issue. If "Five Byte Element IDs = (values from 268435457 upwards) are reserved for Experimental use.=E2=80=9D= Both 268435456 and 268435457 require a five element id, so in my first = reading it seems like this sentence was saying that: 268435456, reservation status unknown 268435457, reservation status unknown >268435457, reserved > Do we really need that any Five Byte Element IDs in specifications? I don=E2=80=99t need five byte element IDs in this specification, but a = user defining an EBML Document Type should be able to read this document = and understand if and how they can create their own identifiers at any = length. Dave= From nobody Wed Jun 13 08:26:29 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A742B130EF7 for ; Wed, 13 Jun 2018 08:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Kccc7lVd-L9 for ; Wed, 13 Jun 2018 08:26:16 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14CBE130F6A for ; Wed, 13 Jun 2018 08:26:16 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 984FC20090; Wed, 13 Jun 2018 11:40:04 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9F11853; Wed, 13 Jun 2018 11:23:18 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9B6424F; Wed, 13 Jun 2018 11:23:18 -0400 (EDT) From: Michael Richardson To: Dave Rice cc: Matroska-Org/ebml-specification , cellar@ietf.org In-Reply-To: <541FED05-BFD2-4BF9-A054-0D241107CD0D@dericed.com> References: <5086.1528391325@localhost> <541FED05-BFD2-4BF9-A054-0D241107CD0D@dericed.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] [Matroska-Org/ebml-specification] IANA considerations for Element ID allocation (#179) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 15:26:26 -0000 Dave Rice wrote: >> I don't think it leaves any: it's all experimental. > This may be related to the off by one issue. If "Five Byte Element IDs > (values from 268435457 upwards) are reserved for Experimental use.=E2= =80=9D > Both 268435456 and 268435457 require a five element id, so in my first > reading it seems like this sentence was saying that: > 268435456, reservation status unknown > 268435457, reservation status unknown I would mark them as simply RESERVED, that way nobody can get the encoding wrong. >> Do we really need that any Five Byte Element IDs in specifications? > I don=E2=80=99t need five byte element IDs in this specification, but= a user > defining an EBML Document Type should be able to read this document a= nd > understand if and how they can create their own identifiers at any > length. The First Come First Served space is usually easiest. If you feel that the text needs to be friendly, or explain things better to non-IETF types, that's completely reasonable. My goal is to write text that *IANA* will understand, and that represents t= he rough consensus of the group. So, again, are there any objections to the essential plan? From nobody Wed Jun 13 10:48:04 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C74130F5B for ; Wed, 13 Jun 2018 10:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxTV2NAWq23C for ; Wed, 13 Jun 2018 10:47:59 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEB58130F3A for ; Wed, 13 Jun 2018 10:47:59 -0700 (PDT) Received: from [146.96.19.240] (port=4371 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1fT9s9-0027BW-I0; Wed, 13 Jun 2018 13:47:58 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dave Rice In-Reply-To: <25624.1528903398@localhost> Date: Wed, 13 Jun 2018 13:47:52 -0400 Cc: Matroska-Org/ebml-specification , cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9EFC9B3B-F622-4085-8ABD-2AB056952D8A@dericed.com> References: <5086.1528391325@localhost> <541FED05-BFD2-4BF9-A054-0D241107CD0D@dericed.com> <25624.1528903398@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] [Matroska-Org/ebml-specification] IANA considerations for Element ID allocation (#179) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 17:48:01 -0000 > On Jun 13, 2018, at 11:23 AM, Michael Richardson = wrote: >=20 >=20 > Dave Rice wrote: >>> I don't think it leaves any: it's all experimental. >=20 >> This may be related to the off by one issue. If "Five Byte Element = IDs >> (values from 268435457 upwards) are reserved for Experimental use.=E2=80= =9D >> Both 268435456 and 268435457 require a five element id, so in my = first >> reading it seems like this sentence was saying that: >=20 >> 268435456, reservation status unknown >> 268435457, reservation status unknown >=20 > I would mark them as simply RESERVED, that way nobody can get the = encoding > wrong. >=20 >>> Do we really need that any Five Byte Element IDs in specifications? >=20 >> I don=E2=80=99t need five byte element IDs in this specification, but = a user >> defining an EBML Document Type should be able to read this document = and >> understand if and how they can create their own identifiers at any >> length. >=20 > The First Come First Served space is usually easiest. >=20 > If you feel that the text needs to be friendly, or explain things = better to > non-IETF types, that's completely reasonable. > My goal is to write text that *IANA* will understand, and that = represents the > rough consensus of the group. > So, again, are there any objections to the essential plan? The essential plan sounds fine with me. Looking forward to reviewing an = updated pull request. Dave From nobody Wed Jun 13 12:21:06 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68123130E8A for ; Wed, 13 Jun 2018 12:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nC4B2ASwQEKD for ; Wed, 13 Jun 2018 12:20:55 -0700 (PDT) Received: from 5.mo69.mail-out.ovh.net (5.mo69.mail-out.ovh.net [46.105.43.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD78130E87 for ; Wed, 13 Jun 2018 12:20:54 -0700 (PDT) Received: from player687.ha.ovh.net (unknown [10.109.105.1]) by mo69.mail-out.ovh.net (Postfix) with ESMTP id E2B3E18B3B for ; Wed, 13 Jun 2018 21:20:51 +0200 (CEST) Received: from [192.168.2.120] (p3EE2DAB3.dip0.t-ipconnect.de [62.226.218.179]) (Authenticated sender: jerome@mediaarea.net) by player687.ha.ovh.net (Postfix) with ESMTPSA id 9BABA2C00A5 for ; Wed, 13 Jun 2018 21:20:51 +0200 (CEST) To: cellar@ietf.org References: <5086.1528391325@localhost> <541FED05-BFD2-4BF9-A054-0D241107CD0D@dericed.com> <25624.1528903398@localhost> From: Jerome Martinez Message-ID: <9591cfe6-e32b-f22b-d6d0-fc15401285b4@mediaarea.net> Date: Wed, 13 Jun 2018 21:20:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <25624.1528903398@localhost> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Ovh-Tracer-Id: 7967712166131470481 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedthedrledugdefhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] [Matroska-Org/ebml-specification] IANA considerations for Element ID allocation (#179) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jun 2018 19:21:03 -0000 On 13/06/2018 17:23, Michael Richardson wrote: > My goal is to write text that *IANA* will understand, and that represents the > rough consensus of the group. > So, again, are there any objections to the essential plan? It is fine for me, thanks for taking care of it. From nobody Sun Jun 17 07:57:54 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC133130E18 for ; Sun, 17 Jun 2018 07:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JYqV-DSVEvIx for ; Sun, 17 Jun 2018 07:57:50 -0700 (PDT) Received: from mail-pf0-x243.google.com (mail-pf0-x243.google.com [IPv6:2607:f8b0:400e:c00::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC278130E15 for ; Sun, 17 Jun 2018 07:57:49 -0700 (PDT) Received: by mail-pf0-x243.google.com with SMTP id a63-v6so6962676pfl.1 for ; Sun, 17 Jun 2018 07:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5MupHC16723Q9FSCAO/JIa6pB6lm6+4T+dnPRDMt3rY=; b=GGcbYhMBxnSRc9NxI+ZKFlBhc8NLSVAWxfHbicXPOB+tec4TwrtvGcTfnxJpUInWSp Sq4eYomM7NjO9qA1WuHEDoaUYA8IX+MZrkuLGpQLPS4c1r2hyAbCLdDhHrQ32lUPrgZk hI0bGm/I+wnyoDBhqgEVT4NZ4UQSDBq06Vqg6ErAZv8aQfsqseN+47p5fAOV0WMmaNGw iiiCeGD6tEj8iESKOBbEYSJEqQGYFTcFw0np+DsBe68VB7/qfCXIdqldv3z2NvRgNRiM 2BP119Mn54My6404IJB3NgyWQ32I2t322USNkpSzFuOSLqLoNjhRPkOFQy7Nol0/L8U2 3urA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5MupHC16723Q9FSCAO/JIa6pB6lm6+4T+dnPRDMt3rY=; b=dk5mK5U00qTbDbkfkrdLA1g8Gml8ObeGcUXXuX0Xd9tV9TTTtUQEl9ZEZQhrPRw/9G Cf3FED1dVrtvF9FczTejdpcMrjYG4nsWH44XZ76g300+7PVQuloLFab1Uwu33qAnuXIB Y+ofXxsuasbt3CGK1B7ObS9sfBQDLVHNaY7Y4YYYXZnoQ8NPGU515ArRINv05mKxjnWQ OssG5v11IVykHj8PTGT40Zw0A8kkV/dEdIiflabWyG8aRBlHydKLr1E25FNApt/l4iEV hhnL7PdmRWE8tPWs1NJGDGItwH/3+0NZz7npCAxbYPZVEKh34ePtidH1OmrcnF4kh64H kvgQ== X-Gm-Message-State: APt69E3ezn3rGD6SRj5PnJlx8e3XXLlm/5cVCyWI5j0bIT09P5J0wfO8 QpEM83J6PriqiPR+wBqXzsVTTV5DUMUBYL2bfD9tiQ== X-Google-Smtp-Source: ADUXVKLO4ZtkVp0ajk0uQB+nAP0UebkQ5gcA2plldWEvq/R6xGupwND5SdzA3Ma99wgcyO6Wa7B6KKuvAlcaDG6Qcx0= X-Received: by 2002:a62:ff1d:: with SMTP id b29-v6mr9971856pfn.181.1529247469337; Sun, 17 Jun 2018 07:57:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9a5:0:0:0:0 with HTTP; Sun, 17 Jun 2018 07:57:48 -0700 (PDT) In-Reply-To: <15361.1528336434@localhost> References: <15361.1528336434@localhost> From: Steve Lhomme Date: Sun, 17 Jun 2018 16:57:48 +0200 Message-ID: To: Michael Richardson Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] IANA Considerations for EBML X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 14:57:53 -0000 I think in general it would be better to use hexadecimal values for the ranges. It's friendlier to know why these values when reading then in "binary". Also they are coded as VINT but in the end are not intrepreted as the integer values they represent but really the whole ID as one. So the integer values are not what people will use/see. 2018-06-07 3:53 GMT+02:00 Michael Richardson : > > I've made a pull request, https://github.com/Matroska-Org/ebml-specification/pull/179 > but I include the text here so that we can discuss it on the list. > I havne't gotten the references done correctly for mmark, so don't worry > about that for now. > > Note: "Specification Required" does not imply IETF specification. > It could be any SDO, and many other entities that might publish things. > First Come/First Served requires no document at all... just ask IANA. > RFC Required does not imply standards track. > > see https://tools.ietf.org/html/rfc8126 > > > # IANA Considerations > > This document creates a new IANA Registry called > "CELLAR EBML Element ID Registry". > > Element IDs are described in section {{#element-id}}. Element IDs are > encoded using the VINT mechanism described in > section {{#variable-sized-integer}} can be between one and five bytes > long. Five byte long Element IDs are possible only if declared in the header. > > One byte Element IDs are numbers between 1 and 126. These items are valuable > because they short, and need to be used for commonly repeated elements. > Values from 1 to 126 are to be allocated according to RFC Required. > > Two byte Element IDs are numbers between 127 and 16382. > Numbers may be allocated within this range according to Specification > Required. > > Three byte Element IDs are numbers between 16383 and 2097150. > Numbers may be allocated within this range according to First Come First > Served. > > Four byte Element IDs are numbers between 2097151 and 268435456. > Four byte Element IDs are somewhat special in that they are useful for > resynchronizing to major structures in the event of data corruption or > loss. As such four byte Element IDs are split into two categories. > Four byte Element IDs whose lower three bytes (as encoded) would make > printable 7-bit ASCII values may be allocated only Specification Required. > Sequential allocation of values is not required: specifications SHOULD > include a specific request, and are encouraged to do early allocations. > > To be clear about the above category: Four Byte Element IDs always start > with hex 0x10 to 0x1F, and that byte may be chosen so that the entire number > has some desirable property, such as a specific CRC. The other three bytes, > when ALL having values between 33 (ASCII !) and 126 (ASCII ~), fall into > this catgory. > > Other Four Byte Element IDs may be allocated by First Come First Served. > > Five Byte Element IDs (values from 268435457 upwards) are reserved for > Experimental use. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > -- Steve Lhomme Matroska association Chairman From nobody Sun Jun 17 08:05:45 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E124130E1B for ; Sun, 17 Jun 2018 08:05:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2eNWWEojGrj for ; Sun, 17 Jun 2018 08:05:41 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F0C130E1E for ; Sun, 17 Jun 2018 08:05:41 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id r21-v6so6403365pgv.4 for ; Sun, 17 Jun 2018 08:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SmO/ls4/GVjEWfF5vWynMfOl+gKYuiIJHZVp+nrPI0o=; b=Rv0pm+0Y0DmkX9nUE8bqbL6kw1Fagcmg8pQXJgyHTRQjgJvElQpxJ9H4Fck0gsb7YJ 7aPN4foe+9IGOCqxL/T21pBF6KYlzEV1e4VM6cCunAOvc/TPTlrUUiBjs913W5loY+QQ q9tFUoKGnEZ33+Z0GIWiSHu5ji9NiXq5Mp9+FPErXwYeFGEb5Vrl14f+owL/smumA76H F4RqnyYlYM1GfsnKnJJlxNMAXmJueKN3C6swV6eSlvXH/k2D30kHwRmYkGFV0wx1Vftx 7T9H6G2y1zY9mSqddz30nbhd+nbGLHM8BIjGntYrcVc7jdHBGfYr/FRHMHptATMpXOaX nU7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SmO/ls4/GVjEWfF5vWynMfOl+gKYuiIJHZVp+nrPI0o=; b=VrIaFeaKaHdepmDt49FtVDKCNPXqN8/BkTyfpfvXCVTy0l+iaT3KRW7KFGsSa7f5Vl sTEH4MlSfxcWFvMz0Ea0TA5fBZrW7lLjAnXBzVwxewJJwX15Ge7BvneP7aJjsfG8gOjc qzMfVzvc76knb9JYZ0xzBnkyBWIAsjSFsVGGslISDTswGNN0txbY9qgolT62GRbQReCa oAH0uTmMqpfyZ6ONnhNxxuKyCjqFJfmqnnD5bizsoBjMUjV2B5YiQ4kyFWhKVg9p/5J0 ptjFrpDIuU8FJfGgJW+D6E403NJSJL8s6hbywvpZK+XkJ8SAzdfK6MRZ5Pb29wa+wQsJ aKkQ== X-Gm-Message-State: APt69E19Tw76O2ffBAjD5VRgkYeasg40ekQlAPxlLcZ3SdKCVPcHMgTe Xt3tDIyEM8RuJTgw9/Ua+tasC0ZDOazmUE2wE0S97Q== X-Google-Smtp-Source: ADUXVKLdI6lvlMd01o7SBwQLRNUyAetBYWnssLdcaLgV+gajmgCUNBaEIuOvfpe8hyLMd2/O2R2NOlGC6JuRLky3Svk= X-Received: by 2002:a63:9b19:: with SMTP id r25-v6mr7912307pgd.197.1529247941006; Sun, 17 Jun 2018 08:05:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:9a5:0:0:0:0 with HTTP; Sun, 17 Jun 2018 08:05:40 -0700 (PDT) In-Reply-To: <2581.1528390679@localhost> References: <14348.1528336161@localhost> <2581.1528390679@localhost> From: Steve Lhomme Date: Sun, 17 Jun 2018 17:05:40 +0200 Message-ID: To: Michael Richardson Cc: Dave Rice , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] VINT_DATA of all ontes X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 15:05:44 -0000 2018-06-07 18:57 GMT+02:00 Michael Richardson : > > Dave Rice wrote: > >> Additionally, > >> an "Element ID" with binary encoding of "1111 1111" is invalid sin= ce > >> the "VINT_DATA" section is set to all one values, whereas an "Elem= ent > >> ID" with binary encoding of "0100 0000 0111 1111" stores a > >> semantically equal "VINT_DATA" and is the shortest possible > >> "VINT" encoding. > >> > >> It seems that there is a prohibition on VINT_DATA that is all ones= . > >> I can't find a place in section 6 that says this. > > > Just before your quote, I see: > > > "The VINT_DATA component of the Element ID MUST NOT be either defin= ed > > or written as either all zero values or all one values.=E2=80=9D > > Ah, my eyes missed that. > > Could we split this into three paragraphs, and can we add some explanatio= n of > why all zeros and all ones is forbidden? In general do why want to explain why this or that technical choice was made ? It doesn't seem to be the case in the RFCs I know and might add considerable work. If it's just for this particular case it can be done. > >> Is this a restriction on > >> all VINT_DATA, or just ones used for Element ID? > > Would the WG like to simply skip allocation of Element IDs values which > would be all ones in the appropriate encoding? Clearly, one can go to th= e > next bigger VINT size and express it, but it seems like skipping that val= ue > is simpler. I believe that my suggested IANA Considerations text on > this value does that. Should the IANA part restate the rules on how the IDs should be understood and what is/isn't allowed ? Or maybe we can just put a reference to the section about EBML IDs ? > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Jun 24 06:30:29 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0CD130DF2 for ; Sun, 24 Jun 2018 06:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCE_6Sg1mhkR for ; Sun, 24 Jun 2018 06:30:25 -0700 (PDT) Received: from mail-pl0-x243.google.com (mail-pl0-x243.google.com [IPv6:2607:f8b0:400e:c01::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56C071277D2 for ; Sun, 24 Jun 2018 06:30:25 -0700 (PDT) Received: by mail-pl0-x243.google.com with SMTP id m16-v6so796297pls.11 for ; Sun, 24 Jun 2018 06:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=dfAxzC8T7ibxGLkYFtwPBIGMyphwzpG6/P4OiCUJtvo=; b=w9ahtoo3rCfJ+Fcj8Yf8LfI5EvkaF1bgYG+gpSNEG2v1QPaA5mdEcbDRAgdgXIXp3e yLeZMss3DVwXEIuoERiS3YV5N/EY2C8tgCwtGuwYJaavAXB2o4du5ECAKuBz+/lLqij8 kriGALl9DhTn0VYOJyKPcUhRxo4tOLwFXvP4rEPU0yBA1t9SuvCYjHBaLqghBPizgHGx F4hP9FeVHOfxU+M0JZMm6ZhQtSfpIzw+UcfpNy2gUcTXCmFhGrEMpHiGjCjwHtgQcFN7 9D4UPqKRUMzPB+hORRXsSIaIdfd/x0aDBnKpCVNkI978QjVsD4+kV3hcsMnpu4jiJQAy 8v/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=dfAxzC8T7ibxGLkYFtwPBIGMyphwzpG6/P4OiCUJtvo=; b=buos5zdQfhkWI/inyUkFTcixhly6EQV0zOfw8gNr7HoWLfol3kF8lhdL/gE3ShtBOC 7HnenJf/0LjyQIjXCmgNqsRLu5Ei/UO/fKTIto1tx7ZhSqVvzFD3Uxj28p8duc6OdSx8 gkwrKPUNTR+J8rm3W986zfpQ3YV1KDJq0bx1ejGRp1aUz50pcqYLQ1cAdEDFs2dbIQqg L709wWn+pr3LvbyxE8NbRGIWyo1K3pI/FqF2kbwUs3jKyVVzQ8jQqKi+rcQgCOvXCF24 jXKHM0VVyIVFk5JYP+u8K/L5V2SHtJwZC7YBB2vKkLFr2455ooIuFW5oyayeQS80t8KW DHUQ== X-Gm-Message-State: APt69E24qZXSzO4BzWD3jnhu7oIT/FD7BbBpxZrMUwkxhWVrqo1Behpi rj8Ldz1eUBjU457895TPlS5KqnetQQQuFObJjj+4sad7 X-Google-Smtp-Source: ADUXVKJCgDhGB3p/CGQyTENTwG6N85hQhaWUghWa7TRWYiBmByHidUXVk1NA3RLgnyKX9r9/lbkuqzcGP66tIC6c8VA= X-Received: by 2002:a17:902:2f43:: with SMTP id s61-v6mr8673404plb.274.1529847024511; Sun, 24 Jun 2018 06:30:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:17af:0:0:0:0 with HTTP; Sun, 24 Jun 2018 06:30:24 -0700 (PDT) From: Steve Lhomme Date: Sun, 24 Jun 2018 15:30:24 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cellar] Experimental elements X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 13:30:28 -0000 As discussed in https://github.com/Matroska-Org/ebml-specification/issues/157 We need a clean way to define experimental elements. So that new elements can be added/tested while not having to iterate the DocType version each time. Especially as the they are meant to be backward compatible as much as possible. I added to proposal on GitHub: - https://github.com/Matroska-Org/ebml-specification/pull/180 a simple DocType sub-version that allows iteration between different versions before new elements are finalized in a new DocTypeVersion. - https://github.com/Matroska-Org/ebml-specification/pull/181 a list of DocTypeExtension which allow different groups to work on different subsets of elements, each with their own name (or workgroup or namespace). In any case elements from each proposal don't have to be handled so long as the EBML Reader can handle the DocTypeReadVersion. But if they can, it's nice. Following this concept, I wonder if Tags could exist as a Matroska Extension, possibly not part of the main DocTypeVersion at all. Jerome wanted some extra elements, this could be done this way as well in a clean way. Note that an extension version depends on the DocTypeVersion it's in. So moving from matroska v4 to matroska v5, each "independent" extension should have an update if they want to keep working. Or we could not do that at all and allow extensions having a life of their own. Maybe there could be 2 types of extensions: those which goal is to be merged in the main DocTypeVersion, those standalone. The DivX elements are good examples of extensions that could leave on their own. And we wouldn't have to put them in the main spec and wonder how they could work. On the other hand these old files don't advertise this extension... -- Steve Lhomme Matroska association Chairman From nobody Sun Jun 24 06:32:00 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A84130DF4 for ; Sun, 24 Jun 2018 06:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RbAH3KRXF1BD for ; Sun, 24 Jun 2018 06:31:56 -0700 (PDT) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA301277D2 for ; Sun, 24 Jun 2018 06:31:56 -0700 (PDT) Received: by mail-pf0-x229.google.com with SMTP id a11-v6so5235146pff.8 for ; Sun, 24 Jun 2018 06:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=KwdP3PMmnP6bhvxjuHXX3fFhq+SzFHDZQEudWvOq04Y=; b=oppZajpDp8nwbilRHPVAfRocWxo+vgcyphyfLVjiVn2gb6bWHzO4tb+ZsZtPEgv4sW TXRVwleMAMRj0c3eJR9faIF/Nr7HAd3s/GYAgIFxwVbF0HCZ3c6227jGHRK8yNSAu1sK gG2Fe2BxrgEG9KLRjBWHrggjn8Sg8F96mGzKWbSyGM7TgGqTk6cup3XVise+ZWfiS6tG gZiLFdLD7V1hfJaV58RKaA1Ol6YdteRSxZhEcIrCkhwmqOpYvZFJG8eQlpIDmuLdxuoS Kmw+mw8x4o3RfuEZ0kpCz6n1ph+PaI1qSow9zm29EV64m0or3X7N4czxEA9OlHAYIb1d +y7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=KwdP3PMmnP6bhvxjuHXX3fFhq+SzFHDZQEudWvOq04Y=; b=ClgrQWYuCEl3GazlhVgjaAqjO3sG0yCKmiFgWBbiEXN2Nk5hqojKgivP3Owh8NcV6+ DjoNj/dPxAufnu/Ib7UxGBiy+lnnHmzHOZ2dx+VoY4TPhEREXaeMjLeP2c1nph1ktaCe DERmzLPV5BeQIewPzHVEgrGtZrsSt2FQBSFT4eUadBiWmmFVlGms8/FgdA0yU6aHpW8f TqhpYbQHk3bp4Q22TuRWj5pm3H1NPSvKsnBZXF9fCdMnAum3slSmEIVb9LSXpFbtn2vE oTVtoDZrvauUaMPb+lrzeiDykcivIoK1K0AC4ViglxhjcuHdj5K1aRjTUDNV5hkB7zIT 8BCQ== X-Gm-Message-State: APt69E3rTbar8NrHyCpOYuLZE9VicvsIDeMtOVce+wet2DrmMRtFihxP +jcWnn7OP4Bq6fwmnU51+Vqqsd4Qfw4QaCKZ45tvcg== X-Google-Smtp-Source: ADUXVKL/+UYZRWBMqAaMJxkNLBrzhNLqM4Amor93fPJpOE/K0Px+wsFcJtZo3A2ED3n9EZjW3sbSrdXXHAp2Hdkj8bw= X-Received: by 2002:a62:830e:: with SMTP id h14-v6mr9347034pfe.64.1529847115656; Sun, 24 Jun 2018 06:31:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:17af:0:0:0:0 with HTTP; Sun, 24 Jun 2018 06:31:55 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sun, 24 Jun 2018 15:31:55 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] Experimental elements X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jun 2018 13:31:59 -0000 PS: I apologize in advance but I won't be able to make it to the CELLAR virtual meeting on Tuesday, I have previous commitments to attend. 2018-06-24 15:30 GMT+02:00 Steve Lhomme : > As discussed in > https://github.com/Matroska-Org/ebml-specification/issues/157 We need > a clean way to define experimental elements. So that new elements can > be added/tested while not having to iterate the DocType version each > time. Especially as the they are meant to be backward compatible as > much as possible. > > I added to proposal on GitHub: > - https://github.com/Matroska-Org/ebml-specification/pull/180 a simple > DocType sub-version that allows iteration between different versions > before new elements are finalized in a new DocTypeVersion. > > - https://github.com/Matroska-Org/ebml-specification/pull/181 a list > of DocTypeExtension which allow different groups to work on different > subsets of elements, each with their own name (or workgroup or > namespace). > > In any case elements from each proposal don't have to be handled so > long as the EBML Reader can handle the DocTypeReadVersion. But if they > can, it's nice. > > Following this concept, I wonder if Tags could exist as a Matroska > Extension, possibly not part of the main DocTypeVersion at all. > > Jerome wanted some extra elements, this could be done this way as well > in a clean way. > > Note that an extension version depends on the DocTypeVersion it's in. > So moving from matroska v4 to matroska v5, each "independent" > extension should have an update if they want to keep working. Or we > could not do that at all and allow extensions having a life of their > own. Maybe there could be 2 types of extensions: those which goal is > to be merged in the main DocTypeVersion, those standalone. > > The DivX elements are good examples of extensions that could leave on > their own. And we wouldn't have to put them in the main spec and > wonder how they could work. On the other hand these old files don't > advertise this extension... > > -- > Steve Lhomme > Matroska association Chairman -- Steve Lhomme Matroska association Chairman From nobody Sun Jun 24 23:37:30 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6CD130F02 for ; Sun, 24 Jun 2018 23:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk9oErr85rDJ for ; Sun, 24 Jun 2018 23:37:19 -0700 (PDT) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E603130EE6 for ; Sun, 24 Jun 2018 23:37:17 -0700 (PDT) Received: by mail-pg0-x232.google.com with SMTP id c10-v6so5638615pgu.9 for ; Sun, 24 Jun 2018 23:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=4mXn4mQC/i7GVf6kIjR0meGqDduDe/ir7gTRphCdfN0=; b=YuOJ66VM6/8MB6pggyII8UosS4EnFKS4XEpyeltdrCVMi5FsnRgTAmmHhBAqvkx5m+ lVr406XSpAGDAFZlKdrZ2VjuqjTpkSgBBUIOiSwXVqrQDh4dpuMff3qvnzumtJRgBaB9 K5o2qyZj9vIiHK1Y/QhIuIaSkhRIywQTcLtftW59koXbVEvbrqDwXk6B8OGJ8Ns0XYfr 1+Le8TfSWr/PmwAARkxbf7JN6YOFKR4FDKSQwaGI/R2+NdWD9X0FtYzdrYc0MdcoGK43 LY0KNMGJjFlrD/55T3SQejqtPBjjD1DK0DmU9dae6Ghi3M5kq4hEKVT3sW/fp1mPMVSE YTjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4mXn4mQC/i7GVf6kIjR0meGqDduDe/ir7gTRphCdfN0=; b=OQT2IH4Tybsn6NmL1GYxKJhztoYXSm3l7PrQF8jcBb5yhP0Pvz70/9fEac6Dl7xzOo FAFPdMm+OiXyrUbGSvoX7SjgCwbcgzv4driVSJ1h3RtBRCXpHHk57t80ufYTmgVjIzw2 9JZY7V9Y8/CkChE19bURMQXvew+UYoAuKGYQDjxoSqq+w9Vwfyes9XNxEOGUBsgOEtLz H6B/td+oypys7J4BOXT+h9PNJg22e63tE+8fdppbBPkewfOEcJfgxlfuqd5L/6nIs8kc 2cDmbmkGxkStG0wXKgn6vrmSYRPSYZFFc+LwwgxEGafSclPEILNKYLBHqGYLYdx/z4pa 04pA== X-Gm-Message-State: APt69E3nXwZ67ZQVPyzYSCwEyyiaBhCGMdUKJnzyZzanaATNJNjgWSc0 6fnHGyrESMRu7hjU6N7YF4NqqAcl3fNCfEneVOh475oB X-Google-Smtp-Source: ADUXVKICXoXXiY9pwA/FCxoVQDTueiAacImbpbNKlJmHs/y+43JnYltnO8euuWk9U8Hm2YuW2w2M+Ji4lk44Erer6k8= X-Received: by 2002:a65:45cc:: with SMTP id m12-v6mr239760pgr.160.1529908636616; Sun, 24 Jun 2018 23:37:16 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:17af:0:0:0:0 with HTTP; Sun, 24 Jun 2018 23:37:15 -0700 (PDT) From: Steve Lhomme Date: Mon, 25 Jun 2018 08:37:15 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cellar] Format Additions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 06:37:28 -0000 As we progress with the specs, new ideas come up to improve EBML and Matroska. For now we are supposed to formalized what exists in specs and then move forward with new format additions. That means we should work on EBML 1 and Matroska 1 to 4. The proposed EBML extensions is one addition that's actually a big can of worm because we need to take a lot of things in consideration, like explaning how to define an extension externally (similar to defining a DocType but maybe with some tweaks). IMO this should go in EBML 2. Also we don't want to delay defining what currently exists to add a new idea, however good it is. The proposal for the next version of each format are marked with a tag "format addition" for Matroska https://github.com/Matroska-Org/matroska-specification/labels/format%20addition and EBML https://github.com/Matroska-Org/ebml-specification/labels/format%20addition These links include both issues and PR. -- Steve Lhomme Matroska association Chairman From nobody Mon Jun 25 00:40:02 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9558112F1AC for ; Mon, 25 Jun 2018 00:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBw5GPdoGWDQ for ; Mon, 25 Jun 2018 00:39:59 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2651A129619 for ; Mon, 25 Jun 2018 00:39:58 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w5P7duQR020254 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Mon, 25 Jun 2018 09:39:57 +0200 Received: from Castor.local (dynamic.wline.6rd.res.cust.swisscom.ch [IPv6:2a02:1205:34e2:bed0:e9a6:a743:36fb:af62] (may be forged)) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w5P7dsbC001857 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jun 2018 09:39:56 +0200 Date: Mon, 25 Jun 2018 09:39:56 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) Archived-At: Subject: Re: [Cellar] Format Additions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 07:40:02 -0000 Steve Lhomme wrote: >The proposed EBML extensions is one addition that's actually a >big can of worm because we need to take a lot of things in >consideration, like explaning how to define an extension >externally (similar to defining a DocType but maybe with some >tweaks). IMO this should go in EBML 2. +1 >Also we don't want to delay defining what currently exists to >add a new idea, however good it is. +1 Thank you! Best regards, Reto From nobody Mon Jun 25 11:17:57 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953C2130E12 for ; Mon, 25 Jun 2018 11:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JvvAYyqRwPRm for ; Mon, 25 Jun 2018 11:17:52 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44EB130E1C for ; Mon, 25 Jun 2018 11:17:51 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 520A220090 for ; Mon, 25 Jun 2018 14:32:22 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 8926E1778; Mon, 25 Jun 2018 14:14:45 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 86FD971 for ; Mon, 25 Jun 2018 14:14:45 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] agenda for June 28, 20:00UTC X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jun 2018 18:17:55 -0000 --=-=-= Content-Type: text/plain https://datatracker.ietf.org/doc/agenda-interim-2018-cellar-02-cellar-01/ Sorry that the agenda took so long to get posted. I will be a few minutes late joining the call, please start without me. CELLAR -- Agenda for Virtual Interim Meeting June 26, 2018 INFO: https://datatracker.ietf.org/meeting/interim-2018-cellar-02/materials/agenda-interim-2018-cellar-02-cellar-02 WEBEX: Meeting number: 313 505 170 Meeting password: dq64cWsm Meeting link: https://ietf.webex.com/ietf/j.php?MTID=me21026faa14be85507cdef66b860014e Host key: 763872 Audio connection: 1-650-479-3208 Call-in toll number (US/Canada) Agenda: 1. Note Well. 2. Draft minutes from Last meeting 2. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.tools.ietf.org/p/notes-cellar-virtual01?useMonospaceFont=true 2b) Roll call 1) need to get WGLC issued for EBML - waiting for new draft with IANA considerations. 2) open issues on ffv1 to get to WGLC. a) response to SecDIR review b) expecting other review by June 30 3) updates to milestones https://datatracker.ietf.org/wg/cellar/about/ see end of page. We need a realistic set of dates. Proposed changes: Aug 2018 Submit specification for EBML to IESG (Standards Track) Aug 2018 Adopt flac and matroska specifications as WG documents Oct 2018 Submit informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication draft-ietf-cellar-ffv1 Dec 2019 Submit specification for FFV1 video codec version 4 to IESG (Standards Track) xxx 2019 Submit informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication xxx 2019 Submit specification for FLAC audio codec to IESG (Standards Track) draft-xiph-cellar-flac xxx 2019 Submit specification for Matroska container format version 4 to IESG (Standards Track) draft-lhomme-cellar-matroska -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWzExEoCLcPvd0N1lAQK0EwgApyXVuf5aaSy7/u8Wc2iMJYBsjwwaxrqK E5lw3nZ4rmNJW/tX1IsKHY7AglwdPhngBN7GM8MyI3icKSkd9z7vEisYsc7A9sh/ hGS7gQKZyFAaaapYIhoFGO+8+sCN6ia+dwWyVHbq6BH+7Q0nLOUr6oPW7YS1u7gn dMM5ehHb5YjrgVhKP+0ztdBUhR5p2/lwKHAqmV1o4H4sxHyru5r6UFpsqDfuqxLA CYjshrZN9onsa7rhdFdlgDhOnmErzn9nC/OmL1UoRmAtisuKi7s/+PXVUMzua+Er xc6HG/fuPIBTO52/cik6cfrvRxscrYgknF/e5+3B2JadZ5iXF0JdjQ== =I9r3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 26 05:15:15 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89273130DC2 for ; Tue, 26 Jun 2018 05:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.102 X-Spam-Level: X-Spam-Status: No, score=-0.102 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdRpjWC4VlGm for ; Tue, 26 Jun 2018 05:15:12 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A4D612F295 for ; Tue, 26 Jun 2018 05:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2017070101; h=Content-Type:MIME-Version:Message-ID:Date:In-reply-to:Subject:To:From:References; bh=xCVn46g1HpDd1PxbWKj6OfCsBsaRgXzqhFhjfUwXJsE=; b=T9k7TEC9j+BCPMQnUx0Q9K0K9p4/VUyxh/QqdSV82I+vhvi9mRQXHsE8yivyVNFbXu6Nw+ay9aPV50n0Z5EdM69ZF5EbPu6fg6EZM53JDYXYdhhaYCh0zNe8t1x3xBDiqU1f6w08z+ppDn4+agFFraDFvmDc9djMxUsy+RnntxVkWCqRsDufPHuDnvBKe2ZR80Yt6KYeqq71v4B5cB9E1OMj1zvYv11k4cFnZt0XBGaVINzf4P+/N3zFH5uyiHPGDZYArE+nHJghfq8M8dQqufgC5JRIRw9L1aveKxz3JBeDLm6x+wdwkerQ+3/UELUBuZvwcEmVMVQac/3eCdzCu/KDAksyfVQsgIIM51NdhFLbUifxhckqtJPYFu8g/+BD9LvrV7tJhj+75EiEFF+sp2ThEHINjeOAGtw0xCJw7REMqv2h4CA/Tbbozo5D0N7vxtz88LbsK9HrByoi5jkRPlIEcol2Nt+VFSARItlbosGaskagorLHIdoy6373m9+Ao2saevTUXP9pW0Sw9+CSaqDZUYj/igz9nI/RgijhK/YiGw1/Pl2G5HxM47Aux3hd5QX9tfUFRDSRssYBcCAPpQPGbwUTzO/6rC6TcyJ45+TjyQYRJ+ixWujzUpfamn78dOumxcI5yzWI7AfuIlpyy0Kzh6zmhV0Vv+j9Z11njt4=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:58956) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1fXmsC-0001Nv-37 for cellar@ietf.org; Tue, 26 Jun 2018 14:15:05 +0200 X-Virus-Scanned: amavisd-new at bunkus.org Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id AC87D654156E for ; Tue, 26 Jun 2018 14:14:58 +0200 (CEST) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id A99CD3BAF308 for ; Tue, 26 Jun 2018 14:14:57 +0200 (CEST) References: <12259.1529950485@localhost> User-agent: mu4e 1.0; emacs 26.1 From: Moritz Bunkus To: cellar@ietf.org In-reply-to: <12259.1529950485@localhost> Date: Tue, 26 Jun 2018 14:14:57 +0200 Message-ID: <87o9fxeoce.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] agenda for June 28, 20:00UTC X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 12:15:14 -0000 Hey, I won't be able to attend tonight due to work :( Kind regards, mosu From nobody Tue Jun 26 08:42:42 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A46C8131038 for ; Tue, 26 Jun 2018 08:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8udaSQ_4ElI for ; Tue, 26 Jun 2018 08:42:38 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CAC8131047 for ; Tue, 26 Jun 2018 08:42:37 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id l65-v6so7798687pgl.8 for ; Tue, 26 Jun 2018 08:42:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=AOivPGjx/0n1ZyCmibC40ChIDyBr4bR0VEnj4uI3Mpo=; b=NTKjf7iScHThu44Ddql8ARXrrFyvQ4guo+ACxFgncYo1Byt5b4njokMlw22+g48Vv/ rXI2+otp36hk3B6QWtLFeKR2cv+n6bxeVrXQ5u+gyKVcghD3e0uXD7wgNI0S2WTQtSJB GOEoHLXMleyy3i83BGp+aIPLq7dmAsjbM0fTSxLGt31t8pwmwOkL/qtBm0UPkreg6D7X u7VqS2oKUAT0FsS1864yDuUfGqFKy7L2gnADeGsnctyCh2NVACpzi9FdpDIEGFPxsFXk 1K7xl022kdcVTHq/MrLyLGKGrq+ieIoK8HT2s4qTrNuml2jgqkV76fQjFRNIYvXEymmn zItA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=AOivPGjx/0n1ZyCmibC40ChIDyBr4bR0VEnj4uI3Mpo=; b=j9n2pwyHUlhksnlkmhnGwX87D2thkum6l33dlBs3qEan58Ez/DQMiI0QPJs2Y4EyUS wyGo58DMKYLRl4HWjDRd0Pnk5JRQtW2HjohQ1JZsaft01VhztEn1ZY2+YV/Hqk79FGDU T3WrXYFmFSYFH/jS5zJrIutRMwGTA6G3WSHAa3khXYQxS0CNad708wf1UBrCRZE4+8XI +tw5bxuPVifVDsPYaun+lnsIhhkEcR8jvQMTGUNEpK3COWgHtv5y3wzj601qjiE4MqRd lxfWqd4PVT7XMJDnlp1TMtTsZzKRhSZskjA1qdBhOVBRsoAgWxxE1kO9fwC76VjznpC8 rZAw== X-Gm-Message-State: APt69E3OVHRKIhZj04rFbFio2OAcyjzFnF7TR1ejGAToh2GAe3fJGef5 xJcMTHDpBprhf6JnhwrBhl/EEqErqWHOhKMjD25n2Djw X-Google-Smtp-Source: ADUXVKIqhB2k6B8LAYaa9pOZtCEq1/oSQTKlQ7iAE2tsHssxMTes6I1YT6Zbh1QkXQw71edDp5CxuBUM9GaaDx2Q41U= X-Received: by 2002:a65:45cc:: with SMTP id m12-v6mr1874934pgr.160.1530027756802; Tue, 26 Jun 2018 08:42:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:17af:0:0:0:0 with HTTP; Tue, 26 Jun 2018 08:42:36 -0700 (PDT) From: Steve Lhomme Date: Tue, 26 Jun 2018 17:42:36 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cellar] AV1 mapping Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 15:42:40 -0000 Hi, I drafted a document to specify how AV1 should be stored within Matroska. You can find the document here: https://github.com/Matroska-Org/matroska-specification/blob/av1-mappin/codec/av1.md It may start as a basis for how we define (extensively) other codecs. Let me know if it's readable for people with no knowledge of AV1 and for people with knowledge of AV1. Some parts marked inside {} are not finished yet. Especially the encryption parts. For reference the MP4 mapping draft can be found here https://aomediacodec.github.io/av1-isobmff/ PS: it seems AV1 has new "standard" values for matrix coefficients and Primaries that we could borrow for Matroska. -- Steve Lhomme Matroska association Chairman From nobody Tue Jun 26 13:18:34 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB41130E37 for ; Tue, 26 Jun 2018 13:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rq5uDbV7_i7X for ; Tue, 26 Jun 2018 13:18:30 -0700 (PDT) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B318130E2C for ; Tue, 26 Jun 2018 13:18:30 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 47A66C02C3 for ; Tue, 26 Jun 2018 20:18:30 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgI3c8Ysxmbw for ; Tue, 26 Jun 2018 20:18:30 +0000 (UTC) Received: from [192.168.1.4] (pool-71-171-120-79.clppva.fios.verizon.net [71.171.120.79]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id D78B2C00B7 for ; Tue, 26 Jun 2018 20:18:29 +0000 (UTC) To: cellar@ietf.org References: <12259.1529950485@localhost> From: "Timothy B. Terriberry" Message-ID: <922899f0-f009-bf04-5465-63bed18ed48a@xiph.org> Date: Tue, 26 Jun 2018 13:18:29 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 SeaMonkey/2.49.7.0 MIME-Version: 1.0 In-Reply-To: <12259.1529950485@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] agenda for ***June 26***, 20:00UTC X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 20:18:33 -0000 As Dave Rice just pointed out to me, the subject of this e-mail said the interim was on the 28th but the body (and the schedule we had drawn up before of the last Tuesday of each month) said it was on the 26th (today). Apologies the confusion. Since we only had two people show up to the call, and we wanted to make sure we had the right people to address the issues on the agenda, we decided to cancel and will attempt to reschedule. From nobody Tue Jun 26 16:37:49 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0F6130E6B for ; Tue, 26 Jun 2018 16:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3NdRZ9PVV9px for ; Tue, 26 Jun 2018 16:37:44 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA423130E61 for ; Tue, 26 Jun 2018 16:37:44 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 83DE820090; Tue, 26 Jun 2018 19:52:20 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 852E81C1F; Tue, 26 Jun 2018 19:34:38 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 826431C1E; Tue, 26 Jun 2018 19:34:38 -0400 (EDT) From: Michael Richardson To: "Timothy B. Terriberry" cc: cellar@ietf.org In-Reply-To: <922899f0-f009-bf04-5465-63bed18ed48a@xiph.org> References: <12259.1529950485@localhost> <922899f0-f009-bf04-5465-63bed18ed48a@xiph.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Tue, 26 Jun 2018 19:34:38 -0400 Message-ID: <19782.1530056078@localhost> Archived-At: Subject: Re: [Cellar] agenda for ***June 26***, 20:00UTC X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 23:37:47 -0000 Timothy B. Terriberry wrote: > As Dave Rice just pointed out to me, the subject of this e-mail said the > interim was on the 28th but the body (and the schedule we had drawn up > before My bad. From nobody Wed Jun 27 01:32:12 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E668612872C for ; Wed, 27 Jun 2018 01:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BvRdZFUS4gK0 for ; Wed, 27 Jun 2018 01:32:08 -0700 (PDT) Received: from 18.mo7.mail-out.ovh.net (18.mo7.mail-out.ovh.net [188.165.56.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D8401277D2 for ; Wed, 27 Jun 2018 01:32:07 -0700 (PDT) Received: from player715.ha.ovh.net (unknown [10.109.122.46]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id C10F6B3B92 for ; Wed, 27 Jun 2018 10:32:05 +0200 (CEST) Received: from [192.168.2.120] (p5DDB49E4.dip0.t-ipconnect.de [93.219.73.228]) (Authenticated sender: jerome@mediaarea.net) by player715.ha.ovh.net (Postfix) with ESMTPSA id DCF8B1C00D3 for ; Wed, 27 Jun 2018 10:32:01 +0200 (CEST) To: cellar@ietf.org References: From: Jerome Martinez Message-ID: Date: Wed, 27 Jun 2018 10:32:03 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 5441474251973464209 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 49 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtiedrudejgddtiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecuogfuuhhsphgvtghtffhomhgrihhnucdlgeelmd Archived-At: Subject: Re: [Cellar] AV1 mapping Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 08:32:11 -0000 Hi, On 26/06/2018 17:42, Steve Lhomme wrote: > Hi, > > I drafted a document to specify how AV1 should be stored within Matroska. > > You can find the document here: > https://github.com/Matroska-Org/matroska-specification/blob/av1-mappin/codec/av1.md > > It may start as a basis for how we define (extensively) other codecs. > > Let me know if it's readable for people with no knowledge of AV1 and > for people with knowledge of AV1. It is readable, at least for me, as a person who implemented quickly the parsing of the AV1 sequence headers. > > Some parts marked inside {} are not finished yet. Especially the > encryption parts. > > For reference the MP4 mapping draft can be found here > https://aomediacodec.github.io/av1-isobmff/ For me it is important to use same semantics that in ISO BMFF, easier for encoders and decoders. > > > PS: it seems AV1 has new "standard" values for matrix coefficients and > Primaries that we could borrow for Matroska. Nothing new, they use up to date H.265 values (which are de facto already in use when muxing H.265, with such values, in Matroska). Jérôme From nobody Wed Jun 27 01:38:09 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72ED12872C for ; Wed, 27 Jun 2018 01:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbIBLr6News6 for ; Wed, 27 Jun 2018 01:38:05 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C5231277D2 for ; Wed, 27 Jun 2018 01:38:05 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id z1-v6so615474pgv.12 for ; Wed, 27 Jun 2018 01:38:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=WYEvPHiTvR6cPtPrxmK118dF7XBS2ezSIBYzkUcbDow=; b=AxD8aLcgScxOWJTqs/OYCUamKVytnX3VMa2i5EGsh4WUV4+Yk+jQL+6k9vdGgKWzTi Jq/tOxHEStd5TD7GLkkYuAX8DhI7+gue8MB4DZHivR8diJysMx/hz7pxoClACTEF9a4l pbCAAsiCaVoYHFO9gk79lMZ+vOzpf6D/V5UsWne48mirGW+oBhU20nxlsBn91qBC7GxC yYSkWRiW/P4wFccharAgOca82nyeujqrGTzNhEWyjflzt6QNfV+r5YAPN9uNPdEMXTke 2RLIpB8BxPdCdKk07ys0ALjnYnLvAe0pwE/b9InD19pwXiAdsxEF4/QmsMb3ZAxulI8c +tBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=WYEvPHiTvR6cPtPrxmK118dF7XBS2ezSIBYzkUcbDow=; b=lqs7+p1d/3baDnAMQP33O4t3mrybXqesDBWEVQwmRHm0B7lhzHnHc4RWyR5I7T7FPU x75hUdl1MTQY3JXIyJumOsawzgCcyDwIzd4Kft3nXQ0bEgQFZehJ8YhmueeHZyrv1kPI HHrUWty1Cuwx5LPwVANYjhsDw8m2MJKb5kL5I0RTgINDp4u/7wKj/ntHpOa2LmjvN9mS gak8BWf4X7LfoPQPZVCmnH6qWc2G9dFWgO9sOM9yTL1TqSMQc0trtaA5tRSPEdYqN8Lr I3XBTXxsSSp+CEcjmX43f4WnfCyng0W3ow4v9NMRCg7DCr6rpPRhZ/G4Ak/vgDyrjpAM xeDQ== X-Gm-Message-State: APt69E2W9EjfrJGu5f7sFooslfpmE3oArrjIQARes4nryfwplrRIOVDy xiBJCJlbUQ8UUWzJBFqR+0qb4RIYpe/HxS6U04cUow== X-Google-Smtp-Source: ADUXVKLUgAKYClstG+cI4tQkan4EWOgkb40UQ1UHYf7WEh2BHAhnJjo/7n+AVN/WNWIdBRaD3ZSKGyKN+langbUeivs= X-Received: by 2002:a65:5307:: with SMTP id m7-v6mr4439777pgq.431.1530088685071; Wed, 27 Jun 2018 01:38:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:17af:0:0:0:0 with HTTP; Wed, 27 Jun 2018 01:38:04 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Wed, 27 Jun 2018 10:38:04 +0200 Message-ID: To: Jerome Martinez Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] AV1 mapping Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 08:38:08 -0000 2018-06-27 10:32 GMT+02:00 Jerome Martinez : > Hi, > > On 26/06/2018 17:42, Steve Lhomme wrote: >> >> Hi, >> >> I drafted a document to specify how AV1 should be stored within Matroska= . >> >> You can find the document here: >> >> https://github.com/Matroska-Org/matroska-specification/blob/av1-mappin/c= odec/av1.md >> >> It may start as a basis for how we define (extensively) other codecs. >> >> Let me know if it's readable for people with no knowledge of AV1 and >> for people with knowledge of AV1. > > > It is readable, at least for me, as a person who implemented quickly the > parsing of the AV1 sequence headers. > >> >> Some parts marked inside {} are not finished yet. Especially the >> encryption parts. >> >> For reference the MP4 mapping draft can be found here >> https://aomediacodec.github.io/av1-isobmff/ > > > For me it is important to use same semantics that in ISO BMFF, easier for > encoders and decoders. Yes. One of the things the currently differ is in CodecPrivate I didn't prefix with the presentation_delay bits. It sounds like this is something we should parse and adjust our timestamps with. It's either TrackOffset which is currently marked as deprecated for all versions (ie never used) or CodecDelay which is an unsigned value and MUST be substracted to the Block timestamp. Except it seems the AV1 presentation delay should be ADDED to the timestamps. I will dig deeper but we may have to tweak CodecDelay to make it signed. >> >> >> PS: it seems AV1 has new "standard" values for matrix coefficients and >> Primaries that we could borrow for Matroska. > > > Nothing new, they use up to date H.265 values (which are de facto already= in > use when muxing H.265, with such values, in Matroska). Ah, I looked at matroska.org not the RFC specs (yet). > > J=C3=A9r=C3=B4me > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Wed Jun 27 01:59:06 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4C1130F36 for ; Wed, 27 Jun 2018 01:59:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zuwtu6_jEnfK for ; Wed, 27 Jun 2018 01:59:02 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCFAB130EC6 for ; Wed, 27 Jun 2018 01:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2017070101; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-reply-to:Subject:To:From:References; bh=8mW99HBEf7T6M8sbqZwfHjfqSwk5P9jBRwmZZRCRouU=; b=MSYmyINilo1wOeNqYXmmH5aVCfTzUZZVkvNJaogL9hJ+7KTpJzUGfTQI9ZENYLzded715zAJXXqQbdfszGfEWqWfYOf/PBYG7ny9tIrRjjeb7PxhJxblU5cA1OXkwLF1q+5OmUv5LU8mMJPBro2TFf8G/xVi2WePCaBlJRKGWkCb1Kdwn1VwtwD8Tv9HIvE7yCXQLW4CmBeqXUNF9lXaWe2saR5DH8XHoLjJOoFYvk5gBi+xgzb5r1VHRykGR+33ihL9tCtbmQKZVck1BiRozZGHpj/3SCamCr/4fnOe0Of2nNHa+JuvXM1CNhdCe9iPNFc6zFhWZ1mGNCnqOyI1pjt9L7UigOW3kuGRvGprTcoyQv0cl2LEobBjt9B7+U8bRV8RHaPVsV+/pA5UzoifPUrZcuRTf2RAajwZopR8Kmgc9TNC8BZ7I1DJiN0W8s5wqw7A+poGYrsrBGKX+PhLpIa+FpTKOeYdV0A+hiS3A8jqpHOYfr1u83PrN9C14JVpVXKiMteNqlWa4J0UgHDsAY+2ZGk2TUctmuaMtHXCTa30ec6d1XCGzKeYK0zq1nIgQUvCgVs7KKyJ+aiFKgW6L+T8D59isChg07Q9Et26/RHnVlD4uwoX+5+s02GFEDQ2mU92iry/FI3GVBE1yrmJBWYWZaavlHvOh1m6yM3qxuQ=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:49464) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1fY6Hz-0005T4-0N for cellar@ietf.org; Wed, 27 Jun 2018 10:58:59 +0200 X-Virus-Scanned: amavisd-new at bunkus.org Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 3C6A16541590 for ; Wed, 27 Jun 2018 10:58:53 +0200 (CEST) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 933C53BB6C38 for ; Wed, 27 Jun 2018 10:58:52 +0200 (CEST) References: User-agent: mu4e 1.0; emacs 26.1 From: Moritz Bunkus To: cellar@ietf.org In-reply-to: Date: Wed, 27 Jun 2018 10:58:52 +0200 Message-ID: <87lgb0ehbn.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] AV1 mapping Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 08:59:05 -0000 Hey, I've only had time to skim over it. It's definitely understandable. For me the most important thing is to have the mapping in Matroska and WebM be identical. As the reference encoder already produces WebM files, I highly suggest we communicate with their developers regarding the mapping. I cannot find a document for AV1/WebM bindings at the moment, though=E2=80=A6 > I will dig deeper but we may have to tweak CodecDelay to make it signed. You cannot change the type of an existing element. It would potentially break the interpretation of existing files created with the old semantics. Let's take the value 144, which as an unsigned EBML integer would be stored as 0x81 0x90. If you read that back as a signed EBML integer, you'd get the value -128. Kind regards, mosu From nobody Wed Jun 27 02:30:46 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D909F130F49 for ; Wed, 27 Jun 2018 02:30:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j96lylOWd-3h for ; Wed, 27 Jun 2018 02:30:42 -0700 (PDT) Received: from mail-pl0-x229.google.com (mail-pl0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E7F130F40 for ; Wed, 27 Jun 2018 02:30:41 -0700 (PDT) Received: by mail-pl0-x229.google.com with SMTP id m16-v6so766068pls.11 for ; Wed, 27 Jun 2018 02:30:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=VAbC9DnO2qFxmo7a/O1cUOa6HIl3tMGa4qvorquZXKQ=; b=Rk8WzeP2V/cYGVAcEwgmC13amRvom8GDXBZEHoFWLgQGzteaMpMHejv1h+fpm/U+h5 eEGHURncJ1n7wVBb2poCgRgrvMypOzgP4xQ4oZtCz1/NgO5MZOLzrWm7mUGf3S3vRWk9 880zmUd4397cA2UoXlXHFhMOROYvvCMWDniQR6ui2slkZk3SVe1bPlOCFY3YUosObygk 3Ema7bNKTmPEnBoWcH4QtOxXCuk5h7bVp4mpOGvTm7pjjEfY3/tYanOKvu7ZEc8UJd7M Nld8IBdm0BfxE320yWVHLPX8Wg1pYu8SU4HthLMslBW9Mtro1JDaw5J0CybLKmDP3rQM ozHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=VAbC9DnO2qFxmo7a/O1cUOa6HIl3tMGa4qvorquZXKQ=; b=a4Qc+Y9qjHiNyA4Zb3gDdpiH4DlXYRhhuZFhYDM2It01+lQCjFz5urYn4uVPhFpIKn XRdH4mrzIw4FZapYv1itebcQ/xPhrf9oVJIjkAkFrFhUBZQW481wuZvNC4/ZzmTr9x3Q vCgC4UO/SJoYeTe3k6o4poZEYKeR8pERh/kNUoTWbdtYhwnj5fJQMkQA7K72MZ90tb/t uWHUaWu69ubY+R40yg3aTjUcSEhjWhFjgIw0zuT3/3PAnd4nddsxofdOoZW+vFVHnPkw Jea7M1kEyzoXRaQ1NCc3BaziZa2D3t/gxFL1TfV4UrYnmJXx88nNSq7Iv/w3ymn+CPmD 75sQ== X-Gm-Message-State: APt69E3iAYpexlIr2BJUtsphRQ7O7dsvjFvcjYB6dlq+Xk5rVd+1MytE UwshNIfXRUCcu8ad80eULUKhG1Z/zgn6VAb90AEb2A== X-Google-Smtp-Source: ADUXVKJdRNZBhCaG/WSbMnkM58yJD80184M607yf4TVbSah5dbY5yDPsbZAkrj/SSlk7PZ55ECoLmMyGcXSLwvg+p6M= X-Received: by 2002:a17:902:bd95:: with SMTP id q21-v6mr5255506pls.237.1530091841376; Wed, 27 Jun 2018 02:30:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:17af:0:0:0:0 with HTTP; Wed, 27 Jun 2018 02:30:40 -0700 (PDT) In-Reply-To: <87lgb0ehbn.fsf@bunkus.org> References: <87lgb0ehbn.fsf@bunkus.org> From: Steve Lhomme Date: Wed, 27 Jun 2018 11:30:40 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Cc: Frank Galligan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] AV1 mapping Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 09:30:44 -0000 2018-06-27 10:58 GMT+02:00 Moritz Bunkus : > Hey, > > I've only had time to skim over it. It's definitely understandable. > > For me the most important thing is to have the mapping in Matroska and We= bM > be identical. As the reference encoder already produces WebM files, I > highly suggest we communicate with their developers regarding the > mapping. I cannot find a document for AV1/WebM bindings at the moment, > though=E2=80=A6 Ah I didn't know that. Now I can see the code. Especially webmenc.c with a TODO for Frank Galligan in there. It way for some Wip In Progress code, because I have been appointed by the powers that be at AOM to do the proper/official mapping. At least this code doesn't write any CodecPrivate which could work, except, as for VP9 we wouldn't know the decoding profile just from reading the TrackEntry which is a major problem to select the proper hardware decoder. And the MP4 mapping also integrates a kind of CodecProvate with the Sequence Header OBU in there. >> I will dig deeper but we may have to tweak CodecDelay to make it signed. > > You cannot change the type of an existing element. It would potentially > break the interpretation of existing files created with the old > semantics. Let's take the value 144, which as an unsigned EBML integer > would be stored as 0x81 0x90. If you read that back as a signed EBML > integer, you'd get the value -128. Given a codec delay sounds like some time the codec needs when fed data before it outputs data. So I have hope it matches and I did the math wrong. In any case I don't know if we should include the flags like MP4 does. Because it seems very MP4 specific (and it's a draft and may go away). Unlike the rest of their "Codec Private" it should not be fed to the decoder (the OBUs we have can be fed as-is to the decoder). > Kind regards, > mosu > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Wed Jun 27 02:45:25 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2626E130F49 for ; Wed, 27 Jun 2018 02:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqjcECkPqjRL for ; Wed, 27 Jun 2018 02:45:21 -0700 (PDT) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B824130F40 for ; Wed, 27 Jun 2018 02:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2017070101; h=Content-Type:MIME-Version:Message-ID:Date:In-reply-to:Subject:Cc:To:From:References; bh=XOqnSFfj1n07SkO7xP11f+aXBVdsxau0UYyeZIw8+qc=; b=mSG2HFhy5PwCfq6tRnfLIT5pbtWU93ZoYm7cn5HVjYqlZQDXKnYlMro8Y+lV7lMPaa/CxM9760zBSGlCFnV66czsI8BzY4E1rB5FVUK89u1dv24t630AA8T4IVskrGIXn8qndy4YpUUloBRp8NunU+nqfg25H6XYPZSYyGgigbocCBclpIpDX7LH5mYMp3Kz+QacKTDD8rzUqykJTrcIeSE6At5/QNqKp/rA6r/yYggobCjat7fSMY+Vq3M3Egqrc4M0hxQF0aXU0fcMtfmocaocRLoW5CbXzGBJKNAhX3f8ObnKnmjZATRL8YKr/LaF4wVekagCDwC4wdI/cZ6f48D3UOWrX3wInEU57btgXxhaYhVrdc2zy2NMh2cxGLUZ4ElxcpvwnkCxvGFFFIov2E9oKUYb9olaocTJiDDfkQtUE1SW7JJWegKAvAQwqYR+xcZGfRDMYwAnEHPfO5m6aIOPqYMvPZaYoaIlcXKA7kHF6SpaTC30Y/yW8vBiT/4EZX69dqcVPq6TDQKpU5eLSQUDYdNtrtDq2Twvm1B055M2LFo4v824/m3b/bPLP9aNoZIqd11lZCGMoA3xyIrevUCVIVn09TWfqzTjraJPx0BoPcgpeZV0Upr98ULI1rErLvWoYzqlk7lnuAx3ezap3+l+ZFRMvkgLR67ttJJiZBs=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:54084) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1fY70n-0006OQ-1u; Wed, 27 Jun 2018 11:45:17 +0200 X-Virus-Scanned: amavisd-new at bunkus.org Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 3098F6541590; Wed, 27 Jun 2018 11:45:11 +0200 (CEST) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 7E8713BB73A5; Wed, 27 Jun 2018 11:45:10 +0200 (CEST) References: <87lgb0ehbn.fsf@bunkus.org> User-agent: mu4e 1.0; emacs 26.1 From: Moritz Bunkus To: Codec Encoding for LossLess Archiving and Realtime transmission , Frank Galligan In-reply-to: Date: Wed, 27 Jun 2018 11:45:10 +0200 Message-ID: <87k1qkef6h.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] AV1 mapping Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 09:45:24 -0000 Hey, > It way for some Wip In Progress code, because I have been appointed by > the powers that be at AOM to do the proper/official mapping. That's good to hear. For both Matroska and WebM? I fear that the existence of the WebM output mode of aomenc may result in its output becoming the de facto standard; therefore we should get the official mapping done quickly. Kind regards, mosu From nobody Wed Jun 27 03:28:48 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444AC130E52 for ; Wed, 27 Jun 2018 03:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcP8al40wEU6 for ; Wed, 27 Jun 2018 03:28:44 -0700 (PDT) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E11B1277CC for ; Wed, 27 Jun 2018 03:28:44 -0700 (PDT) Received: by mail-pf0-x232.google.com with SMTP id s21-v6so770776pfm.6 for ; Wed, 27 Jun 2018 03:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pg9WmPqgweGL+zAQoEhBMJsXN0w5wQ4iG0e9zQsKK1A=; b=pF+nQsLPt7ZH2y8/Tfv1hm836dWt2z7kCJ1+pRfSZBSwqbVDPx1yPeO2fejaSyvz+y YUX8lBa5uEQJa1r71+uQfH1ZKFF/mVaCfoQy4ps7D4Vh0ut8h4w8+OzfBUd1VU591tPo HHPCHJdTJvmOIjeBAREuasB/VZ5HTcgQ+VyZOpAgCuHlWXskMAmRGPpDbjKSU7gi6B0y WZ5cZLIm5UDJrNLU8Wf107zrpNMiIdMgpfLonlKN7jXRyUlMDT1sZbravrd80JTkpRKK d+Dxo9NaMua0fxzTC/b4cneMQojHYkQYQTuEBKKWiJlwW/hJuYYpvrv4fQKqymXcathn Yevg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pg9WmPqgweGL+zAQoEhBMJsXN0w5wQ4iG0e9zQsKK1A=; b=XTL5ISaWygqknzdHabCdzlvVBBFKfnE9QFhNE5ET/3hfJeZ1KvNbdCYzd4pgzGlHR4 QdzCBEZW9KNobuGEdj05Wg6Q60a74+MobwdM5nKPbEE87KTWHRia6q7pTpTmkoKHJJLG Ibr3rE8sLQy6QHhmIb37plLggulxvksp65voivwlB936i+eIGm0snyxO7eThOE7+RMlO F3a+8Pjq0XM3bFJ8VpnwHk4pTGS9S9YmHztIPNppLhFj35WMWimUimrgn8f+wPUuyi4h RmH3YJjJUkbj563T4dm/vK0znrIGgq3IebeVwZOHnTZyHVOnU+htdDudiFxY0NFHjXfS f2Xw== X-Gm-Message-State: APt69E0yTBjlN5p6xo4aNgG7skOJ58zfm7EMzVQQo240ezhSSGByINGK GM9vpYmBU51PH8frF4g2/J+3piTgR8Cm70pIYKp8wg== X-Google-Smtp-Source: AAOMgpfaltvWW2UnsgFRJuhBR4JQvnZBjF/X3AAU8KlqWmCGmFt6Wls3bS/TCAqYVnS2bYFlhxuIAJwTUchbchbL4IU= X-Received: by 2002:a62:768d:: with SMTP id r135-v6mr3893565pfc.181.1530095323963; Wed, 27 Jun 2018 03:28:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:17af:0:0:0:0 with HTTP; Wed, 27 Jun 2018 03:28:43 -0700 (PDT) In-Reply-To: <87k1qkef6h.fsf@bunkus.org> References: <87lgb0ehbn.fsf@bunkus.org> <87k1qkef6h.fsf@bunkus.org> From: Steve Lhomme Date: Wed, 27 Jun 2018 12:28:43 +0200 Message-ID: To: Moritz Bunkus Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Frank Galligan Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] AV1 mapping Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 10:28:47 -0000 2018-06-27 11:45 GMT+02:00 Moritz Bunkus : > Hey, > >> It way for some Wip In Progress code, because I have been appointed by >> the powers that be at AOM to do the proper/official mapping. > > That's good to hear. For both Matroska and WebM? Yes. They should not differ. > I fear that the existence of the WebM output mode of aomenc may result in > its output becoming the de facto standard; therefore we should get the > official mapping done quickly. If/when this mapping is approved I might be able to fix the code in libaom. This code is mostly a proof of concept than an actual lib. But for now that's what people will use. > Kind regards, > mosu > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Wed Jun 27 04:31:25 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228F81277C8 for ; Wed, 27 Jun 2018 04:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qa-FhKpa6qfw for ; Wed, 27 Jun 2018 04:31:21 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6935912777C for ; Wed, 27 Jun 2018 04:31:21 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id a11-v6so832895pff.8 for ; Wed, 27 Jun 2018 04:31:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=wreFHesrNAk8SDuv4sdFkQsgRWOBb4OGImaHWbc5P88=; b=hBDdqghFtioDs4a4sJoHSXPDjJhx3/TYXBFQ5NNq2byuPTFb1lvfFYVQBO4lAqpzc6 Td3bRs2eHEUAmiQwXlr0n/EW/nlj3aWm85472DAmYmefhW0+7068t05o5TEQlNnKOHHI 83hcxBrFA2Q+9aA1HCi7bLn0tKbyGgr2FwqmxQe8mL1p1aNzGJobt9fDCF84ei2/TJli h2zdnEGgNHyC0d5+uO83MMhYGsnwh/ltskO1gK9EJZqeyhQhvcunLQMWJK4rdpuWatFL iQDdM8r5s4bQ5Y+hRdZhoFx8Bf+NyO6DECDo69A1vUH0PtDc0DNesGCvwmg72MVWdIqX H8Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=wreFHesrNAk8SDuv4sdFkQsgRWOBb4OGImaHWbc5P88=; b=IdndJ+yofVV8vVeLCARoIkXH94UWV2u2+fe0/b2QbUPlcoBV+I8zoQzOhx/hO3Smxm kf/FnZtyh9FVNFGwCIcEqb5CPvKh0ConZ9d4qumiRZOcNo2ILsZhehkJz5Nl0TpKB7AW +hVZ7Td7EdhyGjHncGhqOxwaQ0qTnZm3n9VZi8rSy9q9KNfnwhClZbNr4BZ7iltk8afF I0GvGBfmj/YDq0OJqTcir5EAovRG6nu42Etky1wLunBcN/F9Tu5Yfwk8eGYWBW9Bzbdu 38jPvHma3/uLazy/Jfm8j5BUqezbqxydy3+iLhMhnimv2INTql1JYjfqeesycHUvZfoM IJ0A== X-Gm-Message-State: APt69E1IljeskH03ykeZ6NpaLXdFBKj/ZliAj/CNuz3Ok7B71FIPJRN/ EFKXdikLS8JMl1YMEMfsgPhZPQaLpIVqfeaAS2qOEWeY X-Google-Smtp-Source: AAOMgpfNr/C6grbmjKWnxnBlvxrlxdFQBAjWOALUBZGg8l0udQSmc34ORx06OmtuiLz/3ukFWc1t+liVOk/SSDCS/78= X-Received: by 2002:a62:2253:: with SMTP id i80-v6mr5430116pfi.11.1530099080471; Wed, 27 Jun 2018 04:31:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:17af:0:0:0:0 with HTTP; Wed, 27 Jun 2018 04:31:19 -0700 (PDT) In-Reply-To: References: <87lgb0ehbn.fsf@bunkus.org> From: Steve Lhomme Date: Wed, 27 Jun 2018 13:31:19 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Cc: Frank Galligan Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] AV1 mapping Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jun 2018 11:31:25 -0000 2018-06-27 11:30 GMT+02:00 Steve Lhomme : > 2018-06-27 10:58 GMT+02:00 Moritz Bunkus : >> Hey, >> >> I've only had time to skim over it. It's definitely understandable. >> >> For me the most important thing is to have the mapping in Matroska and W= ebM >> be identical. As the reference encoder already produces WebM files, I >> highly suggest we communicate with their developers regarding the >> mapping. I cannot find a document for AV1/WebM bindings at the moment, >> though=E2=80=A6 > > Ah I didn't know that. Now I can see the code. Especially webmenc.c > with a TODO for Frank Galligan in there. > > It way for some Wip In Progress code, because I have been appointed by > the powers that be at AOM to do the proper/official mapping. > > At least this code doesn't write any CodecPrivate which could work, > except, as for VP9 we wouldn't know the decoding profile just from > reading the TrackEntry which is a major problem to select the proper > hardware decoder. And the MP4 mapping also integrates a kind of > CodecProvate with the Sequence Header OBU in there. > >>> I will dig deeper but we may have to tweak CodecDelay to make it signed= . >> >> You cannot change the type of an existing element. It would potentially >> break the interpretation of existing files created with the old >> semantics. Let's take the value 144, which as an unsigned EBML integer >> would be stored as 0x81 0x90. If you read that back as a signed EBML >> integer, you'd get the value -128. > > Given a codec delay sounds like some time the codec needs when fed > data before it outputs data. So I have hope it matches and I did the > math wrong. > > In any case I don't know if we should include the flags like MP4 does. > Because it seems very MP4 specific (and it's a draft and may go away). > Unlike the rest of their "Codec Private" it should not be fed to the > decoder (the OBUs we have can be fed as-is to the decoder). In page 20 of https://aomediacodec.github.io/av1-spec/av1-spec.pdf there's a pseudo-code on how to handle the [initial_display_delay_present_flag]. The values to use may differ for each "operating point" (An operating point specifies which spatial and temporal layers should be decoded). It doesn't say clearly in the MP4 draft but the delay (in frame count) means it should be the maximum delay of all operating points. Which also means it will add too much delay for some operating points. So IMO it's not good. An hypotethical delay in Matroska would also use something similar, but again it won't be a correct delay in some cases. It's really an internal codec thing. So I think we should not handle it at all or say that [initial_display_delay_present_flag] SHOULD be 0. Let alone the fact that it's expressed in number of frames that may not all have the same duration. And finally in MP4 it starts with these bits that are mostly copied from the Sequence Header OBU that just right after. So IMO it's unnecessary in that case, adds more data and is prone to errors... >> Kind regards, >> mosu >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar > > > > -- > Steve Lhomme > Matroska association Chairman --=20 Steve Lhomme Matroska association Chairman From nobody Thu Jun 28 06:37:02 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D40130FEE for ; Thu, 28 Jun 2018 06:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQVn1ye5Rzb1 for ; Thu, 28 Jun 2018 06:36:58 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C4F130FEA for ; Thu, 28 Jun 2018 06:36:56 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w5SDasF0017849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 28 Jun 2018 15:36:54 +0200 Received: from Castor.local (84-73-238-96.dclient.hispeed.ch [84.73.238.96]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w5SDar7d022682 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 28 Jun 2018 15:36:54 +0200 Date: Thu, 28 Jun 2018 15:36:54 +0200 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailer: Mailsmith 2.4.3 (480) Archived-At: Subject: Re: [Cellar] agenda for ***June 26***, 20:00UTC X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 13:37:01 -0000 I am sorry for having missed the errata corrige! Best regards, Reto From nobody Thu Jun 28 16:12:24 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0547A13110C for ; Thu, 28 Jun 2018 16:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMqwrFmtiaCp for ; Thu, 28 Jun 2018 16:12:19 -0700 (PDT) Received: from mxout26.s.uw.edu (mxout26.s.uw.edu [140.142.234.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB5D1130E37 for ; Thu, 28 Jun 2018 16:12:19 -0700 (PDT) Received: from mail-vk0-f70.google.com (mail-vk0-f70.google.com [209.85.213.70]) by mxout26.s.uw.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id w5SN91Od009086 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=OK) for ; Thu, 28 Jun 2018 16:09:02 -0700 Received: by mail-vk0-f70.google.com with SMTP id l23-v6so2699132vkl.10 for ; Thu, 28 Jun 2018 16:09:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=uQiiuCdycwBuwDjNRdHfgRJN6E5atBiIHuM3AbOJ+J4=; b=BL993e8lUQiWLSS3U+Mgzyi2/wdnewqgE9P46jmJhgJQeYsg/Qw1x4YfQVq0NiPS42 qULP/wHEuU8j2e5V7PyltYDm5yzK50ZUhqOYIi7wuAb8/iBEkoBjVaJKBaOGmnFOu2/7 k6Ai5J5P5DVC0Sj+FkN+GgDxfy+l5IWgGPue+lknSODrwRtiyn5D2/rFuAmXmmc1/rRm M8YeTToX05+Q4LxXVhvZdb9rRAzi17+Fo/ZAk6rzwUe0qRKOmUjhg6gvpxXFcdlB4Kzj iCWThEGuo9OVnDqn9uyubUTIipwv5cypIzPFVy+ChAXo0Cjw9ysMaQkxD3W+wqYE0kL7 JCbw== X-Gm-Message-State: APt69E1CDZkPVmTqLGpdgNBM41ji/77HTRcMVW9/BsgBJjR2N6CXEV9L emyUwG/HyC5h3484b4oR8oMhfqLfNH+Cpdw/7yyAKtPrjMs5uFaWIHaaLhwrrbbJ9V3oWcOh6rb I9GtTO03Ms28FqPdGnf/rMY3CDy47OXQL8M9AhfWHRduVmHR/ X-Received: by 2002:a1f:8c87:: with SMTP id o129-v6mr2328944vkd.192.1530227340931; Thu, 28 Jun 2018 16:09:00 -0700 (PDT) X-Google-Smtp-Source: AAOMgpei+7BJMMqcQvc+diUhu9nVySOkzdoEKqi6nktIH9hMdAaIninrubMm83o6UZGIWPsjNh6G1kbfpawrVpp0RoA= X-Received: by 2002:a1f:8c87:: with SMTP id o129-v6mr2328933vkd.192.1530227340408; Thu, 28 Jun 2018 16:09:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab0:13ee:0:0:0:0:0 with HTTP; Thu, 28 Jun 2018 16:08:59 -0700 (PDT) In-Reply-To: References: <5AF37D25-647D-40F6-8480-A4258A604831@dericed.com> <3d967fbc-f2a3-187b-2857-59d3e873a264@das-werkstatt.com> <87371jy5bw.fsf@bunkus.org> <9ebd9899-cf32-2c6b-2aab-500187fedf0f@das-werkstatt.com> From: Andrew James Weaver Date: Thu, 28 Jun 2018 16:08:59 -0700 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="0000000000000d15ac056fbbd174" X-PMX-Version: 6.3.3.2656215, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.6.28.230316, AntiVirus-Engine: 5.50.0, AntiVirus-Data: 2018.6.28.5500004 X-PMX-Server: mxout26.s.uw.edu X-Uwash-Spam: Gauge=X, Probability=10%, Report= TO_IN_SUBJECT 0.5, BODYTEXTH_SIZE_10000_LESS 0, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, FROM_NAME_PHRASE 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, REFERENCES 0, SPF_NEUTRAL 0, WEBMAIL_SOURCE 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __DQ_NEG_HEUR 0, __DQ_NEG_IP 0, __FORWARDED_MSG 0, __FUR_RDNS_GMAIL 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __HELO_GMAIL 0, __HEX28_LC_BOUNDARY 0, __HTML_AHREF_TAG 0, __HTML_TAG_DIV 0, __HTTPS_URI 0, __INVOICE_MULTILINGUAL 0, __IN_REP_TO 0, __MIME_HTML 0, __MIME_TEXT_H 0, __MIME_TEXT_H1 0, __MIME_TEXT_H2 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_TEXT_P2 0, __MIME_VERSION 0, __MULTIPLE_URI_HTML 0, __MULTIPLE_URI_TEXT 0, __PHISH_SPEAR_HTTP_RECEIVED 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_WEBMAIL 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __SUBJ_REPLY 0, __TO_IN_SUBJECT2 0, __TO_MALFORMED_2 0, __URI_IN_BODY 0, __URI_NOT_IMG 0, __URI_NS , __URI_WITHOUT_PATH 0, __URI_WITH_PATH 0, __YOUTUBE_RCVD 0 Archived-At: Subject: Re: [Cellar] doc shepherd appointments X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2018 23:12:22 -0000 --0000000000000d15ac056fbbd174 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, I wanted to check in on this and see if there has been any movement! Assuming all the volunteers are still willing, are we at a point to make the document shepherds official? Best, Andrew On Sat, Mar 17, 2018 at 4:38 AM, Ben Campbell wrote: > (Speaking as Area Director) > > Dave has the process correct, and it=E2=80=99s on my radar now. I will sp= eak to > Tim about how we can move this forward. > > Thanks! > > Ben. > > > On Mar 8, 2018, at 6:33 PM, Dave Rice wrote: > > > > > >> On Mar 8, 2018, at 12:32 PM, Peter B. wrote: > >> > >> On 2018-03-01 23:29, Dave Rice wrote: > >>> To reiterate the expressions to volunteer within this thread. We > >>> currently have no assigned Document Shepherds but are likely in need > >>> of that role, particularly as some documents are ready for last call. > >>> For volunteers for Document Shepherds we have: > >>> FLAC - Andrew Weaver > >>> FFV1 - Peter Bubestinger > >>> EBML - Steve Villereal > >> > >> What's the status of this? > >> Anything we need to sign? ;) > > > > IIUC appointment of Document Shepherds and issuance of a Last-Call for > document work is at the discretion of the WG Chair(s) working with the Ar= ea > Director, so I think we=E2=80=99re waiting on guidance from the chairs. > > > > Dave Rice > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --0000000000000d15ac056fbbd174 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I wanted to check in= on this and=20 see if there has been any movement! Assuming all the volunteers are=20 still willing, are we at a point to make the document shepherds=20 official?

Best,
Andrew


On Sat, Mar 17, 201= 8 at 4:38 AM, Ben Campbell <ben@nostrum.com> wrote:
(Speaking as Area Director)

Dave has the process correct, and it=E2=80=99s on my radar now. I will spea= k to Tim about how we can move this forward.

Thanks!

Ben.

> On Mar 8, 2018, at 6:33 PM, Dave Rice <dave@dericed.com> wrote:
>
>
>> On Mar 8, 2018, at 12:32 PM, Peter B. <pb@das-werkstatt.com> wrote:
>>
>> On 2018-03-01 23:29, Dave Rice wrote:
>>> To reiterate the expressions to volunteer within this thread. = We
>>> currently have no assigned Document Shepherds but are likely i= n need
>>> of that role, particularly as some documents are ready for las= t call.
>>> For volunteers for Document Shepherds we have:
>>> FLAC - Andrew Weaver
>>> FFV1 - Peter Bubestinger
>>> EBML - Steve Villereal
>>
>> What's the status of this?
>> Anything we need to sign? ;)
>
> IIUC appointment of Document Shepherds and issuance of a Last-Call for= document work is at the discretion of the WG Chair(s) working with the Are= a Director, so I think we=E2=80=99re waiting on guidance from the chairs. >
> Dave Rice
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar


_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

--0000000000000d15ac056fbbd174-- From nobody Fri Jun 29 09:18:01 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45514130DE3 for ; Fri, 29 Jun 2018 09:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zPdMuuK9J1x for ; Fri, 29 Jun 2018 09:17:57 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE63C130DDC for ; Fri, 29 Jun 2018 09:17:56 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 91215200A3; Fri, 29 Jun 2018 12:32:41 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 3B5B31555; Fri, 29 Jun 2018 12:14:48 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 38F681245; Fri, 29 Jun 2018 12:14:48 -0400 (EDT) From: Michael Richardson To: Andrew James Weaver cc: Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: References: <5AF37D25-647D-40F6-8480-A4258A604831@dericed.com> <3d967fbc-f2a3-187b-2857-59d3e873a264@das-werkstatt.com> <87371jy5bw.fsf@bunkus.org> <9ebd9899-cf32-2c6b-2aab-500187fedf0f@das-werkstatt.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] doc shepherd appointments X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 16:18:00 -0000 --=-=-= Content-Type: text/plain First, thank you for volunteering! Andrew James Weaver wrote: > I wanted to check in on this and see if there has been any movement! Assuming > all the volunteers are still willing, are we at a point to make the document > shepherds official? We need the document shepherd when the document goes into WGLC. If we have them earlier, than that's better. The shepherd does not need expertise in the topic itself, but rather expertise in https://tools.ietf.org/html/rfc7282. At this point, we need to get a new revision of EBML out!! The deadline is Monday (July 2) for internet drafts. see: https://www.ietf.org/how/meetings/important-dates/ If we can get the new document posted by Monday, we can start the WGLC on it... -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBWzZa9YCLcPvd0N1lAQKalAf/T34NqWaURVx4MeqCpyJ3XsI01EY/yPKA BISU9XF2TLqNyjvYlJVqBsILAXJbRcUldy2SDrnEhyCXShB49Bvq9NMchjVcuDAR uFSXxttNOYluNflAuusor/S1r7gqTfMkgMqiVem/6Q1ziKLZ0y+6GkrH2SHVJ1vO H44SQ1axmvaOTWWOLYlgNmT39IQetOTz0y07swemFuNm5XvU9pMez8z7JySKNiAM Qh7KVWv/ag/POJ9cG0qWw71d7be5uhjI1fIArNCX3HtOcUEsNkArVjWCE/m92gMA t3qWc+iTl4AzdiIPpX2hYOAbISGWp0Pho/tSoRn2Cnfc/2TOYewU9w== =Iapd -----END PGP SIGNATURE----- --=-=-=-- From andreas.rheinhardt@googlemail.com Fri Jun 29 15:11:07 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8BE130E29 for ; Fri, 29 Jun 2018 15:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xti1O-fxiMY8 for ; Fri, 29 Jun 2018 15:11:06 -0700 (PDT) Received: from mail-wr0-x243.google.com (mail-wr0-x243.google.com [IPv6:2a00:1450:400c:c0c::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB98130E1B for ; Fri, 29 Jun 2018 15:11:05 -0700 (PDT) Received: by mail-wr0-x243.google.com with SMTP id c5-v6so10110295wrs.10 for ; Fri, 29 Jun 2018 15:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:subject:to:in-reply-to:message-id:date:mime-version :content-transfer-encoding; bh=HssF7oasnKP6lDdJYTZszvhaAuCr0fBeRN5WqZu+R0Y=; b=fVw5oCW5muRDRCEEqaNLdW3ZhqbYQBvv6SbxVAfeqtonB7YGQTBmfnh94iJrNq4A0M 9t5lwY15Pds63DGAwZgzvzdtEKWlvAAqU47QFUP2XRDpKpD5X/kYO+C9txqqoeu6GTkE W+kmLcpv3ARcbBPZTgFYKMttBlCxDrXMg82mCqL1WzPQCphA3nyMTGMITx3/pJvvhEVm cUW4xs0/phXCJQSyVvtt7BgHoUWJ6m2UIkc9B9nsL/7N6T/kI4palJb30QRcav5y6YMC qpXVsA/j/oZL4W9ZPExplnYfIIjgfnzrJonMHu/D1KaKnyn80rElEmN/om9heozm5xGx 976Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:in-reply-to:message-id:date :mime-version:content-transfer-encoding; bh=HssF7oasnKP6lDdJYTZszvhaAuCr0fBeRN5WqZu+R0Y=; b=EquGxSdPFis1RpN/sMtWs1mKtyA0fXeIF3++VuUiZlXkJGrUP1za43CZ4b2vcmAKzb 5dpL+LE5hV5Shx5TQJnnrAgtVwWUEok6nHHIs29gkUm2J4fvs3X+cazfoSLcfE1MzG2M AjJVxsTJlfUAUBAiml0ybufmL8o5B81zINRTfPgKiUQ3Tj7ceqFEnJZUfKo1D81CaDZo Z49nyfJr+yTKmBbhAvyVN1ab7UufZ9bpoeDkPFU1UsaDTd+sw7cvA3f4MtErYLa7wM0N MaCHcYnKV+BclsMrz92W44EXz/XVbgWGejB29aWJCCtAMDHTTtIgZ+98t1STZj5XhV/q 4IUQ== X-Gm-Message-State: APt69E15izWJI1b/jIRPorl1Zq3iunrzvFaEWcVCGWkhMcNheiTQVc7Y xRptEdT18hRFPXM9gpEWdMwRMePk X-Google-Smtp-Source: AAOMgpdZs1EFM2s4weRwi7V3SR1Q15XlI7r3Wmi3mqMYJrwpkfkhfRJrj/AmC83DGj0jSXvbKy18KA== X-Received: by 2002:adf:9226:: with SMTP id 35-v6mr9637436wrj.44.1530310263851; Fri, 29 Jun 2018 15:11:03 -0700 (PDT) Received: from [127.0.0.1] (178.ip-217-182-168.eu. [217.182.168.178]) by smtp.googlemail.com with ESMTPSA id e126-v6sm4096658wmd.43.2018.06.29.15.11.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jun 2018 15:11:03 -0700 (PDT) From: Andreas Rheinhardt To: cellar@ietf.org In-Reply-To: Message-ID: Date: Fri, 29 Jun 2018 22:09:00 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] AV1 mapping Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2018 22:17:45 -0000 Hello, I have only just started reading the specification, but I already have some comments: 1. Your proposal says that DisplayHeight and DisplayWidth must be set so that they agree with what is said in the CodecPrivate/in the bitstream so that one can't use the Matroska fields anymore to override what is set in the bitstream. If I am not mistaken, then AV1 would be unique in this regard among all the video codecs that are allowed in Matroska. I don't see a reason for this at all and propose that there shouldn't be a special treatment for DisplayHeight and DisplayWidth in AV1. 2. Two sequence header OBUs with the same [seq_profile], [high_bitdepth], [seq_level_idx] and [color_range] can still differ in the [BitDepth] derived from them due to [twelve_bit]. Therefore I wonder if this is the right restriction. Wouldn't it be better if it is demanded that the derived [BitDepth] coincide for every sequence header OBU? 3. Given that AV1 seems to only use one Sequence Header OBU at a time couldn't one use the CodecState and CueCodecState elements to designate where the currently active Sequence Header OBU can be found so that one doesn't need to repeat the Sequence Header with every keyframe? (Btw: There are currently conflicting recommendations regarding the existence of Sequence Header OBU if there is actually only one Sequence Header OBU. On the one hand, they should be omitted, on the other hand every block marked as keyframe should start with a Sequence Header OBU.) Andreas Rheinhardt/mkver PS: This is my first mail to this list and I hope that it will be presented as a reply to Steve Lhomme's proposed AV1 mapping in Matroska, but given the fact that I only subscribed today I can't simply reply, but had to explicitly set the "In-Reply-To" field. Hope it works. From nobody Fri Jun 29 17:42:27 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65888130F8B for ; Fri, 29 Jun 2018 17:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bqo4UE6-0AHC for ; Fri, 29 Jun 2018 17:42:22 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F5B130F88 for ; Fri, 29 Jun 2018 17:42:22 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id s198-v6so6128986oih.11 for ; Fri, 29 Jun 2018 17:42:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=MVn9J0mI2ccQxXxZgaTl/8C7QgLT5sygM9/fLzySs0Y=; b=NOx51AOoQ0YWIt17X6genzD6LZuJa+BHyD3u7lMXGO0jrkCG9XuUIwjfyTSRsQe9mC Go1RsuAhLqfJUT1pcphuee64g4kpokd3OLmPKzLUpmpgPtlnPHPjNFhp82GfAMNVmFuS TACpZpxbqoLeun59wqhcR4wr0AD9yPnwTvjkE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=MVn9J0mI2ccQxXxZgaTl/8C7QgLT5sygM9/fLzySs0Y=; b=dXIXJCU782d4K6vRVh17tBH2JpOYGkbLWFr6Sei5BiouzajSnYAbaFEX4l5wxtSYXY K2QyXGxzKMxHMBmmBA2FvE/idxFa+cr2Ao3aAXFOb7CBFPpW4LADSp3ZRuNFITM3bjY7 3Yg3rhcUwW8fENddf8fuwk1YnIyH9syt1wIr4P1l3VjhqPo0Zu8a/3SeJcdXJyo2bjGD +JCX4+BYK5j2FCVYqMyyEbfqya/v2Tfm+pfJIi+108NyZg/v6Wu7IzlPaNxixECUbkiq mH5hNj0npROYCmN3ZHwTo8V/peJlJfXr4YNHoHlzVqMemRjiT69th/ZxM7YLtVjuRZYn VL1g== X-Gm-Message-State: APt69E2sEP0d339Vx6T/pXCdW8sgvYz2C0lZBOG0+DJ3j+WIXT3hK3YX fZN9CDM+NtfnvTT+D/Im9etMjqyD7ps= X-Google-Smtp-Source: AAOMgpeSFO6a2PXJ2gL6HbG347Eoqc6ZNgKAjGc1oL+uGtmT71/EeN1H1OZ9ksTrL7xJLNtM3Klbug== X-Received: by 2002:aca:494b:: with SMTP id w72-v6mr4308347oia.293.1530319341347; Fri, 29 Jun 2018 17:42:21 -0700 (PDT) Received: from ?IPv6:2602:306:bca9:8f8::87c? ([2602:306:bca9:8f8::87c]) by smtp.gmail.com with ESMTPSA id t196-v6sm5561378oie.1.2018.06.29.17.42.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jun 2018 17:42:20 -0700 (PDT) To: cellar@ietf.org References: <87lgb0ehbn.fsf@bunkus.org> <87k1qkef6h.fsf@bunkus.org> From: Thomas Daede Openpgp: preference=signencrypt Autocrypt: addr=tdaede@mozilla.com; prefer-encrypt=mutual; keydata= xsBNBFO66EwBCACYuVh1EWi+DaQ+JxPB1w/9NqZ3CDycN+GokSy1dU1tTRjwbzqiUKFDYcgH wOngJMdm9s0gprwyQGox4noUyAozWcUKSY2YGN+tr2ZkdVakMt0Ly/k6zWZ70J4ajTA1765w yYPhby/pAQcPXeme18+eXwuhVd3BUN/57A9tiuhBN0nH2I66lbFjUR/uhC8NGU/qAd3nMFJf RUcZqs1OsSXQkyaFiFvd6zXpmoRrjPjpm+S5egGYnPLDhDEob1tEZdkYBddB5G0Z77iKvIdb QKVaiJtnAPnldjl2mzUpiFOzJnsAXXbei4FMzF3Fh8cnyijFOB7nxdBGJO+2XZ7kQK4JABEB AAHNIlRob21hcyBEYWVkZSA8Ynp0ZGxpbnV4QGdtYWlsLmNvbT7CwHgEEwECACIFAlPGul0C Gy8GCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEHtsd6iDUvbyQ9gH/2KMR6tLtyEhbj7M NffxlkGbUl7hKYnskOqq5vFQI3v+AdaKGJFtlkecvHfHzuQDD8SDJAug+o0hadpxnZpmw2Kl NSWC81cOyQoIPtapvvfG54X6BCKw3jfZ5rHOj3kf5ToAEepM9/g5/DLiuVUf5SucusP3K7YS gu+T5LRYlz45Eo9oS0jLnp8rFrJ4xpuVW2l0O76mOwMl6M/vk5bvDj3mU6ulfmoT9Zl+KlN0 SgvOVCUvPBBsUnISp7iSXpSnuFHTvrcQfvYbQTV3bmhKH2ns5oS9ITyq0b46O5TN7jr6e7jf d+laUpMqUC1QUDyMCJCVTe+LwwqDbQlrMDz1TIvOwE0EU7roTAEIANOm6K6c3eES7mz0xMcM vmNQniX2BSY0h0RITx2N6TnbMQRgQgItPDToJaReOe8z+QCza2vf79kRj126pQMm7VXQWwDy 2p63Rnu5+XzVforsHGrBf4NuSKUMQOhconG6cnF2vwQm1IjYekwhYQJLGZCAscB7oJdZY9Vm e/6YCnlcET7iQxQLjjjj3VTKbyoP2fj6H8LYKygIq11HqN+9yibxWvvIW6PndSXMJqVcHYpP J0W4Urygs8FNWY1alt3Ei96j45p1DvdwbJlfYk08rCz9YEwyLd+GUP2BbgG4LbarUzWkXmWt q6J5g10x0qPJf1fyDB9EoYV7smCLFs3yBLcAEQEAAcLBfgQYAQIACQUCU7roTAIbLgEpCRB7 bHeog1L28sBdIAQZAQIABgUCU7roTAAKCRB6rD5Vf1yi2174B/0fK+mc+FRh2DuQNc0g4rHQ jRl6IyYI8yprs9KOpjnYQ5R3fvsUgz+qUAmY34Stb1C4LSXIj8k6K3FehDig7KtJwEfC8nwt KIyifP7AEto6t9j0UeVYypocdJIH35UOP4/4/ee0xrQUVmpdhUGpDA4fMAHIo7Rfk6JEhQPT r9N34tHPzncYT93n1Rhht1GGq4UD1Ar9aCFVph8B7Lqc3rrrShhM6rn6RsH7QXLD0WUe53jX mYxvH+uYU20FogwciRmTXlnEDe2YGqyELemTMc/huiI3uWVYuySgPl+aIt1kx4jcQbKFuLMR g+NKVRxp/6VeCcuWDPGc919HkdH4gxhFGi0H/jvGPG3SKo48EeVwAPy6THWky/8FGsdBOzvX FEoQOe6RHF4JflZAghfDAyqi7nzl0t8PBb0yFDjw3wLVJ/3AXkNc9UJFyWECtm4onb8TmymJ 0LygCktwEloE1hySgFJzaIB9xMFJIXRz8UxR5GH/o1LED4D/z9LQ4js3sn8QwHG0+Hkvzh8t 9qgxDKxQ7aREy1/Si+BmAdf8Xt/nf/dzYeXTPbjjZyzp4R6B0z6MfZ4xH8/b/lDC1UqU702f GFcYPnIcn9xxxaRRvYHwq5x55Gpy/aAvIs7tLqSFVh816LOa0zytCUCEN8bR2+xuwW4IApEQ VAycc3Qqfz8tZAQ49kE= Message-ID: <911412bb-e011-d97c-c701-64e19cd2f013@mozilla.com> Date: Fri, 29 Jun 2018 17:42:19 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] AV1 mapping Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 00:42:25 -0000 On 06/27/2018 03:28 AM, Steve Lhomme wrote: > If/when this mapping is approved I might be able to fix the code in > libaom. This code is mostly a proof of concept than an actual lib. But > for now that's what people will use. I can help with this too. Indeed, the webm output code in libaom was just inherited from VP9, and is not supposed to be the final mapping. We will want to change it as soon as possible to prevent files created with the incomplete mapping entering the wild. From nobody Sat Jun 30 00:44:18 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3EE13102E for ; Sat, 30 Jun 2018 00:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ml-1MM9mmQq4 for ; Sat, 30 Jun 2018 00:44:14 -0700 (PDT) Received: from mail-pl0-x235.google.com (mail-pl0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7659213102C for ; Sat, 30 Jun 2018 00:44:14 -0700 (PDT) Received: by mail-pl0-x235.google.com with SMTP id m16-v6so5524304pls.11 for ; Sat, 30 Jun 2018 00:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=378RXwcZQEjPt7B5sCE6hV2ygqx2PlicNqU+zLFUdwg=; b=y0X72CtK1XoJcQgjHN6zJxrifn+hGKcU10RQd6O6hAThJh8pVDnu5ROEeMO1VCbo7G FjVm3IA8TGF8Kh8xAhAHIYTADHz7bePy7Pt7SuuNlxYHUdak+Q53LadtJDCp2cKiKWN5 7M7qTKNs7AimFV2bsVuibAsbF2R5ix9eSZfjYm4uHMUsD/wux5vHSRPa71gAqf9Dzwjl 03DilrK9nJiU6tIXilmuKKxVtoxSlR7KTMTdOKXMC4TMBfluSBYrgHTHX4mcuH/w0fWc CyDNSaCnnGkppQo6kQg1DIDbmH9ssG/NbQYc//G6UNJnIPNKKvVHRJ6FiA0kvGfZkzX2 6gDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=378RXwcZQEjPt7B5sCE6hV2ygqx2PlicNqU+zLFUdwg=; b=bDBxhOvHHrYL73zXKC113z9rK69XkfV7XcUetMyI+7D4/1rG8mnAppV4aKzn64184I F0rBvwRw7/7wZtOkI41K3TBmgm6lP+JthsGIxvaVsmD9D3YMHan1B763Gphu5fpLxlBf xswywm5MpTgjuQVc+Mzh0F1FeWgjDZL6l0E4Xn81uUz5f/NZy03R5SA3ApG+MlO6I27e 7OfdEP4zP9UMwk2rfTOxKV6jBh6CYOkO0aNvCIqsvzXJShyvyMP45UtB17olv8SW2dAJ 9RD0ALOt4rf0EyNOE4uonNPQjIXCb6pKT+JGIQqMEwrDqwHUc7ArOJ7VsRB6jL08u4ra shWQ== X-Gm-Message-State: APt69E0X85M3L3V8/poOVUufYjfuHYCon7DfracPfleWK0MAZ07i9rAd 7z2sh8DAWa9sJ346r52UhEaVgvatGNUNKFwu8i7Ofw== X-Google-Smtp-Source: ADUXVKJPUUOMBMMQ5Up/PYGiHtgEJMpeFBvxLjgb8VRK8fc5OEqbraFUU4jW+c/GMBgfm7Xo2rCzPJhcnEORGX63+Xw= X-Received: by 2002:a17:902:bd95:: with SMTP id q21-v6mr17729422pls.237.1530344653757; Sat, 30 Jun 2018 00:44:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:17af:0:0:0:0 with HTTP; Sat, 30 Jun 2018 00:44:13 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sat, 30 Jun 2018 09:44:13 +0200 Message-ID: To: Andreas Rheinhardt Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] AV1 mapping Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 07:44:17 -0000 Hi, 2018-06-30 0:09 GMT+02:00 Andreas Rheinhardt : > Hello, > > I have only just started reading the specification, but I already have > some comments: > > 1. Your proposal says that DisplayHeight and DisplayWidth must be set so > that they agree with what is said in the CodecPrivate/in the bitstream > so that one can't use the Matroska fields anymore to override what is > set in the bitstream. If I am not mistaken, then AV1 would be unique in > this regard among all the video codecs that are allowed in Matroska. I > don't see a reason for this at all and propose that there shouldn't be a > special treatment for DisplayHeight and DisplayWidth in AV1. You're right. This is a mistake on my part. Instead of MUST it's a SHOULD. Because Matroska allows to override the codec internal values to display this differently, including changing the aspect ratio or forcing physical dimensions. I will change that. > 2. Two sequence header OBUs with the same [seq_profile], > [high_bitdepth], [seq_level_idx] and [color_range] can still differ in > the [BitDepth] derived from them due to [twelve_bit]. Therefore I wonder > if this is the right restriction. Wouldn't it be better if it is > demanded that the derived [BitDepth] coincide for every sequence header OBU? It depends if it influences the output of the decoder or the decoder that can be used. My main concern here is that we have the necessary information to setup the decoder to start playback and be done with the duration of the Segment. Otherwise that means the CodecPrivate is sufficient. There's a fine line between being too restrictive and forcing multiple Segment for a simple internal change in the codec. So we don't want to restrict too many field from the Sequence Header. But on the other hand we want to ensure a Segment is consistent, especially regarding seeking. That being said, you're right [high_bitdepth] and [twelve_bit] are the ones needed to make up the actual [BitDepth] so I will change that. > 3. Given that AV1 seems to only use one Sequence Header OBU at a time > couldn't one use the CodecState and CueCodecState elements to designate > where the currently active Sequence Header OBU can be found so that one > doesn't need to repeat the Sequence Header with every keyframe? Yes, that would be a good use for when seeking is used. But these elements were ruled out as deprecated because they were of no use until now. I know VLC doesn't read them for example. > (Btw: There are currently conflicting recommendations regarding the > existence of Sequence Header OBU if there is actually only one Sequence > Header OBU. On the one hand, they should be omitted, on the other hand > every block marked as keyframe should start with a Sequence Header OBU.) You mean in my document or the AV1 specs ? My understanding is that the AV1 bitstream allow Sequence Header OBUs to be found within the stream. And doesn't mention which elements are allowed to change or not. Maybe there will be profiles for such restrictions. It won't be stored in the bitstream (which is frozen) but could be extra data we put in the CodecPrivate. > Andreas Rheinhardt/mkver > > PS: This is my first mail to this list and I hope that it will be > presented as a reply to Steve Lhomme's proposed AV1 mapping in Matroska, > but given the fact that I only subscribed today I can't simply reply, > but had to explicitly set the "In-Reply-To" field. Hope it works. It worked perfectly. Thanks for taking the time to review this ! > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Sat Jun 30 00:50:03 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5656613103B for ; Sat, 30 Jun 2018 00:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9B7ZpcIJfkt7 for ; Sat, 30 Jun 2018 00:49:58 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9FC113103A for ; Sat, 30 Jun 2018 00:49:58 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id g3-v6so5225214pfi.1 for ; Sat, 30 Jun 2018 00:49:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NAMwkE24f69rQ8LoQ2+eJzwKNwgnqDIhvXgFMLJxSgg=; b=uZqPDCNkcJqbiRdp6hRXPs75EkLM3J2vTEbUspTwJG7PzjGXkUt1+1cTVLB3mWHHGO Ut7E0lqKkQJoqBdC9UGdM9sWZ9nX3kdrkPjQEgcgFtcw7gbjpGS3zHb1pPE2H02B/ihV Sn4okjMc32eoaor1fV7YEQbguYX3+Wlldzuli4pN4XDBihqnz+xuc843L4jejSlS0cxP y/iYRJBn/AP5zX8l//iRx03+G+KaPasHeTQ+QLSvZztdMfWCVo4PRuNnSZ+yWqyTCdVh /Ti5dv/coPQEIPhN0h01wnTjlimh++T3l9gmigCd00z5N2K8ChG9KE889v46W/NhGMl5 EfuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NAMwkE24f69rQ8LoQ2+eJzwKNwgnqDIhvXgFMLJxSgg=; b=FAQtYjD6L9BDu2EWDyohVYUnP2z1jQ6jOymP90CllitmeZPI6RyDqcoHm8JAst6w86 v/6QC1Fv9IXLAEX/MmqXk6a9fjYfCZ6sH4/0i5XRCx1nGUvrXyyFfwEYxNycRPZ84U8V zsIEZu//HGOr4+2sFTEjbb/kJqwtkfrCPaHbLcmGH/hJ7NlpbGxZezMkHqAPVqyfnVyz lOSKNPSOWyB3jrF6XyX3hOwBnVfOVYyOGMVZQ6Q0ouZ5QSZ/K9ThbmalIG+j7QG917wl xwAqXbfoyYPqJJEu3BO2czaCxvYobMMsC5fGhS0wrKRfH5aZDO4o/lUaHzDjF50Bqhw8 giZQ== X-Gm-Message-State: APt69E1bH+HO99u7z2R9rO6Wae13hnPrJThqxHci70GP9cu8mWh+TXti 2Ko6ndVND4k689OybmlwjopOCeqW5bGp5SpdKxmrjQ== X-Google-Smtp-Source: AAOMgpfuZIw/3Qy1Wt1iD2QnK7OmPzAb4sn/Vp2TILmI4xKc/iFLmExVL2PQqxTv+iho7AaPQ6KPpJ55bsY4/EPz/Bo= X-Received: by 2002:a62:8d16:: with SMTP id z22-v6mr3943595pfd.181.1530344998203; Sat, 30 Jun 2018 00:49:58 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:17af:0:0:0:0 with HTTP; Sat, 30 Jun 2018 00:49:57 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Sat, 30 Jun 2018 09:49:57 +0200 Message-ID: To: Andreas Rheinhardt Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Cellar] AV1 mapping Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 07:50:00 -0000 I updated my pull request with these 2 changes. 2018-06-30 9:44 GMT+02:00 Steve Lhomme : > Hi, > > > 2018-06-30 0:09 GMT+02:00 Andreas Rheinhardt > : >> Hello, >> >> I have only just started reading the specification, but I already have >> some comments: >> >> 1. Your proposal says that DisplayHeight and DisplayWidth must be set so >> that they agree with what is said in the CodecPrivate/in the bitstream >> so that one can't use the Matroska fields anymore to override what is >> set in the bitstream. If I am not mistaken, then AV1 would be unique in >> this regard among all the video codecs that are allowed in Matroska. I >> don't see a reason for this at all and propose that there shouldn't be a >> special treatment for DisplayHeight and DisplayWidth in AV1. > > You're right. This is a mistake on my part. Instead of MUST it's a > SHOULD. Because Matroska allows to override the codec internal values > to display this differently, including changing the aspect ratio or > forcing physical dimensions. I will change that. > >> 2. Two sequence header OBUs with the same [seq_profile], >> [high_bitdepth], [seq_level_idx] and [color_range] can still differ in >> the [BitDepth] derived from them due to [twelve_bit]. Therefore I wonder >> if this is the right restriction. Wouldn't it be better if it is >> demanded that the derived [BitDepth] coincide for every sequence header OBU? > > It depends if it influences the output of the decoder or the decoder > that can be used. My main concern here is that we have the necessary > information to setup the decoder to start playback and be done with > the duration of the Segment. Otherwise that means the CodecPrivate is > sufficient. > > There's a fine line between being too restrictive and forcing multiple > Segment for a simple internal change in the codec. So we don't want to > restrict too many field from the Sequence Header. But on the other > hand we want to ensure a Segment is consistent, especially regarding > seeking. > > That being said, you're right [high_bitdepth] and [twelve_bit] are the > ones needed to make up the actual [BitDepth] so I will change that. > >> 3. Given that AV1 seems to only use one Sequence Header OBU at a time >> couldn't one use the CodecState and CueCodecState elements to designate >> where the currently active Sequence Header OBU can be found so that one >> doesn't need to repeat the Sequence Header with every keyframe? > > Yes, that would be a good use for when seeking is used. But these > elements were ruled out as deprecated because they were of no use > until now. I know VLC doesn't read them for example. > >> (Btw: There are currently conflicting recommendations regarding the >> existence of Sequence Header OBU if there is actually only one Sequence >> Header OBU. On the one hand, they should be omitted, on the other hand >> every block marked as keyframe should start with a Sequence Header OBU.) > > You mean in my document or the AV1 specs ? My understanding is that > the AV1 bitstream allow Sequence Header OBUs to be found within the > stream. And doesn't mention which elements are allowed to change or > not. Maybe there will be profiles for such restrictions. It won't be > stored in the bitstream (which is frozen) but could be extra data we > put in the CodecPrivate. > >> Andreas Rheinhardt/mkver >> >> PS: This is my first mail to this list and I hope that it will be >> presented as a reply to Steve Lhomme's proposed AV1 mapping in Matroska, >> but given the fact that I only subscribed today I can't simply reply, >> but had to explicitly set the "In-Reply-To" field. Hope it works. > > It worked perfectly. Thanks for taking the time to review this ! > >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar > > > > -- > Steve Lhomme > Matroska association Chairman -- Steve Lhomme Matroska association Chairman From nobody Sat Jun 30 06:54:42 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E0B130DC7 for ; Sat, 30 Jun 2018 06:54:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 85EuWmXG6tFT for ; Sat, 30 Jun 2018 06:54:36 -0700 (PDT) Received: from smtp.mozilla.org (mx2.scl3.mozilla.com [63.245.214.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98C9112F295 for ; Sat, 30 Jun 2018 06:54:36 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 6F5ACC008D for ; Sat, 30 Jun 2018 13:54:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx2.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p7heNcakCmU5 for ; Sat, 30 Jun 2018 13:54:34 +0000 (UTC) Received: from [172.31.0.23] (38-132-129-164.dynamic-broadband.skybest.com [38.132.129.164]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id D84BABFF58 for ; Sat, 30 Jun 2018 13:54:31 +0000 (UTC) To: Codec Encoding for LossLess Archiving and Realtime transmission References: From: "Timothy B. Terriberry" Message-ID: Date: Sat, 30 Jun 2018 06:54:21 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 SeaMonkey/2.49.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] AV1 mapping Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 13:54:40 -0000 Steve Lhomme wrote: > You're right. This is a mistake on my part. Instead of MUST it's a > SHOULD. Because Matroska allows to override the codec internal values > to display this differently, including changing the aspect ratio or > forcing physical dimensions. I will change that. Keep in mind that "SHOULD" tends to have a somewhat stronger force in an IETF specification than in normal English. If you're going to use SHOULD and not MUST, it is a good idea to explain when someone might reasonably violate that SHOULD (if you can't because you can't think of a reason, then you want MUST; if you can't because there are too many reasons, then you want MAY). > You mean in my document or the AV1 specs ? My understanding is that > the AV1 bitstream allow Sequence Header OBUs to be found within the > stream. And doesn't mention which elements are allowed to change or > not. Maybe there will be profiles for such restrictions. It won't be See Section 7.5 "Ordering of OBUs": "Sequence header OBUs may appear in any order within a coded video sequence. Within a particular coded video sequence, the contents of sequence_header_obu must be bit-identical each time the sequence header appears except for the contents of operating_parameters_info. A new coded video sequence is required if the sequence header parameters change." So the question you want to answer is how what is stored in a Matroska file maps to a "coded video sequence". My opinion (as an individual) is that a single EBML Document should correspond to a single coded video sequence. That means that nothing in the sequence header can change (except for the operating_parameters_info). From nobody Sat Jun 30 08:10:54 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713D81294D0 for ; Sat, 30 Jun 2018 08:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f6VSlU-1tPiJ for ; Sat, 30 Jun 2018 08:10:19 -0700 (PDT) Received: from smtp.gentoo.org (smtp.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1ABB127598 for ; Sat, 30 Jun 2018 08:10:19 -0700 (PDT) Received: from eris.local (dynamic-adsl-84-221-239-52.clienti.tiscali.it [84.221.239.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 6AC4D335C89 for ; Sat, 30 Jun 2018 15:10:17 +0000 (UTC) To: cellar@ietf.org References: From: Luca Barbato Message-ID: <528546a0-7795-f432-84b0-fefc4a9b8985@libav.org> Date: Sat, 30 Jun 2018 17:10:03 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] AV1 mapping Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 15:10:22 -0000 On 30/06/2018 15:54, Timothy B. Terriberry wrote: > > So the question you want to answer is how what is stored in a Matroska > file maps to a "coded video sequence". My opinion (as an individual) is > that a single EBML Document should correspond to a single coded video > sequence. That means that nothing in the sequence header can change > (except for the operating_parameters_info). +1 I had to plan for sudden codec reconfiguration because it MAY happen, but I'd rather have it clearly signaled at demuxer level when possible. lu From nobody Sat Jun 30 14:03:15 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD27130E04 for ; Sat, 30 Jun 2018 14:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBgjhcqmoTI2 for ; Sat, 30 Jun 2018 14:03:10 -0700 (PDT) Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81CC2124C04 for ; Sat, 30 Jun 2018 14:03:10 -0700 (PDT) Received: by mail-wr0-x22c.google.com with SMTP id f16-v6so11889506wrm.3 for ; Sat, 30 Jun 2018 14:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=subject:to:references:from:message-id:date:mime-version:in-reply-to :content-transfer-encoding; bh=9ydqtxBSRRRfOTM9v/7ZIYtSLMBtwtS+jU4HFa7EnFQ=; b=NOlk6X4APn73GIFGP9tW9IDgqeACTAIhP6woaThDxJseqiK8DKz57shNlDTmiP/ejB GkuU/vRVz9th5jkfz4nA10UlAkkbjlWsjxvne8SqMzxBqPIJw4rwYoONbv7MZHkVDGhd nXUf40p6zvG07vr32xMq+z/0jOnPCx2kzpKT3ytcorrmk9cI2c86f34+FjB9cm/VLOf0 +LEDUTJ5ajn4c/BiUCli0OEKtRSXlIkSofYubk89aiwBWbgk3MjuLkT1oT5iBbXUC0As PtRlzZc4+MDQRsO1+5bJSILuDdf5hcB7RW22VEazc1qCuf28e81m9jGqPpe2a8zfqR2u 22vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :mime-version:in-reply-to:content-transfer-encoding; bh=9ydqtxBSRRRfOTM9v/7ZIYtSLMBtwtS+jU4HFa7EnFQ=; b=U/qqoj9IrgoG1ZGM9kXzc5OgqDSRLIx7wSzUqm9/TmXHoaCCC/2B02hweY5ZfCPntb jzxW/BFCaLuPIQRpudUa4g0taVUOogWvz3LOjWvcZ/WJXWly+TJg7XF1Y+Y5dchiawBb uuBNQC5Zz2UB3WrGwZT6QOB6AKBeQBLs4eao20l6Hn+fmcKgDAYS46RYtbFoqWLNP6x0 mQobBvijpdR4rSw2MZuSvJ3qUJEGRhJPnxt9/qjW0C9MUr5VazmTU8fVy+o3/HWySnXA iVUsuoa/MeyFo5LLdXJbOWQpKIacWboWKwzMqaYLiIL1qzCYae/w6qNegvjM+raSOAWG NJ4g== X-Gm-Message-State: APt69E1fJxvo2QEFosd8s+lJla3HMhyDY1DsRsVSsouyKyXVIiwCTxXC O+6km3AatShLxDw26xsqkBdzGPAihLE= X-Google-Smtp-Source: AAOMgpciV0dA8ZCCb/fp8dpu9qe5v8ETPQ3VxaYNu/26GeT3BG9lHPI4zngAOjsoN2UQtt1sl5fBsw== X-Received: by 2002:adf:9883:: with SMTP id w3-v6mr16741856wrb.9.1530392588816; Sat, 30 Jun 2018 14:03:08 -0700 (PDT) Received: from [127.0.0.1] (178-175-135-100.static.as43289.net. [178.175.135.100]) by smtp.googlemail.com with ESMTPSA id s200-v6sm10190701wmb.44.2018.06.30.14.03.06 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Jun 2018 14:03:07 -0700 (PDT) To: cellar@ietf.org References: From: Andreas Rheinhardt Message-ID: Date: Sat, 30 Jun 2018 21:02:00 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] AV1 mapping Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 21:03:14 -0000 Hello, 1. Steve Lhomme: >> 3. Given that AV1 seems to only use one Sequence Header OBU at a time >> couldn't one use the CodecState and CueCodecState elements to designate >> where the currently active Sequence Header OBU can be found so that one >> doesn't need to repeat the Sequence Header with every keyframe? > > Yes, that would be a good use for when seeking is used. But these > elements were ruled out as deprecated because they were of no use > until now. I know VLC doesn't read them for example. Are you sure that it is deprecated? I couldn't find anything that says this and the current version of the Codec Specs contains this: "When the Initialisation is updated within a track then that updated Initialisation data MUST be written into the CodecState Element of the first Cluster to require it." (Btw: This requirement is not fulfilled for the way H.264 is commonly muxed into Matroska.) Your draft also includes nothing that indicates that CodecState is deprecated. Anyway, given that this element is not part of WebM means that it can't be used in Matroska either if one (sensibly) wants only one codec mapping for both. >> (Btw: There are currently conflicting recommendations regarding the >> existence of Sequence Header OBU if there is actually only one Sequence >> Header OBU. On the one hand, they should be omitted, on the other hand >> every block marked as keyframe should start with a Sequence Header OBU.) > > You mean in my document or the AV1 specs ? In your document. I have already made a PR for this. Timothy B. Terriberry has misunderstood what I had in mind: At one place the draft said that every keyframe should have a sequence header OBU and at another place it said that there shouldn't be in-band sequence header OBUs if all of them coincide. This is contradictory in case all of the sequence header OBUs coincide. 2. How does one signal the difference between a real KEY_FRAME and an INTRA_ONLY_FRAME (that isn't a valid random access point) when using blocks (that don't have a keyframe flag)? According to your draft, the relevant `BlockGroup` won't have any `ReferenceBlocks` so that both frame types are indistinguishable at the container level when using `BlockGroup`s (if the muxer knows how to handle AV1 it should of course not reference an INTRA_ONLY_FRAME in the cues, but it would really be advantageous to be able to infer this without resorting to cues which are optional anyway and unavailable for e.g. live-streaming). 3. There is something wrong with the invisible flag: a) According to 7.5. every temporal unit contains at least one frame for which [show_frame] || [show_existing_frame] equals 1, i.e. for each Matroska block there is an output frame (even if said output frame is only from a frame buffer and not from data directly contained in the Matroska block). This implies that actually no block should have the invisible flag bit set. And if it is set, it actually means that the frame that should normally be output due to said frame should not be displayed (regardless of whether the frame that would normally be output is one of the already existing ([show_existing_frame] == 1) frames or not). Otherwise we'd be breaking the semantics of the invisible flag (and therefore make it impossible to hide individual frames of an already encoded AV1 track). b) If one nevertheless wants to map the invisible flag to properties of the track, it IMO shouldn't be done the way it is currently proposed: i) It is possible that [show_frame] equals 1 (meaning the frame should be immediately be output) and [showable_frame] is 1 (namely if [frame_type] is not KEY_FRAME). In your draft the invisible bit should be set to 1 for such a `Block` meaning that the frame should not be displayed although it should be immediately output. This is obviously wrong. ii) Apart from that there is the problem that a temporal unit can contain more than one frame. iii) A frame might also be displayed later if [showable_frame] equals 1. So the closest to a invisible frame seems to be a frame with [show_frame] and [showable_frame] equal to zero. So a temporal unit that contains only frames with [show_frame] and [showable_frame] equal to 0 seems to be a sensible choice to merit the invisible flag. (Such a temporal unit must contain a frame with [show_existing_frame] equal to 1.) 4. There is currently no hard requirement that only real random access points get flagged as keyframes in Matroska/WebM. The current wording is only a "SHOULD". Is this really intended? 5. Given that changing extradata are not that uncommon in H.264 I don't deem it a good idea to restrict Matroska to one coded video sequence. This might end up excluding a lot of content from being muxed into Matroska (and it makes it much harder to append different tracks). Andreas Rheinhardt