From nobody Tue May 3 22:07:08 2016 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 BF39D12D172 for ; Tue, 3 May 2016 22:07:06 -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 vfDSfE_jbk1j for ; Tue, 3 May 2016 22:07:05 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 0B43F12D170 for ; Tue, 3 May 2016 22:07:04 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:35394 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1axp1Y-000TR3-QB; Wed, 04 May 2016 01:07:01 -0400 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_93F8F4EB-6C39-460B-B70D-A5418192205B" Message-Id: Date: Wed, 4 May 2016 01:07:01 -0400 To: cellar@ietf.org, "Timothy B. Terriberry" , Tessa Fallon Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) 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: [Cellar] timeline updates X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 05:07:07 -0000 --Apple-Mail=_93F8F4EB-6C39-460B-B70D-A5418192205B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tim, Tessa, and others, The working group charter page now refers to some timeline events in the = past that haven=E2=80=99t happened: = https://datatracker.ietf.org/wg/cellar/charter/ = . I propose replacing the two April milestones with: May 2016 Submit informational specification for EBML version 1 to = IESG for publication Jun 2016 Submit informational specification for Matroska = container format versions 1, 2, 3, and 4 to IESG for publication Jul 2016 Submit informational specification for FFV1 video codec = versions 0, 1 and 3 to IESG for publication In additional to moving the time of the milestone forward in time = (though still before the IETF96), I=E2=80=99m splitting EBML and = Matroska into two separate milestones and also adding Matroska version 4 = into the same initial Matroska milestone. Comments? Best Regards, Dave Rice --Apple-Mail=_93F8F4EB-6C39-460B-B70D-A5418192205B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Tim, Tessa, and others,

The working group charter page now refers to some timeline = events in the past that haven=E2=80=99t happened: https://datatracker.ietf.org/wg/cellar/charter/.

I propose replacing the = two April milestones with:

May 2016 Submit informational = specification for EBML version 1 to IESG for publication
Jun 2016 Submit informational = specification for Matroska container format versions 1, 2, 3, and 4 to = IESG for publication
Jul 2016 Submit = informational specification for FFV1 video codec versions 0, 1 and 3 to = IESG for publication

In additional to moving the time of the milestone forward in = time (though still before the IETF96), I=E2=80=99m splitting EBML and = Matroska into two separate milestones and also adding Matroska version 4 = into the same initial Matroska milestone.

Comments?

Best Regards,
Dave = Rice

= --Apple-Mail=_93F8F4EB-6C39-460B-B70D-A5418192205B-- From nobody Tue May 3 22:07:17 2016 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 39E1D12D198 for ; Tue, 3 May 2016 22:07:16 -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 K2jvmHiukbqt for ; Tue, 3 May 2016 22:07:15 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 7123C12D18A for ; Tue, 3 May 2016 22:07:15 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:35394 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1axp1k-000TR3-Br; Wed, 04 May 2016 01:07:12 -0400 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 4 May 2016 01:07:14 -0400 To: cellar@ietf.org, "Timothy B. Terriberry" , Tessa Fallon Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) 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: [Cellar] IETF96 meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 05:07:16 -0000 Hi all, but in particular Tim, Tessa, and those who have participated in = organizing events at IETF conferences before, Since many of the participants of the working group are near Berlin I = suggest having a working group meeting at the conference. How should we = go about proposing this? If there any protocol to suggest a meeting on = the Tuesday or Wednesday of that week? Best Regards, Dave Rice= From nobody Tue May 3 22:19:27 2016 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 0BF7B12D124 for ; Tue, 3 May 2016 22:19:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 Q3TIBwqwwhBs for ; Tue, 3 May 2016 22:19:24 -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 3785612D0A3 for ; Tue, 3 May 2016 22:19:24 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 920E6C3427 for ; Wed, 4 May 2016 05:19:23 +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 3kkrd8Zf_3Zd for ; Wed, 4 May 2016 05:19:23 +0000 (UTC) Received: from [172.17.0.79] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 386C3C0526 for ; Wed, 4 May 2016 05:19:23 +0000 (UTC) Message-ID: <5729865A.8050208@xiph.org> Date: Tue, 03 May 2016 22:19:22 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: cellar@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] IETF96 meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 05:19:26 -0000 Dave Rice wrote: > How should we go about proposing this? Either Tessa or I can request a session be scheduled. Just let us know the details. I assume one session is enough? We can request any time between half an hour and two and a half hours (more than that requires multiple sessions). Do you have a rough estimate of the number of attendees? Are there any other WGs you'd like to avoid a conflict with? > If there any protocol to suggest a meeting on the Tuesday or Wednesday of that week? There's a Special Requests section where we can ask. I don't know how often that's done (not for any WGs I've been involved with), so I don't know how likely that is to be accommodated. From nobody Tue May 3 22:27:26 2016 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 03D2412D124 for ; Tue, 3 May 2016 22:27:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 KbTJ7w4VX2Xx for ; Tue, 3 May 2016 22:27:23 -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 BC56412D0E2 for ; Tue, 3 May 2016 22:27:23 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 8384BC051C for ; Wed, 4 May 2016 05:27:23 +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 7AyKeVI3jQzf for ; Wed, 4 May 2016 05:27:23 +0000 (UTC) Received: from [172.17.0.79] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 390E6C02FD for ; Wed, 4 May 2016 05:27:23 +0000 (UTC) Message-ID: <5729883B.4070307@xiph.org> Date: Tue, 03 May 2016 22:27:23 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: cellar@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] timeline updates X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 05:27:25 -0000 Dave Rice wrote: > two separate milestones and also adding Matroska version 4 into the same > initial Matroska milestone. The reason versions 1, 2, and 3 were separated from version 4 is that the first three were expected to be in an Informational document, and the last one was expected to be Standards Track. I assume you didn't mean that you wanted to publish version 4 as Informational instead? From nobody Tue May 3 22:40:13 2016 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 19C7C12D17D for ; Tue, 3 May 2016 22:40:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 4iVLSiGoIkcD for ; Tue, 3 May 2016 22:40:10 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 BAC0112D170 for ; Tue, 3 May 2016 22:40:10 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u445dRkP029210 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 May 2016 00:39:28 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Dave Rice" Date: Wed, 04 May 2016 00:39:26 -0500 Message-ID: <1E211E3A-6CB8-4EAE-BF86-7C5A3228CF58@nostrum.com> In-Reply-To: <5729865A.8050208@xiph.org> References: <5729865A.8050208@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: cellar@ietf.org, "Timothy B. Terriberry" Subject: Re: [Cellar] IETF96 meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 05:40:12 -0000 On 4 May 2016, at 0:19, Timothy B. Terriberry wrote: > If there any protocol to suggest a meeting on the Tuesday or Wednesday > of that week? > > > There's a Special Requests section where we can ask. I don't know how > often that's done (not for any WGs I've been involved with), so I > don't know how likely that is to be accommodated. Hi David, We will try to accommodate such requests as best we can, but there's no guaranty. Also, please consider whether it is really needed. Scheduling all the working group meetings at a full IETF meeting is pretty complicated, and constraints like this make it more so. Thanks, Ben. From nobody Wed May 4 09:07:48 2016 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 7365B12DCD2 for ; Wed, 4 May 2016 09:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 jiEdM3_0kUpE for ; Wed, 4 May 2016 09:07:44 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F12DB12DB53 for ; Wed, 4 May 2016 08:59:14 -0700 (PDT) Received: from [192.168.0.14] (chello213047163139.5.15.vie.surfer.at [::ffff:213.47.163.139]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 04 May 2016 17:59:10 +0200 id 0000000000000037.00000000572A1C4E.000035C9 Message-ID: <572A1C4E.60104@das-werkstatt.com> Date: Wed, 04 May 2016 17:59:10 +0200 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: cellar@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] IETF96 meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 16:07:47 -0000 Hi Dave, On 05/04/2016 07:07 AM, Dave Rice wrote: > If there any protocol to suggest a meeting on the Tuesday or Wednesday of that week? Just to clarify: Tuesday/Wednesday *before* the IETF96 (July 12., 13.) ...or during the IETF96: July 19., 20. ? Additionally: Has anyone yet registered for the IETF96? On the website [1] it says that online registration starts at April 25th, but the link is still not enabled :( Thanks and regards, Pb == References: [1] http://ietf.org/meeting/important-dates-2016.html#ietf96 From nobody Wed May 4 10:09:48 2016 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 0E7D212D0CE for ; Wed, 4 May 2016 10:09:47 -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 zuAtCrgeR7Oi for ; Wed, 4 May 2016 10:09:43 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 9DD6912D108 for ; Wed, 4 May 2016 10:07:44 -0700 (PDT) Received: from [146.96.19.240] (port=16984 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1ay0Gv-002kzG-1e; Wed, 04 May 2016 13:07:41 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <5729865A.8050208@xiph.org> Date: Wed, 4 May 2016 13:07:37 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8038712D-919D-4723-8F8D-936909CEC033@dericed.com> References: <5729865A.8050208@xiph.org> To: "Timothy B. Terriberry" X-Mailer: Apple Mail (2.3112) 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: Cc: cellar@ietf.org Subject: Re: [Cellar] IETF96 meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 17:09:47 -0000 > On May 4, 2016, at 1:19 AM, Timothy B. Terriberry = wrote: >=20 > Dave Rice wrote: >> How should we go about proposing this? >=20 > Either Tessa or I can request a session be scheduled. Just let us know = the details. I assume one session is enough? We can request any time = between half an hour and two and a half hours (more than that requires = multiple sessions). Do you have a rough estimate of the number of = attendees? I don't have any IETF conference experience to know this well (others?). = I'm coordinating another event in Berlin related to using Matroska and = FFV1 at the Deutsche Kinemathek within archives so some of that group = may likely attend. To attend the working group meeting in person, is the = minimal sufficient registration for attendance a day pass? > Are there any other WGs you'd like to avoid a conflict with? netvc certainly. Are there other active audiovisual working groups? Dave Rice= From nobody Wed May 4 10:12:05 2016 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 5AF8812D77A for ; Wed, 4 May 2016 10:12:03 -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 L40Z6ZnISSSv for ; Wed, 4 May 2016 10:12:02 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 0407B12D7E0 for ; Wed, 4 May 2016 10:10:38 -0700 (PDT) Received: from [146.96.19.240] (port=18684 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1ay0Jl-002vop-I6; Wed, 04 May 2016 13:10:34 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <1E211E3A-6CB8-4EAE-BF86-7C5A3228CF58@nostrum.com> Date: Wed, 4 May 2016 13:10:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <466F4C1E-1714-4DD7-B2F3-E21A113B4B13@dericed.com> References: <5729865A.8050208@xiph.org> <1E211E3A-6CB8-4EAE-BF86-7C5A3228CF58@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3112) 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: Cc: cellar@ietf.org, "Timothy B. Terriberry" Subject: Re: [Cellar] IETF96 meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 17:12:03 -0000 > On May 4, 2016, at 1:39 AM, Ben Campbell wrote: >=20 > On 4 May 2016, at 0:19, Timothy B. Terriberry wrote: >=20 >> If there any protocol to suggest a meeting on the Tuesday or = Wednesday of that week? >>=20 >>=20 >> There's a Special Requests section where we can ask. I don't know how = often that's done (not for any WGs I've been involved with), so I don't = know how likely that is to be accommodated. >=20 > Hi David, >=20 > We will try to accommodate such requests as best we can, but there's = no guaranty. Also, please consider whether it is really needed. = Scheduling all the working group meetings at a full IETF meeting is = pretty complicated, and constraints like this make it more so. This is a not a worthy excuse but I'm suggesting Tuesday or Wednesday in = coordination with other Matroska/FFV1-related events in Berlin as well = as the fact that I already purchased a ticket to travel from Berlin to = London on Thursday. Monday works as well. If it happened on Thursday or = Friday I could perhaps participate remotely if not in travel. Kind Regards, Dave Rice= From nobody Wed May 4 10:12:55 2016 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 8B5A112D108 for ; Wed, 4 May 2016 10:12:54 -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 jbFri9BP51TZ for ; Wed, 4 May 2016 10:12:53 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 B431712D1C2 for ; Wed, 4 May 2016 10:11:42 -0700 (PDT) Received: from [146.96.19.240] (port=19361 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1ay0Ko-002wXl-UC; Wed, 04 May 2016 13:11:39 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <572A1C4E.60104@das-werkstatt.com> Date: Wed, 4 May 2016 13:11:39 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1855B5D6-9097-46DD-8EE2-1996AB5E6D36@dericed.com> References: <572A1C4E.60104@das-werkstatt.com> To: Peter Bubestinger X-Mailer: Apple Mail (2.3112) 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: Cc: cellar@ietf.org Subject: Re: [Cellar] IETF96 meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 17:12:54 -0000 > On May 4, 2016, at 11:59 AM, Peter B. wrote: >=20 > Hi Dave, >=20 > On 05/04/2016 07:07 AM, Dave Rice wrote: >> If there any protocol to suggest a meeting on the Tuesday or = Wednesday of that week? >=20 > Just to clarify: >=20 > Tuesday/Wednesday *before* the IETF96 (July 12., 13.) > ...or during the IETF96: July 19., 20. ? During. See you there! > Additionally: > Has anyone yet registered for the IETF96? > On the website [1] it says that online registration starts at April > 25th, but the link is still not enabled :( :( , Dave Rice= From nobody Wed May 4 10:17:35 2016 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 66E5612D1DA for ; Wed, 4 May 2016 10:17:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.895 X-Spam-Level: X-Spam-Status: No, score=-2.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.996] 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 bDjfK-t_dTTf for ; Wed, 4 May 2016 10:17:32 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 CE47F12D6DE for ; Wed, 4 May 2016 10:17:31 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u44HHPVS016221 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 May 2016 12:17:26 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: "Peter B." , cellar@ietf.org References: <572A1C4E.60104@das-werkstatt.com> From: Adam Roach Message-ID: Date: Wed, 4 May 2016 12:17:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <572A1C4E.60104@das-werkstatt.com> Content-Type: multipart/alternative; boundary="------------053336983E5504DFA1B768DD" Archived-At: Subject: Re: [Cellar] IETF96 meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 17:17:33 -0000 This is a multi-part message in MIME format. --------------053336983E5504DFA1B768DD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 5/4/16 10:59 AM, Peter B. wrote: > Additionally: > Has anyone yet registered for the IETF96? > On the website [1] it says that online registration starts at April > 25th, but the link is still not enabled:( I'll contact the secretariat. Thanks for pointing this out. /a --------------053336983E5504DFA1B768DD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 5/4/16 10:59 AM, Peter B. wrote:
Additionally:
Has anyone yet registered for the  IETF96?
On the website [1] it says that online registration starts at April
25th, but the link is still not enabled :(


I'll contact the secretariat. Thanks for pointing this out.


/a

--------------053336983E5504DFA1B768DD-- From nobody Wed May 4 10:35:38 2016 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 08BA712D7FE for ; Wed, 4 May 2016 10:35:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 IUsZmQ5WFKFl for ; Wed, 4 May 2016 10:35:35 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 D6A5812D6D8 for ; Wed, 4 May 2016 10:35:33 -0700 (PDT) Received: from [10.0.1.18] (cpe-70-119-246-39.tx.res.rr.com [70.119.246.39]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id u44HYpYu017738 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 May 2016 12:34:51 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-246-39.tx.res.rr.com [70.119.246.39] claimed to be [10.0.1.18] From: "Ben Campbell" To: "Dave Rice" Date: Wed, 04 May 2016 12:34:50 -0500 Message-ID: In-Reply-To: <466F4C1E-1714-4DD7-B2F3-E21A113B4B13@dericed.com> References: <5729865A.8050208@xiph.org> <1E211E3A-6CB8-4EAE-BF86-7C5A3228CF58@nostrum.com> <466F4C1E-1714-4DD7-B2F3-E21A113B4B13@dericed.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: cellar@ietf.org, "Timothy B. Terriberry" Subject: Re: [Cellar] IETF96 meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 17:35:37 -0000 On 4 May 2016, at 12:10, Dave Rice wrote: >> On May 4, 2016, at 1:39 AM, Ben Campbell wrote: >> >> On 4 May 2016, at 0:19, Timothy B. Terriberry wrote: >> >>> If there any protocol to suggest a meeting on the Tuesday or >>> Wednesday of that week? >>> >>> >>> There's a Special Requests section where we can ask. I don't know >>> how often that's done (not for any WGs I've been involved with), so >>> I don't know how likely that is to be accommodated. >> >> Hi David, >> >> We will try to accommodate such requests as best we can, but there's >> no guaranty. Also, please consider whether it is really needed. >> Scheduling all the working group meetings at a full IETF meeting is >> pretty complicated, and constraints like this make it more so. > > This is a not a worthy excuse but I'm suggesting Tuesday or Wednesday > in coordination with other Matroska/FFV1-related events in Berlin as > well as the fact that I already purchased a ticket to travel from > Berlin to London on Thursday. Monday works as well. If it happened on > Thursday or Friday I could perhaps participate remotely if not in > travel. Coordination with a related event is a perfectly good reason. Thanks! Ben. From nobody Wed May 4 11:55:48 2016 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 9DA2012D14B for ; Wed, 4 May 2016 11:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 mAkV4q1I_SgF for ; Wed, 4 May 2016 11:55:45 -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 2637612D0A7 for ; Wed, 4 May 2016 11:55:45 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 9A2CDC0BF6 for ; Wed, 4 May 2016 18:55:44 +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 PPeJDY7fYYiY for ; Wed, 4 May 2016 18:55:44 +0000 (UTC) Received: from [10.252.26.84] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 86C0BC0BEE for ; Wed, 4 May 2016 18:55:44 +0000 (UTC) Message-ID: <572A45B0.2010301@xiph.org> Date: Wed, 04 May 2016 11:55:44 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: cellar@ietf.org References: <5729865A.8050208@xiph.org> <8038712D-919D-4723-8F8D-936909CEC033@dericed.com> In-Reply-To: <8038712D-919D-4723-8F8D-936909CEC033@dericed.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] IETF96 meeting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 04 May 2016 18:55:46 -0000 Dave Rice wrote: > I'm coordinating another event in Berlin related to using Matroska > and FFV1 at the Deutsche Kinemathek within archives so some of that > group may likely attend. Any rough estimate of how big that other group will be? > To attend the working group meeting in person, is the minimal > sufficient registration for attendance a day pass? Correct. >> Are there any other WGs you'd like to avoid a conflict with? > > netvc certainly. Are there other active audiovisual working groups? There are a number of other WGs in the Applications and Real-Time (ART) Area... I was already planning to add the ones that I personally will need to attend, but if there's something from an area, just let me know. From nobody Sun May 8 04:42:38 2016 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 A4EEF12D0DF for ; Sun, 8 May 2016 04:42:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 rMXG2WL_yLfM for ; Sun, 8 May 2016 04:42:35 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002: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 B3AB912D09F for ; Sun, 8 May 2016 04:42:35 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id t10so261411599ywa.0 for ; Sun, 08 May 2016 04:42:35 -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:date:message-id:subject:from:to :cc; bh=6HYMzdQyjnd27VZU1HqBCNlVxsMoO2iRso6t0so9GOo=; b=R86eI2yY+Gkmt242Wp9NM436btmYlicu8+JhaVOhaL415fDorPqjEaPHxPzCmZsg7V IDZ6AMI0a+G27Ry6e3rbX8sQkzJ44EThXlcq6Pj44Uwp1jUykojtmQQ9LCW+3KHvKDtY 11l4AQP9aRDMD6d23DpPSZsZT7pZLbIwlydeX70ega+6CLF88LMoOePkdApk/N78bq25 nfgcYhEB4i3L0OYJnvbgrHvKitdbmxxmHPJ38IZOtnpd4M5kmgpxz+3JJq7npLrBoGlu HL+UmEag6fCjogm2Ec6DNclQ71vSXs3vXj8oSgrIvQKp2igamEv1WwfrNkgqV1Q6f0vM twOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=6HYMzdQyjnd27VZU1HqBCNlVxsMoO2iRso6t0so9GOo=; b=H6cYnVoWriaLkU8YXAQYu32lFTbUDWU0U2gxnK0jEef1FZLtCzHP4R4FhYCQJ30RuR zTj+vfemZakBhpEK/XmFA46J52KTIOwJuP3f9HDP+uw2ywDwS5UuE8cdNitqTEqKVSor pKQBFrgBhCqztTQgHqKTOeHxwCwAE4paBDfbY7GqqVasul2g2gPdLoYnpM+KlUIv+ddx w5nEbDVUbK/Hu3vu2vIaK/AJUPsBYNkdameXKvFO8cd+W8FqlavgQDv93HOEsM2ZBCVz alt1jQk9HcZMiqyO5kakJDmBbGG+DnKm1Tb/3nvw7HHvzx0fEPQCCZZ1myeDA3ylSSmc 9sOA== X-Gm-Message-State: AOPr4FUb3Skor/SmivLUmOBDk5BLdUuvYnvIQ0HDus7Vk5tHmpCjDnsaP9xgKVhXH8t0fm6ckS5xz8EPcnHU7A== MIME-Version: 1.0 X-Received: by 10.129.43.68 with SMTP id r65mr17125518ywr.327.1462707754804; Sun, 08 May 2016 04:42:34 -0700 (PDT) Received: by 10.83.48.81 with HTTP; Sun, 8 May 2016 04:42:34 -0700 (PDT) In-Reply-To: <08896C4C-F809-4614-9489-21A16D9BE12D@dericed.com> References: <1ED4498D-FC22-4D36-8163-BCA301FD4738@dericed.com> <20160418155706.GI30912@bunkus.org> <08896C4C-F809-4614-9489-21A16D9BE12D@dericed.com> Date: Sun, 8 May 2016 13:42:34 +0200 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: cellar@ietf.org, Moritz Bunkus Subject: Re: [Cellar] patch on textual expressions of floats in EBML Schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 May 2016 11:42:38 -0000 2016-04-18 18:00 GMT+02:00 Dave Rice : > >> On Apr 18, 2016, at 11:57 AM, Moritz Bunkus wrote: >> >> Hey, >> >>>> I think the parser can resolve this issue without much trouble. In this >>> context, the hyphen expresses a negative binary power, when it is preceded >>> by a 'P' or 'p'. On the other hand, the hyphen serves as the delimiter >>> between the minimum and maximum values, when it is not preceded by a 'P' or >>> 'p'. This criterion can be used to distinguish the two cases. >> >> I agree. If a p occurs the following element must be the >> exponent. Therefore there's no ambiguity. > > Regarding such interpretation, currently specdata.xml expresses float range in a style of "0.0-1.0". Should we say that both forms are valid as ranges? Or that "0x0p+1-0x1p+0" is valid but "0.0-1.0" is invalid. For the moment the range value is not used to generate code. Only "0-1" integers are assumed to be boolean. So these changes won't affect the generated code. >>> In this context, does 'float' mean only 32-bit floats, or does it mean >>> both 32-bit floats and 64-bit doubles? If it is the latter, then I think >>> 'floating constant' (given in the C11 standard) may be a more unambiguous >>> term. >> >> The specs always talk about the numerical types as they apply to EBML >> (section "EBML Element Types" at [1]). We don't talk about data types in >> a specific programming language; that's an implementation detail the >> specs shouldn't care about. So "float" means up to 64bits, just as >> "unsigned integer" does. We don't say "uint64_t" there either. >> >> Kind regards, >> mosu >> >> [1] https://github.com/Matroska-Org/ebml-specification/blob/master/specification.markdown >> _______________________________________________ >> 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 > -- Steve Lhomme Matroska association Chairman From nobody Sun May 8 05:05:34 2016 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 6E07E12D09C for ; Sun, 8 May 2016 05:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 6ivGF5eeBRyP for ; Sun, 8 May 2016 05:05:31 -0700 (PDT) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::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 A1CDD12B04A for ; Sun, 8 May 2016 05:05:31 -0700 (PDT) Received: by mail-yw0-x235.google.com with SMTP id o66so261469223ywc.3 for ; Sun, 08 May 2016 05:05:31 -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:date:message-id:subject:from:to :cc; bh=N7jdOToFqdz5XZjvLj3aLl0OkTr4c6TofYOe/dtjQoY=; b=NL937x8jw6QOefDoEfb978SwPGPYyHYKJ/5oYSIuaWBWVmhUlPB3Uz/Y7JFQDH+7b4 LYkQ4lem6CGy7Hkmvwr+ImuYg6Xbk+SzboLHixMyF5Qv7aV+8sqk+QTs6hmwphPqAGcJ eVPhkwbO6lA0dV3WoeB+Qd++xmkX+0TULbnZJMrQPpwDiaP9EoabKGvpHwMG2RhF2KEX ufO3gjMg0hzdpafiP3mZYy2G5TJHvf/I+z4KoPgLefKXSHPghsW2dkY30rPzQMJiy+9Z aRvBidmY1Onx51zP9IxSl6eN/4NKlCTpLC7zcyUVIhwCeFEcptj4jTas0/Diw5nVFvqr InJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=N7jdOToFqdz5XZjvLj3aLl0OkTr4c6TofYOe/dtjQoY=; b=aZ9GqJFfNpWde+YwyIH4+yBUter778ueHhTCpdjCx52C294YssOtxb1aebsUNxrept vJKBHuNtY9X+Pjkh5xHC8Erf+CXwVDkAmnojyDxs2nEOvRw9dfrihpmdc1mXe3Ex5Bto iZcMTdT9Bsnq25AQJoJnXzgPJK8aHdImxoeuLcDwZNt9gq3hpUitpbLTAvQzF0eg3aHF xdKwuLQjmq2QIVM0liHWOFWtS6s1rNNwp1ebd9Zr/TciVc9F/IcqBgm7GM80tXIqHNuY djSWGgCTZ5HpVg37bMnv0Kq4ZtYCQcmWvJYmdueQzsGHCtpQBo7dPZQZ18QsoR2OtIZP A5YQ== X-Gm-Message-State: AOPr4FXBZgT4mEel6+QadYmpLg7ewunjC1/sjgUOXJG1/O4v9usljlCEqquXO7V0VRAsiV5TPli3q5UGnT25ew== MIME-Version: 1.0 X-Received: by 10.37.50.147 with SMTP id y141mr5362287yby.98.1462709130803; Sun, 08 May 2016 05:05:30 -0700 (PDT) Received: by 10.83.48.81 with HTTP; Sun, 8 May 2016 05:05:30 -0700 (PDT) In-Reply-To: References: Date: Sun, 8 May 2016 14:05:30 +0200 Message-ID: From: Steve Lhomme To: Nithin Mathew Kurien Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Discussion about the current and future development of Matroska , cellar@ietf.org Subject: Re: [Cellar] Channel Positions for Multichannel LPCM Track Inside Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 08 May 2016 12:05:33 -0000 2016-04-24 17:39 GMT+02:00 Nithin Mathew Kurien : > Hi, > > Currently the specification for storing a multichannel LPCM track (CodecID > A_PCM/INT/LIT) inside a Matroska file [1, 2], does not specify a way to > indicate the channel positions of the track. Due to this, players find it > difficult to map the channels to the correct speaker positions when playing > such a track. MakeMKV employs a workaround for this problem. It stores the > track under the CodecID A_MS/ACM, along with a WAVEFORMATEXTENSIBLE > structure in CodecPrivate. This structure contains a field called > dwChannelMask which specifies the channel positions [3]. This is identical > to the way LPCM is stored inside AVI files. The problem with this approach > is that most players do not recognise the CodecID A_MS/ACM, except for a few > open-source players like Kodi [4]. We used to have a field for that but it was never used AFAIK https://matroska.org/technical/specs/index.html#ChannelPositions This is how it used to be, describing each speaker position with an angle. I don't know there is a standard way to express this. I'd assume the distance to the center should play a role too. https://web.archive.org/web/20071211091532/http://www.matroska.org/technical/specs/channelposition/index.html > In the case of a FLAC track (inside either a raw .FLAC file or a .MKA file), > we can specify an optional WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag [5]. Could > a similar solution be implemented for LPCM inside Matroska too? > > On a related note, the ffmpeg documentation [6] specifies additional channel > positions which are not found in the Microsoft documentation [3], like Wide > Left and Wide Right speakers. Are these speaker positions recognised by > players when reading WAV files? VLC currently handles 'only' 9 speaker positions out of the 18 MS ones. > [1] https://matroska.org/technical/specs/codecid/index.html > [2] http://haali.su/mkv/codecs.pdf > [3] > https://msdn.microsoft.com/en-us/library/windows/hardware/dn653308(v=vs.85).aspx > [4] http://www.makemkv.com/forum2/viewtopic.php?f=8&t=2530 > [5] https://sourceforge.net/p/mediainfo/discussion/297609/thread/164b4fb3/ > [6] https://ffmpeg.org/doxygen/2.2/channel__layout_8h_source.html > > Thanks and regards, > Nithin > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > -- Steve Lhomme Matroska association Chairman From nobody Mon May 9 15:28:02 2016 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 5D00912D0B9; Mon, 9 May 2016 15:27:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160509222749.18333.59331.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2016 15:27:49 -0700 Archived-At: Cc: tterriberry@mozilla.com, ben@nostrum.com, cellar@ietf.org, cellar-chairs@ietf.org Subject: [Cellar] cellar - New Meeting Session Request for IETF 96 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 09 May 2016 22:27:53 -0000 A new meeting session request has just been submitted by Tim Terriberry, a Chair of the cellar working group. --------------------------------------------------------- Working Group Name: Codec Encoding for LossLess Archiving and Realtime transmission Area Name: Applications and Real-Time Area Session Requester: Tim Terriberry Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: rtcweb avtcore netvc Second Priority: mmusic avtext Third Priority: acme tcpinc tls webpush Special Requests: If possible, we would prefer a slot on Tuesday or Wednesday, in order to coordinate with other Matroska/FFV1-related events in Berlin. Failing those, Monday is the next best day. Thanks. --------------------------------------------------------- From nobody Mon May 9 15:32:40 2016 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 706B112D156 for ; Mon, 9 May 2016 15:32:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160509223237.18357.94817.idtracker@ietfa.amsl.com> Date: Mon, 09 May 2016 15:32:37 -0700 From: IETF Secretariat Archived-At: Subject: [Cellar] Milestones changed for cellar WG X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 09 May 2016 22:32:37 -0000 Changed milestone "Submit informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication", set due date to June 2016 from April 2016. Changed milestone "Submit informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication", set due date to July 2016 from April 2016. URL: https://datatracker.ietf.org/wg/cellar/charter/ From nobody Mon May 9 15:48:28 2016 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 A205512D149 for ; Mon, 9 May 2016 15:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 O9ZU2CznHoQb for ; Mon, 9 May 2016 15:48:25 -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 C5E6C12D0CE for ; Mon, 9 May 2016 15:48:24 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 50318C1A98 for ; Mon, 9 May 2016 22:48:24 +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 uQug3E-uInIy for ; Mon, 9 May 2016 22:48:24 +0000 (UTC) Received: from [10.252.26.63] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 3CF2AC0608 for ; Mon, 9 May 2016 22:48:24 +0000 (UTC) Message-ID: <573113B8.6070702@xiph.org> Date: Mon, 09 May 2016 15:48:24 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: cellar@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cellar] Call for consensus to add a milestone for EBML X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 09 May 2016 22:48:27 -0000 In order to adopt the (hopefully forthcoming) EBML Internet-Draft as a working-group item, we need to add a milestone, which requires Area Director review. As such, I'd like to establish working-group consensus for whether or not we should add the following milestone: "Submit informational specification for EBML version 1 to IESG for publication" This will be a one-week call for consensus. Please respond to this message on or before 16 May if you support or oppose adding this milestone. -Timothy B. Terriberry, for the chairs. From nobody Mon May 9 15:51:11 2016 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 7E4AC12D0CE for ; Mon, 9 May 2016 15:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.235 X-Spam-Level: X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 nzh7uwCnHtXm for ; Mon, 9 May 2016 15:51:09 -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 0EF8712D0A2 for ; Mon, 9 May 2016 15:51:09 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id A7D3FC3473 for ; Mon, 9 May 2016 22:51:08 +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 4ceCY3zzkXqg for ; Mon, 9 May 2016 22:51:08 +0000 (UTC) Received: from [10.252.26.63] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 953C8C0F3B for ; Mon, 9 May 2016 22:51:08 +0000 (UTC) Message-ID: <5731145C.7020102@xiph.org> Date: Mon, 09 May 2016 15:51:08 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: cellar@ietf.org References: <5729883B.4070307@xiph.org> In-Reply-To: <5729883B.4070307@xiph.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] timeline updates X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 09 May 2016 22:51:10 -0000 Timothy B. Terriberry wrote: > the last one was expected to be Standards Track. I assume you didn't > mean that you wanted to publish version 4 as Informational instead? Seeing no answer to this question on the list, I went ahead and updated the dates for the existing milestones, but did not consolidate them. I want to run a call for consensus to add the new milestone you proposed for EBML, which I have just issued. My personal expectation is that these dates are still unrealistic, but nothing wrong with being an optimist, I suppose. From nobody Mon May 9 20:24:12 2016 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 656DD12D175 for ; Mon, 9 May 2016 20:24:11 -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 exyqU9wBBn7c for ; Mon, 9 May 2016 20:24:07 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 C49B312B052 for ; Mon, 9 May 2016 20:24:07 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:41609 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1azyHD-004OND-2W; Mon, 09 May 2016 23:24:06 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave Rice In-Reply-To: <573113B8.6070702@xiph.org> Date: Mon, 9 May 2016 23:24:01 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <573113B8.6070702@xiph.org> To: "Timothy B. Terriberry" X-Mailer: Apple Mail (2.3124) 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: Cc: cellar@ietf.org Subject: Re: [Cellar] Call for consensus to add a milestone for EBML X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 03:24:11 -0000 I support adding the milestone (and proposed it). The work on Matroska = happened to start on its structural foundation which is EBML. Much of = the logic of the current matroska specification on matroska.org is now = documented in the underlying format EBML. I think the specification work = on EBML makes Matroska=E2=80=99s specification work quite easier. +1 Dave Rice > On May 9, 2016, at 6:48 PM, Timothy B. Terriberry = wrote: >=20 > In order to adopt the (hopefully forthcoming) EBML Internet-Draft as a = working-group item, we need to add a milestone, which requires Area = Director review. As such, I'd like to establish working-group consensus = for whether or not we should add the following milestone: >=20 > "Submit informational specification for EBML version 1 to IESG for = publication" >=20 > This will be a one-week call for consensus. Please respond to this = message on or before 16 May if you support or oppose adding this = milestone. >=20 > -Timothy B. Terriberry, for the chairs. >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Mon May 9 20:49:36 2016 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 51D6F12D184 for ; Mon, 9 May 2016 20:49:35 -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 sj9RXpe_p4Ee for ; Mon, 9 May 2016 20:49:33 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 6E53A12D111 for ; Mon, 9 May 2016 20:49:33 -0700 (PDT) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:41701 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1azyfr-000TWE-LN; Mon, 09 May 2016 23:49:32 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave Rice In-Reply-To: Date: Mon, 9 May 2016 23:49:29 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5A551233-6AFF-4E70-ABA1-F5F2002CB9F9@dericed.com> References: <1ED4498D-FC22-4D36-8163-BCA301FD4738@dericed.com> <20160418155706.GI30912@bunkus.org> <08896C4C-F809-4614-9489-21A16D9BE12D@dericed.com> To: Steve Lhomme X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.1 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: Cc: cellar@ietf.org, Moritz Bunkus Subject: Re: [Cellar] patch on textual expressions of floats in EBML Schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 03:49:35 -0000 > On May 8, 2016, at 7:42 AM, Steve Lhomme wrote: >=20 > 2016-04-18 18:00 GMT+02:00 Dave Rice : >>=20 >>> On Apr 18, 2016, at 11:57 AM, Moritz Bunkus = wrote: >>>=20 >>> Hey, >>>=20 >>>>> I think the parser can resolve this issue without much trouble. In = this >>>> context, the hyphen expresses a negative binary power, when it is = preceded >>>> by a 'P' or 'p'. On the other hand, the hyphen serves as the = delimiter >>>> between the minimum and maximum values, when it is not preceded by = a 'P' or >>>> 'p'. This criterion can be used to distinguish the two cases. >>>=20 >>> I agree. If a p occurs the following element must be the >>> exponent. Therefore there's no ambiguity. >>=20 >> Regarding such interpretation, currently specdata.xml expresses float = range in a style of "0.0-1.0". Should we say that both forms are valid = as ranges? Or that "0x0p+1-0x1p+0" is valid but "0.0-1.0" is invalid. >=20 > For the moment the range value is not used to generate code. Only > "0-1" integers are assumed to be boolean. So these changes won't > affect the generated code. In that case I supplied a pull request here which changes > 0=E2=80=9D = to ">0x0p+1" https://github.com/Matroska-Org/foundation-source/pull/16/files. Also note that the definition of SamplingFrequency (a float element) = includes a default of =E2=80=9C8000.0=E2=80=9D. My Hexadecimal = Floating-Point Constants skills are still new; Nithin, what is the = Hexadecimal Floating-Point Constants form of 8000? >>>> In this context, does 'float' mean only 32-bit floats, or does it = mean >>>> both 32-bit floats and 64-bit doubles? If it is the latter, then I = think >>>> 'floating constant' (given in the C11 standard) may be a more = unambiguous >>>> term. >>>=20 >>> The specs always talk about the numerical types as they apply to = EBML >>> (section "EBML Element Types" at [1]). We don't talk about data = types in >>> a specific programming language; that's an implementation detail the >>> specs shouldn't care about. So "float" means up to 64bits, just as >>> "unsigned integer" does. We don't say "uint64_t" there either. >>>=20 >>> Kind regards, >>> mosu >>>=20 >>> [1] = https://github.com/Matroska-Org/ebml-specification/blob/master/specificati= on.markdown >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >>=20 >>=20 >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >>=20 >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman From nobody Tue May 10 01:57:22 2016 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 A682912D621 for ; Tue, 10 May 2016 01:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 KlfSbr6Pg2K7 for ; Tue, 10 May 2016 01:57:18 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002: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 56A8612D57D for ; Tue, 10 May 2016 01:57:16 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id j74so5400773ywg.1 for ; Tue, 10 May 2016 01:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=hMtS4dehfk97HYN9fgRQQcvNX/fp5ipQs4BfGyEgZqc=; b=blRgyi8DU6aikdIqJNAmaaF5wdH80hlOw3t2hNtMzw9VMq53gEO12oS0gpToFNpb8e dn0eoef3f9OzLI+emkNCeZOis110FhdMr73LOuzBYh+h/RiXteaPorpx6q5mLF8zkM7K EjgRqeSMoGHAxd+uAAiJ3Z03buOKechlhmfJ/tNLFTGiHn5/zMew7M49uleCde+hQ1so dl6GMqrqEWl/3EAjQXOAqyjscPQnReHwgk/VeUeZj3i1F0IWp9XtM66nXfYh+Hoq/skQ VogcoNanEGJAKQW1kyH4nK0+qijW9blhkfLNLpoy4gtGHDye/cJFCOiN4MJK36vemhK5 4HjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=hMtS4dehfk97HYN9fgRQQcvNX/fp5ipQs4BfGyEgZqc=; b=aXzAQWo78JtkbjZ0fQJgqLf9FkHBnsF7ynppdNiDOa5rfpWZQKeg6o+L1aZy6ROBbq Yd/Zg6kKolKZ3oJcMWW0fJmdHX5E24DvGVijJsDmV+Vm7GrJpWFnHJ5mq2ALVagHSdlm Ixt6MOuoKEwCaiUM18ILGioSgiFxtaerQa8MUNW086UroTztkiEckoRqt53ugQPPuNaR LW/pGCDhLsOXtsKG8CZaCn8cvO6rYPzSQeU6AlYTEok/LGyG8mzV2WotiY46Z9OgayBr yByp01M7OXfMPaAc8kD4fzuidIA32Pct7N/59998SimuCkFsM1U6uke9DG7KtJfJam5l LjSg== X-Gm-Message-State: AOPr4FXj5K1JfuVppyr1vB7fqzGlWPC6nY3uZ3uC5+V/ib7GXBVb3+tNMW7cyme10RNozMy9OJhxHxXecUUAIA== MIME-Version: 1.0 X-Received: by 10.129.98.139 with SMTP id w133mr22327453ywb.222.1462870635654; Tue, 10 May 2016 01:57:15 -0700 (PDT) Received: by 10.129.108.68 with HTTP; Tue, 10 May 2016 01:57:15 -0700 (PDT) In-Reply-To: <5A551233-6AFF-4E70-ABA1-F5F2002CB9F9@dericed.com> References: <1ED4498D-FC22-4D36-8163-BCA301FD4738@dericed.com> <20160418155706.GI30912@bunkus.org> <08896C4C-F809-4614-9489-21A16D9BE12D@dericed.com> <5A551233-6AFF-4E70-ABA1-F5F2002CB9F9@dericed.com> Date: Tue, 10 May 2016 14:27:15 +0530 Message-ID: From: Nithin Mathew Kurien To: Dave Rice Content-Type: multipart/alternative; boundary=001a11470a7c97366a0532791c46 Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] patch on textual expressions of floats in EBML Schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 08:57:21 -0000 --001a11470a7c97366a0532791c46 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Tue, May 10, 2016 at 9:19 AM, Dave Rice wrote: > > > On May 8, 2016, at 7:42 AM, Steve Lhomme wrote: > > > > 2016-04-18 18:00 GMT+02:00 Dave Rice : > >> > >>> On Apr 18, 2016, at 11:57 AM, Moritz Bunkus wrote= : > >>> > >>> Hey, > >>> > >>>>> I think the parser can resolve this issue without much trouble. In > this > >>>> context, the hyphen expresses a negative binary power, when it is > preceded > >>>> by a 'P' or 'p'. On the other hand, the hyphen serves as the delimit= er > >>>> between the minimum and maximum values, when it is not preceded by a > 'P' or > >>>> 'p'. This criterion can be used to distinguish the two cases. > >>> > >>> I agree. If a p occurs the following element must be the > >>> exponent. Therefore there's no ambiguity. > >> > >> Regarding such interpretation, currently specdata.xml expresses float > range in a style of "0.0-1.0". Should we say that both forms are valid as > ranges? Or that "0x0p+1-0x1p+0" is valid but "0.0-1.0" is invalid. > > > > For the moment the range value is not used to generate code. Only > > "0-1" integers are assumed to be boolean. So these changes won't > > affect the generated code. > > In that case I supplied a pull request here which changes > 0=E2=80=9D= to > ">0x0p+1" > https://github.com/Matroska-Org/foundation-source/pull/16/files. > > Also note that the definition of SamplingFrequency (a float element) > includes a default of =E2=80=9C8000.0=E2=80=9D. My Hexadecimal Floating-P= oint Constants > skills are still new; Nithin, what is the Hexadecimal Floating-Point > Constants form of 8000? > It is 0x1.f4p+12. Also, there is a small typo in https://github.com/Matroska-Org/ebml-specification/pull/61. +Within an expression of a float range, as in an integer range, the `-` (hyphen) character is the separator between the minimal and maximum value permitted by the range. Note that Hexadecimal Floating-Point Constants also use a `-` (hyphen) when indicating a negative binary power. Within a float range, when a `-` (hyphen) is immediately preceded by a letter `p`, then the `-` (hyphen) is a part of the Hexadecimal Floating-Point Constant which notes negative binary power. Within a float range, when a `-` (hyphen) is immediately preceded by a letter `p`, then the `-` (hyphen) represents the separator between the minimal and maximum value permitted by the range. The last sentence should be "Within a float range, when a `-` (hyphen) is *not* immediately preceded by a letter `p`, then the `-` (hyphen) represents the separator between the minimal and maximum value permitted by the range." Thanks and regards, Nithin --001a11470a7c97366a0532791c46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Tue, May 10, 2016 at 9:19 AM, Da= ve Rice <dave@dericed.com> wrote:

> On May 8, 2016, at 7:42 AM, Steve Lhomme <slhomme@matroska.org> wrote:
>
> 2016-04-18 18:00 GMT+02:00 Dave Rice <dave@dericed.com>:
>>
>>> On Apr 18, 2016, at 11:57 AM, Moritz Bunkus <moritz@bunkus.org> wrote:
>>>
>>> Hey,
>>>
>>>>> I think the parser can resolve this issue without much= trouble. In this
>>>> context, the hyphen expresses a negative binary power, whe= n it is preceded
>>>> by a 'P' or 'p'. On the other hand, the hy= phen serves as the delimiter
>>>> between the minimum and maximum values, when it is not pre= ceded by a 'P' or
>>>> 'p'. This criterion can be used to distinguish the= two cases.
>>>
>>> I agree. If a p occurs the following element must be the
>>> exponent. Therefore there's no ambiguity.
>>
>> Regarding such interpretation, currently specdata.xml expresses fl= oat range in a style of "0.0-1.0". Should we say that both forms = are valid as ranges? Or that "0x0p+1-0x1p+0" is valid but "0= .0-1.0" is invalid.
>
> For the moment the range value is not used to generate code. Only
> "0-1" integers are assumed to be boolean. So these changes w= on't
> affect the generated code.

In that case I supplied a pull request here which changes &gt; 0= =E2=80=9D to "&gt;0x0p+1"
https://github.com/Matroska-Org/found= ation-source/pull/16/files.

Also note that the definition of SamplingFrequency (a float element) includ= es a default of =E2=80=9C8000.0=E2=80=9D. My Hexadecimal Floating-Point Con= stants skills are still new; Nithin, what is the Hexadecimal Floating-Point= Constants form of 8000?

It is=C2=A00x1= .f4p+12. Also, there is a small typo in=C2=A0https://github.com/Matroska-Org/ebml-specific= ation/pull/61.

+Within an expression of a floa= t range, as in an integer range, the `-` (hyphen) character is the separato= r between the minimal and maximum value permitted by the range. Note that H= exadecimal Floating-Point Constants also use a `-` (hyphen) when indicating= a negative binary power. Within a float range, when a `-` (hyphen) is imme= diately preceded by a letter `p`, then the `-` (hyphen) is a part of the He= xadecimal Floating-Point Constant which notes negative binary power. Within= a float range, when a `-` (hyphen) is immediately preceded by a letter `p`= , then the `-` (hyphen) represents the separator between the minimal and ma= ximum value permitted by the range.

The last s= entence should be "Within a float range, when a `-` (hyphen) is not= immediately preceded by a letter `p`, then the `-` (hyphen) represents= the separator between the minimal and maximum value permitted by the range= ."

Thanks and regards,
Nithin
=
--001a11470a7c97366a0532791c46-- From nobody Tue May 10 02:17:56 2016 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 4CBFB12D64D for ; Tue, 10 May 2016 02:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 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, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 sDJE4H2edsts for ; Tue, 10 May 2016 02:17:52 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::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 55BF812D0C0 for ; Tue, 10 May 2016 02:17:52 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id t10so6584033ywa.0 for ; Tue, 10 May 2016 02:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=onTc2RqTSODYSG/Ogsz0CsiCNX2YtehX+q9qRposmzk=; b=dsjAlLFdZHkdIIndYD5flJCYqhvakXVHdwQeHsSszfaCrKTaoCm/xrBQEr7XZ8dctt pmwfYaCPfE2DSpWbchP0jTWIt6OxaPTlwelMZ5Q10hU+BWRcvrq7HoCS3JzHzSsqlxko PwlQRORf+gbZHv0CX1wp9IUe5lvJ4C12Gv8MDQKAfS/8Jez0kS4IPZZLxBJwnhVGUDOD JQ3MotxiwsMqTemmNcHnNpfmGR58aa1DNFRod5ag16yzrYQmvE34LHKBpYHP35IPfPZD gepnGBmNFCKsrk4qpg5v2Ix3+ow/aFCxJkTJOlwhBLp2aM1RvGAn2Nr7/D4hIhEyuMR0 Kwmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=onTc2RqTSODYSG/Ogsz0CsiCNX2YtehX+q9qRposmzk=; b=mDc80O7sH84fl4z7DWwEA1aaNBtfJD7HH/3xL7umMzAiLmmHcpfd6NOl/ZlKUNAvMe 7BrHlmq5FVyNWAGs+IqP/LeUURPbqBtHMZR82LLdmHBrPd2rkCSSGCFvdU8hx4Rex1rj didfJTdu9pTuLRA0GxyPq0a+uR4FliQYOiT/3M/MRHihMVeeRNdYZkGkCPBB56wAjogo Z8Ji0glkP+84ndcmvKJCjahIRIqg2Nm3n7bsE2cmg+MOwUho/gtYYkauk/tqpC5eNetI 3PSmfphWexfhG31oUsFJ8K88W8Ec1TCrIk6hFn/uwFWMLjWZmPVEyD3i7I/O1VqjiRrt Evww== X-Gm-Message-State: AOPr4FU3/Ql6fXvOCrJVoYG16Gti0ca2cIUC4vZdsLF+rkrLLYTlnmbLQbYzrJMyD0I8m3ZDjTAXxaqKp45SNg== MIME-Version: 1.0 X-Received: by 10.37.68.137 with SMTP id r131mr21081957yba.22.1462871871474; Tue, 10 May 2016 02:17:51 -0700 (PDT) Received: by 10.129.108.68 with HTTP; Tue, 10 May 2016 02:17:51 -0700 (PDT) In-Reply-To: References: Date: Tue, 10 May 2016 14:47:51 +0530 Message-ID: From: Nithin Mathew Kurien To: Steve Lhomme Content-Type: multipart/alternative; boundary=001a113f45b440575f05327966ac Archived-At: Cc: Discussion about the current and future development of Matroska , cellar@ietf.org Subject: Re: [Cellar] Channel Positions for Multichannel LPCM Track Inside Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 10 May 2016 09:17:55 -0000 --001a113f45b440575f05327966ac Content-Type: text/plain; charset=UTF-8 Hi, On Sun, May 8, 2016 at 5:35 PM, Steve Lhomme wrote: > 2016-04-24 17:39 GMT+02:00 Nithin Mathew Kurien : > > Hi, > > > > Currently the specification for storing a multichannel LPCM track > (CodecID > > A_PCM/INT/LIT) inside a Matroska file [1, 2], does not specify a way to > > indicate the channel positions of the track. Due to this, players find it > > difficult to map the channels to the correct speaker positions when > playing > > such a track. MakeMKV employs a workaround for this problem. It stores > the > > track under the CodecID A_MS/ACM, along with a WAVEFORMATEXTENSIBLE > > structure in CodecPrivate. This structure contains a field called > > dwChannelMask which specifies the channel positions [3]. This is > identical > > to the way LPCM is stored inside AVI files. The problem with this > approach > > is that most players do not recognise the CodecID A_MS/ACM, except for a > few > > open-source players like Kodi [4]. > > We used to have a field for that but it was never used AFAIK > https://matroska.org/technical/specs/index.html#ChannelPositions > > This is how it used to be, describing each speaker position with an > angle. I don't know there is a standard way to express this. I'd > assume the distance to the center should play a role too. > > https://web.archive.org/web/20071211091532/http://www.matroska.org/technical/specs/channelposition/index.html This notation is appropriate for speaker positions in the horizontal plane, but there is a problem. The LFE channel is omni-directional; so how do we denote whether the LFE channel is present or not, in this notation? > In the case of a FLAC track (inside either a raw .FLAC file or a .MKA > file), > > we can specify an optional WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag [5]. > Could > > a similar solution be implemented for LPCM inside Matroska too? > > > > On a related note, the ffmpeg documentation [6] specifies additional > channel > > positions which are not found in the Microsoft documentation [3], like > Wide > > Left and Wide Right speakers. Are these speaker positions recognised by > > players when reading WAV files? > > VLC currently handles 'only' 9 speaker positions out of the 18 MS ones. > > > [1] https://matroska.org/technical/specs/codecid/index.html > > [2] http://haali.su/mkv/codecs.pdf > > [3] > > > https://msdn.microsoft.com/en-us/library/windows/hardware/dn653308(v=vs.85).aspx > > [4] http://www.makemkv.com/forum2/viewtopic.php?f=8&t=2530 > > [5] > https://sourceforge.net/p/mediainfo/discussion/297609/thread/164b4fb3/ > > [6] https://ffmpeg.org/doxygen/2.2/channel__layout_8h_source.html > > > > Thanks and regards, > > Nithin > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > > > -- > Steve Lhomme > Matroska association Chairman > Thanks and regards, Nithin --001a113f45b440575f05327966ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

On Sun, May 8, 2016 at 5:35 PM, Steve Lhomme <slhomme@mat= roska.org> wrote:
2016-04-24 17:39 GMT+02:00 Nithin Mathew Kurien <nithinmkurien@gmail.com>:
> Hi,
>
> Currently the specification for storing a multichannel LPCM track (Cod= ecID
> A_PCM/INT/LIT) inside a Matroska file [1, 2], does not specify a way t= o
> indicate the channel positions of the track. Due to this, players find= it
> difficult to map the channels to the correct speaker positions when pl= aying
> such a track. MakeMKV employs a workaround for this problem. It stores= the
> track under the CodecID A_MS/ACM, along with a WAVEFORMATEXTENSIBLE > structure in CodecPrivate. This structure contains a field called
> dwChannelMask which specifies the channel positions [3]. This is ident= ical
> to the way LPCM is stored inside AVI files. The problem with this appr= oach
> is that most players do not recognise the CodecID A_MS/ACM, except for= a few
> open-source players like Kodi [4].

We used to have a field for that but it was never used AFAIK
https://matroska.org/technical/specs= /index.html#ChannelPositions

This is how it used to be, describing each speaker position with an
angle. I don't know there is a standard way to express this. I'd assume the distance to the center should play a role too.
https://web.archive.org/web/20071211091532/http://www.matroska.org= /technical/specs/channelposition/index.html

=
This notation is appropriate for speaker positions in the horizontal p= lane, but there is a problem. The LFE channel is omni-directional; so how d= o we denote whether the LFE channel is present or not, in this notation?

> In t= he case of a FLAC track (inside either a raw .FLAC file or a .MKA file), > we can specify an optional WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag [5]. = Could
> a similar solution be implemented for LPCM inside Matroska too?
>
> On a related note, the ffmpeg documentation [6] specifies additional c= hannel
> positions which are not found in the Microsoft documentation [3], like= Wide
> Left and Wide Right speakers. Are these speaker positions recognised b= y
> players when reading WAV files?

VLC currently handles 'only' 9 speaker positions out of the = 18 MS ones.

> [1] https://matroska.org/technical/specs= /codecid/index.html
> [2] http://haali.su/mkv/codecs.pdf
> [3]
> https://msdn.= microsoft.com/en-us/library/windows/hardware/dn653308(v=3Dvs.85).aspx > [4] http://www.makemkv.com/forum2= /viewtopic.php?f=3D8&t=3D2530
> [5] https://sourceforge.n= et/p/mediainfo/discussion/297609/thread/164b4fb3/
> [6] https://ffmpeg.org/doxygen/2.2= /channel__layout_8h_source.html
>
> Thanks and regards,
> Nithin
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar >



--
Steve Lhomme
Matroska association Chairman

Thank= s and regards,
Nithin
--001a113f45b440575f05327966ac-- From nobody Thu May 12 07:01:54 2016 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 055FD12D683 for ; Thu, 12 May 2016 07:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 XNc7DEc20l9e for ; Thu, 12 May 2016 07:01:49 -0700 (PDT) Received: from 1.mo7.mail-out.ovh.net (1.mo7.mail-out.ovh.net [178.33.45.51]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A8C612D1AC for ; Thu, 12 May 2016 07:01:46 -0700 (PDT) Received: from player759.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 719A41000200 for ; Thu, 12 May 2016 16:01:39 +0200 (CEST) Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player759.ha.ovh.net (Postfix) with ESMTPSA id 4F97964009F for ; Thu, 12 May 2016 16:01:36 +0200 (CEST) To: cellar@ietf.org References: <104d0f51-4b95-509f-13e2-b305f5f7fe3d@mediaarea.net> <20160427003739.GF25812@nb4> From: Jerome Martinez Message-ID: <56fddd48-efe5-36d0-bac7-d279bbd58fdf@mediaarea.net> Date: Thu, 12 May 2016 16:01:31 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160427003739.GF25812@nb4> Content-Type: multipart/alternative; boundary="------------A7A9DC135417CD9F76B5D51F" X-Ovh-Tracer-Id: 10142106362648137873 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrudelgdeilecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] FFV1 slices count X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 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, 12 May 2016 14:01:53 -0000 This is a multi-part message in MIME format. --------------A7A9DC135417CD9F76B5D51F Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 27/04/2016 02:37, Michael Niedermayer a crit : > On Tue, Apr 26, 2016 at 10:01:26PM +0200, Jerome Martinez wrote: >> Checking FFmpeg code for how FFV1 slices are constrained, I understand that: >> - FFmpeg encoder tries to find a value compatible with some >> constraints (minimum 2 rows and 2 columns, rows count must not be > >> 2x columns count, columns count must not be > 2x rows count, and >> slices count can not be more than 64). so 25 is acceptable (5x5, >> OK), 26 is not (13x2 or 2x13 are the only combinations, NOK) >> - FFmpeg decoder accepts any slices count below 256 >> >> I don't see any of these constraints in the current FFV1 specifications. >> I also don't see any reason to have these constraints: cases like 1 >> row and 64 columns could be used somewhere, not really worse than 8 >> rows and 8 columns (and maybe someday an encoder could compare >> compression performance an select 1x64 for compression performance >> with some frames). In 10 years, maybe we'll have 8K frames and CPUs >> with 1024 low-powered cores everywhere, having 32x32 slices (slices >> of 256x144 pixels) could make sense. >> >> On another side, the current specifications don't limit the count of >> slices, so having more slices than pixels on a row (so we have >> slices with 0 pixels) is theoretically possible. >> >> >> I would like to have comments on: >> - do we agree that we don't have any constraint on the slices count >> in the specification. FFmpeg implementation is a developer decision >> only and does not have any impact on the specification? > There is: > 5.6.1 Restrictions > In version 2 and later the maximum slice size in pixels is width*height > ------------ > 4 > , unless the frame is smaller or equal > 352x288 this is to ensure that fast multithreaded decoding is possible. oops, I missed it. I see that the 352x288 limit was added in mid-2015, after the "freeze" of the bitstream (but FFmpeg code is from 2012) I am sceptical about the maximum slice size in pixels. the goal is multithreaded processing, but we could have an advanced encoder optimizing the decoder CPU load instead of pixels count. Example: let's take an hypothetical frame with the top half in black. with this slice size limitation, 2 threads would do nearly nothing and 2 threads would be maybe overloaded. instead of having this scenario for slices (num_h_slice=2 and num_v_slice=2): 12 34 we could imagine (num_h_slice=4 and num_v_slice=2) 1111 (slice 1 with slice_width of 4) 2344 (slice 4 with slice_width of 2) in that case, 1 thread would do nearly nothing and 3 threads would be maybe with less overloading than with the limitation, but it is forbidden by the slice size limitation. We prevent encoder to imagine optimizations we don't currently think about. Additionally, from my point of view, such restriction is an encoder policy, not a bitstream restriction. Actually, I see the restriction in the FFmpeg encoder but I don't see a reject of e.g. 353x288 FFV1.2 frame with 1 slice with the FFmpeg decoder, looks like the FFmpeg decoder can decode it (not tested). Additionally, I think that "smaller or equal" to 2 numbers is not mathematically correct, and in the FFmpeg code: s->num_v_slices = (avctx->width > 352 || avctx->height > 288 || !avctx->slices) ? 2 : 1; if width is 353 and height is 1 (may be considered as stupid but a spec must take care of all cases), count of slices in FFmpeg is 4 (num_v_slices of 2, so 2 slices with 0 pixels? BTW the resulting FFV1 stream from FFmpeg is buggy, I'll write a FFmpeg issue ticket about it) and specs are not clear about if it is "smaller or equal to" 352x288. I propose to put such text in an annex, not part of the specification, as an informative recommendation instead of a bitstream restriction. Proposal: *** Annex A: Encoder settings This annex is an infaormal recommendation To ensure that fast multithreaded decoding is possible, starting version 2, an encoder SHOULD set by default a slices count of 4 if frame size in pixels (width * height) is greater than 101376 else a slices count of 1. To avoid too much slice header overhead, starting version 2, an encoder SHOULD NOT encode more than 4 + floor (width * height / 101376) slices per frame (example: maximum of 4 slices below a 352x288 frame, maximum of 24 slices for a 1920x1080 HD frame, maximum of 85 slices for a 3840*2160 UHD-4K frame, maximum of 331 slices for a 7680*4320 UHD-8K frame) Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF ("Common Intermediate Format") frame size format. *** (BTW: I see that width and height, the ones relative to the frame, are not defined. I'll add some text about it too in order to say that such value comes from the container) > >> - should we add a constraint about num_h_slices must be less or >> equal to the frame width, and num_v_slices must be less or equal to >> frame height? > I think a restriction stating that "each slice must contain at least > one sample from each plane" should be added > Otherwise that may lead to odd special cases where a slice has > luma but no chroma samples I propose: *** num_h_slices MUST be less than ceil (width / h_chroma_subsample) num_v_slices MUST be less than ceil (height / v_chroma_subsample) *** so with e.g. a 3x1 4:2:0 frame: - num_h_slices = ceil (3 / 2) = 2 so we have luma plane 2+1 horizontal pixels and chroma plane 1+1 horizontal pixels - num_v_slices = ceil (1 / 2) = 1 so we have luma plane 1 vertical pixel and chroma plane 1 vertical pixel >> - In the future, we could have "profiles" as constraints for >> performance reasons, like "profile 1 = 720x576 pixels maximum, 64 >> slices maximum; profile 2 = 1920x1080 pixels maximum, 256 slices >> maximum", in addition to the core specifications without such >> arbitrary choices. >> >> >> _______________________________________________ >> 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 --------------A7A9DC135417CD9F76B5D51F Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Le 27/04/2016 02:37, Michael Niedermayer a crit:
On Tue, Apr 26, 2016 at 10:01:26PM +0200, Jerome Martinez wrote:

Checking FFmpeg code for how FFV1 slices are constrained, I understand that:
- FFmpeg encoder tries to find a value compatible with some
constraints (minimum 2 rows and 2 columns, rows count must not be >
2x columns count, columns count must not be > 2x rows count, and
slices count can not be more than 64). so 25 is acceptable (5x5,
OK), 26 is not (13x2 or 2x13 are the only combinations, NOK)
- FFmpeg decoder accepts any slices count below 256

I don't see any of these constraints in the current FFV1 specifications.
I also don't see any reason to have these constraints: cases like 1
row and 64 columns could be used somewhere, not really worse than 8
rows and 8 columns (and maybe someday an encoder could compare
compression performance an select 1x64 for compression performance
with some frames). In 10 years, maybe we'll have 8K frames and CPUs
with 1024 low-powered cores everywhere, having 32x32 slices (slices
of 256x144 pixels) could make sense.

On another side, the current specifications don't limit the count of
slices, so having more slices than pixels on a row (so we have
slices with 0 pixels) is theoretically possible.


I would like to have comments on:
- do we agree that we don't have any constraint on the slices count
in the specification. FFmpeg implementation is a developer decision
only and does not have any impact on the specification?

There is:
    5.6.1   Restrictions
    In version 2 and later the maximum slice size in pixels is width*height
                                                               ------------
                                                                    4
    , unless the frame is smaller or equal
    352x288 this is to ensure that fast multithreaded decoding is possible.

oops, I missed it.
I see that the 352x288 limit was added in mid-2015, after the "freeze" of the bitstream (but FFmpeg code is from 2012)

I am sceptical about the maximum slice size in pixels. the goal is multithreaded processing, but we could have an advanced encoder optimizing the decoder CPU load instead of pixels count. Example: let's take an hypothetical frame with the top half in black. with this slice size limitation, 2 threads would do nearly nothing
and 2 threads would be maybe overloaded.
instead of having this scenario for slices (num_h_slice=2 and num_v_slice=2):
12
34
we could imagine (num_h_slice=4 and num_v_slice=2)
1111 (slice 1 with slice_width of 4)
2344 (slice 4 with slice_width of 2)
in that case, 1 thread would do nearly nothing and 3 threads would be maybe with less overloading than with the limitation, but it is forbidden by the slice size limitation. We prevent encoder to imagine optimizations we don't currently think about.

Additionally, from my point of view, such restriction is an encoder policy, not a bitstream restriction. Actually, I see the restriction in the FFmpeg encoder but I don't see a reject of e.g. 353x288 FFV1.2 frame with 1 slice with the FFmpeg decoder, looks like the FFmpeg decoder can decode it (not tested).
Additionally, I think that "smaller or equal" to 2 numbers is not mathematically correct, and in the FFmpeg code:
s->num_v_slices = (avctx->width > 352 || avctx->height > 288 || !avctx->slices) ? 2 : 1;
if width is 353 and height is 1 (may be considered as stupid but a spec must take care of all cases), count of slices in FFmpeg is 4 (num_v_slices of 2, so 2 slices with 0 pixels? BTW the resulting FFV1 stream from FFmpeg is buggy, I'll write a FFmpeg issue ticket about it) and specs are not clear about if it is "smaller or equal to" 352x288.

I propose to put such text in an annex, not part of the specification, as an informative recommendation instead of a bitstream restriction.

Proposal:

***
Annex A: Encoder settings
This annex is an infaormal recommendation
To ensure that fast multithreaded decoding is possible, starting version 2, an encoder SHOULD set by default a slices count of 4 if frame size in pixels (width * height) is greater than 101376 else a slices count of 1.
To avoid too much slice header overhead, starting version 2, an encoder SHOULD NOT encode more than 4 + floor (width * height / 101376) slices per frame (example: maximum of 4 slices below a 352x288 frame, maximum of 24 slices for a 1920x1080 HD frame, maximum of 85 slices for a 3840*2160 UHD-4K frame, maximum of 331 slices for a 7680*4320 UHD-8K frame)
Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF ("Common Intermediate Format") frame size format.
***

(BTW: I see that width and height, the ones relative to the frame, are not defined. I'll add some text about it too in order to say that such value comes from the container)




- should we add a constraint about num_h_slices must be less or
equal to the frame width, and num_v_slices must be less or equal to
frame height?

I think a restriction stating that "each slice must contain at least
one sample from each plane" should be added
Otherwise that may lead to odd special cases where a slice has
luma but no chroma samples


I propose:

***
num_h_slices MUST be less than ceil (width / h_chroma_subsample)
num_v_slices MUST be less than ceil (height / v_chroma_subsample)
***

so with e.g. a 3x1 4:2:0 frame:
- num_h_slices = ceil (3 / 2) = 2 so we have luma plane 2+1 horizontal pixels and chroma plane 1+1 horizontal pixels
- num_v_slices = ceil (1 / 2) = 1 so we have luma plane 1 vertical pixel and chroma plane 1 vertical pixel



      

        
- In the future, we could have "profiles" as constraints for
performance reasons, like "profile 1 = 720x576 pixels maximum, 64
slices maximum; profile 2 = 1920x1080 pixels maximum, 256 slices
maximum", in addition to the core specifications without such
arbitrary choices.


_______________________________________________
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


    

    


    

  


--------------A7A9DC135417CD9F76B5D51F--


From nobody Thu May 12 08:33:47 2016
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 2DFB812D1B2 for ; Thu, 12 May 2016 08:33:46 -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, RCVD_IN_MSPIKE_H2=-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 iPtGc0quqloT for ; Thu, 12 May 2016 08:33:43 -0700 (PDT)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CF9412D190 for ; Thu, 12 May 2016 08:33:43 -0700 (PDT)
Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 0A70541C080 for ; Thu, 12 May 2016 17:33:42 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter17-d.gandi.net (mfilter17-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id rnE1OFKLiVhy for ; Thu, 12 May 2016 17:33:40 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 0083A41C0AC for ; Thu, 12 May 2016 17:33:39 +0200 (CEST)
Date: Thu, 12 May 2016 17:31:36 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160512153136.GF25812@nb4>
References: <104d0f51-4b95-509f-13e2-b305f5f7fe3d@mediaarea.net> <20160427003739.GF25812@nb4> <56fddd48-efe5-36d0-bac7-d279bbd58fdf@mediaarea.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tyYlYYB72akoZjTa"
Content-Disposition: inline
In-Reply-To: <56fddd48-efe5-36d0-bac7-d279bbd58fdf@mediaarea.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] FFV1 slices count
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 12 May 2016 15:33:46 -0000

--tyYlYYB72akoZjTa
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi

On Thu, May 12, 2016 at 04:01:31PM +0200, Jerome Martinez wrote:
> Le 27/04/2016 =E0 02:37, Michael Niedermayer a =E9crit :
> >On Tue, Apr 26, 2016 at 10:01:26PM +0200, Jerome Martinez wrote:
> >>Checking FFmpeg code for how FFV1 slices are constrained, I understand =
that:
> >>- FFmpeg encoder tries to find a value compatible with some
> >>constraints (minimum 2 rows and 2 columns, rows count must not be >
> >>2x columns count, columns count must not be > 2x rows count, and
> >>slices count can not be more than 64). so 25 is acceptable (5x5,
> >>OK), 26 is not (13x2 or 2x13 are the only combinations, NOK)
> >>- FFmpeg decoder accepts any slices count below 256
> >>
> >>I don't see any of these constraints in the current FFV1 specifications.
> >>I also don't see any reason to have these constraints: cases like 1
> >>row and 64 columns could be used somewhere, not really worse than 8
> >>rows and 8 columns (and maybe someday an encoder could compare
> >>compression performance an select 1x64 for compression performance
> >>with some frames). In 10 years, maybe we'll have 8K frames and CPUs
> >>with 1024 low-powered cores everywhere, having 32x32 slices (slices
> >>of 256x144 pixels) could make sense.
> >>
> >>On another side, the current specifications don't limit the count of
> >>slices, so having more slices than pixels on a row (so we have
> >>slices with 0 pixels) is theoretically possible.
> >>
> >>
> >>I would like to have comments on:
> >>- do we agree that we don't have any constraint on the slices count
> >>in the specification. FFmpeg implementation is a developer decision
> >>only and does not have any impact on the specification?
> >There is:
> >     5.6.1   Restrictions
> >     In version 2 and later the maximum slice size in pixels is width*he=
ight
> >                                                                --------=
----
> >                                                                     4
> >     , unless the frame is smaller or equal
> >     352x288 this is to ensure that fast multithreaded decoding is possi=
ble.
>=20
> oops, I missed it.
> I see that the 352x288 limit was added in mid-2015, after the
> "freeze" of the bitstream (but FFmpeg code is from 2012)
>=20
> I am sceptical about the maximum slice size in pixels. the goal is
> multithreaded processing, but we could have an advanced encoder
> optimizing the decoder CPU load instead of pixels count. Example:

thats not really possible, a encoder does not know how a
decoder is implemented or how much CPU load a specific input would
cause.
Also it makes it harder to implement decoders that are guranteed
to be able to decode a stream.
Knowing that the max slice size is X is something one can write an
implementation against. Knowing that the encoder might have made an
effort to minimize CPU load is not so easy to design a decoder against
that is guranteed to be fast enough for for example real time decoding
of some specific resolution and frame rate.


> let's take an hypothetical frame with the top half in black. with
> this slice size limitation, 2 threads would do nearly nothing
> and 2 threads would be maybe overloaded.

or maybe they would all need roughly the same time,
I think a decoder implemeted as a FPGA or ASIC could fall in that
category


> instead of having this scenario for slices (num_h_slice=3D2 and
> num_v_slice=3D2):
> 12
> 34
> we could imagine (num_h_slice=3D4 and num_v_slice=3D2)
> 1111 (slice 1 with slice_width of 4)
> 2344 (slice 4 with slice_width of 2)
> in that case, 1 thread would do nearly nothing and 3 threads would
> be maybe with less overloading than with the limitation, but it is
> forbidden by the slice size limitation. We prevent encoder to
> imagine optimizations we don't currently think about.

and a decoder designed to support a max slice size of 352x288 would
then run out of memory, so every decoder would need to suport arbitrary
slice sizes
what is gained by the optimization you suggest ?
have you benchmarked it ?


>=20
> Additionally, from my point of view, such restriction is an encoder
> policy, not a bitstream restriction. Actually, I see the restriction

restricting what is allowed to exist in the bitstream or what an
encoder is allowed to generate is the same IMO


> in the FFmpeg encoder but I don't see a reject of e.g. 353x288
> FFV1.2 frame with 1 slice with the FFmpeg decoder, looks like the
> FFmpeg decoder can decode it (not tested).

FFmpeg has always been designed around the idea of being able to
decode everything that can be decoded especially when its easy, no
matter how broken and invalid the bitstreams are.
Of course FFmpeg should loudly warn about invalid things, and i guess
it fails to do that (didnt check)


> Additionally, I think that "smaller or equal" to 2 numbers is not
> mathematically correct, and in the FFmpeg code:
> s->num_v_slices =3D (avctx->width > 352 || avctx->height > 288 ||
> !avctx->slices) ? 2 : 1;
> if width is 353 and height is 1 (may be considered as stupid but a
> spec must take care of all cases), count of slices in FFmpeg  is 4
> (num_v_slices of 2, so 2 slices with 0 pixels? BTW the resulting
> FFV1 stream from FFmpeg is buggy, I'll write a FFmpeg issue ticket
> about it) and specs are not clear about if it is "smaller or equal
> to" 352x288.
>=20

> I propose to put such text in an annex, not part of the
> specification, as an informative recommendation instead of a
> bitstream restriction.

i think making this just a informative recommendation is a bad idea

if having it as a unconditional bitstream restriction is a disadvantage
for some use case then i suggest we add profiles/levels where each
would have a limit on for example the slice size and number of slices
and other parameters. That way one can implement a decoder that one
can say supports all content compliant to that profile and level.

But if a single unconditional limit could be used that would be simpler
and decoders could then still claim to support for example all content
up to 1080p 60fps

Can you provide an actual testcase where removing the limit improves
decoding speed or something else ?

[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope

--tyYlYYB72akoZjTa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc0odgACgkQYR7HhwQLD6uI5QCglKe3uBHDKa0TxnFLgtdmHLHn
3gAAoI+oClY4P1vmkAFzqK5DdXeaI4VY
=jxJN
-----END PGP SIGNATURE-----

--tyYlYYB72akoZjTa--


From nobody Thu May 12 11:40:26 2016
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 E4DA112D0F4 for ; Thu, 12 May 2016 11:40:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 1bJVGMTSc-b4 for ; Thu, 12 May 2016 11:40:11 -0700 (PDT)
Received: from 13.mo7.mail-out.ovh.net (13.mo7.mail-out.ovh.net [87.98.150.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADDDB12D6FF for ; Thu, 12 May 2016 11:40:03 -0700 (PDT)
Received: from player759.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id D8E63FFC254 for ; Thu, 12 May 2016 20:39:57 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player759.ha.ovh.net (Postfix) with ESMTPSA id 9295D64008D for ; Thu, 12 May 2016 20:39:57 +0200 (CEST)
To: cellar@ietf.org
References: <104d0f51-4b95-509f-13e2-b305f5f7fe3d@mediaarea.net> <20160427003739.GF25812@nb4> <56fddd48-efe5-36d0-bac7-d279bbd58fdf@mediaarea.net> <20160512153136.GF25812@nb4>
From: Jerome Martinez 
Message-ID: 
Date: Thu, 12 May 2016 20:39:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <20160512153136.GF25812@nb4>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 14843019948600725649
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrudelgdduvdegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc
Archived-At: 
Subject: Re: [Cellar] FFV1 slices count
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 12 May 2016 18:40:16 -0000

Hi Michael,
Thanks for your feedback.
as you may guess, I disagree a bit, so let's go:

Le 12/05/2016  17:31, Michael Niedermayer a crit :
> [...]
>
>> instead of having this scenario for slices (num_h_slice=2 and
>> num_v_slice=2):
>> 12
>> 34
>> we could imagine (num_h_slice=4 and num_v_slice=2)
>> 1111 (slice 1 with slice_width of 4)
>> 2344 (slice 4 with slice_width of 2)
>> in that case, 1 thread would do nearly nothing and 3 threads would
>> be maybe with less overloading than with the limitation, but it is
>> forbidden by the slice size limitation. We prevent encoder to
>> imagine optimizations we don't currently think about.
> and a decoder designed to support a max slice size of 352x288 would
> then run out of memory,

Currently, it is authorized that a frame of 706x576 has only 4 slices, 
limitation of a slice size of 352x288 in a decoder means that a 706x576 
"legal" frame could not be decoded.
The criticism of the current arbitrary restriction is that it does not 
make a lot of sense until we provide a full set of restrictions (e.g. 
with maximum frame width/height) in order to fit in limited hardware. 
for the moment, a UHD-8K (and more) frame with 4 slices is authorized 
when a 353x288 frame with 1 slice is forbidden. We need more time for 
thinking on such restrictions.

>   so every decoder would need to suport arbitrary
> slice sizes
> what is gained by the optimization you suggest ?
> have you benchmarked it ?

For the moment, the idea is to avoid a future limitation, not to 
demonstrate it.

>
>
>> Additionally, from my point of view, such restriction is an encoder
>> policy, not a bitstream restriction. Actually, I see the restriction
> restricting what is allowed to exist in the bitstream or what an
> encoder is allowed to generate is the same IMO

I disagree. An encoder can have some policies due to a specific goal 
(proselytism? ;-) ), this does not prevent a decoder to accept different 
cases. an encoder may refuse to encode 4 slices for 352x288 streams, it 
is a policy of the encoder, not what any encoder is allowed to generate. 
Having restrictions in what the developer of an encoder want to generate 
is one thing (there are good reason for doing so, no problem), having 
restriction in the bitstream itself is a decision for all encoders.
Another example if that FFmpeg encoder forces that s->num_h_slices < 
2*s->num_v_slices, but it is not in spec. This is the demonstration that 
there are policies in the encoder (the developer decided of such 
limitation) but this is not in the bitstream spec (the spec does not 
forbid another policy).
Here, the issue is that we arbitrary forbid 1 slice in case of 353x288, 
I think without enough reasons to forbid it (e.g. we accept huge slice 
size), it should only be an encoder policy and a decoder should be able 
to decode it until we have a full set of profiles/levels.

I reverse the questions:
if a decoder is able to decode 4 slices of a 7680x4320 frame (so max 
slice size of 3840x2160), why could it not decode a single slice of 
353x288 when the frame size is 353x288?
why should we forbidden 353x288 with 1 slice if we authorize 4 slices of 
3840x2160?
Do yo have a proof that a FPGA or ASIC could handle my example badly due 
to performance (which ones?) problems?


>
>
>> in the FFmpeg encoder but I don't see a reject of e.g. 353x288
>> FFV1.2 frame with 1 slice with the FFmpeg decoder, looks like the
>> FFmpeg decoder can decode it (not tested).
> FFmpeg has always been designed around the idea of being able to
> decode everything that can be decoded especially when its easy, no
> matter how broken and invalid the bitstreams are.
> Of course FFmpeg should loudly warn about invalid things, and i guess
> it fails to do that (didnt check)

For the moment, the FFmpeg decoder quits when there are more than 256 
slices, and this limit is not in the specification.
This is problematic.
(and the arbitrary choice whatever is the frame size may be a 
limitation, as I wrote in my first email with e.g. CPUs with 1024 
low-powered cores. My proposal of limitations is a informal 
recommendation with a dependency of frame width/height because we don't 
limit the width/height for the moment, so I try to find a good balance 
without forbidding something else in case )

>
>
>> Additionally, I think that "smaller or equal" to 2 numbers is not
>> mathematically correct, and in the FFmpeg code:
>> s->num_v_slices = (avctx->width > 352 || avctx->height > 288 ||
>> !avctx->slices) ? 2 : 1;
>> if width is 353 and height is 1 (may be considered as stupid but a
>> spec must take care of all cases), count of slices in FFmpeg  is 4
>> (num_v_slices of 2, so 2 slices with 0 pixels? BTW the resulting
>> FFV1 stream from FFmpeg is buggy, I'll write a FFmpeg issue ticket
>> about it) and specs are not clear about if it is "smaller or equal
>> to" 352x288.
>>
>> I propose to put such text in an annex, not part of the
>> specification, as an informative recommendation instead of a
>> bitstream restriction.
> i think making this just a informative recommendation is a bad idea
>
> if having it as a unconditional bitstream restriction is a disadvantage
> for some use case then i suggest we add profiles/levels where each
> would have a limit on for example the slice size and number of slices
> and other parameters. That way one can implement a decoder that one
> can say supports all content compliant to that profile and level.

this is what I proposed in the initial email.
I propose to be informative only for FFV1.3 and to implement FFV1.4 with 
profiles/levels based on this informal recommendation, after having 
finished FFV1.3 specifications. forcing a single "profile" (i.e. slices 
pixel slice of width * height / 4) seems a bit hard (forbidding 1 slice 
for 353x288 forever, it is written "In version 2 and later", is not 
future-proof) and early (we did not study the impact of it).


>
> But if a single unconditional limit could be used that would be simpler
> and decoders could then still claim to support for example all content
> up to 1080p 60fps
>
> Can you provide an actual testcase where removing the limit improves
> decoding speed or something else ?

The idea is to permit future development, not to prove it right now.

But let speak of frame byte size:
ffmpeg -y -f lavfi -i testsrc -t 1 -filter:v scale="353:288" -vcodec 
ffv1 -level 3 353x288-4slices.mkv
1st frame is 11048 bytes, file size is 242 kiB
ffmpeg -y -f lavfi -i testsrc -t 1 -filter:v scale="353:288" -vcodec 
ffv1 -level 3 -slices 1 353x288-4slices.mkv
1st frame 10138 bytes (-8%), file size is 222 kiB (-8% too)
(note: modified FFmpeg in order to accept this command)

this example may be considered as stupid (small file, small frame size) 
but it is just a demonstration that forcing some restriction for all 
FFV1 streams is sometimes not optimal.

***

If I don't succeed to convince you about the informal recommendation, 
would the use of "SHOULD" in the current spec (without changing the 
other parts) be acceptable?
 From RFC 2119: SHOULD means "that there may exist valid reasons in 
particular circumstances to ignore a particular item, but the full 
implications must be understood and carefully weighed before choosing a 
different course"
and what is your point of view about max slices count recommendation? do 
we recommend nothing? for the moment, as is or with my proposal about 
num_h_slices and num_v_slices, FFmpeg can not handle "legal" streams 
e.g. UHD-8K frame with 264 (22x12 slices of 350x360 pixels, so more that 
the current obligation of 4 slices for 353x288, it is a realistic 
scenario for an encoder not following FFmpeg encoder limitations and 
built for CPUs having lot of low powered cores).

Jrme




From nobody Thu May 12 14:58:30 2016
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 859D112D1B8 for ; Thu, 12 May 2016 14:58:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 YJG4HevyjFJn for ; Thu, 12 May 2016 14:58:25 -0700 (PDT)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8EA712B02F for ; Thu, 12 May 2016 14:58:25 -0700 (PDT)
Received: from mfilter28-d.gandi.net (mfilter28-d.gandi.net [217.70.178.159]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id BFF99C5A50 for ; Thu, 12 May 2016 23:58:23 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter28-d.gandi.net
Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter28-d.gandi.net (mfilter28-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id eW1C1T98na9i for ; Thu, 12 May 2016 23:58:22 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id CA66DC5A67 for ; Thu, 12 May 2016 23:58:21 +0200 (CEST)
Date: Thu, 12 May 2016 23:56:18 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160512215618.GH25812@nb4>
References: <104d0f51-4b95-509f-13e2-b305f5f7fe3d@mediaarea.net> <20160427003739.GF25812@nb4> <56fddd48-efe5-36d0-bac7-d279bbd58fdf@mediaarea.net> <20160512153136.GF25812@nb4> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+qNChTrHUOKOVxyU"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] FFV1 slices count
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 12 May 2016 21:58:28 -0000

--+qNChTrHUOKOVxyU
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi

On Thu, May 12, 2016 at 08:39:44PM +0200, Jerome Martinez wrote:
> Hi Michael,
> Thanks for your feedback.
> as you may guess, I disagree a bit, so let's go:
>=20
> Le 12/05/2016 =E0 17:31, Michael Niedermayer a =E9crit :
> >[...]
> >
> >>instead of having this scenario for slices (num_h_slice=3D2 and
> >>num_v_slice=3D2):
> >>12
> >>34
> >>we could imagine (num_h_slice=3D4 and num_v_slice=3D2)
> >>1111 (slice 1 with slice_width of 4)
> >>2344 (slice 4 with slice_width of 2)
> >>in that case, 1 thread would do nearly nothing and 3 threads would
> >>be maybe with less overloading than with the limitation, but it is
> >>forbidden by the slice size limitation. We prevent encoder to
> >>imagine optimizations we don't currently think about.
> >and a decoder designed to support a max slice size of 352x288 would
> >then run out of memory,
>=20
> Currently, it is authorized that a frame of 706x576 has only 4
> slices, limitation of a slice size of 352x288 in a decoder means
> that a 706x576 "legal" frame could not be decoded.

The current restriction limits the slice size to a quarter of the
resolution for "non tiny" resolutions.
if we remove this restriction decoders must support slices that are
4 times as big. If the decoder runs on a quad core CPU it would
require a 4 times faster one to do that.


> The criticism of the current arbitrary restriction is that it does
> not make a lot of sense until we provide a full set of restrictions

see above, it quadruples the decodable resolution on the currently
commonly used CPUs compared to not having that restriction

i dont oppose doing something else at all, but if high resolution
single slice files get created and they use the context information
=66rom each previous frame, they basically would be forced to be
decoded single threaded and probably not in realtime.


[...]
>=20
> >
> >
> >>Additionally, from my point of view, such restriction is an encoder
> >>policy, not a bitstream restriction. Actually, I see the restriction
> >restricting what is allowed to exist in the bitstream or what an
> >encoder is allowed to generate is the same IMO
>=20
> I disagree. An encoder can have some policies due to a specific goal
> (proselytism? ;-) ), this does not prevent a decoder to accept

we misunderstand each other here
what i meant was that the specification restricting what the bitstream
is allowed to look like and the specification restricting what an
encoder can generate is effectively the same

encoder implementations of course can and do have many more
restrictions for all kinds or reasons. Thats an implementation detail


[...]
> I reverse the questions:
> if a decoder is able to decode 4 slices of a 7680x4320 frame (so max
> slice size of 3840x2160), why could it not decode a single slice of
> 353x288 when the frame size is 353x288?
> why should we forbidden 353x288 with 1 slice if we authorize 4
> slices of 3840x2160?

thats a good question as it shows the problem well i think
many decoders wont be able to decode 7680x4320 in realtime
thus your assumtation you start with already doesnt apply

if you have a really powerfull decoder it of course doesnt matter
 if you have 1 or 4 slices for cases where the decoder is vastly
overpowered. It does matters alot for cases that are at the edge of
being decodeable in realtime



> Do yo have a proof that a FPGA or ASIC could handle my example badly
> due to performance (which ones?) problems?

If you have a decoding pipeline in hw, id assume each pipeline step
would require a fixed and equal number of cycles, its probably
easier to implement that way. So it wouldnt be any faster with
black than with detailed data. Iam not a hw guy, i might be wrong
here of course

But lets look at the reverse, assume the hardware would need more
time to decode highly detailed data.
To be able to decode a specific resolution and slice resolution
the hardware must be able to decode the most detailed and hardest
picture or its users would be kind of unhappy occasionally
now would you make that hw able to decode higher resolutions if they
are all black or simpler?
i guess it depends on how much resolution one gains with real world
videos and what the aditional cost is


[...]

> >
> >But if a single unconditional limit could be used that would be simpler
> >and decoders could then still claim to support for example all content
> >up to 1080p 60fps
> >
> >Can you provide an actual testcase where removing the limit improves
> >decoding speed or something else ?
>=20

> The idea is to permit future development, not to prove it right now.

i dont see how the restriction would prevent future development
a future version could lift it for files under that future version


>=20
> But let speak of frame byte size:
> ffmpeg -y -f lavfi -i testsrc -t 1 -filter:v scale=3D"353:288" -vcodec
> ffv1 -level 3 353x288-4slices.mkv
> 1st frame is 11048 bytes, file size is 242 kiB
> ffmpeg -y -f lavfi -i testsrc -t 1 -filter:v scale=3D"353:288" -vcodec
> ffv1 -level 3 -slices 1 353x288-4slices.mkv
> 1st frame 10138 bytes (-8%), file size is 222 kiB (-8% too)
> (note: modified FFmpeg in order to accept this command)
>=20
> this example may be considered as stupid (small file, small frame
> size) but it is just a demonstration that forcing some restriction
> for all FFV1 streams is sometimes not optimal.

indeed, thanks for looking for that case


>=20
> ***
>=20
> If I don't succeed to convince you about the informal
> recommendation, would the use of "SHOULD" in the current spec
> (without changing the other parts) be acceptable?
> From RFC 2119: SHOULD means "that there may exist valid reasons in
> particular circumstances to ignore a particular item, but the full
> implications must be understood and carefully weighed before
> choosing a different course"

i think some restriction should remain to ensure that files dont
needlessly end up requiring 4 times more time to decode
that can be a different restriction of course, i dont mind that at all

but if we end up having 1080p files that can be decoded in realtime
and others that need can only be decoded at a quarter of realtime
because they where encoded ignoring a recommandition that could be
a bad experience for the user trying to use these files
i think we should try to avoid that


> and what is your point of view about max slices count
> recommendation? do we recommend nothing? for the moment, as is or
> with my proposal about num_h_slices and num_v_slices, FFmpeg can not
> handle "legal" streams e.g. UHD-8K frame with 264 (22x12 slices of
> 350x360 pixels, so more that the current obligation of 4 slices for
> 353x288, it is a realistic scenario for an encoder not following
> FFmpeg encoder limitations and built for CPUs having lot of low
> powered cores).

honestly i dont know ATM
i think there should be a minimum slice size so that tiny slices like
10x10 arent causing problems but 350x360 does seem a reasonable size

[...]
--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.

--+qNChTrHUOKOVxyU
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc0/AIACgkQYR7HhwQLD6sW0wCfQqYYn/sFRO9niLs7yiwuXu06
IJsAoJSetocL27SmnsCxCPWDOm0eaHFA
=0Aza
-----END PGP SIGNATURE-----

--+qNChTrHUOKOVxyU--


From nobody Fri May 13 01:44:51 2016
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 D886E12D0E9 for ; Fri, 13 May 2016 01:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Wx9CmtXq0mNp for ; Fri, 13 May 2016 01:44:47 -0700 (PDT)
Received: from 1.mo7.mail-out.ovh.net (1.mo7.mail-out.ovh.net [178.33.45.51]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CD5612D0A9 for ; Fri, 13 May 2016 01:44:46 -0700 (PDT)
Received: from player759.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 5DCA01000F60 for ; Fri, 13 May 2016 10:44:41 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player759.ha.ovh.net (Postfix) with ESMTPSA id 2C7DA6400AD for ; Fri, 13 May 2016 10:44:41 +0200 (CEST)
From: Jerome Martinez 
To: cellar@ietf.org
Message-ID: 
Date: Fri, 13 May 2016 10:44:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------013EBE792F97678BFC032B04"
X-Ovh-Tracer-Id: 10662553595544277137
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrvddugddtfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Archived-At: 
Subject: [Cellar] [PATCH FFV1] Replace slice_count because it is not precisely defined
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 13 May 2016 08:44:50 -0000

This is a multi-part message in MIME format.
--------------013EBE792F97678BFC032B04
Content-Type: multipart/alternative;
 boundary="------------DD759CCE83D0A0E0BE77234D"


--------------DD759CCE83D0A0E0BE77234D
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

In the spec, I see:
"*slice_count* indicates the number of slices in the current frame, 
slice_count is 1 if it is not explicitly coded."
and:
"for(i=0; i
  

    
  
  
    
In the spec, I see:

      "slice_count indicates the number of slices in
      the current frame, slice_count is 1 if it is not explicitly
      coded."

      and:

      "for(i=0; i<slice_count; i++)"

      

      but slice_count is not explicitly defined (based on bitstream
      elements).

      As a slice can have a width or height more than 1, slice_count is
      not num_h_slices * num_v_slices, it depends of slice_width and
      slice_height of each slice.

      

      

      I understand that Range coder state variables (see 4.6.1.3) are
      per slice_x and slice_y in the slice raster.

      Is it correct if I say that if for frame 0 a slice with slice_x=0,
      slice_y=0, slice_width=2, slice_height=1 (so no frame 0 slice with
      slice_x=1, slice_y=0), for frame 1 a slice with slice_x=1,
      slice_y=0 will have Range coder state variables set to their
      initial state?

      

      I propose the following patch for being more explicit about
      slices.

      - add "maximal" to num_h/v_slices because we could have less
      elements (e.g. if num_h_slices is 4, we could have a scenario with
      only 3 slices horizontal, e.g. slices with slice_x=0 have always
      slice_width=2)

      - remove slice_count definition and replace it by a test about the
      presence of remaining bytes at the end of the frame

      - replace "[i]" by "[slice_x][slice_y]"

    
Jérôme

    

  


--------------DD759CCE83D0A0E0BE77234D--

--------------013EBE792F97678BFC032B04
Content-Type: text/plain; charset=UTF-8;
 name="0001-Replace-slice_count-because-it-is-not-precisely-defi.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*0="0001-Replace-slice_count-because-it-is-not-precisely-defi.pa";
 filename*1="tch"

RnJvbSAzY2JiMGIxODAzYjhhODM1MzM5MjIyZDEyNGU1NWM3MWE1YWExNzI1IE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Sj1DMz1BOXI9QzM9QjRtZT0yME1h
cnRpbmV6Pz0gPGplcm9tZUBtZWRpYWFyZWEubmV0PgpEYXRlOiBGcmksIDEzIE1heSAyMDE2
IDA5OjI2OjQzICswMjAwClN1YmplY3Q6IFtQQVRDSF0gUmVwbGFjZSBzbGljZV9jb3VudCBi
ZWNhdXNlIGl0IGlzIG5vdCBwcmVjaXNlbHkgZGVmaW5lZAoKLSBhZGQgIm1heGltYWwiIHRv
IG51bV9oL3Zfc2xpY2VzIGJlY2F1c2Ugd2UgY291bGQgaGF2ZSBsZXNzCmVsZW1lbnRzIChl
LmcuIGlmIG51bV9oX3NsaWNlcyBpcyA0LCB3ZSBjb3VsZCBoYXZlIGEgc2NlbmFyaW8Kd2l0
aCBvbmx5IDMgc2xpY2VzIGhvcml6b250YWwsIGUuZy4gc2xpY2VzIHdpdGggc2xpY2VfeD0w
IGhhdmUKYWx3YXlzIHNsaWNlX3dpZHRoPTIpCi0gcmVtb3ZlIHNsaWNlX2NvdW50IGRlZmlu
aXRpb24gYW5kIHJlcGxhY2UgaXQgYnkgYSB0ZXN0IGFib3V0CnRoZSBwcmVzZW5jZSBvZiBy
ZW1haW5pbmcgYnl0ZXMgYXQgdGhlIGVuZCBvZiB0aGUgZnJhbWUKLSByZXBsYWNlICJbaV0i
IGJ5ICJbc2xpY2VfeF1bc2xpY2VfeV0iCi0tLQogZmZ2MS5tZCB8IDIwICsrKysrKysrKy0t
LS0tLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgOSBpbnNlcnRpb25zKCspLCAxMSBkZWxldGlv
bnMoLSkKCmRpZmYgLS1naXQgYS9mZnYxLm1kIGIvZmZ2MS5tZAppbmRleCBlNDhhN2VlLi4z
ZmQwNTA3IDEwMDY0NAotLS0gYS9mZnYxLm1kCisrKyBiL2ZmdjEubWQKQEAgLTUxNiwxNyAr
NTE2LDE3IEBAIFNlZSBbTlVUXSgjcmVmZXJlbmNlcykgZm9yIG1vcmUgaW5mb3JtYXRpb24g
YWJvdXQgZWxlbWVudHMuCiB8wqDCoMKgwqBrZXlmcmFtZSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHwgIGJyfAogfMKgwqDCoMKgaWYoIGtleWZyYW1lICYmICFD
b25maWd1cmF0aW9uUmVjb3JkSXNQcmVzZW50ICl8ICAgIHwKIHzCoMKgwqDCoMKgwqDCoMKg
wqBQYXJhbWV0ZXJzKCApICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIHwKLXzC
oMKgwqDCoGZvciggaSA9IDA7IGkgXDwgc2xpY2VcX2NvdW50OyBpKysgKSAgICAgICAgICAg
fCAgICB8Ci18wqDCoMKgwqDCoMKgwqDCoFNsaWNlKCBpICkgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB8ICAgIHwKK3zCoMKgwqDCoHdoaWxlICggcmVtYWluaW5nX2JpdHNf
aW5fYml0c3RyZWFtKCkgKSAgICAgICAgfCAgICB8Cit8wqDCoMKgwqDCoMKgwqDCoFNsaWNl
KCApICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIHwKIHx9ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIHwKIAog
IyMgU2xpY2UKIAogfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXw6LS0tLS0tfAotfFNsaWNl
KCBpICkgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHwgdHlwZSAgfAorfFNsaWNlKCApICAgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHwgdHlwZSAgfAogfMKgwqDCoMKgaWYoIHZlcnNpb24gXD4g
MiApICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKLXzC
oMKgwqDCoMKgwqDCoMKgU2xpY2VIZWFkZXIoIGkgKSAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwgICAgICAgfAorfMKgwqDCoMKgwqDCoMKgwqBTbGljZUhlYWRlcigg
KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8CiB8wqDC
oMKgwqBpZiggY29sb3JzcGFjZVxfdHlwZSA9PSAwKSB7ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHwgICAgICAgfAogfMKgwqDCoMKgwqDCoMKgwqBmb3IoIHAgPSAwOyBwIFw8IHBy
aW1hcnlcX2NvbG9yXF9jb3VudDsgcCsrICkgeyAgICAgfCAgICAgICB8CiB8wqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgUGxhbmUoIHAgKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgfCAgICAgICB8CkBAIC01MzUsNyArNTM1LDcgQEAgU2VlIFtOVVRdKCNyZWZl
cmVuY2VzKSBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBlbGVtZW50cy4KIHzCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqBmb3IoIHAgPSAwOyBwIFw8IHByaW1hcnlcX2NvbG9yXF9jb3Vu
dDsgcCsrICkgeyB8ICAgICAgIHwKIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oExpbmUoIHAsIHkgKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8
CiB8wqDCoMKgwqB9ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwgICAgICAgfAotfMKgwqDCoMKgaWYoIGkgXHxcfCB2ZXJzaW9uIFw+
IDIgKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKK3zCoMKgwqDC
oGlmKCBzbGljZV94IFx8XHwgc2xpY2VfeSBcfFx8IHZlcnNpb24gXD4gMiApICAgICAgICAg
ICAgfCAgICAgICB8CiB8wqDCoMKgwqDCoMKgwqDCoHNsaWNlXF9zaXplICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHUoMjQpIHwKIHzCoMKgwqDCoGlmKCBl
YyApIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAg
ICAgICB8CiB8wqDCoMKgwqDCoMKgwqDCoGVycm9yXF9zdGF0dXMgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8ICB1KDgpIHwKQEAgLTU2NSwxMyArNTY1LDEzIEBA
IFRoZSBDUkMgZ2VuZXJhdG9yIHBvbHlub20gdXNlZCBpcyB0aGUgc3RhbmRhcmQgSUVFRSBD
UkMgcG9seW5vbSAoMHgxMDRDMTFEQjcpIHdpCiAKIHwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIHwKIHwtLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18
LS0tOnwKLXwgU2xpY2VIZWFkZXIoIGkgKSB7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB8dHlwZXwKK3wgU2xpY2VIZWFkZXIoICkgeyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8dHlwZXwKIHwgwqDCoMKgc2xpY2VcX3gg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHVyIHwK
IHwgwqDCoMKgc2xpY2VcX3kgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB8IHVyIHwKIHwgwqDCoMKgc2xpY2VcX3dpZHRoIC0gMSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHVyIHwKIHwgwqDCoMKgc2xpY2VcX2hl
aWdodCAtIDEgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHVyIHwK
IHwgwqDCoMKgZm9yKCBqID0gMDsgaiBcPCBxdWFudFxfdGFibGVcX2luZGV4XF9jb3VudDsg
aisrICkgICAgICB8ICAgIHwKLXwgwqDCoMKgwqDCoMKgwqBxdWFudFxfdGFibGVcX2luZGV4
IFsgaSBdWyBqIF0gICAgICAgICAgICAgICAgICAgICAgfCB1ciB8Cit8IMKgwqDCoMKgwqDC
oMKgcXVhbnRcX3RhYmxlXF9pbmRleCBbIHNsaWNlXF94IF1bIHNsaWNlXF95IF1bIGogXSAg
IHwgdXIgfAogfCDCoMKgwqBwaWN0dXJlXF9zdHJ1Y3R1cmUgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHwgdXIgfAogfCDCoMKgwqBzYXJcX251bSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgdXIgfAogfCDCoMKgwqBz
YXJcX2RlbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHwgdXIgfApAQCAtNzU1LDEwICs3NTUsMTAgQEAgRGVjb2RlcnMgU0hPVUxEIGFjY2VwdCBh
bmQgaW50ZXJwcmV0IGJpdHNfcGVyX3Jhd19zYW1wbGUgPSAwIGFzIDguCiB8IDAgICAgIHwg
dHJhbnNwYXJlbmN5IHBsYW5lIGlzIG5vdCBwcmVzZW50fAogfCAxICAgICB8IHRyYW5zcGFy
ZW5jeSBwbGFuZSBpcyBwcmVzZW50ICAgIHwKIAotKipudW1cX2hcX3NsaWNlcyoqIGluZGlj
YXRlcyB0aGUgbnVtYmVyIG9mIGhvcml6b250YWwgZWxlbWVudHMgb2YgdGhlIHNsaWNlIHJh
c3Rlci4KKyoqbnVtXF9oXF9zbGljZXMqKiBpbmRpY2F0ZXMgdGhlIG1heGltYWwgbnVtYmVy
IG9mIGhvcml6b250YWwgZWxlbWVudHMgb2YgdGhlIHNsaWNlIHJhc3Rlci4KIEluZmVycmVk
IHRvIGJlIDEgaWYgbm90IHByZXNlbnQuCiAKLSoqbnVtXF92XF9zbGljZXMqKiBpbmRpY2F0
ZXMgdGhlIG51bWJlciBvZiB2ZXJ0aWNhbCBlbGVtZW50cyBvZiB0aGUgc2xpY2UgcmFzdGVy
LgorKipudW1cX3ZcX3NsaWNlcyoqIGluZGljYXRlcyB0aGUgbWF4aW1hbCBudW1iZXIgb2Yg
dmVydGljYWwgZWxlbWVudHMgb2YgdGhlIHNsaWNlIHJhc3Rlci4KIEluZmVycmVkIHRvIGJl
IDEgaWYgbm90IHByZXNlbnQuCiAKICoqcXVhbnRcX3RhYmxlXF9jb3VudCoqIGluZGljYXRl
cyB0aGUgbnVtYmVyIG9mIHF1YW50aXphdGlvbiB0YWJsZSBzZXRzLgpAQCAtNzc2LDggKzc3
Niw2IEBAIEluZmVycmVkIHRvIGJlIDAgaWYgbm90IHByZXNlbnQuCiBwcmVkID0gaiA/IGlu
aXRpYWxcX3N0YXRlc1sgaSBdW2ogLSAxXVsgayBdIDogMTI4CiBpbml0aWFsXF9zdGF0ZVsg
aSBdWyBqIF1bIGsgXSA9ICggcHJlZCArIGluaXRpYWxcX3N0YXRlXF9kZWx0YVsgaSBdWyBq
IF1bIGsgXSApICYgMjU1CiAKLSoqc2xpY2VcX2NvdW50KiogaW5kaWNhdGVzIHRoZSBudW1i
ZXIgb2Ygc2xpY2VzIGluIHRoZSBjdXJyZW50IGZyYW1lLCBzbGljZVxfY291bnQgaXMgMSBp
ZiBpdCBpcyBub3QgZXhwbGljaXRseSBjb2RlZC4KLQogKiplYyoqIGluZGljYXRlcyB0aGUg
ZXJyb3IgZGV0ZWN0aW9uL2NvcnJlY3Rpb24gdHlwZS4KIAogfHZhbHVlIHwgZXJyb3IgZGV0
ZWN0aW9uL2NvcnJlY3Rpb24gdHlwZSAgICAgICAgICB8Ci0tIAoyLjcuMC53aW5kb3dzLjEK
Cg==
--------------013EBE792F97678BFC032B04--


From nobody Fri May 13 02:40:25 2016
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 DE5F112B044 for ; Fri, 13 May 2016 02:40:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 DRJbUykSyOAx for ; Fri, 13 May 2016 02:40:20 -0700 (PDT)
Received: from mo7.mail-out.ovh.net (mo7.mail-out.ovh.net [178.32.228.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2B812B04E for ; Fri, 13 May 2016 02:40:20 -0700 (PDT)
Received: from player759.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id E65B110041B9 for ; Fri, 13 May 2016 11:40:18 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player759.ha.ovh.net (Postfix) with ESMTPSA id 8E9C864006E for ; Fri, 13 May 2016 11:40:18 +0200 (CEST)
To: cellar@ietf.org
From: Jerome Martinez 
Message-ID: <4bd781e0-a6a3-2249-2a3e-a4f50e93c351@mediaarea.net>
Date: Fri, 13 May 2016 11:40:06 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------F62AF6ADFE80CCB646D3292B"
X-Ovh-Tracer-Id: 11601835593462976657
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrvddugdduiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Archived-At: 
Subject: [Cellar] [PATCH] Rewrite of the restrictions paragraph
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 13 May 2016 09:40:23 -0000

This is a multi-part message in MIME format.
--------------F62AF6ADFE80CCB646D3292B
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Following the discussion "FFV1 slices count", I propose the attached 
patch in order to be more explicit about the restrictions.

- Definition of frame width and height,
- Removal of pixel size in the formula (we can have a formula based on 
the bitstream fields)

Jérôme


--------------F62AF6ADFE80CCB646D3292B
Content-Type: text/plain; charset=UTF-8;
 name="0001-Rewrite-of-the-restrictions-paragraph.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="0001-Rewrite-of-the-restrictions-paragraph.patch"

RnJvbSAyYzE5N2U0ODA0ODZkODA2NDA2NjVlNThmZjJmYjQ5YThiZjNkY2ZiIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Sj1DMz1BOXI9QzM9QjRtZT0yME1h
cnRpbmV6Pz0gPGplcm9tZUBtZWRpYWFyZWEubmV0PgpEYXRlOiBGcmksIDEzIE1heSAyMDE2
IDExOjM3OjQ1ICswMjAwClN1YmplY3Q6IFtQQVRDSF0gUmV3cml0ZSBvZiB0aGUgcmVzdHJp
Y3Rpb25zIHBhcmFncmFwaAoKLSBEZWZpbml0aW9uIG9mIGZyYW1lIHdpZHRoIGFuZCBoZWln
aHQsCi0gUmVtb3ZhbCBvZiBwaXhlbCBzaXplIGluIHRoZSBmb3JtdWxhICh3ZSBjYW4gaGF2
ZSBhIGZvcm11bGEgYmFzZWQKb24gdGhlIGJpdHN0cmVhbSBmaWVsZHMpCi0tLQogZmZ2MS5t
ZCB8IDkgKysrKysrKystCiAxIGZpbGUgY2hhbmdlZCwgOCBpbnNlcnRpb25zKCspLCAxIGRl
bGV0aW9uKC0pCgpkaWZmIC0tZ2l0IGEvZmZ2MS5tZCBiL2ZmdjEubWQKaW5kZXggZTQ4YTdl
ZS4uMDQ4MGM2MyAxMDA2NDQKLS0tIGEvZmZ2MS5tZAorKysgYi9mZnYxLm1kCkBAIC00NTgs
NiArNDU4LDEyIEBAIE5vdGUsIHRoaXMgaXMgZGlmZmVyZW50IGZyb20gSlBFRy1MUywgd2hp
Y2ggZG9lc27igJl0IHVzZSBwcmVkaWN0aW9uIGluIHJ1biBtb2RlCiAKIFRoZSBzYW1lIGNv
bnRleHQgd2hpY2ggaXMgaW5pdGlhbGl6ZWQgdG8gMTI4IGlzIHVzZWQgZm9yIGFsbCBmaWVs
ZHMgaW4gdGhlIGhlYWRlci4KIAorVGhlIHN0cmVhbSB0cmFuc3BvcnQgbGF5ZXIgTVVTVCBw
cm92aWRlIHRoZSBmb2xsb3dpbmcgZGF0YSBkdXJpbmcgaW5pdGlhbGl6YXRpb24gb2YgdGhl
IGRlY29kZXI6CisKKyoqZnJhbWVcX3dpZHRoKiogaXMgZGVmaW5lZCBhcyBmcmFtZSB3aWR0
aCBpbiBwaXhlbHMuCisKKyoqZnJhbWVcX2hlaWdodCoqIGlzIGRlZmluZWQgYXMgZnJhbWUg
aGVpZ2h0IGluIHBpeGVscy4KKwogRGVmYXVsdCB2YWx1ZXMgYXQgdGhlIGRlY29kZXIgaW5p
dGlhbGl6YXRpb24gcGhhc2U6CiAKICoqQ29uZmlndXJhdGlvblJlY29yZElzUHJlc2VudCoq
IGlzIHNldCB0byAwLgpAQCAtODQzLDcgKzg0OSw4IEBAIE1BWFxfQ09OVEVYVFxfSU5QVVRT
IGlzIDUuCiAKICMjIyBSZXN0cmljdGlvbnMKIAotSW4gdmVyc2lvbiAyIGFuZCBsYXRlciB0
aGUgbWF4aW11bSBzbGljZSBzaXplIGluIHBpeGVscyBpcyAkXGZyYWN7d2lkdGhcY2VudGVy
ZG90IGhlaWdodH17NH0kLCB1bmxlc3MgdGhlIGZyYW1lIGlzIHNtYWxsZXIgb3IgZXF1YWwg
MzUyeDI4OCB0aGlzIGlzIHRvIGVuc3VyZSB0aGF0IGZhc3QgbXVsdGl0aHJlYWRlZCBkZWNv
ZGluZyBpcyBwb3NzaWJsZS4KK1RvIGVuc3VyZSB0aGF0IGZhc3QgbXVsdGl0aHJlYWRlZCBk
ZWNvZGluZyBpcyBwb3NzaWJsZSwgc3RhcnRpbmcgdmVyc2lvbiAyIGFuZCBpZiBmcmFtZVxf
d2lkdGggKiBmcmFtZVxfaGVpZ2h0IGlzIG1vcmUgdGhhbiAxMDEzNzYsIHNsaWNlXF93aWR0
aCAqIHNsaWNlXF9oZWlnaHQgU0hPVUxEIGJlIGxlc3Mgb3IgZXF1YWwgdG8gbnVtXF9oXF9z
bGljZXMgKiBudW1cX3ZcX3NsaWNlcyAvIDQuCitOb3RlOiAxMDEzNzYgaXMgdGhlIGZyYW1l
IHNpemUgaW4gcGl4ZWxzIG9mIGEgMzUyeDI4OCBmcmFtZSBhbHNvIGtub3duIGFzIENJRiAo
IkNvbW1vbiBJbnRlcm1lZGlhdGUgRm9ybWF0IikgZnJhbWUgc2l6ZSBmb3JtYXQuCiAKICMg
Q2hhbmdlbG9nCiAKLS0gCjIuNy4wLndpbmRvd3MuMQoK
--------------F62AF6ADFE80CCB646D3292B--


From nobody Fri May 13 03:26:29 2016
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 5332A12D172 for ; Fri, 13 May 2016 03:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 oAzXUvCmq--o for ; Fri, 13 May 2016 03:26:25 -0700 (PDT)
Received: from 1.mo7.mail-out.ovh.net (1.mo7.mail-out.ovh.net [178.33.45.51]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA9E12B05E for ; Fri, 13 May 2016 03:26:24 -0700 (PDT)
Received: from player759.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 2F3D8100424E for ; Fri, 13 May 2016 12:26:16 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player759.ha.ovh.net (Postfix) with ESMTPSA id 8E1F9640078 for ; Fri, 13 May 2016 12:26:16 +0200 (CEST)
To: cellar@ietf.org
References: <104d0f51-4b95-509f-13e2-b305f5f7fe3d@mediaarea.net> <20160427003739.GF25812@nb4> <56fddd48-efe5-36d0-bac7-d279bbd58fdf@mediaarea.net> <20160512153136.GF25812@nb4>  <20160512215618.GH25812@nb4>
From: Jerome Martinez 
Message-ID: <70998718-e28e-80e7-a03a-081d85881041@mediaarea.net>
Date: Fri, 13 May 2016 12:26:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <20160512215618.GH25812@nb4>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 12378143578194317457
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrvddugddvhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Archived-At: 
Subject: Re: [Cellar] FFV1 slices count
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 13 May 2016 10:26:28 -0000

hi,

Le 12/05/2016  23:56, Michael Niedermayer a crit :
> Hi
>
> On Thu, May 12, 2016 at 08:39:44PM +0200, Jerome Martinez wrote:
>> Hi Michael,
>> Thanks for your feedback.
>> as you may guess, I disagree a bit, so let's go:
>>
>> Le 12/05/2016  17:31, Michael Niedermayer a crit :
>>> [...]
>>>
>>>> instead of having this scenario for slices (num_h_slice=2 and
>>>> num_v_slice=2):
>>>> 12
>>>> 34
>>>> we could imagine (num_h_slice=4 and num_v_slice=2)
>>>> 1111 (slice 1 with slice_width of 4)
>>>> 2344 (slice 4 with slice_width of 2)
>>>> in that case, 1 thread would do nearly nothing and 3 threads would
>>>> be maybe with less overloading than with the limitation, but it is
>>>> forbidden by the slice size limitation. We prevent encoder to
>>>> imagine optimizations we don't currently think about.
>>> and a decoder designed to support a max slice size of 352x288 would
>>> then run out of memory,
>> Currently, it is authorized that a frame of 706x576 has only 4
>> slices, limitation of a slice size of 352x288 in a decoder means
>> that a 706x576 "legal" frame could not be decoded.
> The current restriction limits the slice size to a quarter of the
> resolution for "non tiny" resolutions.
> if we remove this restriction decoders must support slices that are
> 4 times as big. If the decoder runs on a quad core CPU it would
> require a 4 times faster one to do that.

but a person having a 16-core CPU can complain that you force only 4 
slices instead of 16, and a person having a single-core CPU may complain 
that compression ratio is not as good as it could be without such 
restriction and he gets not value added of 4 slices.
this is the reason I talk of encoder policy: it depends so much of the 
goal of the person who does the encode.

I totally agree that we need profiles/levels, but fact is that we are 
not ready yet about it, having a full set of restrictions for a policy 
with e.g. real time in mind.
In other specifications.

>
>
>> The criticism of the current arbitrary restriction is that it does
>> not make a lot of sense until we provide a full set of restrictions
> see above, it quadruples the decodable resolution on the currently
> commonly used CPUs compared to not having that restriction
>
> i dont oppose doing something else at all, but if high resolution
> single slice files get created and they use the context information
> from each previous frame, they basically would be forced to be
> decoded single threaded and probably not in realtime.

Agreed. But we don't limit the frame width/height so this is not 
complete for guaranteeing something about real time.

>
>
> [...]
>>>
>>>> Additionally, from my point of view, such restriction is an encoder
>>>> policy, not a bitstream restriction. Actually, I see the restriction
>>> restricting what is allowed to exist in the bitstream or what an
>>> encoder is allowed to generate is the same IMO
>> I disagree. An encoder can have some policies due to a specific goal
>> (proselytism? ;-) ), this does not prevent a decoder to accept
> we misunderstand each other here
> what i meant was that the specification restricting what the bitstream
> is allowed to look like and the specification restricting what an
> encoder can generate is effectively the same
>
> encoder implementations of course can and do have many more
> restrictions for all kinds or reasons. Thats an implementation detail

And here I think that the mandatory 4 slices is more an implementation 
detail that something relevant for a specification restriction.

>
>
> [...]
>> I reverse the questions:
>> if a decoder is able to decode 4 slices of a 7680x4320 frame (so max
>> slice size of 3840x2160), why could it not decode a single slice of
>> 353x288 when the frame size is 353x288?
>> why should we forbidden 353x288 with 1 slice if we authorize 4
>> slices of 3840x2160?
> thats a good question as it shows the problem well i think
> many decoders wont be able to decode 7680x4320 in realtime
> thus your assumtation you start with already doesnt apply
>
> if you have a really powerfull decoder it of course doesnt matter
>   if you have 1 or 4 slices for cases where the decoder is vastly
> overpowered. It does matters alot for cases that are at the edge of
> being decodeable in realtime

But another person could say that in few years we will all have 16-core 
CPU so that we must forbid less than 16 slices, for cases that are at 
the edge of
being decodeable in realtime.


>
>
>
>> Do yo have a proof that a FPGA or ASIC could handle my example badly
>> due to performance (which ones?) problems?
> If you have a decoding pipeline in hw, id assume each pipeline step
> would require a fixed and equal number of cycles, its probably
> easier to implement that way. So it wouldnt be any faster with
> black than with detailed data. Iam not a hw guy, i might be wrong
> here of course
>
> But lets look at the reverse, assume the hardware would need more
> time to decode highly detailed data.
> To be able to decode a specific resolution and slice resolution
> the hardware must be able to decode the most detailed and hardest
> picture or its users would be kind of unhappy occasionally
> now would you make that hw able to decode higher resolutions if they
> are all black or simpler?
> i guess it depends on how much resolution one gains with real world
> videos and what the aditional cost is
>
>
> [...]
>
>>> But if a single unconditional limit could be used that would be simpler
>>> and decoders could then still claim to support for example all content
>>> up to 1080p 60fps
>>>
>>> Can you provide an actual testcase where removing the limit improves
>>> decoding speed or something else ?
>> The idea is to permit future development, not to prove it right now.
> i dont see how the restriction would prevent future development
> a future version could lift it for files under that future version

A future encoder could detect black frames and:
- encode 4 slices when a frame is complex
- encode 1 slice (slice_width=2 and slice_height=2) when a black frame 
is detected.

the difference is only few bytes saved (e.g. 439 bytes with 4 slices vs 
190 bytes with 1 slice for a 353x288 frame), but again it is a demo that 
it may be useful sometimes (e.g. if compression ratio is the goal rather 
than decoding speed, or an average between compression and decompression 
speed).

>
>
>> But let speak of frame byte size:
>> ffmpeg -y -f lavfi -i testsrc -t 1 -filter:v scale="353:288" -vcodec
>> ffv1 -level 3 353x288-4slices.mkv
>> 1st frame is 11048 bytes, file size is 242 kiB
>> ffmpeg -y -f lavfi -i testsrc -t 1 -filter:v scale="353:288" -vcodec
>> ffv1 -level 3 -slices 1 353x288-4slices.mkv
>> 1st frame 10138 bytes (-8%), file size is 222 kiB (-8% too)
>> (note: modified FFmpeg in order to accept this command)
>>
>> this example may be considered as stupid (small file, small frame
>> size) but it is just a demonstration that forcing some restriction
>> for all FFV1 streams is sometimes not optimal.
> indeed, thanks for looking for that case
>
>
>> ***
>>
>> If I don't succeed to convince you about the informal
>> recommendation, would the use of "SHOULD" in the current spec
>> (without changing the other parts) be acceptable?
>>  From RFC 2119: SHOULD means "that there may exist valid reasons in
>> particular circumstances to ignore a particular item, but the full
>> implications must be understood and carefully weighed before
>> choosing a different course"
> i think some restriction should remain to ensure that files dont
> needlessly end up requiring 4 times more time to decode
> that can be a different restriction of course, i dont mind that at all

this is the point: this is more a policy (different restrictions could 
be used) instead of a bitstream restriction due to technical things.

>
> but if we end up having 1080p files that can be decoded in realtime
> and others that need can only be decoded at a quarter of realtime
> because they where encoded ignoring a recommandition that could be
> a bad experience for the user trying to use these files
> i think we should try to avoid that

I agree. I never said that I want to remove the limitation, just that it 
may be not useful in all cases.
 From the discussion, I think we could agree on "SHOULD" here, because 
it clearly stipulate that "may exist valid reasons in particular 
circumstances to ignore a particular item, but the full implications 
must be understood and carefully weighed before choosing a different 
course" so it fits your goal.
I am against a "MUST".

>
>
>> and what is your point of view about max slices count
>> recommendation? do we recommend nothing? for the moment, as is or
>> with my proposal about num_h_slices and num_v_slices, FFmpeg can not
>> handle "legal" streams e.g. UHD-8K frame with 264 (22x12 slices of
>> 350x360 pixels, so more that the current obligation of 4 slices for
>> 353x288, it is a realistic scenario for an encoder not following
>> FFmpeg encoder limitations and built for CPUs having lot of low
>> powered cores).
> honestly i dont know ATM
> i think there should be a minimum slice size so that tiny slices like
> 10x10 arent causing problems but 350x360 does seem a reasonable size

but you want to forbid 350x360 slices in some cases (e.g. 350x360 
frames) ;-).
the point is that there is a start of definition of a profile but it is 
not complete. This is the reason I am reluctant to write "MUST" here, 
for the moment (until we get profiles/levels in the next version of FFV1)

I wrote a patch for this subject.

Jrme


From nobody Fri May 13 11:06:49 2016
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 ED47D12D1C2 for ; Fri, 13 May 2016 11:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 pHO2Ltlfq9KM for ; Fri, 13 May 2016 11:06:46 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3224412B04D for ; Fri, 13 May 2016 11:06:46 -0700 (PDT)
Received: from mfilter38-d.gandi.net (mfilter38-d.gandi.net [217.70.178.169]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 49096172097 for ; Fri, 13 May 2016 20:06:44 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter38-d.gandi.net
Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter38-d.gandi.net (mfilter38-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id AAqMzVjFG58O for ; Fri, 13 May 2016 20:06:42 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 6FD451720A5 for ; Fri, 13 May 2016 20:06:42 +0200 (CEST)
Date: Fri, 13 May 2016 20:04:37 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160513180437.GI25812@nb4>
References: 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qXGZxhfzFeF/KFJy"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Replace slice_count because it is not precisely defined
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 13 May 2016 18:06:49 -0000

--qXGZxhfzFeF/KFJy
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 13, 2016 at 10:44:29AM +0200, Jerome Martinez wrote:
> In the spec, I see:
> "*slice_count* indicates the number of slices in the current frame,
> slice_count is 1 if it is not explicitly coded."
> and:
> "for(i=3D0; i=20
> but slice_count is not explicitly defined (based on bitstream elements).
> As a slice can have a width or height more than 1, slice_count is
> not num_h_slices * num_v_slices, it depends of slice_width and
> slice_height of each slice.

i think it was meant to be the number of slices if one follows the
chain of slice_size  (or in a badly damaged frame the number of byte
ranges that would have valid looking headers and coded sizes)


>=20
>=20
> I understand that Range coder state variables (see 4.6.1.3) are per
> slice_x and slice_y in the slice raster.
> Is it correct if I say that if for frame 0 a slice with slice_x=3D0,
> slice_y=3D0, slice_width=3D2, slice_height=3D1 (so no frame 0 slice with
> slice_x=3D1, slice_y=3D0), for frame 1 a slice with slice_x=3D1, slice_y=
=3D0
> will have Range coder state variables set to their initial state?

I think the behavior when the slice segmentation changes in a non
key slice is undefined (litterally so as the spec does not say what to
do for that)
i would tend toward leaving that undefined / disallowed
instead of trying to specify some behavior without a bit of study of
its effects and alternatives
disallowing it is easy for implementations


>=20
> I propose the following patch for being more explicit about slices.
> - add "maximal" to num_h/v_slices because we could have less
> elements (e.g. if num_h_slices is 4, we could have a scenario with
> only 3 slices horizontal, e.g. slices with slice_x=3D0 have always
> slice_width=3D2)
> - remove slice_count definition and replace it by a test about the
> presence of remaining bytes at the end of the frame
> - replace "[i]" by "[slice_x][slice_y]"
>=20
> J=E9r=F4me
>=20

>  ffv1.md |   20 +++++++++-----------
>  1 file changed, 9 insertions(+), 11 deletions(-)
> 74f93a5ba93c4fd91e1857e7a3a5a224e6db8a1e  0001-Replace-slice_count-becaus=
e-it-is-not-precisely-defi.patch
> From 3cbb0b1803b8a835339222d124e55c71a5aa1725 Mon Sep 17 00:00:00 2001
> From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D 
> Date: Fri, 13 May 2016 09:26:43 +0200
> Subject: [PATCH] Replace slice_count because it is not precisely defined
>=20
> - add "maximal" to num_h/v_slices because we could have less
> elements (e.g. if num_h_slices is 4, we could have a scenario
> with only 3 slices horizontal, e.g. slices with slice_x=3D0 have
> always slice_width=3D2)
> - remove slice_count definition and replace it by a test about
> the presence of remaining bytes at the end of the frame
> - replace "[i]" by "[slice_x][slice_y]"
> ---
>  ffv1.md | 20 +++++++++-----------
>  1 file changed, 9 insertions(+), 11 deletions(-)
>=20
> diff --git a/ffv1.md b/ffv1.md
> index e48a7ee..3fd0507 100644
> --- a/ffv1.md
> +++ b/ffv1.md
> @@ -516,17 +516,17 @@ See [NUT](#references) for more information about e=
lements.
>  |=A0=A0=A0=A0keyframe                                       |  br|
>  |=A0=A0=A0=A0if( keyframe && !ConfigurationRecordIsPresent )|    |
>  |=A0=A0=A0=A0=A0=A0=A0=A0=A0Parameters( )                             | =
   |
> -|=A0=A0=A0=A0for( i =3D 0; i \< slice\_count; i++ )           |    |
> -|=A0=A0=A0=A0=A0=A0=A0=A0Slice( i )                                 |   =
 |
> +|=A0=A0=A0=A0while ( remaining_bits_in_bitstream() )        |    |
> +|=A0=A0=A0=A0=A0=A0=A0=A0Slice( )                                   |   =
 |
>  |}                                                  |    |

iam a bit sceptic on this
first it does not work for multitreading, maybe its not wrong but
one cannot implement multitreading if one has to decode the previous
slice before knowing the start of the next

also theres the question about extensibility when defined by
more bits instead of teh slice sizes
i _think_ we currently could add things before slice_size without
breaking the bitstream but maybe iam missing something


> =20
>  ## Slice
> =20
>  |                                                                    |
>  |------------------------------------------------------------|:------|
> -|Slice( i ) {                                                | type  |
> +|Slice( )   {                                                | type  |
>  |=A0=A0=A0=A0if( version \> 2 )                                      |  =
     |
> -|=A0=A0=A0=A0=A0=A0=A0=A0SliceHeader( i )                               =
     |       |
> +|=A0=A0=A0=A0=A0=A0=A0=A0SliceHeader( )                                 =
     |       |
>  |=A0=A0=A0=A0if( colorspace\_type =3D=3D 0) {                           =
 |       |
>  |=A0=A0=A0=A0=A0=A0=A0=A0for( p =3D 0; p \< primary\_color\_count; p++ )=
 {     |       |
>  |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Plane( p )                         =
             |       |
> @@ -535,7 +535,7 @@ See [NUT](#references) for more information about ele=
ments.
>  |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0for( p =3D 0; p \< primary\_color\_=
count; p++ ) { |       |
>  |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Line( p, y )           =
                     |       |
>  |=A0=A0=A0=A0}                                                       |  =
     |
> -|=A0=A0=A0=A0if( i \|\| version \> 2 )                               |  =
     |
> +|=A0=A0=A0=A0if( slice_x \|\| slice_y \|\| version \> 2 )            |  =
     |
>  |=A0=A0=A0=A0=A0=A0=A0=A0slice\_size                                    =
     | u(24) |
>  |=A0=A0=A0=A0if( ec ) {                                              |  =
     |
>  |=A0=A0=A0=A0=A0=A0=A0=A0error\_status                                  =
     |  u(8) |
> @@ -565,13 +565,13 @@ The CRC generator polynom used is the standard IEEE=
 CRC polynom (0x104C11DB7) wi
> =20
>  |                                                            |    |
>  |------------------------------------------------------------|---:|
> -| SliceHeader( i ) {                                         |type|
> +| SliceHeader( ) {                                           |type|
>  | =A0=A0=A0slice\_x                                                | ur |
>  | =A0=A0=A0slice\_y                                                | ur |
>  | =A0=A0=A0slice\_width - 1                                        | ur |
>  | =A0=A0=A0slice\_height - 1                                       | ur |
>  | =A0=A0=A0for( j =3D 0; j \< quant\_table\_index\_count; j++ )      |  =
  |
> -| =A0=A0=A0=A0=A0=A0=A0quant\_table\_index [ i ][ j ]                   =
   | ur |
> +| =A0=A0=A0=A0=A0=A0=A0quant\_table\_index [ slice\_x ][ slice\_y ][ j ]=
   | ur |
>  | =A0=A0=A0picture\_structure                                      | ur |
>  | =A0=A0=A0sar\_num                                                | ur |
>  | =A0=A0=A0sar\_den                                                | ur |

> @@ -755,10 +755,10 @@ Decoders SHOULD accept and interpret bits_per_raw_s=
ample =3D 0 as 8.
>  | 0     | transparency plane is not present|
>  | 1     | transparency plane is present    |
> =20
> -**num\_h\_slices** indicates the number of horizontal elements of the sl=
ice raster.
> +**num\_h\_slices** indicates the maximal number of horizontal elements o=
f the slice raster.
>  Inferred to be 1 if not present.

i would define the raster resolution (whatever one wants to call it)
and then have slices span multiple raster elements if thats what they
do
as in the resolution is X by Y elements and each element of that is
either part of the blue rectangle or not ...

[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.

--qXGZxhfzFeF/KFJy
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc2FzUACgkQYR7HhwQLD6uHlACghjU67hC69NDNx0sgdOvyYgXo
SMQAn27NrWTRBQusOpfNVrc0dZ4UYuBT
=U2H3
-----END PGP SIGNATURE-----

--qXGZxhfzFeF/KFJy--


From nobody Fri May 13 11:16:44 2016
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 2B22E12D66A for ; Fri, 13 May 2016 11:16:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 Ru7P23DZODL1 for ; Fri, 13 May 2016 11:16:41 -0700 (PDT)
Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [IPv6:2001:4b98:c:538::194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25FCA12D663 for ; Fri, 13 May 2016 11:16:40 -0700 (PDT)
Received: from mfilter44-d.gandi.net (mfilter44-d.gandi.net [217.70.178.175]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 2C353C5A50 for ; Fri, 13 May 2016 20:16:39 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter44-d.gandi.net
Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter44-d.gandi.net (mfilter44-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id lvkV0-sVzmHJ for ; Fri, 13 May 2016 20:16:37 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 779FCC5A53 for ; Fri, 13 May 2016 20:16:37 +0200 (CEST)
Date: Fri, 13 May 2016 20:14:32 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160513181432.GJ25812@nb4>
References: <4bd781e0-a6a3-2249-2a3e-a4f50e93c351@mediaarea.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WfCN8Biv230Eu90c"
Content-Disposition: inline
In-Reply-To: <4bd781e0-a6a3-2249-2a3e-a4f50e93c351@mediaarea.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH] Rewrite of the restrictions paragraph
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 13 May 2016 18:16:43 -0000

--WfCN8Biv230Eu90c
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 13, 2016 at 11:40:06AM +0200, Jerome Martinez wrote:
> Following the discussion "FFV1 slices count", I propose the attached
> patch in order to be more explicit about the restrictions.
>=20
> - Definition of frame width and height,
> - Removal of pixel size in the formula (we can have a formula based
> on the bitstream fields)
>=20
> J=C3=A9r=C3=B4me
>=20

>  ffv1.md |    9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> ade5ca179746784b68b5123b83d4a25f9b29d2f0  0001-Rewrite-of-the-restriction=
s-paragraph.patch
> From 2c197e480486d80640665e58ff2fb49a8bf3dcfb Mon Sep 17 00:00:00 2001
> From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D 
> Date: Fri, 13 May 2016 11:37:45 +0200
> Subject: [PATCH] Rewrite of the restrictions paragraph
>=20
> - Definition of frame width and height,
> - Removal of pixel size in the formula (we can have a formula based
> on the bitstream fields)
> ---
>  ffv1.md | 9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
>=20
> diff --git a/ffv1.md b/ffv1.md
> index e48a7ee..0480c63 100644
> --- a/ffv1.md
> +++ b/ffv1.md
> @@ -458,6 +458,12 @@ Note, this is different from JPEG-LS, which doesn=E2=
=80=99t use prediction in run mode
> =20
>  The same context which is initialized to 128 is used for all fields in t=
he header.
> =20
> +The stream transport layer MUST provide the following data during initia=
lization of the decoder:
> +
> +**frame\_width** is defined as frame width in pixels.
> +
> +**frame\_height** is defined as frame height in pixels.

not sure about the exact wording "stream transport layer" vs
something like "the follwing must be provided by external means"
but its ok either way with me
ITU H.263 talks about "external means" in similar cases (the ones i
looked at at least)


> +
>  Default values at the decoder initialization phase:
> =20
>  **ConfigurationRecordIsPresent** is set to 0.
> @@ -843,7 +849,8 @@ MAX\_CONTEXT\_INPUTS is 5.
> =20
>  ### Restrictions
> =20
> -In version 2 and later the maximum slice size in pixels is $\frac{width\=
centerdot height}{4}$, unless the frame is smaller or equal 352x288 this is=
 to ensure that fast multithreaded decoding is possible.
> +To ensure that fast multithreaded decoding is possible, starting version=
 2 and if frame\_width * frame\_height is more than 101376, slice\_width * =
slice\_height SHOULD be less or equal to num\_h\_slices * num\_v\_slices / =
4.
> +Note: 101376 is the frame size in pixels of a 352x288 frame also known a=
s CIF ("Common Intermediate Format") frame size format.

is it possible to use stronger wording than just SHOULD ?
explicitly stating that not doing so would quarduple the time needed
to decode the frames and that thus potentially significantly fewer
decoders would be able to decode the stream in realtime
but i still feel that some harder restriction should be left in the
spec

[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.

--WfCN8Biv230Eu90c
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc2GYgACgkQYR7HhwQLD6uKiACeMl1RU4QF+MMu6K10u7VfaLnR
bGoAn2dK1PWtA5j+6sCdHcrGOQ0lDs8B
=bvsK
-----END PGP SIGNATURE-----

--WfCN8Biv230Eu90c--


From nobody Fri May 13 11:34:40 2016
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 8FA7B12D0A0 for ; Fri, 13 May 2016 11:34:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 os4tOSC-xpmF for ; Fri, 13 May 2016 11:34:35 -0700 (PDT)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2803312D52A for ; Fri, 13 May 2016 11:34:35 -0700 (PDT)
Received: from mfilter40-d.gandi.net (mfilter40-d.gandi.net [217.70.178.171]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 7BC05FB8C7 for ; Fri, 13 May 2016 20:34:33 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter40-d.gandi.net
Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter40-d.gandi.net (mfilter40-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id aJpecISlcTpP for ; Fri, 13 May 2016 20:34:31 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 9305FFB882 for ; Fri, 13 May 2016 20:34:31 +0200 (CEST)
Date: Fri, 13 May 2016 20:32:26 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160513183226.GK25812@nb4>
References: <104d0f51-4b95-509f-13e2-b305f5f7fe3d@mediaarea.net> <20160427003739.GF25812@nb4> <56fddd48-efe5-36d0-bac7-d279bbd58fdf@mediaarea.net> <20160512153136.GF25812@nb4>  <20160512215618.GH25812@nb4> <70998718-e28e-80e7-a03a-081d85881041@mediaarea.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="pnKWRgl7dPxnfV0h"
Content-Disposition: inline
In-Reply-To: <70998718-e28e-80e7-a03a-081d85881041@mediaarea.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] FFV1 slices count
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 13 May 2016 18:34:39 -0000

--pnKWRgl7dPxnfV0h
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 13, 2016 at 12:26:04PM +0200, Jerome Martinez wrote:
> hi,
>=20
> Le 12/05/2016 =E0 23:56, Michael Niedermayer a =E9crit :
> >Hi
> >
> >On Thu, May 12, 2016 at 08:39:44PM +0200, Jerome Martinez wrote:
> >>Hi Michael,
> >>Thanks for your feedback.
> >>as you may guess, I disagree a bit, so let's go:
> >>
> >>Le 12/05/2016 =E0 17:31, Michael Niedermayer a =E9crit :
> >>>[...]
> >>>
> >>>>instead of having this scenario for slices (num_h_slice=3D2 and
> >>>>num_v_slice=3D2):
> >>>>12
> >>>>34
> >>>>we could imagine (num_h_slice=3D4 and num_v_slice=3D2)
> >>>>1111 (slice 1 with slice_width of 4)
> >>>>2344 (slice 4 with slice_width of 2)
> >>>>in that case, 1 thread would do nearly nothing and 3 threads would
> >>>>be maybe with less overloading than with the limitation, but it is
> >>>>forbidden by the slice size limitation. We prevent encoder to
> >>>>imagine optimizations we don't currently think about.
> >>>and a decoder designed to support a max slice size of 352x288 would
> >>>then run out of memory,
> >>Currently, it is authorized that a frame of 706x576 has only 4
> >>slices, limitation of a slice size of 352x288 in a decoder means
> >>that a 706x576 "legal" frame could not be decoded.
> >The current restriction limits the slice size to a quarter of the
> >resolution for "non tiny" resolutions.
> >if we remove this restriction decoders must support slices that are
> >4 times as big. If the decoder runs on a quad core CPU it would
> >require a 4 times faster one to do that.
>=20
> but a person having a 16-core CPU can complain that you force only 4
> slices instead of 16, and a person having a single-core CPU may
> complain that compression ratio is not as good as it could be
> without such restriction and he gets not value added of 4 slices.
> this is the reason I talk of encoder policy: it depends so much of
> the goal of the person who does the encode.

the restriction is a compromise indeed
the compression rate for real world videos at real world resolutions
should (i hope) be negligible and both 4 core and 16core users have
4 times a=B4faster decode times with it than with 1s slice videos
without the restriction

the compression difference is indeed as you showed not negligible in
corner cases, like a single frame at 353x288 and iam indeed not happy
about that ...


>=20
> I totally agree that we need profiles/levels, but fact is that we
> are not ready yet about it, having a full set of restrictions for a
> policy with e.g. real time in mind.
> In other specifications.
>=20
> >
> >
> >>The criticism of the current arbitrary restriction is that it does
> >>not make a lot of sense until we provide a full set of restrictions
> >see above, it quadruples the decodable resolution on the currently
> >commonly used CPUs compared to not having that restriction
> >
> >i dont oppose doing something else at all, but if high resolution
> >single slice files get created and they use the context information
> >from each previous frame, they basically would be forced to be
> >decoded single threaded and probably not in realtime.
>=20
> Agreed. But we don't limit the frame width/height so this is not
> complete for guaranteeing something about real time.

frame width/height is a quite different beast IMHO
like also frame rate it fundamentally is a parameter that says
how much temporal / spatial detail is in a video. double it and the
video becomes twice as hard to decode (approximately)

OTOH the slice segmentation is a ffv1 coding detail, it doesnt
change the actual raw samples


[...]
>=20
> >
> >
> >[...]
> >>I reverse the questions:
> >>if a decoder is able to decode 4 slices of a 7680x4320 frame (so max
> >>slice size of 3840x2160), why could it not decode a single slice of
> >>353x288 when the frame size is 353x288?
> >>why should we forbidden 353x288 with 1 slice if we authorize 4
> >>slices of 3840x2160?
> >thats a good question as it shows the problem well i think
> >many decoders wont be able to decode 7680x4320 in realtime
> >thus your assumtation you start with already doesnt apply
> >
> >if you have a really powerfull decoder it of course doesnt matter
> >  if you have 1 or 4 slices for cases where the decoder is vastly
> >overpowered. It does matters alot for cases that are at the edge of
> >being decodeable in realtime
>=20
> But another person could say that in few years we will all have
> 16-core CPU so that we must forbid less than 16 slices, for cases
> that are at the edge of
> being decodeable in realtime.

yes


[...]

> >
> >but if we end up having 1080p files that can be decoded in realtime
> >and others that need can only be decoded at a quarter of realtime
> >because they where encoded ignoring a recommandition that could be
> >a bad experience for the user trying to use these files
> >i think we should try to avoid that
>=20
> I agree. I never said that I want to remove the limitation, just
> that it may be not useful in all cases.
> From the discussion, I think we could agree on "SHOULD" here,
> because it clearly stipulate that "may exist valid reasons in
> particular circumstances to ignore a particular item, but the full
> implications must be understood and carefully weighed before
> choosing a different course" so it fits your goal.
> I am against a "MUST".

what iam afraid of is that a implementor or even user reads
"SHOULD", tests it,finds 0.1% better compression and it working fine
on his high end box and  then encodes videos that way withiout
undertanding that they wont be decodeable in realtime on more
average systems
and with multiple/many people doing that suddenly we have material
all over the place that many people cannot watch even though the
one creating it did so without actually gaining anything worthwhile


[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus

--pnKWRgl7dPxnfV0h
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc2HboACgkQYR7HhwQLD6uudgCdGf+uk77w5ZiiuNNfbQGODrL0
z7wAn2nl1679oWUPnrmXyiXriSBzb5hE
=x07G
-----END PGP SIGNATURE-----

--pnKWRgl7dPxnfV0h--


From nobody Fri May 13 12:00:37 2016
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 B1DEA12D6F8 for ; Fri, 13 May 2016 12:00:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 q96QNLWdlyko for ; Fri, 13 May 2016 12:00:32 -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 AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A17A12D693 for ; Fri, 13 May 2016 12:00:26 -0700 (PDT)
Received: from player759.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id D0E8EFFCC01 for ; Fri, 13 May 2016 21:00:23 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player759.ha.ovh.net (Postfix) with ESMTPSA id 45C4E640094 for ; Fri, 13 May 2016 21:00:23 +0200 (CEST)
To: cellar@ietf.org
References:  <20160513180437.GI25812@nb4>
From: Jerome Martinez 
Message-ID: 
Date: Fri, 13 May 2016 21:00:11 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <20160513180437.GI25812@nb4>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 2614058109080375441
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrvddugdduvdelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Replace slice_count because it is not precisely defined
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 13 May 2016 19:00:36 -0000

Le 13/05/2016  20:04, Michael Niedermayer a crit :
> On Fri, May 13, 2016 at 10:44:29AM +0200, Jerome Martinez wrote:
>> In the spec, I see:
>> "*slice_count* indicates the number of slices in the current frame,
>> slice_count is 1 if it is not explicitly coded."
>> and:
>> "for(i=0; i>
>> but slice_count is not explicitly defined (based on bitstream elements).
>> As a slice can have a width or height more than 1, slice_count is
>> not num_h_slices * num_v_slices, it depends of slice_width and
>> slice_height of each slice.
> i think it was meant to be the number of slices if one follows the
> chain of slice_size  (or in a badly damaged frame the number of byte
> ranges that would have valid looking headers and coded sizes)

but it is not in the bitstream, I see no way to define it in another way 
(currently, it is not defined at all so we can not keep it as is), this 
is the reason I propose to replace it.
but depending of your answer on the other questions below, I could 
define it.

>
>>
>> I understand that Range coder state variables (see 4.6.1.3) are per
>> slice_x and slice_y in the slice raster.
>> Is it correct if I say that if for frame 0 a slice with slice_x=0,
>> slice_y=0, slice_width=2, slice_height=1 (so no frame 0 slice with
>> slice_x=1, slice_y=0), for frame 1 a slice with slice_x=1, slice_y=0
>> will have Range coder state variables set to their initial state?
> I think the behavior when the slice segmentation changes in a non
> key slice is undefined (litterally so as the spec does not say what to
> do for that)

this is the reason I raise the issue and propose something ;-).

> i would tend toward leaving that undefined

undefined in the spec does not seem good.

>   / disallowed
> instead of trying to specify some behavior without a bit of study of
> its effects and alternatives
> disallowing it is easy for implementations

if it is disallowed, slice_x, slice_y, slice_width, slice_height are 
useless (they can be copied from the previous frame) and only extra bits 
not optimal for compression ratio.
Anyway, it is the definition of an existing bitstream so let say that we 
add restrictions.
Before I propose another patch, please confirm that it is OK to forbid a 
non-key slice with slice_x, slice_y, slice_width, slice_height not 
identical to a slice present in the previous frame.

>
>
>> I propose the following patch for being more explicit about slices.
>> - add "maximal" to num_h/v_slices because we could have less
>> elements (e.g. if num_h_slices is 4, we could have a scenario with
>> only 3 slices horizontal, e.g. slices with slice_x=0 have always
>> slice_width=2)
>> - remove slice_count definition and replace it by a test about the
>> presence of remaining bytes at the end of the frame
>> - replace "[i]" by "[slice_x][slice_y]"
>>
>> Jrme
>>
>>   ffv1.md |   20 +++++++++-----------
>>   1 file changed, 9 insertions(+), 11 deletions(-)
>> 74f93a5ba93c4fd91e1857e7a3a5a224e6db8a1e  0001-Replace-slice_count-because-it-is-not-precisely-defi.patch
>>  From 3cbb0b1803b8a835339222d124e55c71a5aa1725 Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
>> Date: Fri, 13 May 2016 09:26:43 +0200
>> Subject: [PATCH] Replace slice_count because it is not precisely defined
>>
>> - add "maximal" to num_h/v_slices because we could have less
>> elements (e.g. if num_h_slices is 4, we could have a scenario
>> with only 3 slices horizontal, e.g. slices with slice_x=0 have
>> always slice_width=2)
>> - remove slice_count definition and replace it by a test about
>> the presence of remaining bytes at the end of the frame
>> - replace "[i]" by "[slice_x][slice_y]"
>> ---
>>   ffv1.md | 20 +++++++++-----------
>>   1 file changed, 9 insertions(+), 11 deletions(-)
>>
>> diff --git a/ffv1.md b/ffv1.md
>> index e48a7ee..3fd0507 100644
>> --- a/ffv1.md
>> +++ b/ffv1.md
>> @@ -516,17 +516,17 @@ See [NUT](#references) for more information about elements.
>>   |    keyframe                                       |  br|
>>   |    if( keyframe && !ConfigurationRecordIsPresent )|    |
>>   |         Parameters( )                             |    |
>> -|    for( i = 0; i \< slice\_count; i++ )           |    |
>> -|        Slice( i )                                 |    |
>> +|    while ( remaining_bits_in_bitstream() )        |    |
>> +|        Slice( )                                   |    |
>>   |}                                                  |    |
> iam a bit sceptic on this
> first it does not work for multitreading, maybe its not wrong but
> one cannot implement multitreading if one has to decode the previous
> slice before knowing the start of the next

It does: the way it is described in the bitstream does not forbid 
another method for decoding it, and we provide something for doing the 
multithread (the slice byte size at the end).

>
> also theres the question about extensibility when defined by
> more bits instead of teh slice sizes
> i _think_ we currently could add things before slice_size without
> breaking the bitstream but maybe iam missing something

this way to define it definitely forbids things after the end of the 
current slice bitstream.
but it is actually the way it is defined in the current spec (and/or it 
is not clear, so we need to define it).
The way you are thinking about (reading slice byte size at the end of 
the frame and "reading back" all slice byte size) adds a constraint: we 
must receive the last byte of the frame before starting to decode the 
2nd slice.
As is, the first slice can be decoded until the last pixel, and we wait 
for the last byte of the frame in order to get the real slice byte size.
If we have 256 slices in a frame streamed by Internet, we must receive 
the last byte of the frame before starting to decode 255 slices. In some 
scenarios, it could be considered as a problem because it adds some 
delay in the delivery of the decoded frame. This also means that the 
decoder must keep the complete frame in memory (it can not decode then 
drop bytes), the decoder can not decode without seeking in the 
bytstream, I am not not sure it is pertinent but it is a potential issue.

So I can propose a patch with 2 passes:
- first pass for getting slice_count and all slices byte size
- second pass for decoding each slice.

Before I propose another patch, please confirm that it is OK with the 
constraints added due to this way to implement the spec.



>
>
>>   
>>   ## Slice
>>   
>>   |                                                                    |
>>   |------------------------------------------------------------|:------|
>> -|Slice( i ) {                                                | type  |
>> +|Slice( )   {                                                | type  |
>>   |    if( version \> 2 )                                      |       |
>> -|        SliceHeader( i )                                    |       |
>> +|        SliceHeader( )                                      |       |
>>   |    if( colorspace\_type == 0) {                            |       |
>>   |        for( p = 0; p \< primary\_color\_count; p++ ) {     |       |
>>   |            Plane( p )                                      |       |
>> @@ -535,7 +535,7 @@ See [NUT](#references) for more information about elements.
>>   |            for( p = 0; p \< primary\_color\_count; p++ ) { |       |
>>   |                Line( p, y )                                |       |
>>   |    }                                                       |       |
>> -|    if( i \|\| version \> 2 )                               |       |
>> +|    if( slice_x \|\| slice_y \|\| version \> 2 )            |       |
>>   |        slice\_size                                         | u(24) |
>>   |    if( ec ) {                                              |       |
>>   |        error\_status                                       |  u(8) |
>> @@ -565,13 +565,13 @@ The CRC generator polynom used is the standard IEEE CRC polynom (0x104C11DB7) wi
>>   
>>   |                                                            |    |
>>   |------------------------------------------------------------|---:|
>> -| SliceHeader( i ) {                                         |type|
>> +| SliceHeader( ) {                                           |type|
>>   |    slice\_x                                                | ur |
>>   |    slice\_y                                                | ur |
>>   |    slice\_width - 1                                        | ur |
>>   |    slice\_height - 1                                       | ur |
>>   |    for( j = 0; j \< quant\_table\_index\_count; j++ )      |    |
>> -|        quant\_table\_index [ i ][ j ]                      | ur |
>> +|        quant\_table\_index [ slice\_x ][ slice\_y ][ j ]   | ur |
>>   |    picture\_structure                                      | ur |
>>   |    sar\_num                                                | ur |
>>   |    sar\_den                                                | ur |
>> @@ -755,10 +755,10 @@ Decoders SHOULD accept and interpret bits_per_raw_sample = 0 as 8.
>>   | 0     | transparency plane is not present|
>>   | 1     | transparency plane is present    |
>>   
>> -**num\_h\_slices** indicates the number of horizontal elements of the slice raster.
>> +**num\_h\_slices** indicates the maximal number of horizontal elements of the slice raster.
>>   Inferred to be 1 if not present.
> i would define the raster resolution (whatever one wants to call it)
> and then have slices span multiple raster elements if thats what they
> do
> as in the resolution is X by Y elements and each element of that is
> either part of the blue rectangle or not ...

I see.
I just don't really have ideas about how to call it. from my point of 
view, "slice raster" was a bit misleading (not taking the possibility 
that a slice can have a slice_width not 1).
I'll try to find a way to better define it.

Jrme


From nobody Fri May 13 12:21:18 2016
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 52F9C12D538 for ; Fri, 13 May 2016 12:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 7E0JimmckScI for ; Fri, 13 May 2016 12:21:15 -0700 (PDT)
Received: from 19.mo7.mail-out.ovh.net (19.mo7.mail-out.ovh.net [178.33.251.118]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064CD12B04A for ; Fri, 13 May 2016 12:21:14 -0700 (PDT)
Received: from player759.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id EA11EFFCBD3 for ; Fri, 13 May 2016 21:21:12 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player759.ha.ovh.net (Postfix) with ESMTPSA id D529F64008A for ; Fri, 13 May 2016 21:21:11 +0200 (CEST)
To: cellar@ietf.org
References: <4bd781e0-a6a3-2249-2a3e-a4f50e93c351@mediaarea.net> <20160513181432.GJ25812@nb4>
From: Jerome Martinez 
Message-ID: <33252ed7-3f8e-b91b-d4cc-e5efd715d59a@mediaarea.net>
Date: Fri, 13 May 2016 21:21:00 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <20160513181432.GJ25812@nb4>
Content-Type: multipart/mixed; boundary="------------3B7C1F0D4E6F55AC12DED65A"
X-Ovh-Tracer-Id: 2965338879766237329
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrvddugddufeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc
Archived-At: 
Subject: Re: [Cellar] [PATCH] Rewrite of the restrictions paragraph
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 13 May 2016 19:21:17 -0000

This is a multi-part message in MIME format.
--------------3B7C1F0D4E6F55AC12DED65A
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Le 13/05/2016  20:14, Michael Niedermayer a crit :
> On Fri, May 13, 2016 at 11:40:06AM +0200, Jerome Martinez wrote:
>>   ffv1.md |    9 ++++++++-
>>   1 file changed, 8 insertions(+), 1 deletion(-)
>> ade5ca179746784b68b5123b83d4a25f9b29d2f0  0001-Rewrite-of-the-restrictions-paragraph.patch
>>  From 2c197e480486d80640665e58ff2fb49a8bf3dcfb Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
>> Date: Fri, 13 May 2016 11:37:45 +0200
>> Subject: [PATCH] Rewrite of the restrictions paragraph
>>
>> - Definition of frame width and height,
>> - Removal of pixel size in the formula (we can have a formula based
>> on the bitstream fields)
>> ---
>>   ffv1.md | 9 ++++++++-
>>   1 file changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/ffv1.md b/ffv1.md
>> index e48a7ee..0480c63 100644
>> --- a/ffv1.md
>> +++ b/ffv1.md
>> @@ -458,6 +458,12 @@ Note, this is different from JPEG-LS, which doesnt use prediction in run mode
>>   
>>   The same context which is initialized to 128 is used for all fields in the header.
>>   
>> +The stream transport layer MUST provide the following data during initialization of the decoder:
>> +
>> +**frame\_width** is defined as frame width in pixels.
>> +
>> +**frame\_height** is defined as frame height in pixels.
> not sure about the exact wording "stream transport layer" vs
> something like "the follwing must be provided by external means"
> but its ok either way with me
> ITU H.263 talks about "external means" in similar cases (the ones i
> looked at at least)

Changed.

>
>> +
>>   Default values at the decoder initialization phase:
>>   
>>   **ConfigurationRecordIsPresent** is set to 0.
>> @@ -843,7 +849,8 @@ MAX\_CONTEXT\_INPUTS is 5.
>>   
>>   ### Restrictions
>>   
>> -In version 2 and later the maximum slice size in pixels is $\frac{width\centerdot height}{4}$, unless the frame is smaller or equal 352x288 this is to ensure that fast multithreaded decoding is possible.
>> +To ensure that fast multithreaded decoding is possible, starting version 2 and if frame\_width * frame\_height is more than 101376, slice\_width * slice\_height SHOULD be less or equal to num\_h\_slices * num\_v\_slices / 4.
>> +Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF ("Common Intermediate Format") frame size format.
> is it possible to use stronger wording than just SHOULD ?
> explicitly stating that not doing so would quarduple the time needed
> to decode the frames and that thus potentially significantly fewer
> decoders would be able to decode the stream in realtime
> but i still feel that some harder restriction should be left in the
> spec

I think that the definition of SHOULD fits your point, but as we can not 
agree on this word right now I propose to postpone the SHOULD/MUST 
debate and go with the rest.
Modified with MUST.

Jrme

--------------3B7C1F0D4E6F55AC12DED65A
Content-Type: text/plain; charset=UTF-8;
 name="0001-Rewrite-of-the-restrictions-paragraph.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename="0001-Rewrite-of-the-restrictions-paragraph.patch"

>From d92c4687a23f293f4958614fc00fd608cfa15e37 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Fri, 13 May 2016 21:09:38 +0200
Subject: [PATCH] Rewrite of the restrictions paragraph

- Definition of frame width and height,
- Removal of pixel size in the formula (we can have a formula based
on the bitstream fields)
---
 ffv1.md | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/ffv1.md b/ffv1.md
index e48a7ee..4de8ac9 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -458,6 +458,12 @@ Note, this is different from JPEG-LS, which doesn’t use prediction in run mode
 
 The same context which is initialized to 128 is used for all fields in the header.
 
+The following MUST be provided by external means during initialization of the decoder:
+
+**frame\_width** is defined as frame width in pixels.
+
+**frame\_height** is defined as frame height in pixels.
+
 Default values at the decoder initialization phase:
 
 **ConfigurationRecordIsPresent** is set to 0.
@@ -843,7 +849,8 @@ MAX\_CONTEXT\_INPUTS is 5.
 
 ### Restrictions
 
-In version 2 and later the maximum slice size in pixels is $\frac{width\centerdot height}{4}$, unless the frame is smaller or equal 352x288 this is to ensure that fast multithreaded decoding is possible.
+To ensure that fast multithreaded decoding is possible, starting version 2 and if frame\_width * frame\_height is more than 101376, slice\_width * slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4.
+Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF ("Common Intermediate Format") frame size format.
 
 # Changelog
 
-- 
2.7.0.windows.1


--------------3B7C1F0D4E6F55AC12DED65A--


From nobody Fri May 13 14:54:25 2016
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 25A4A12D6A3 for ; Fri, 13 May 2016 14:54:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 L821WXnoWyQ6 for ; Fri, 13 May 2016 14:54:21 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEBF812D6A1 for ; Fri, 13 May 2016 14:54:21 -0700 (PDT)
Received: from mfilter31-d.gandi.net (mfilter31-d.gandi.net [217.70.178.162]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 44C3DA80CB for ; Fri, 13 May 2016 23:54:20 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter31-d.gandi.net
Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter31-d.gandi.net (mfilter31-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id j5MmtXawUZNO for ; Fri, 13 May 2016 23:54:18 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 67088A80BE for ; Fri, 13 May 2016 23:54:17 +0200 (CEST)
Date: Fri, 13 May 2016 23:52:13 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160513215213.GL25812@nb4>
References:  <20160513180437.GI25812@nb4> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qzKMdJ73R52Pbqt0"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Replace slice_count because it is not precisely defined
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 13 May 2016 21:54:24 -0000

--qzKMdJ73R52Pbqt0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 13, 2016 at 09:00:11PM +0200, Jerome Martinez wrote:
> Le 13/05/2016 =E0 20:04, Michael Niedermayer a =E9crit :
> >On Fri, May 13, 2016 at 10:44:29AM +0200, Jerome Martinez wrote:
> >>In the spec, I see:
> >>"*slice_count* indicates the number of slices in the current frame,
> >>slice_count is 1 if it is not explicitly coded."
> >>and:
> >>"for(i=3D0; i >>
> >>but slice_count is not explicitly defined (based on bitstream elements).
> >>As a slice can have a width or height more than 1, slice_count is
> >>not num_h_slices * num_v_slices, it depends of slice_width and
> >>slice_height of each slice.
> >i think it was meant to be the number of slices if one follows the
> >chain of slice_size  (or in a badly damaged frame the number of byte
> >ranges that would have valid looking headers and coded sizes)
>=20
> but it is not in the bitstream, I see no way to define it in another
> way (currently, it is not defined at all so we can not keep it as
> is), this is the reason I propose to replace it.
> but depending of your answer on the other questions below, I could
> define it.
>=20
> >
> >>
> >>I understand that Range coder state variables (see 4.6.1.3) are per
> >>slice_x and slice_y in the slice raster.
> >>Is it correct if I say that if for frame 0 a slice with slice_x=3D0,
> >>slice_y=3D0, slice_width=3D2, slice_height=3D1 (so no frame 0 slice with
> >>slice_x=3D1, slice_y=3D0), for frame 1 a slice with slice_x=3D1, slice_=
y=3D0
> >>will have Range coder state variables set to their initial state?
> >I think the behavior when the slice segmentation changes in a non
> >key slice is undefined (litterally so as the spec does not say what to
> >do for that)
>=20
> this is the reason I raise the issue and propose something ;-).
>=20
> >i would tend toward leaving that undefined
>=20
> undefined in the spec does not seem good.
>=20
> >  / disallowed
> >instead of trying to specify some behavior without a bit of study of
> >its effects and alternatives
> >disallowing it is easy for implementations
>=20
> if it is disallowed, slice_x, slice_y, slice_width, slice_height are
> useless (they can be copied from the previous frame) and only extra
> bits not optimal for compression ratio.

remove them, transmit it with some packet loss and try to decode
and you will see why they are usefull

slices should be independant of each other, so at the very least
one needs to know where the slice is located in the slice or pixel
raster. The width & height would generally be 1 so they take almost
no space


> Anyway, it is the definition of an existing bitstream so let say
> that we add restrictions.
> Before I propose another patch, please confirm that it is OK to
> forbid a non-key slice with slice_x, slice_y, slice_width,
> slice_height not identical to a slice present in the previous frame.

I think as the spec does not say what to do about this and i think
the implementation wouldnt behave sane either adding this restriction
to the current bitstream version does just state more clearly how it
already is


[...]
>=20
> >
> >also theres the question about extensibility when defined by
> >more bits instead of teh slice sizes
> >i _think_ we currently could add things before slice_size without
> >breaking the bitstream but maybe iam missing something
>=20
> this way to define it definitely forbids things after the end of the
> current slice bitstream.
> but it is actually the way it is defined in the current spec (and/or
> it is not clear, so we need to define it).
> The way you are thinking about (reading slice byte size at the end
> of the frame and "reading back" all slice byte size) adds a
> constraint: we must receive the last byte of the frame before
> starting to decode the 2nd slice.
> As is, the first slice can be decoded until the last pixel, and we
> wait for the last byte of the frame in order to get the real slice
> byte size.
> If we have 256 slices in a frame streamed by Internet, we must
> receive the last byte of the frame before starting to decode 255
> slices. In some scenarios, it could be considered as a problem
> because it adds some delay in the delivery of the decoded frame.
> This also means that the decoder must keep the complete frame in
> memory (it can not decode then drop bytes), the decoder can not
> decode without seeking in the bytstream, I am not not sure it is
> pertinent but it is a potential issue.

This is something we should look into for the next version of the
bitstream
for now we could cheat a bit by either aligning slices with
network packets in some way so their start is known by external means
or also to allow and define decoding to be valid both by the
slice_sizes and by the  remaining_bits_in_bitstream loop if that
works, but that would only help single threaded decoding


>=20
> So I can propose a patch with 2 passes:
> - first pass for getting slice_count and all slices byte size
> - second pass for decoding each slice.
>=20
> Before I propose another patch, please confirm that it is OK with
> the constraints added due to this way to implement the spec.

iam fine with defining the decoding both ways (if that actually works)
or the way you describe above

[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes

--qzKMdJ73R52Pbqt0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc2TI0ACgkQYR7HhwQLD6sLrQCeNFYTpcRm3SwlBrwPEc+XhucL
C3MAn2Rajv3FAEpe/MkT07dyLNC6oWEp
=ZpXN
-----END PGP SIGNATURE-----

--qzKMdJ73R52Pbqt0--


From nobody Fri May 13 15:08:10 2016
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 EE3A412D181 for ; Fri, 13 May 2016 15:08:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 wtwGPj3OUbY6 for ; Fri, 13 May 2016 15:08:02 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6DCB12D69B for ; Fri, 13 May 2016 15:08:01 -0700 (PDT)
Received: from mfilter38-d.gandi.net (mfilter38-d.gandi.net [217.70.178.169]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id B1C2DA80D1 for ; Sat, 14 May 2016 00:08:00 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter38-d.gandi.net
Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter38-d.gandi.net (mfilter38-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id TtYXBZf4m_im for ; Sat, 14 May 2016 00:07:59 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id EFC6FA80BE for ; Sat, 14 May 2016 00:07:58 +0200 (CEST)
Date: Sat, 14 May 2016 00:05:54 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160513220554.GM25812@nb4>
References: <4bd781e0-a6a3-2249-2a3e-a4f50e93c351@mediaarea.net> <20160513181432.GJ25812@nb4> <33252ed7-3f8e-b91b-d4cc-e5efd715d59a@mediaarea.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="+oMowpWkHrfFA4gj"
Content-Disposition: inline
In-Reply-To: <33252ed7-3f8e-b91b-d4cc-e5efd715d59a@mediaarea.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH] Rewrite of the restrictions paragraph
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 13 May 2016 22:08:04 -0000

--+oMowpWkHrfFA4gj
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 13, 2016 at 09:21:00PM +0200, Jerome Martinez wrote:
> Le 13/05/2016 =C3=A0 20:14, Michael Niedermayer a =C3=A9crit :
> >On Fri, May 13, 2016 at 11:40:06AM +0200, Jerome Martinez wrote:
> >>  ffv1.md |    9 ++++++++-
> >>  1 file changed, 8 insertions(+), 1 deletion(-)
> >>ade5ca179746784b68b5123b83d4a25f9b29d2f0  0001-Rewrite-of-the-restricti=
ons-paragraph.patch
> >> From 2c197e480486d80640665e58ff2fb49a8bf3dcfb Mon Sep 17 00:00:00 2001
> >>From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D 
> >>Date: Fri, 13 May 2016 11:37:45 +0200
> >>Subject: [PATCH] Rewrite of the restrictions paragraph
> >>
> >>- Definition of frame width and height,
> >>- Removal of pixel size in the formula (we can have a formula based
> >>on the bitstream fields)
> >>---
> >>  ffv1.md | 9 ++++++++-
> >>  1 file changed, 8 insertions(+), 1 deletion(-)
> >>
> >>diff --git a/ffv1.md b/ffv1.md
> >>index e48a7ee..0480c63 100644
> >>--- a/ffv1.md
> >>+++ b/ffv1.md
> >>@@ -458,6 +458,12 @@ Note, this is different from JPEG-LS, which doesn=
=E2=80=99t use prediction in run mode
> >>  The same context which is initialized to 128 is used for all fields i=
n the header.
> >>+The stream transport layer MUST provide the following data during init=
ialization of the decoder:
> >>+
> >>+**frame\_width** is defined as frame width in pixels.
> >>+
> >>+**frame\_height** is defined as frame height in pixels.
> >not sure about the exact wording "stream transport layer" vs
> >something like "the follwing must be provided by external means"
> >but its ok either way with me
> >ITU H.263 talks about "external means" in similar cases (the ones i
> >looked at at least)
>=20
> Changed.
>=20
> >
> >>+
> >>  Default values at the decoder initialization phase:
> >>  **ConfigurationRecordIsPresent** is set to 0.
> >>@@ -843,7 +849,8 @@ MAX\_CONTEXT\_INPUTS is 5.
> >>  ### Restrictions
> >>-In version 2 and later the maximum slice size in pixels is $\frac{widt=
h\centerdot height}{4}$, unless the frame is smaller or equal 352x288 this =
is to ensure that fast multithreaded decoding is possible.
> >>+To ensure that fast multithreaded decoding is possible, starting versi=
on 2 and if frame\_width * frame\_height is more than 101376, slice\_width =
* slice\_height SHOULD be less or equal to num\_h\_slices * num\_v\_slices =
/ 4.
> >>+Note: 101376 is the frame size in pixels of a 352x288 frame also known=
 as CIF ("Common Intermediate Format") frame size format.
> >is it possible to use stronger wording than just SHOULD ?
> >explicitly stating that not doing so would quarduple the time needed
> >to decode the frames and that thus potentially significantly fewer
> >decoders would be able to decode the stream in realtime
> >but i still feel that some harder restriction should be left in the
> >spec
>=20
> I think that the definition of SHOULD fits your point, but as we can
> not agree on this word right now I propose to postpone the
> SHOULD/MUST debate and go with the rest.
> Modified with MUST.
>=20
> J=C3=A9r=C3=B4me

>  ffv1.md |    9 ++++++++-
>  1 file changed, 8 insertions(+), 1 deletion(-)
> b5af0f23762c6259596632f895f8798d17da3caa  0001-Rewrite-of-the-restriction=
s-paragraph.patch
> >From d92c4687a23f293f4958614fc00fd608cfa15e37 Mon Sep 17 00:00:00 2001
> From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D 
> Date: Fri, 13 May 2016 21:09:38 +0200
> Subject: [PATCH] Rewrite of the restrictions paragraph
>=20
> - Definition of frame width and height,
> - Removal of pixel size in the formula (we can have a formula based
> on the bitstream fields)

applied

thx

[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.

--+oMowpWkHrfFA4gj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc2T8IACgkQYR7HhwQLD6vdSACfV48ZWEf77MkGPAWuAV+YTgdb
o1MAmQE535LSkFnwHqy8qjpNZVE57CtQ
=oc9H
-----END PGP SIGNATURE-----

--+oMowpWkHrfFA4gj--


From nobody Tue May 17 02:08:34 2016
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 71BF112B055 for ; Tue, 17 May 2016 02:08:32 -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, 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 pnJM2Bq5fOU2 for ; Tue, 17 May 2016 02:08:30 -0700 (PDT)
Received: from 7.mo177.mail-out.ovh.net (7.mo177.mail-out.ovh.net [46.105.61.149]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B232512B00C for ; Tue, 17 May 2016 02:08:29 -0700 (PDT)
Received: from player716.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id 1F329FF9A7F for ; Tue, 17 May 2016 11:08:23 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player716.ha.ovh.net (Postfix) with ESMTPSA id AD2BE56006B for ; Tue, 17 May 2016 11:08:22 +0200 (CEST)
To: cellar@ietf.org
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4>
From: Jerome Martinez 
Message-ID: <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net>
Date: Tue, 17 May 2016 11:08:20 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160513215213.GL25812@nb4>
Content-Type: multipart/mixed; boundary="------------59B189D5AC33061954235722"
X-Ovh-Tracer-Id: 16106561118454091921
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrvdekgdduudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Replace slice_count because it is not precisely defined
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 09:08:32 -0000

This is a multi-part message in MIME format.
--------------59B189D5AC33061954235722
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Le 13/05/2016  23:52, Michael Niedermayer a crit :
> On Fri, May 13, 2016 at 09:00:11PM +0200, Jerome Martinez wrote:
>> [...]
>>
>> this way to define it definitely forbids things after the end of the
>> current slice bitstream.
>> but it is actually the way it is defined in the current spec (and/or
>> it is not clear, so we need to define it).
>> The way you are thinking about (reading slice byte size at the end
>> of the frame and "reading back" all slice byte size) adds a
>> constraint: we must receive the last byte of the frame before
>> starting to decode the 2nd slice.
>> As is, the first slice can be decoded until the last pixel, and we
>> wait for the last byte of the frame in order to get the real slice
>> byte size.
>> If we have 256 slices in a frame streamed by Internet, we must
>> receive the last byte of the frame before starting to decode 255
>> slices. In some scenarios, it could be considered as a problem
>> because it adds some delay in the delivery of the decoded frame.
>> This also means that the decoder must keep the complete frame in
>> memory (it can not decode then drop bytes), the decoder can not
>> decode without seeking in the bytstream, I am not not sure it is
>> pertinent but it is a potential issue.
> This is something we should look into for the next version of the
> bitstream
> for now we could cheat a bit by either aligning slices with
> network packets in some way so their start is known by external means
> or also to allow and define decoding to be valid both by the
> slice_sizes and by the  remaining_bits_in_bitstream loop if that
> works, but that would only help single threaded decoding
>
>
>> So I can propose a patch with 2 passes:
>> - first pass for getting slice_count and all slices byte size
>> - second pass for decoding each slice.
>>
>> Before I propose another patch, please confirm that it is OK with
>> the constraints added due to this way to implement the spec.
> iam fine with defining the decoding both ways (if that actually works)
> or the way you describe above

I think that having the possibility to decode from the end (from 
slice_size values) and from the beginning (parsing the bitstream 
sequentially) may be useful for error recovery and choice of the decoder 
to decide how to decode.
Additionally, the current spec (and the old one) never say that it is 
possible to have additional bits/bytes between Line( p, y ) and 
slice_size so it would be weird to say now, for the current version, 
that it is possible.
In next version of FFV1, we could add after "Line( p, y )" e.g. an 
"extension_present" flag (so only one bit) + "extension_size" value (in 
bytes) for letting the possibility to extend the bitstream at this point 
without removing any decoding possibility (from begin or from end).
so I prefer to define the bitstream in the bitstream sequential order 
(and letting the possibility to decode in sequential order).

updated .patch :

In Parameter():
I keep "raster", no better idea.
I remove "elements", I think it may be misleading (may be understood as 
"slices" or making understanding difficult), I prefer to use "size of 
the slice raster". Better idea from someone else?

In Slice():
I added byte alignment function (as currently specified, slice_size is 
not byte-aligned but FFmpeg decoder mandates byte alignment)

In Restrictions:
Added the need of having 1 and only 1 slice for each position in the 
slice raster (no missing part in the slice raster, no overlapping)
no change of slices positions when it is not a keyframe.




--------------59B189D5AC33061954235722
Content-Type: text/plain; charset=UTF-8;
 name="0001-Replace-slice_count-because-it-is-not-precisely-defi.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename*0="0001-Replace-slice_count-because-it-is-not-precisely-defi.pa";
 filename*1="tch"

>From d8b479a93ac1bc6d0e29c0d33cd79640c33d7431 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Tue, 17 May 2016 11:00:48 +0200
Subject: [PATCH] Replace slice_count because it is not precisely defined

- remove slice_count definition and replace it by a test about
the presence of remaining bytes at the end of the frame
- replace "[i]" by "[slice_x][slice_y]"
- add byte alignment test
- add restrictions about slice_x, slice_y, slice_width,
slice_height
---
 ffv1.md | 32 +++++++++++++++++++-------------
 1 file changed, 19 insertions(+), 13 deletions(-)

diff --git a/ffv1.md b/ffv1.md
index 80e3cf9..0fd1249 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -153,6 +153,8 @@ __a...b__ means any value starting from a to b, inclusive.
 
 **remaining\_bits\_in\_bitstream( )** means the count of remaining bits after the current position in the bitstream. It is computed from the NumBytes value multiplied by 8 minus the count of bits already read by the bitstream parser.
 
+**byte\_aligned( )** means the last parsed bit in the bitstream is the last bit in a byte.
+
 \pagebreak
 
 # General Description
@@ -522,17 +524,17 @@ See [NUT](#references) for more information about elements.
 |    keyframe                                       |  br|
 |    if( keyframe && !ConfigurationRecordIsPresent )|    |
 |         Parameters( )                             |    |
-|    for( i = 0; i \< slice\_count; i++ )           |    |
-|        Slice( i )                                 |    |
+|    while ( remaining_bits_in_bitstream() )        |    |
+|        Slice( )                                   |    |
 |}                                                  |    |
 
 ## Slice
 
 |                                                                    |
 |------------------------------------------------------------|:------|
-|Slice( i ) {                                                | type  |
+|Slice( )   {                                                | type  |
 |    if( version \> 2 )                                      |       |
-|        SliceHeader( i )                                    |       |
+|        SliceHeader( )                                      |       |
 |    if( colorspace\_type == 0) {                            |       |
 |        for( p = 0; p \< primary\_color\_count; p++ ) {     |       |
 |            Plane( p )                                      |       |
@@ -541,7 +543,9 @@ See [NUT](#references) for more information about elements.
 |            for( p = 0; p \< primary\_color\_count; p++ ) { |       |
 |                Line( p, y )                                |       |
 |    }                                                       |       |
-|    if( i \|\| version \> 2 )                               |       |
+|    while ( !byte_aligned() )                               |       |
+|        padding                                             |  u(1) |
+|    if( slice_x \|\| slice_y \|\| version \> 2 )            |       |
 |        slice\_size                                         | u(24) |
 |    if( ec ) {                                              |       |
 |        error\_status                                       |  u(8) |
@@ -571,13 +575,13 @@ The CRC generator polynom used is the standard IEEE CRC polynom (0x104C11DB7) wi
 
 |                                                            |    |
 |------------------------------------------------------------|---:|
-| SliceHeader( i ) {                                         |type|
+| SliceHeader( ) {                                           |type|
 |    slice\_x                                                | ur |
 |    slice\_y                                                | ur |
 |    slice\_width - 1                                        | ur |
 |    slice\_height - 1                                       | ur |
 |    for( j = 0; j \< quant\_table\_index\_count; j++ )      |    |
-|        quant\_table\_index [ i ][ j ]                      | ur |
+|        quant\_table\_index [ slice\_x ][ slice\_y ][ j ]   | ur |
 |    picture\_structure                                      | ur |
 |    sar\_num                                                | ur |
 |    sar\_den                                                | ur |
@@ -593,10 +597,10 @@ Inferred to be 0 if not present.
 **slice_y** indicates the y position on the slice raster formed by num_v_slices.
 Inferred to be 0 if not present.
 
-**slice_width** indicates the width on the slice raster.
+**slice_width** indicates the width on the slice raster formed by num_h_slices.
 Inferred to be 1 if not present.
 
-**slice_height** indicates the height on the slice raster.
+**slice_height** indicates the height on the slice raster formed by num_v_slices.
 Inferred to be 1 if not present.
 
 **quant\_table\_index\_count** is defined as 1 + ( ( chroma_planes || version \< 4 ) ? 1 : 0 ) + ( alpha_plane ? 1 : 0 ).
@@ -761,10 +765,10 @@ Decoders SHOULD accept and interpret bits_per_raw_sample = 0 as 8.
 | 0     | transparency plane is not present|
 | 1     | transparency plane is present    |
 
-**num\_h\_slices** indicates the number of horizontal elements of the slice raster.
+**num\_h\_slices** indicates the horizontal size of the slice raster.
 Inferred to be 1 if not present.
 
-**num\_v\_slices** indicates the number of vertical elements of the slice raster.
+**num\_v\_slices** indicates the vertical size of the slice raster.
 Inferred to be 1 if not present.
 
 **quant\_table\_count** indicates the number of quantization table sets.
@@ -782,8 +786,6 @@ Inferred to be 0 if not present.
 pred = j ? initial\_states[ i ][j - 1][ k ] : 128
 initial\_state[ i ][ j ][ k ] = ( pred + initial\_state\_delta[ i ][ j ][ k ] ) & 255
 
-**slice\_count** indicates the number of slices in the current frame, slice\_count is 1 if it is not explicitly coded.
-
 **ec** indicates the error detection/correction type.
 
 |value | error detection/correction type          |
@@ -852,6 +854,10 @@ MAX\_CONTEXT\_INPUTS is 5.
 To ensure that fast multithreaded decoding is possible, starting version 2 and if frame\_width * frame\_height is more than 101376, slice\_width * slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4.
 Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF ("Common Intermediate Format") frame size format.
 
+For each frame, each position in the slice raster MUST be filled by one and only one slice of the frame (no missing slice position, no slice overlapping).
+
+For each Frame with keyframe value of 0, each slice MUST have the same value of slice\_x, slice\_y, slice\_width, slice\_height as a slice in the previous frame.
+
 # Changelog
 
 See 
-- 
2.7.0.windows.1


--------------59B189D5AC33061954235722--


From nobody Tue May 17 05:54:46 2016
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 1463E12D5A5 for ; Tue, 17 May 2016 05:54:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 7vZw6-BjnIMA for ; Tue, 17 May 2016 05:54:43 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53E5012D55C for ; Tue, 17 May 2016 05:54:42 -0700 (PDT)
Received: from mfilter18-d.gandi.net (mfilter18-d.gandi.net [217.70.178.146]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 3B00F172139 for ; Tue, 17 May 2016 14:54:41 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter18-d.gandi.net
Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter18-d.gandi.net (mfilter18-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id SL-Cy6HP5QSk for ; Tue, 17 May 2016 14:54:39 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 33B7F172125 for ; Tue, 17 May 2016 14:54:38 +0200 (CEST)
Date: Tue, 17 May 2016 14:52:30 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160517125230.GU25812@nb4>
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z1IV5Hkp0Z/sUao3"
Content-Disposition: inline
In-Reply-To: <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Replace slice_count because it is not precisely defined
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 12:54:45 -0000

--z1IV5Hkp0Z/sUao3
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi

On Tue, May 17, 2016 at 11:08:20AM +0200, Jerome Martinez wrote:
> Le 13/05/2016 =E0 23:52, Michael Niedermayer a =E9crit :
> >On Fri, May 13, 2016 at 09:00:11PM +0200, Jerome Martinez wrote:
> >>[...]
> >>
> >>this way to define it definitely forbids things after the end of the
> >>current slice bitstream.
> >>but it is actually the way it is defined in the current spec (and/or
> >>it is not clear, so we need to define it).
> >>The way you are thinking about (reading slice byte size at the end
> >>of the frame and "reading back" all slice byte size) adds a
> >>constraint: we must receive the last byte of the frame before
> >>starting to decode the 2nd slice.
> >>As is, the first slice can be decoded until the last pixel, and we
> >>wait for the last byte of the frame in order to get the real slice
> >>byte size.
> >>If we have 256 slices in a frame streamed by Internet, we must
> >>receive the last byte of the frame before starting to decode 255
> >>slices. In some scenarios, it could be considered as a problem
> >>because it adds some delay in the delivery of the decoded frame.
> >>This also means that the decoder must keep the complete frame in
> >>memory (it can not decode then drop bytes), the decoder can not
> >>decode without seeking in the bytstream, I am not not sure it is
> >>pertinent but it is a potential issue.
> >This is something we should look into for the next version of the
> >bitstream
> >for now we could cheat a bit by either aligning slices with
> >network packets in some way so their start is known by external means
> >or also to allow and define decoding to be valid both by the
> >slice_sizes and by the  remaining_bits_in_bitstream loop if that
> >works, but that would only help single threaded decoding
> >
> >
> >>So I can propose a patch with 2 passes:
> >>- first pass for getting slice_count and all slices byte size
> >>- second pass for decoding each slice.
> >>
> >>Before I propose another patch, please confirm that it is OK with
> >>the constraints added due to this way to implement the spec.
> >iam fine with defining the decoding both ways (if that actually works)
> >or the way you describe above
>=20
> I think that having the possibility to decode from the end (from
> slice_size values) and from the beginning (parsing the bitstream
> sequentially) may be useful for error recovery and choice of the
> decoder to decide how to decode.

i think for error recovery slices should be decodable with both
slices before and after them being destroyed beyond recognization


> Additionally, the current spec (and the old one) never say that it
> is possible to have additional bits/bytes between Line( p, y ) and
> slice_size so it would be weird to say now, for the current version,
> that it is possible.

The issue is the range coder, or more precissely switching from the
range coder back to storing bits and bytes

i am not sure its specified restricted enough to know where the end is
exactly (thats why i said "if that works" earlier ...

IIRC it basically just says any bytestream that decodes correctly
is fine, leaving it to the encoder to add an unneeded byte or 2 at
the end. (Which simplifies the encoder)
If such extra bytes would be allowed then future specs could also use
the area to hold some usefull information

ill look at he patch in a moment

[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. U=
ser
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.

--z1IV5Hkp0Z/sUao3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc7FA4ACgkQYR7HhwQLD6vjSACglYRoYjdXA9RP0Gxl50zti2PV
7M0AoId25zCDY6wJqBepgGr59oC4VhTb
=Wxhu
-----END PGP SIGNATURE-----

--z1IV5Hkp0Z/sUao3--


From nobody Tue May 17 08:08:30 2016
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 9FF4C12D945 for ; Tue, 17 May 2016 08:08:28 -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, 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 KqYFGaM37d6N for ; Tue, 17 May 2016 08:08:23 -0700 (PDT)
Received: from 10.mo177.mail-out.ovh.net (10.mo177.mail-out.ovh.net [46.105.73.133]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC0312D6E2 for ; Tue, 17 May 2016 08:08:22 -0700 (PDT)
Received: from player716.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id A39E7FF9A6A for ; Tue, 17 May 2016 17:08:15 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player716.ha.ovh.net (Postfix) with ESMTPSA id 956F55600AC for ; Tue, 17 May 2016 17:08:14 +0200 (CEST)
To: cellar@ietf.org
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net> <20160517125230.GU25812@nb4>
From: Jerome Martinez 
Message-ID: <7b547674-02e9-8fd3-b5c9-8b80bc7a2387@mediaarea.net>
Date: Tue, 17 May 2016 17:08:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160517125230.GU25812@nb4>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 3737424743099535505
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrvdekgdekfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Replace slice_count because it is not precisely defined
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 15:08:28 -0000

Le 17/05/2016  14:52, Michael Niedermayer a crit :
> [...]
> The issue is the range coder, or more precissely switching from the
> range coder back to storing bits and bytes

Right. This is something I am currently not comfortable with.
I proposed in the patch a byte_aligned test, usually used with 
bitstreams without range coder, not sure it is useful here (does a range 
coder always "eat" 8 bits whatever is the implementation?) so I ask for 
comment (maybe saying that we don't use anymore the range coder at this 
point is a better method)

> IIRC it basically just says any bytestream that decodes correctly
> is fine, leaving it to the encoder to add an unneeded byte or 2 at
> the end. (Which simplifies the encoder)
> If such extra bytes would be allowed then future specs could also use
> the area to hold some usefull information

Issue I have is: what is "decodes correctly"?
FFmpeg reads the end of the frame in order to get all slice_size values. 
But the idea is that FFmpeg will not be the only decoder in the future .
The method from FFmpeg is a method, but not the only one: reading from 
the beginning of the stream, without reading slice_size first, looks 
like currently possible when we read the current spec (a decoder could 
decide to ignore slice_size values).
In that case, it is not possible to authorize an encoder to add an 
unneeded byte or 2 at the end even if it simplifies the encoder.
If we authorize an encoder to add arbitrary bytes at the end, a decoder 
not waiting for the a complete frame before decoding would not decode 
correctly.
The main question to answer is if we authorize or not a decoder to read 
sequentially a FFV1 frame (or if a decoder could easily decode a frame 
missing the last 2 bytes), as it is currently more or less authorized in 
the spec (slice_size right after Line( p, y ), no place of "unneeded 
byte or 2").

for example, if slice_size of the last slice is corrupted (1 byte of 
corruption), FFmpeg decodes only the 1st slice but my own decoder (not 
for release, just a proof of concept) relying on a sequential decode of 
slices and on the idea there is no unneeded byte or 2 at the end of any 
slice can decode all slices without any loss of detail. If unneeded byte 
or 2 is authorized in the bitstream (and already created by FFmpeg 
encoder?), such decoder can not exist so it is important to know now 
what is authorized in the bitstream.


From nobody Tue May 17 08:54:59 2016
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 DCE0F12DA31 for ; Tue, 17 May 2016 08:54:57 -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, RCVD_IN_MSPIKE_H2=-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 xNdro4sDbBgg for ; Tue, 17 May 2016 08:54:56 -0700 (PDT)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5ABB12DA26 for ; Tue, 17 May 2016 08:54:55 -0700 (PDT)
Received: from mfilter32-d.gandi.net (mfilter32-d.gandi.net [217.70.178.163]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 1CAED41C17B for ; Tue, 17 May 2016 17:54:54 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter32-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter32-d.gandi.net (mfilter32-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id pDncx0pbYDvw for ; Tue, 17 May 2016 17:54:52 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 0C01D41C166 for ; Tue, 17 May 2016 17:54:51 +0200 (CEST)
Date: Tue, 17 May 2016 17:52:42 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160517155242.GW25812@nb4>
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9NpOjhd3EplVA7ET"
Content-Disposition: inline
In-Reply-To: <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Replace slice_count because it is not precisely defined
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 15:54:58 -0000

--9NpOjhd3EplVA7ET
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 17, 2016 at 11:08:20AM +0200, Jerome Martinez wrote:
[...]

> @@ -761,10 +765,10 @@ Decoders SHOULD accept and interpret bits_per_raw_s=
ample =3D 0 as 8.
>  | 0     | transparency plane is not present|
>  | 1     | transparency plane is present    |
> =20
> -**num\_h\_slices** indicates the number of horizontal elements of the sl=
ice raster.
> +**num\_h\_slices** indicates the horizontal size of the slice raster.
>  Inferred to be 1 if not present.

is this really clearer ?
size could be in anything from pixels, elements, even inch



> =20
> -**num\_v\_slices** indicates the number of vertical elements of the slic=
e raster.
> +**num\_v\_slices** indicates the vertical size of the slice raster.
>  Inferred to be 1 if not present.
> =20
>  **quant\_table\_count** indicates the number of quantization table sets.
> @@ -782,8 +786,6 @@ Inferred to be 0 if not present.
>  pred =3D j ? initial\_states[ i ][j - 1][ k ] : 128
>  initial\_state[ i ][ j ][ k ] =3D ( pred + initial\_state\_delta[ i ][ j=
 ][ k ] ) & 255
> =20
> -**slice\_count** indicates the number of slices in the current frame, sl=
ice\_count is 1 if it is not explicitly coded.
> -
>  **ec** indicates the error detection/correction type.
> =20
>  |value | error detection/correction type          |
> @@ -852,6 +854,10 @@ MAX\_CONTEXT\_INPUTS is 5.
>  To ensure that fast multithreaded decoding is possible, starting version=
 2 and if frame\_width * frame\_height is more than 101376, slice\_width * =
slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4.
>  Note: 101376 is the frame size in pixels of a 352x288 frame also known a=
s CIF ("Common Intermediate Format") frame size format.
> =20
> +For each frame, each position in the slice raster MUST be filled by one =
and only one slice of the frame (no missing slice position, no slice overla=
pping).
> +

> +For each Frame with keyframe value of 0, each slice MUST have the same v=
alue of slice\_x, slice\_y, slice\_width, slice\_height as a slice in the p=
revious frame.

i was wondering if reset_contexts =3D 1 should allow changing the layout
it doesnt use the previous so it should be fine in terms of being
well specified, but maybe i miss something


> +
>  # Changelog
> =20
>  See 
> --=20
> 2.7.0.windows.1
>=20

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


--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus

--9NpOjhd3EplVA7ET
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc7PkoACgkQYR7HhwQLD6uKmgCggVnqLS/WG6QVlHz/toy4NddL
xsUAn3aXMvELAdnfIkfEUBBI/YBg45Sb
=Rym2
-----END PGP SIGNATURE-----

--9NpOjhd3EplVA7ET--


From nobody Tue May 17 09:12:20 2016
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 5849E12D1A7 for ; Tue, 17 May 2016 09:12:19 -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, 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 uJ3n3JYCfk7s for ; Tue, 17 May 2016 09:12:16 -0700 (PDT)
Received: from 8.mo177.mail-out.ovh.net (8.mo177.mail-out.ovh.net [46.105.61.98]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E5C512D199 for ; Tue, 17 May 2016 09:12:15 -0700 (PDT)
Received: from player716.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id 5952EFF9B15 for ; Tue, 17 May 2016 18:12:10 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player716.ha.ovh.net (Postfix) with ESMTPSA id 29A3656008F for ; Tue, 17 May 2016 18:12:08 +0200 (CEST)
To: cellar@ietf.org
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net> <20160517155242.GW25812@nb4>
From: Jerome Martinez 
Message-ID: 
Date: Tue, 17 May 2016 18:12:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160517155242.GW25812@nb4>
Content-Type: multipart/mixed; boundary="------------57D17379C06023A78BD8F0B4"
X-Ovh-Tracer-Id: 4816881280397349009
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrvdekgdelhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Replace slice_count because it is not precisely defined
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 16:12:19 -0000

This is a multi-part message in MIME format.
--------------57D17379C06023A78BD8F0B4
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Le 17/05/2016  17:52, Michael Niedermayer a crit :
> On Tue, May 17, 2016 at 11:08:20AM +0200, Jerome Martinez wrote:
> [...]
>
>> @@ -761,10 +765,10 @@ Decoders SHOULD accept and interpret bits_per_raw_sample = 0 as 8.
>>   | 0     | transparency plane is not present|
>>   | 1     | transparency plane is present    |
>>   
>> -**num\_h\_slices** indicates the number of horizontal elements of the slice raster.
>> +**num\_h\_slices** indicates the horizontal size of the slice raster.
>>   Inferred to be 1 if not present.
> is this really clearer ?
> size could be in anything from pixels, elements, even inch

It is for me but I understand that it is not for others, I definitely 
didn't find a good way for having it obvious.
I remove the change for the moment.

>
>
>
>>   
>> -**num\_v\_slices** indicates the number of vertical elements of the slice raster.
>> +**num\_v\_slices** indicates the vertical size of the slice raster.
>>   Inferred to be 1 if not present.
>>   
>>   **quant\_table\_count** indicates the number of quantization table sets.
>> @@ -782,8 +786,6 @@ Inferred to be 0 if not present.
>>   pred = j ? initial\_states[ i ][j - 1][ k ] : 128
>>   initial\_state[ i ][ j ][ k ] = ( pred + initial\_state\_delta[ i ][ j ][ k ] ) & 255
>>   
>> -**slice\_count** indicates the number of slices in the current frame, slice\_count is 1 if it is not explicitly coded.
>> -
>>   **ec** indicates the error detection/correction type.
>>   
>>   |value | error detection/correction type          |
>> @@ -852,6 +854,10 @@ MAX\_CONTEXT\_INPUTS is 5.
>>   To ensure that fast multithreaded decoding is possible, starting version 2 and if frame\_width * frame\_height is more than 101376, slice\_width * slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4.
>>   Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF ("Common Intermediate Format") frame size format.
>>   
>> +For each frame, each position in the slice raster MUST be filled by one and only one slice of the frame (no missing slice position, no slice overlapping).
>> +
>> +For each Frame with keyframe value of 0, each slice MUST have the same value of slice\_x, slice\_y, slice\_width, slice\_height as a slice in the previous frame.
> i was wondering if reset_contexts = 1 should allow changing the layout
> it doesnt use the previous so it should be fine in terms of being
> well specified, but maybe i miss something

My role for the moment is to write the specification based on what 
exists, not to create the future bitstream.
I currently mainly focus on FFV1 "frozen" versions, and reset_contexts 
does not exist in frozen versions.
Anyway, I added "except if reset_contexts is 1" but note that I plan to 
remove (in a specific branch) any reference to FFV1 >= version 4 before 
proposing the spec to IETF, so this addition would be removed (and we'll 
be able to change it before version 4 freeze if necessary).

New patch attached.

--------------57D17379C06023A78BD8F0B4
Content-Type: text/plain; charset=UTF-8;
 name="0001-Replace-slice_count-because-it-is-not-precisely-defi.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename*0="0001-Replace-slice_count-because-it-is-not-precisely-defi.pa";
 filename*1="tch"

>From cdd324b2db682ecf600890a8b07bda8d32fc28a1 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Tue, 17 May 2016 18:09:21 +0200
Subject: [PATCH] Replace slice_count because it is not precisely defined

- remove slice_count definition and replace it by a test about
the presence of remaining bytes at the end of the frame
- replace "[i]" by "[slice_x][slice_y]"
- add byte alignment test
- add restrictions about slice_x, slice_y, slice_width,
slice_height
---
 ffv1.md | 28 +++++++++++++++++-----------
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/ffv1.md b/ffv1.md
index 80e3cf9..8298c6d 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -153,6 +153,8 @@ __a...b__ means any value starting from a to b, inclusive.
 
 **remaining\_bits\_in\_bitstream( )** means the count of remaining bits after the current position in the bitstream. It is computed from the NumBytes value multiplied by 8 minus the count of bits already read by the bitstream parser.
 
+**byte\_aligned( )** means the last parsed bit in the bitstream is the last bit in a byte.
+
 \pagebreak
 
 # General Description
@@ -522,17 +524,17 @@ See [NUT](#references) for more information about elements.
 |    keyframe                                       |  br|
 |    if( keyframe && !ConfigurationRecordIsPresent )|    |
 |         Parameters( )                             |    |
-|    for( i = 0; i \< slice\_count; i++ )           |    |
-|        Slice( i )                                 |    |
+|    while ( remaining_bits_in_bitstream() )        |    |
+|        Slice( )                                   |    |
 |}                                                  |    |
 
 ## Slice
 
 |                                                                    |
 |------------------------------------------------------------|:------|
-|Slice( i ) {                                                | type  |
+|Slice( )   {                                                | type  |
 |    if( version \> 2 )                                      |       |
-|        SliceHeader( i )                                    |       |
+|        SliceHeader( )                                      |       |
 |    if( colorspace\_type == 0) {                            |       |
 |        for( p = 0; p \< primary\_color\_count; p++ ) {     |       |
 |            Plane( p )                                      |       |
@@ -541,7 +543,9 @@ See [NUT](#references) for more information about elements.
 |            for( p = 0; p \< primary\_color\_count; p++ ) { |       |
 |                Line( p, y )                                |       |
 |    }                                                       |       |
-|    if( i \|\| version \> 2 )                               |       |
+|    while ( !byte_aligned() )                               |       |
+|        padding                                             |  u(1) |
+|    if( slice_x \|\| slice_y \|\| version \> 2 )            |       |
 |        slice\_size                                         | u(24) |
 |    if( ec ) {                                              |       |
 |        error\_status                                       |  u(8) |
@@ -571,13 +575,13 @@ The CRC generator polynom used is the standard IEEE CRC polynom (0x104C11DB7) wi
 
 |                                                            |    |
 |------------------------------------------------------------|---:|
-| SliceHeader( i ) {                                         |type|
+| SliceHeader( ) {                                           |type|
 |    slice\_x                                                | ur |
 |    slice\_y                                                | ur |
 |    slice\_width - 1                                        | ur |
 |    slice\_height - 1                                       | ur |
 |    for( j = 0; j \< quant\_table\_index\_count; j++ )      |    |
-|        quant\_table\_index [ i ][ j ]                      | ur |
+|        quant\_table\_index [ slice\_x ][ slice\_y ][ j ]   | ur |
 |    picture\_structure                                      | ur |
 |    sar\_num                                                | ur |
 |    sar\_den                                                | ur |
@@ -593,10 +597,10 @@ Inferred to be 0 if not present.
 **slice_y** indicates the y position on the slice raster formed by num_v_slices.
 Inferred to be 0 if not present.
 
-**slice_width** indicates the width on the slice raster.
+**slice_width** indicates the width on the slice raster formed by num_h_slices.
 Inferred to be 1 if not present.
 
-**slice_height** indicates the height on the slice raster.
+**slice_height** indicates the height on the slice raster formed by num_v_slices.
 Inferred to be 1 if not present.
 
 **quant\_table\_index\_count** is defined as 1 + ( ( chroma_planes || version \< 4 ) ? 1 : 0 ) + ( alpha_plane ? 1 : 0 ).
@@ -782,8 +786,6 @@ Inferred to be 0 if not present.
 pred = j ? initial\_states[ i ][j - 1][ k ] : 128
 initial\_state[ i ][ j ][ k ] = ( pred + initial\_state\_delta[ i ][ j ][ k ] ) & 255
 
-**slice\_count** indicates the number of slices in the current frame, slice\_count is 1 if it is not explicitly coded.
-
 **ec** indicates the error detection/correction type.
 
 |value | error detection/correction type          |
@@ -852,6 +854,10 @@ MAX\_CONTEXT\_INPUTS is 5.
 To ensure that fast multithreaded decoding is possible, starting version 2 and if frame\_width * frame\_height is more than 101376, slice\_width * slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4.
 Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF ("Common Intermediate Format") frame size format.
 
+For each frame, each position in the slice raster MUST be filled by one and only one slice of the frame (no missing slice position, no slice overlapping).
+
+For each Frame with keyframe value of 0, each slice MUST have the same value of slice\_x, slice\_y, slice\_width, slice\_height as a slice in the previous frame, except if reset\_contexts is 1.
+
 # Changelog
 
 See 
-- 
2.7.0.windows.1


--------------57D17379C06023A78BD8F0B4--


From nobody Tue May 17 09:29:46 2016
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 24A4912DB07 for ; Tue, 17 May 2016 09:29:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 kFJh6MzDq89y for ; Tue, 17 May 2016 09:29:43 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8D8912DAC9 for ; Tue, 17 May 2016 09:29:40 -0700 (PDT)
Received: from mfilter40-d.gandi.net (mfilter40-d.gandi.net [217.70.178.171]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 30C67172097 for ; Tue, 17 May 2016 18:29:39 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter40-d.gandi.net
Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter40-d.gandi.net (mfilter40-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 51KUfv6zaRMi for ; Tue, 17 May 2016 18:29:37 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 8048C17209C for ; Tue, 17 May 2016 18:29:37 +0200 (CEST)
Date: Tue, 17 May 2016 18:27:28 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160517162728.GX25812@nb4>
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net> <20160517125230.GU25812@nb4> <7b547674-02e9-8fd3-b5c9-8b80bc7a2387@mediaarea.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Yu0b5Z6gpzkXNZiF"
Content-Disposition: inline
In-Reply-To: <7b547674-02e9-8fd3-b5c9-8b80bc7a2387@mediaarea.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Replace slice_count because it is not precisely defined
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 16:29:45 -0000

--Yu0b5Z6gpzkXNZiF
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 17, 2016 at 05:08:12PM +0200, Jerome Martinez wrote:
> Le 17/05/2016 =E0 14:52, Michael Niedermayer a =E9crit :
> >[...]
> >The issue is the range coder, or more precissely switching from the
> >range coder back to storing bits and bytes
>=20
> Right. This is something I am currently not comfortable with.
> I proposed in the patch a byte_aligned test, usually used with
> bitstreams without range coder, not sure it is useful here (does a
> range coder always "eat" 8 bits whatever is the implementation?) so
> I ask for comment (maybe saying that we don't use anymore the range
> coder at this point is a better method)
>=20
> >IIRC it basically just says any bytestream that decodes correctly
> >is fine, leaving it to the encoder to add an unneeded byte or 2 at
> >the end. (Which simplifies the encoder)
> >If such extra bytes would be allowed then future specs could also use
> >the area to hold some usefull information
>=20
> Issue I have is: what is "decodes correctly"?
> FFmpeg reads the end of the frame in order to get all slice_size
> values. But the idea is that FFmpeg will not be the only decoder in
> the future .
> The method from FFmpeg is a method, but not the only one: reading
> from the beginning of the stream, without reading slice_size first,
> looks like currently possible when we read the current spec (a
> decoder could decide to ignore slice_size values).
> In that case, it is not possible to authorize an encoder to add an
> unneeded byte or 2 at the end even if it simplifies the encoder.
> If we authorize an encoder to add arbitrary bytes at the end, a
> decoder not waiting for the a complete frame before decoding would
> not decode correctly.
> The main question to answer is if we authorize or not a decoder to
> read sequentially a FFV1 frame (or if a decoder could easily decode
> a frame missing the last 2 bytes), as it is currently more or less
> authorized in the spec (slice_size right after Line( p, y ), no
> place of "unneeded byte or 2").
>

> for example, if slice_size of the last slice is corrupted (1 byte of

the chance of this is 1 in 10000+ or so if you have a single byte error

robust decoders should search for slices not relying on sequential
decoding from either side


> corruption), FFmpeg decodes only the 1st slice but my own decoder
> (not for release, just a proof of concept) relying on a sequential
> decode of slices and on the idea there is no unneeded byte or 2 at
> the end of any slice can decode all slices without any loss of
> detail. If unneeded byte or 2 is authorized in the bitstream (and
> already created by FFmpeg encoder?), such decoder can not exist so
> it is important to know now what is authorized in the bitstream.

I possibly misremembered and this ambiguity was already fixed
either way sequential forward decoding is something that should really
work.
if theres mismatch between spec and encoder in a bit at the end it
might make sense to treat that as a bug in the spec given that there
is just one encoder and existing files generated by it

[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange

--Yu0b5Z6gpzkXNZiF
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc7RnAACgkQYR7HhwQLD6vyKwCfck3Ec3SNV+LLyzVBihEdqMbP
InsAnAxACufRsaeUbKRfpWg4iLNaABmr
=RdTc
-----END PGP SIGNATURE-----

--Yu0b5Z6gpzkXNZiF--


From nobody Tue May 17 10:03:00 2016
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 9610512DB89 for ; Tue, 17 May 2016 10:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.835
X-Spam-Level: 
X-Spam-Status: No, score=-4.835 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 4Z6tz5nKh5It for ; Tue, 17 May 2016 10:02:51 -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 D6C8F12DB2F for ; Tue, 17 May 2016 10:02:51 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 568A8C0F57 for ; Tue, 17 May 2016 17:02:51 +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 xZ7oneUv9v-d for ; Tue, 17 May 2016 17:02:51 +0000 (UTC)
Received: from [10.252.28.103] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 4032AC13EC for ; Tue, 17 May 2016 17:02:51 +0000 (UTC)
Message-ID: <573B4EBB.4020309@xiph.org>
Date: Tue, 17 May 2016 10:02:51 -0700
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: cellar@ietf.org
References: <573113B8.6070702@xiph.org>
In-Reply-To: <573113B8.6070702@xiph.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Cellar] Call for consensus to add a milestone for EBML
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 17:02:58 -0000

Timothy B. Terriberry wrote:
> This will be a one-week call for consensus. Please respond to this
> message on or before 16 May if you support or oppose adding this milestone.

I was hoping we could have a consensus call that was shorter than the 
usual 2 weeks, but given that I've only seen one response, and it was 
from the person proposing the milestone, I'd like to extend this another 
week. Hopefully we'll get enough input to be able to declare consensus.

Please send a message to the list indicating whether or not you support 
adding this milestone on or before May 23rd.


From nobody Tue May 17 10:05:59 2016
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 DB14B12D613 for ; Tue, 17 May 2016 10:05:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 QuC21YjQIuF4 for ; Tue, 17 May 2016 10:05:53 -0700 (PDT)
Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001:c05::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 ACBD912D12E for ; Tue, 17 May 2016 10:05:53 -0700 (PDT)
Received: by mail-ig0-x22c.google.com with SMTP id bi2so78094115igb.0 for ; Tue, 17 May 2016 10:05:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=vyCQtbn/WCcvcGOg0WiE5fHO0PR8NewFH1BnCgPfFeQ=; b=G/k6gWBCRSmnaP3bqPhcJ6B1Fw3KAQRDNcKy6/0h1IQA+K0SgeJjjF4KdDDi3e4HRU Ug9PdJcsVrG2cT99lBQJlrSLFeDpFwC98axPpnATgeT2dwdetQwZJt6n2DYwv4Q7GwGy NNTTle1Dh3utTQR59a6wZnQUnLZybd4nth2xxBjlCqSgtuCt41cxCAQf7HlpX7mWHBqR GVNvTrbaHWtAADA5lcuYmFDf30tRftQRdVNpMO65nY/J5RYGbf2H5p6Ho//jJ4Dtaz7x GlC6NM9uOPJ+9wtHUz4GBSiwGgWOSeyUCRtP7XW+c11+/7GmZ5YD1TquD7qLRnfZeADE 8MVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=vyCQtbn/WCcvcGOg0WiE5fHO0PR8NewFH1BnCgPfFeQ=; b=YOhiEoO/qcJr77rOZAI3MUrg8JzmRU9ptBWUBfntMe2I+PdA16e5G/OWJnMhyvzoZf Sg1A7BaQog3/9Wa493zOMxFb0Chi7fHaDhijjVRIFz6mNmiqrJ/tlKtPZpC9spNOqPN5 SokC0HiCzEjMwJpNXenNQVZF+XMl8wizvoFWlf40oJhZLALVSVnMc1x7NbepYUBHfIe5 mnr5rOOSB3j6X24KwMTdETXL598yxC+XWO3hD/tci08sJGeOnC83dtCdAu5unJfWAC09 2DVvFI9cpYZQR1vtxT36NQM3mYdmqSdltDf0TIRMwV08E4bsEwzZ6Pctt1yggtZIxvXy mDyw==
X-Gm-Message-State: AOPr4FXXlV/uWgsUlkolMU4X+EKAVA3GhOdUwvSZ5DGRWQx/upkphfME0EE2sg1wuwOwe3/Riy/EdFZJqwkoKw==
MIME-Version: 1.0
X-Received: by 10.50.28.113 with SMTP id a17mr1927032igh.44.1463504753056; Tue, 17 May 2016 10:05:53 -0700 (PDT)
Received: by 10.79.114.210 with HTTP; Tue, 17 May 2016 10:05:53 -0700 (PDT)
In-Reply-To: <573B4EBB.4020309@xiph.org>
References: <573113B8.6070702@xiph.org> <573B4EBB.4020309@xiph.org>
Date: Tue, 17 May 2016 13:05:53 -0400
Message-ID: 
From: Ashley Blewer 
To: "Timothy B. Terriberry" 
Content-Type: multipart/alternative; boundary=089e01538ac8eee83505330cc0eb
Archived-At: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] Call for consensus to add a milestone for EBML
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 17:05:58 -0000

--089e01538ac8eee83505330cc0eb
Content-Type: text/plain; charset=UTF-8

I support this milestone as well!

On Tue, May 17, 2016 at 1:02 PM, Timothy B. Terriberry 
wrote:

> Timothy B. Terriberry wrote:
>
>> This will be a one-week call for consensus. Please respond to this
>> message on or before 16 May if you support or oppose adding this
>> milestone.
>>
>
> I was hoping we could have a consensus call that was shorter than the
> usual 2 weeks, but given that I've only seen one response, and it was from
> the person proposing the milestone, I'd like to extend this another week.
> Hopefully we'll get enough input to be able to declare consensus.
>
> Please send a message to the list indicating whether or not you support
> adding this milestone on or before May 23rd.
>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
>

--089e01538ac8eee83505330cc0eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


I support this milestone as well!

On Tue, May 17, 2016 at 1:02 PM, Tim=
othy B. Terriberry <tterribe@xiph.org> wrote:
Timothy B. Terriberry wrote:



This will be a one-week call for consensus. Please respond to this

message on or before 16 May if you support or oppose adding this milestone.=






I was hoping we could have a consensus call that was shorter than the usual=
 2 weeks, but given that I've only seen one response, and it was from t=
he person proposing the milestone, I'd like to extend this another week=
. Hopefully we'll get enough input to be able to declare consensus.



Please send a message to the list indicating whether or not you support add=
ing this milestone on or before May 23rd.




_______________________________________________

Cellar mailing list

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





--089e01538ac8eee83505330cc0eb--


From nobody Tue May 17 10:09:45 2016
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 6DDA312DBE2 for ; Tue, 17 May 2016 10:09:42 -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, 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 3Ob3OEYVYebP for ; Tue, 17 May 2016 10:09:40 -0700 (PDT)
Received: from 5.mo177.mail-out.ovh.net (5.mo177.mail-out.ovh.net [46.105.39.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AECC712DBDF for ; Tue, 17 May 2016 10:09:40 -0700 (PDT)
Received: from player716.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id 08C19FF8A54 for ; Tue, 17 May 2016 19:09:38 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player716.ha.ovh.net (Postfix) with ESMTPSA id DAB99560081 for ; Tue, 17 May 2016 19:09:37 +0200 (CEST)
To: cellar@ietf.org
References: <573113B8.6070702@xiph.org> <573B4EBB.4020309@xiph.org>
From: Jerome Martinez 
Message-ID: <5b1c5c94-1921-efb0-c47e-cc0a07d8c203@mediaarea.net>
Date: Tue, 17 May 2016 19:09:37 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <573B4EBB.4020309@xiph.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 5787406997802258577
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrvdekgddutdejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc
Archived-At: 
Subject: Re: [Cellar] Call for consensus to add a milestone for EBML
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 17:09:42 -0000

I support this milestone.

Le 17/05/2016  19:02, Timothy B. Terriberry a crit :
> Timothy B. Terriberry wrote:
>> This will be a one-week call for consensus. Please respond to this
>> message on or before 16 May if you support or oppose adding this 
>> milestone.
>
> I was hoping we could have a consensus call that was shorter than the 
> usual 2 weeks, but given that I've only seen one response, and it was 
> from the person proposing the milestone, I'd like to extend this 
> another week. Hopefully we'll get enough input to be able to declare 
> consensus.
>
> Please send a message to the list indicating whether or not you 
> support adding this milestone on or before May 23rd.
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar



From nobody Tue May 17 10:17:20 2016
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 3A30812DC00 for ; Tue, 17 May 2016 10:17:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.427
X-Spam-Level: 
X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_HELO_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 qQzlUf_3w-_k for ; Tue, 17 May 2016 10:17:13 -0700 (PDT)
Received: from liselle.bunkus.org (liselle.bunkus.org [176.9.119.9]) (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 6693C12D71C for ; Tue, 17 May 2016 10:17:13 -0700 (PDT)
Received: by liselle.bunkus.org (Postfix, from userid 1002) id 8041F30CB009; Tue, 17 May 2016 19:17:11 +0200 (CEST)
Received: from sweet-chili.local (unknown [10.55.1.18]) by liselle.bunkus.org (Postfix) with ESMTPS id 670B630CAFFF for ; Tue, 17 May 2016 19:17:10 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2016040101; t=1463505430; bh=tY2bIJw6Yc8DwT5tOTh0zCgBhG0e/rM12wso7kiYmfk=; h=Date:From:To:Subject:References:In-Reply-To; b=uJ87SmF92YtWauHkEQg0FIhim+Su5kkzz2nBZfZLm26/2CX5u0qw1h56PXsRTxLgB 0L0EePYjk6twIFNvvZ3fL1+vwyTNAu7dCTvz/4YWSTT/RV71QWcP2GxfqCPk5oClFw HU59w1qWNBy0VISPQPZEiltGDvulDbW7hOEgOtufdxu7hqmdlwr22ERWchfTQkr/+H dmqUC8zWyd/Ad4A5P9Lb/QvoNPpk3mdh5jPr2NTqn2hzybDnVcUT+fCkyO9eJHr8DA J1/4cAuMT6t2FBLTTnznAlel5qdeo2MMVtnySn2Yy5sbo10s0wUiVhJy3SOOp8wMAR yQbbcd8F2wfQ37frH7pMLjHhbBIZm7ds8w6ngPZ3cXEhlsZOVvyCDA6Lats4/4zUWk hSIwPxsDjnHYjyfxxz6stx5nxMZSWATZnkpP+7e1rv/2haTL5YfOi4cODI5kjpb6TR f72tHhsnyYBTIGEcfP4+HQF/7+0Vbl9buKZ44iQs1oBVJ2ZcKzunuF6RHS/+ffwFEb DT5zgpRirxhFP+KJRpLUXzhE+EHPElSrKmuZztxMOs9PykcrKTHlWWZ9E17CHahiJY jDPEsU3JAtUWdc5GSuBZfpGHBtUHVlQVTzJE+yKvVOyosa0OEWAr8pkdBOL04DCdPq 1rHSFfMx44mM8BXQHsGIliGw=
Received: by sweet-chili.local (Postfix, from userid 1000) id DC099623BC6; Tue, 17 May 2016 19:17:09 +0200 (CEST)
Date: Tue, 17 May 2016 19:17:09 +0200
From: Moritz Bunkus 
To: cellar@ietf.org
Message-ID: <20160517171709.x32d36pgkpanunld@bunkus.org>
References: <573113B8.6070702@xiph.org> <573B4EBB.4020309@xiph.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3qnco4fcyu3pbdwc"
Content-Disposition: inline
In-Reply-To: <573B4EBB.4020309@xiph.org>
User-Agent: Mutt/1.6.1-neo ()
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4
X-Virus-Scanned: clamav-milter 0.98.7 at liselle
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [Cellar] Call for consensus to add a milestone for EBML
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 17:17:19 -0000

--3qnco4fcyu3pbdwc
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

Hey,

I'm in favor, too.

Kind regards,
mosu

--3qnco4fcyu3pbdwc
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAABCgAGBQJXO1IVAAoJEHSvAK3y4yyFivEQAJNZRClkKk91htge8tSgJ37r
5d0ERG0JklLqY7EBNzvkEM1R2XyMESuSGki1d4QGPbGexp8qLzPPv+RXIiUIIfUc
0/u3nyKHVts+j5xY0rByys2x7KCCZ9+LRVLuPTVn0S4sGFw+lVaC+xeKZSCmp7hI
UbygF6GoOhPFdbpYk7HiByGPAM/2wgR6u7jZpKJo9xiylkYbxIkEowv8zhj2FO2i
++6vGE+WRjYxPwrdbpneqZcsGRHkedRT3q2PdlJ2kb3H3QK9XjV03pgu8Ey2far4
1CmXg2KhL3+AU72lBuyJ5ieCFlReywnZ0CTb7M2fTrcuuEkpPgT7qwxWUNGkGe3z
xMd+XG0a3UjuDthh+iSG/+DMw/cmr+g3AyTudd8VQzi7UXVnzd7fHWby2/ByymDH
A9p2EN1o9Vj5H6Xp+pJhOZUmXL7bl2yKdtzbcsKlVD4j0jeNAsLmBQmOjJmesCTu
lKZd2g4CKpsJ752YEslRpEjuDLNrzA/7yTbNIDsWouvQhkLsqJgTD/gHQTNNJyLV
W7hfQRV3h9i4VNEhWeAu1FAOrBoZBG4hdStwfl00oROlAp7oBmp/g1q0skl3ngpe
xJyPIyT18e/HIPELjAmBcDOv58DPKV7+ZgcCesOEbPWxeu5TuoD2/w6vMyvXfOyZ
iZJTtXJ2g2LU/zOTK/2Q
=ByJS
-----END PGP SIGNATURE-----

--3qnco4fcyu3pbdwc--


From nobody Tue May 17 10:53:13 2016
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 3EB5412DC6D for ; Tue, 17 May 2016 10:53:11 -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 lp6U1dy0m73X for ; Tue, 17 May 2016 10:53:05 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 54BAC12DC6B for ; Tue, 17 May 2016 10:53:05 -0700 (PDT)
Received: from [146.96.19.240] (port=30979 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b2jAx-000VV8-1Q; Tue, 17 May 2016 13:53:03 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_6DD19FD8-762E-42A1-B5F1-714BE26639ED"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dave Rice 
In-Reply-To: 
Date: Tue, 17 May 2016 13:52:56 -0400
Message-Id: 
References:   <56B8CD1A.20307@mediaarea.net>   <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com>  <9CE0170E-E63D-411D-AFAF-EE5CBB4B56D7@dericed.com>   <20160219214538.GL4557@nb4>     
To: Steve Lhomme , Frank Galligan , Discussion about the current and future development of Matroska 
X-Mailer: Apple Mail (2.3112)
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: 
Cc: Reto Kromer , Discussion about the current and future development of Matroska , cellar@ietf.org, Hendrik Leppkes 
Subject: Re: [Cellar] [Matroska-devel]  Colour Format proposal
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 17 May 2016 17:53:11 -0000

--Apple-Mail=_6DD19FD8-762E-42A1-B5F1-714BE26639ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Steve, Frank, Reto, and all,

> On Apr 18, 2016, at 4:29 AM, Steve Lhomme via Matroska-devel =
 wrote:
>=20
> Following the Videolan Colorimetry workshop from this week-end, I have
> a better understanding of this whole subject.

I wanted to bump this conversation and topic. I'm curious to hear more =
of what came out of the Videolan Coloimetry workshop, but I also see =
that the color format proposed elements are now integrated into =
https://matroska.org/technical/specs/index.html =
, as well as in process =
in Libav and FFmpeg, and the webm project. I don't mean to rush the =
specification work but wanted to note that the proposed color elements =
are in use. I suggest that we give this work a status to say if it is =
complete or needs more work (and if so, identify what work remains).

> I think it's good if we can have as much information in Matroska as we
> can. But they probably should be split between elements that are
> necessary for accurate playback (list to be defined) and the other
> information like how the content was captured on camera. The first
> group should be in the TrackInfo while the others should be just tags
> (so with string names) that target the whole file or some chapters
> (each scene probably has different capture characteristics).
>=20
> =46rom Frank's list I would put those in the TrackInfo:
> - MatrixCoefficients
> - Range
> - TransferFunction
> - Primaries
>=20
> - BitsPerChannel
> - ChromaSubsamplingHorz / ChromaSubsamplingVert
> - CbSubsamplingHorz / CbSubsamplingVert
>=20
> I'm not sure about the Luminance min/max but maybe it's needed for HDR =
?
> Not sure either about arbitrary RGB chromacity values of the
> primaries. Are people deviating from the few norms that are available
> ? And have tools for playback ? That seems to provide the same
> information as the "Primaries" field and it's never good to have 2
> different set of values describing the same thing. You never know if
> you have to write both and which to use for playback especially when
> you need 8 values to make one set to compare...

I'm interested in hearing about the use cases for these (ping to Reto). =
Are we certain that the "Primaries" element overlaps semantically with =
the Primary[R|G|B]Chromaticity[X|Y] elements? Perhaps we should define =
one to overrule the other.

> Are MaxCLL and MaxFALL exclusive ? Are they needed for HDR playback ?
>=20
> I think MasteringMetadata is not needed for playback.
>=20
> For list of possible values, we shouldn't follow lists from standards
> that are not freely available. We should also have the default value
> be 0 when possible.

For much of the semantics used in the proposed colour elements, '2' =
rather than '0' has been used to express an 'undetermined' state whereas =
'0' has a specific meaning. I think it's consistent to keep it this way =
as it better aligns with existing specification (even if non-free) and =
existing implementations (free and not free).

> And no "reserved" values.

Same comment as above. If we are deriving a vocabulary from an =
established existing standard then I think adopting traditional reserved =
values is okay.
Best Regards,
Dave Rice

> 2016-03-29 19:12 GMT+02:00 Hendrik Leppkes via Matroska-devel
> :
>> On Tue, Mar 29, 2016 at 6:11 PM, Frank Galligan via Matroska-devel
>>  wrote:
>>>=20
>>>=20
>>> On Mon, Mar 28, 2016 at 5:05 AM, Steve Lhomme  =
wrote:
>>>>=20
>>>> 2016-03-17 5:46 GMT+01:00 Frank Galligan :
>>>>> OK really no comments for a long time.
>>>>>=20
>>>>> On Fri, Feb 19, 2016 at 1:45 PM, Michael Niedermayer
>>>>>  wrote:
>>>>>>=20
>>>>>> Hi
>>>>>>=20
>>>>>> On Thu, Feb 18, 2016 at 11:50:27AM -0800, Frank Galligan wrote:
>>>>>>> Here is the current proposal, minus the reference to the 265 =
doc.
>>>>>>>=20
>>>>>>> The parent element would be Video [E0].
>>>>>>>=20
>>>>>>>=20
>>>>>>> Element Name: Colour
>>>>>>>=20
>>>>>>> Level:        4
>>>>>>>=20
>>>>>>> ID:           [55][B0]
>>>>>>>=20
>>>>>>> Mandatory:    -
>>>>>>>=20
>>>>>>> Multiple:     -
>>>>>>>=20
>>>>>>> Default:      -
>>>>>>>=20
>>>>>>> Type:         m
>>>>>>>=20
>>>>>>> Description:  Settings describing the colour format.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Element Name: MatrixCoefficients
>>>>>>>=20
>>>>>>> Level:        5
>>>>>>>=20
>>>>>>> ID:           [55][B1]
>>>>>>>=20
>>>>>>> Mandatory:    -
>>>>>>>=20
>>>>>>> Multiple:     -
>>>>>>>=20
>>>>>>> Default:      2
>>>>>>>=20
>>>>>>> Type:         u
>>>>>>>=20
>>>>>>> Description:  The Matrix Coefficients of the video used to =
derive
>>>>>>> luma
>>>>>>> and
>>>>>>>=20
>>>>>>>             chroma values from reg, green, and blue color =
primaries.
>>>>>>> For
>>>>>>>=20
>>>>>>>             clarity, the value and meanings for =
MatrixCoefficients
>>>>>>> are
>>>>>>> adopted
>>>>>>>=20
>>>>>>>             from Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0:GBR, =
1:
>>>>>>> BT709,
>>>>>>>=20
>>>>>>>             2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6:
>>>>>>> SMPTE
>>>>>>> 170M,
>>>>>>>=20
>>>>>>>             7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant
>>>>>>> Luminance,
>>>>>>>=20
>>>>>>>             10: BT2020 Constant Luminance)
>>>>>>>=20
>>>>>>>=20
>>>>>>=20
>>>>>>> Element Name: BitsPerChannel
>>>>>>>=20
>>>>>>> Level:        5
>>>>>>>=20
>>>>>>> ID:           [55][B2]
>>>>>>>=20
>>>>>>> Mandatory:    -
>>>>>>>=20
>>>>>>> Multiple:     -
>>>>>>>=20
>>>>>>> Default:      0
>>>>>>>=20
>>>>>>> Type:         u
>>>>>>>=20
>>>>>>> Description:  Number of decoded bits per channel. A value of 0
>>>>>>> indicates
>>>>>>> that
>>>>>>>=20
>>>>>>>             the BitsPerChannel is unspecified.
>>>>>>>=20
>>>>>>=20
>>>>>> what would this be set to for old 16bit rgb, that is 5 bit red
>>>>>> 6 bit green, 5 bit blue rawvideo.
>>>>>> This maybe does not matter and iam not strongly suggesting to add =
it,
>>>>>> rather i want to point it out so its not unintentionally =
forgotten
>>>>>=20
>>>>>=20
>>>>> I didn't get into RGB here. As you said 565, 551, there are a good
>>>>> amount of
>>>>> combinations. I think DirectShow (or maybe it was DirectDraw) that =
had
>>>>> R,G,B, and A masks to show which bits belonged to which channel. I =
also
>>>>> worked with formats like RGBBGR repeating.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> [...]
>>>>>>=20
>>>>>>> Element Name: CbSubsamplingHorz
>>>>>>>=20
>>>>>>> Level:        5
>>>>>>>=20
>>>>>>> ID:           [55][B5]
>>>>>>>=20
>>>>>>> Mandatory:    -
>>>>>>>=20
>>>>>>> Multiple:     -
>>>>>>>=20
>>>>>>> Default:      -
>>>>>>>=20
>>>>>>> Type:         u
>>>>>>>=20
>>>>>>> Description:  The amount of pixels to remove in the Cb channel =
for
>>>>>>> every
>>>>>>> pixel
>>>>>>>=20
>>>>>>>             not removed horizontally. This is additive with
>>>>>>>=20
>>>>>>>             ChromaSubsamplingHorz. Example: For video with 4:2:1
>>>>>>> chroma
>>>>>>>=20
>>>>>>>             subsampling, the ChromaSubsamplingHorz should be set =
to
>>>>>>> 1
>>>>>>> and
>>>>>>>=20
>>>>>>>             CbSubsamplingHorz should be set to 1.
>>>>>>>=20
>>>>>>>=20
>>>>>>> Element Name: CbSubsamplingVert
>>>>>>>=20
>>>>>>> Level:        5
>>>>>>>=20
>>>>>>> ID:           [55][B6]
>>>>>>>=20
>>>>>>> Mandatory:    -
>>>>>>>=20
>>>>>>> Multiple:     -
>>>>>>>=20
>>>>>>> Default:      -
>>>>>>>=20
>>>>>>> Type:         u
>>>>>>>=20
>>>>>>> Description:  The amount of pixels to remove in the Cb channel =
for
>>>>>>> every
>>>>>>> pixel
>>>>>>>=20
>>>>>>>             not removed vertically. This is additive with
>>>>>>>=20
>>>>>>>             ChromaSubsamplingVert.
>>>>>>=20
>>>>>> What if Cr is subsampled more than Cb ?
>>>>>> That too is rather obscure, but theres code in FFmpeg to handle =
such
>>>>>> jpegs, so i suspect this case while very rare is not entirely non
>>>>>> existent ...
>>>>>=20
>>>>>=20
>>>>> I guess we can add that as well if more people really want it. =
Actually
>>>>> I
>>>>> didn't even have CbSubsampling* elements at first. I only added =
that to
>>>>> support the 4:2:1 format that was defined in the first enum.
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>> Element Name: ChromaSitingHorz
>>>>>>>=20
>>>>>>> Level:        5
>>>>>>>=20
>>>>>>> ID:           [55][B7]
>>>>>>>=20
>>>>>>> Mandatory:    -
>>>>>>>=20
>>>>>>> Multiple:     -
>>>>>>>=20
>>>>>>> Default:      0
>>>>>>>=20
>>>>>>> Type:         u
>>>>>>>=20
>>>>>>> Description:  How Chroma is subsampled horizontally. (0: =
Unspecified,
>>>>>>> 1:
>>>>>>> Left
>>>>>>>=20
>>>>>>>             collocated , 2: Half)
>>>>>>>=20
>>>>>>> Element Name: ChromaSitingVert
>>>>>>>=20
>>>>>>> Level:        5
>>>>>>>=20
>>>>>>> ID:           [55][B8]
>>>>>>>=20
>>>>>>> Mandatory:    -
>>>>>>>=20
>>>>>>> Multiple:     -
>>>>>>>=20
>>>>>>> Default:      0
>>>>>>>=20
>>>>>>> Type:         u
>>>>>>>=20
>>>>>>> Description:  How Chroma is subsampled vertically. (0: =
Unspecified,
>>>>>>> 1:
>>>>>>> Top
>>>>>>>=20
>>>>>>>             collocated , 2: Half)
>>>>>>>=20
>>>>>>=20
>>>>>> iam not sure this is enough to specify all variants
>>>>>> for 4:2:0 alone there are a few different variants
>>>>>> theres mpeg1 style
>>>>>> mpeg2 progressive and interlaced
>>>>>> the mpeg2/mpeg4 style also differs from itself if the image is =
fliped
>>>>>> right-left
>>>>>> cropping 1 or 2 lines of the top of mpeg2 yuv420 also results in
>>>>>> different variants
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> I also didn't get into interlaced.
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> I don't think we should add enough elements to support every =
format that
>>>>> was
>>>>> ever produced. Opinions?
>>>>=20
>>>> For archival (one of the main goal here) I think we should.
>>>>=20
>>>>> I think we should probably strive to support 99% of what is =
currently
>>>>> produced today. Opinions?
>>>>=20
>>>> The problem is that when you leave 1% out, you need to be sure it's
>>>> possible to integrate it later. Usually the best approach is to =
know
>>>> beforehand how you're going to do it. So in the end it's just like
>>>> covering it. That's just a general remark though.
>>>=20
>>> I don't want to exclude anything in the future, but I also don't =
want to
>>> make something overly complex/over specified to support a format =
that will
>>> barely see any use.
>>>=20
>>> I want to move forward with this, so how about we make a list and =
then vote
>>> on what we think should be added to the sepc?
>>> 1. Raw RGB
>>> 2. Raw YUV
>>> 3. Interlaced
>>> 4. mpeg1 style
>>> 5. mpeg2 pogessive
>>> 6. mpeg2 interlaced
>>> 7. image flipped right-left
>>> 8. jpeg Cr subsampled more than Cb
>>> 9. non-linear color values (DPX scans)
>>>=20
>>> Anything else we should add?
>>>=20
>>=20
>> Just my 2 cents, but if you want to support everything and the =
kitchen
>> sink, you should use string fields that can be arbitrarily expanded,
>> instead of integer enumerations.
>>=20
>> - Hendrik
>> _______________________________________________
>> Matroska-devel mailing list
>> Matroska-devel@lists.matroska.org
>> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
>> Read Matroska-Devel on GMane: =
http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>=20
>=20
>=20
> --=20
> Steve Lhomme
> Matroska association Chairman
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel@polgara.bunkus.org
> https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane: =
http://dir.gmane.org/gmane.comp.multimedia.matroska.devel


--Apple-Mail=_6DD19FD8-762E-42A1-B5F1-714BE26639ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii


Hi Steve, Frank, Reto, and all,

On =
Apr 18, 2016, at 4:29 AM, Steve Lhomme via Matroska-devel <matroska-devel@polgara.bunkus.org> wrote:

Following the Videolan Colorimetry workshop from this =
week-end, I have
a better understanding of this whole =
subject.

I wanted to bump this conversation and topic. I'm =
curious to hear more of what came out of the Videolan Coloimetry =
workshop, but I also see that the color format proposed elements are now =
integrated into https://matroska.org/technical/specs/index.html, as well =
as in process in Libav and FFmpeg, and the webm project. I don't mean to =
rush the specification work but wanted to note that the proposed color =
elements are in use. I suggest that we give this work a status to say if =
it is complete or needs more work (and if so, identify what work =
remains).

I think it's good if we can have as much =
information in Matroska as we
can. But they probably =
should be split between elements that are
necessary for =
accurate playback (list to be defined) and the other
information like how the content was captured on camera. The =
first
group should be in the TrackInfo while the others =
should be just tags
(so with string names) that target the =
whole file or some chapters
(each scene probably has =
different capture characteristics).

=46rom =
Frank's list I would put those in the TrackInfo:
- =
MatrixCoefficients
- Range
- =
TransferFunction
- Primaries

- =
BitsPerChannel
- ChromaSubsamplingHorz / =
ChromaSubsamplingVert
- CbSubsamplingHorz / =
CbSubsamplingVert

I'm not sure about the =
Luminance min/max but maybe it's needed for HDR ?
Not sure =
either about arbitrary RGB chromacity values of the
primaries. Are people deviating from the few norms that are =
available
? And have tools for playback ? That seems to =
provide the same
information as the "Primaries" field and =
it's never good to have 2
different set of values =
describing the same thing. You never know if
you have to =
write both and which to use for playback especially when
you=
 need 8 values to make one set to compare...

I'm =
interested in hearing about the use cases for these (ping to Reto). Are =
we certain that the "Primaries" element overlaps semantically with the =
Primary[R|G|B]Chromaticity[X|Y] elements? Perhaps we should define one =
to overrule the other.

Are MaxCLL and MaxFALL =
exclusive ? Are they needed for HDR playback ?

I think MasteringMetadata is not needed for playback.

For list of possible values, we shouldn't =
follow lists from standards
that are not freely available. =
We should also have the default value
be 0 when =
possible.

For =
much of the semantics used in the proposed colour elements, '2' rather =
than '0' has been used to express an 'undetermined' state whereas '0' =
has a specific meaning. I think it's consistent to keep it this way as =
it better aligns with existing specification (even if non-free) and =
existing implementations (free and not free).

And no "reserved" values.

Same =
comment as above. If we are deriving a vocabulary from an established =
existing standard then I think adopting traditional reserved values is =
okay.
Best Regards,
Dave Rice

2016-03-29 19:12 GMT+02:00 Hendrik Leppkes via =
Matroska-devel
<matroska-devel@lists.matroska.org>:
On Tue, Mar 29, 2016 at =
6:11 PM, Frank Galligan via Matroska-devel
<matroska-devel@lists.matroska.org> wrote:


On Mon, Mar 28, 2016 at 5:05 AM, Steve Lhomme <slhomme@matroska.org> wrote:

2016-03-17 5:46 GMT+01:00 Frank =
Galligan <frankgalligan@gmail.com>:
OK really no comments for a long time.

On Fri, Feb 19, 2016 at 1:45 PM, Michael =
Niedermayer
<michael@niedermayer.cc> wrote:

Hi

On Thu, Feb 18, 2016 at 11:50:27AM -0800, Frank Galligan =
wrote:
Here is the =
current proposal, minus the reference to the 265 doc.

The parent element would be Video [E0].


Element Name: Colour

Level:        4

ID: =
          [55][B0]

Mandatory:    -
Multiple:     -

Default:      -

Type:         m

Description:  Settings describing the =
colour format.


Element Name: =
MatrixCoefficients

Level: =
       5

ID: =
          [55][B1]

Mandatory:    -
Multiple:     -

Default:      2

Type:         u

Description:  The Matrix Coefficients of =
the video used to derive
luma
and

 =
            ch=
roma values from reg, green, and blue color primaries.
For

 =
            cl=
arity, the value and meanings for MatrixCoefficients
are
adopted

 =
            fr=
om Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0:GBR, 1:
BT709,

 =
            2:=
 Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6:
SMPTE
170M,

 =
            7:=
 SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant
Luminance,

 =
            10=
: BT2020 Constant Luminance)



Element Name: BitsPerChannel

Level:        5

ID: =
          [55][B2]

Mandatory:    -
Multiple:     -

Default:      0

Type:         u

Description:  Number of decoded bits per =
channel. A value of 0
indicates
that

 =
            th=
e BitsPerChannel is unspecified.


what would this be set to for old =
16bit rgb, that is 5 bit red
6 bit green, 5 bit blue =
rawvideo.
This maybe does not matter and iam not strongly =
suggesting to add it,
rather i want to point it out so its =
not unintentionally forgotten


I didn't get into RGB here. As you said 565, =
551, there are a good
amount of
combinations. =
I think DirectShow (or maybe it was DirectDraw) that had
R,G,B, and A masks to show which bits belonged to which =
channel. I also
worked with formats like RGBBGR =
repeating.



[...]

Element Name: =
CbSubsamplingHorz

Level: =
       5

ID: =
          [55][B5]

Mandatory:    -
Multiple:     -

Default:      -

Type:         u

Description:  The amount of pixels to =
remove in the Cb channel for
every
pixel

 =
            no=
t removed horizontally. This is additive with

 =
            Ch=
romaSubsamplingHorz. Example: For video with 4:2:1
chroma
 =
            su=
bsampling, the ChromaSubsamplingHorz should be set to
1
and

 =
            Cb=
SubsamplingHorz should be set to 1.


Element Name: CbSubsamplingVert

Level:        5

ID: =
          [55][B6]

Mandatory:    -
Multiple:     -

Default:      -

Type:         u

Description:  The amount of pixels to =
remove in the Cb channel for
every
pixel

 =
            no=
t removed vertically. This is additive with

 =
            Ch=
romaSubsamplingVert.

What if =
Cr is subsampled more than Cb ?
That too is rather =
obscure, but theres code in FFmpeg to handle such
jpegs, =
so i suspect this case while very rare is not entirely non
existent ...


I guess we can add that as well if more people really want =
it. Actually
I
didn't even have =
CbSubsampling* elements at first. I only added that to
support the 4:2:1 format that was defined in the first =
enum.





Element Name: =
ChromaSitingHorz

Level: =
       5

ID: =
          [55][B7]

Mandatory:    -
Multiple:     -

Default:      0

Type:         u

Description:  How Chroma is subsampled =
horizontally. (0: Unspecified,
1:
Left

 =
            co=
llocated , 2: Half)

Element Name: =
ChromaSitingVert

Level: =
       5

ID: =
          [55][B8]

Mandatory:    -
Multiple:     -

Default:      0

Type:         u

Description:  How Chroma is subsampled =
vertically. (0: Unspecified,
1:
Top

 =
            co=
llocated , 2: Half)


iam not sure this is enough to specify all variants
for 4:2:0 alone there are a few different variants
theres mpeg1 style
mpeg2 progressive and =
interlaced
the mpeg2/mpeg4 style also differs from itself =
if the image is fliped
right-left
cropping 1 =
or 2 lines of the top of mpeg2 yuv420 also results in
different variants



I also didn't get into =
interlaced.



I =
don't think we should add enough elements to support every format =
that
was
ever produced. Opinions?

For archival (one of the main =
goal here) I think we should.

I think we should probably strive to support =
99% of what is currently
produced today. Opinions?

The problem is that when you =
leave 1% out, you need to be sure it's
possible to =
integrate it later. Usually the best approach is to know
beforehand how you're going to do it. So in the end it's just =
like
covering it. That's just a general remark though.

I don't want to exclude anything =
in the future, but I also don't want to
make something =
overly complex/over specified to support a format that will
barely see any use.

I want to =
move forward with this, so how about we make a list and then vote
on what we think should be added to the sepc?
1. =
Raw RGB
2. Raw YUV
3. Interlaced
4. mpeg1 style
5. mpeg2 pogessive
6. mpeg2 interlaced
7. image flipped =
right-left
8. jpeg Cr subsampled more than Cb
9. non-linear color values (DPX scans)

Anything else we should add?


Just my 2 cents, but if you want =
to support everything and the kitchen
sink, you should use =
string fields that can be arbitrarily expanded,
instead of =
integer enumerations.

- Hendrik
_______________________________________________
Matroska-devel mailing list
Matroska-devel@lists.matroska.org
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-dev=
el
Read Matroska-Devel on GMane: =
http://dir.gmane.org/gmane.comp.multimedia.matroska.devel



-- =

Steve Lhomme
Matroska association =
Chairman
_______________________________________________
Matroska-devel mailing list
Matroska-devel@polgara.bunkus.org
https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-de=
vel
Read Matroska-Devel on GMane: =
http://dir.gmane.org/gmane.comp.multimedia.matroska.devel

=

--Apple-Mail=_6DD19FD8-762E-42A1-B5F1-714BE26639ED--


From nobody Tue May 17 18:55:07 2016
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 3E0F812D8FF for ; Tue, 17 May 2016 18:55:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 piCTCo_8M9XZ for ; Tue, 17 May 2016 18:55:03 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001: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 3AB1012D568 for ; Tue, 17 May 2016 18:55:03 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id i75so47338476ioa.3 for ; Tue, 17 May 2016 18:55:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to; bh=rTzb6vsc0k6RJthSNahmxsgPRWe+VKy8jcu7MaqLc0A=; b=YkmLguzMktl/qRbJJzhoaYI+avNXmqv8bEaTPr+q7sdyf5bZ/Y449n/IQPci+o2XT0 1ms5MgpSZY5kWDdKxuvjwkfNT2fT6zeacjYO8hEVfWmYnjGVjb/noGUPnfuhvohyfMhH nNdaVueVy6rKb2hGtvS3n9c3JoVxNnsrTZLqnHliad0IOkUnua81vQSSbrUH+qumHCen bgih/yw9cnNFFVTtR66JrwthakldH0Cf1iAn4xbwxoZbEv6KbxCvBgDLiGOtpqY+CMPE 45KKCj9kKfrSKsxHhBrMj5ONmHCMZn7OTsnkvwm8jkLr/VUhl77C2H97ZFXNvWpjMCD9 0DgQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=rTzb6vsc0k6RJthSNahmxsgPRWe+VKy8jcu7MaqLc0A=; b=a+q9CFWTH4Yq9Rmk3ZmnU/6XO6E/WobROp7hdSr6L1WqXDA9EVbZwCXHQBoO5QV3gJ WMITuTsFfiypDbQcvApKbImTjbw7O3RNWPMX1PYHJyDxjZhTrUCKS6P/yPrIrqp/mSDi 8BUAZFikG0iHh5lTVZz4DbO39nkG/crebVpZoUgKxLsqB5EhXCZOcsaedQ2pqJPa1kGg 05YTlr0mdV1z5gHlW5KeR614dj+rU6lBXxUgklwzOEwHHsbQRT1qRx7qdHu7TFJtY/tc /8/DGfXbLhzn6LT3U/S9iQX3vfJ53sqaKprJiK6RHv13hHDtKNNO7F9E1Pz93RfcqPi8 8T1w==
X-Gm-Message-State: AOPr4FU2T8DxiyBhOc1o1jJ0LOsUiZ703xXb+P6lBX0dA22aYCQffhFhxK42E3i3VTonXZ86NRWKXifI/Sa36A==
MIME-Version: 1.0
X-Received: by 10.36.64.14 with SMTP id n14mr14495233ita.53.1463536502435; Tue, 17 May 2016 18:55:02 -0700 (PDT)
Received: by 10.79.114.210 with HTTP; Tue, 17 May 2016 18:55:02 -0700 (PDT)
Date: Tue, 17 May 2016 21:55:02 -0400
Message-ID: 
From: Ashley Blewer 
To: cellar@ietf.org
Content-Type: multipart/alternative; boundary=001a11352f0257f93f053314255d
Archived-At: 
Subject: [Cellar] MatroskaOrg on Github Pages
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 01:55:06 -0000

--001a11352f0257f93f053314255d
Content-Type: text/plain; charset=UTF-8

Hi all,

I opened up three pull requests on the matroska-specification
 github site.

https://github.com/Matroska-Org/matroska-specification/pull/4 Adds the
Order Guidelines page, which seeks to resolve Dave Rice's open issue.

https://github.com/Matroska-Org/matroska-specification/pull/5 -- modified
the config so links would not be broken. The base url is based on the repo
name, which changed when moving to Matroska-Org.

https://github.com/Matroska-Org/matroska-specification/pull/6 -- converts a
few more pages to Markdown. Specifically, Diagram, Specification Notes, and
Tagging.

Please review (and/or contribute with me)! I also plan to revisit the
Markdown > RFC issue this week so we can make more progress there.

My best,
Ashley Blewer

--001a11352f0257f93f053314255d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi all,

I opened up three pull requests=
 on the =
matroska-specification=C2=A0github site.

https:=
//github.com/Matroska-Org/matroska-specification/pull/4 Adds the Order =
Guidelines page, which seeks to resolve Dave Rice's open issue.

https://github.com/Matroska-Org/matroska-specification/pul=
l/5 -- modified the config so links would not be broken. The base url i=
s based on the repo name, which changed when moving to Matroska-Org.

https://github.com/Matroska-Org/matroska-specificatio=
n/pull/6 -- converts a few more pages to Markdown. Specifically,=C2=A0D=
iagram, Specification Notes, and Tagging.

Plea=
se review (and/or contribute with me)! I also plan to revisit the Markdown =
> RFC issue this week so we can make more progress there.

=

My best,
Ashley Blewer


--001a11352f0257f93f053314255d--


From nobody Tue May 17 23:12:02 2016
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 72D3812B03E for ; Tue, 17 May 2016 23:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 u9lV34dgHevc for ; Tue, 17 May 2016 23:11:59 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 38DDD12B047 for ; Tue, 17 May 2016 23:11:59 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id g133so38421593ywb.2 for ; Tue, 17 May 2016 23:11:59 -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:date:message-id:subject:from:to :cc; bh=JId4SVai+h7hx9A8ePkSpjRqHg/gLKxOqUrpulCoBwI=; b=D4ETjEZyYrj9lRX5ZqVp92hF0jxodRxtg5LGUjl+0eHKKJ9oq2hWakhMt9SIWYpwU6 Jl3J3Eh/zEXXHH/yUhGHcDyza3uCMU5gYV8SbIIZYv8c+CWdZnvIfij5z8yPJ2C11x/X 1+W70ohCEaCvPLcwQkMVAqevsq4MRg2hwdBMedIGLNxWf2qiINZOwuJi3+aTbtxXuXDM FBwt3GZrVNOPxQfIWOFBwzOs+efYLeMxE5UOvZ/lN8dpYUhCAec/9z1jIb/cjRPgODtL +ocBFCYBFfqhnE+C88ExWVerBJlLkYye0tUDAl2X+Fc55dh6Wa772RsIoDn3GUOwgvnt GXAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=JId4SVai+h7hx9A8ePkSpjRqHg/gLKxOqUrpulCoBwI=; b=G85DMIdsdw1eGOLAl5zVy9yTRawtuvjY/1QCHWhVNI3tnkiUKcpp6ZoLh5+Oo7o9L0 UUsYzW3SfsAoxN9fSuClZ4Gi1TOHPdPDO3GjrljJ7kNmcm7EzFK7U9a2gIey4BzP9/fP aw3nu8K1mcEvHSLcQerxecwv53d0ffRVSugqeF3dIO5mUxSyd28XA5Yt/0IdkYMx5DIw c+aEJCkWuZGnf8CpkdOfcUxY47sms5ghECSNAPbd9F2QQbKPKNIfRnF/R7kJRV+7DFE8 B/d752X85MATFAbfIiHSHJ96azjqIPWV7vuuBbhieRDd9YQHkla4Uwmhs9pv+3u6wHvs LKzQ==
X-Gm-Message-State: AOPr4FVbB5VjBb1uTplteVTSHztqLMwmbT4lgc55ScUmKdvd76L4Tbmxeyym4mTs45r5mQiKlfHQ1lrgojHbVw==
MIME-Version: 1.0
X-Received: by 10.37.115.146 with SMTP id o140mr2888463ybc.177.1463551918493;  Tue, 17 May 2016 23:11:58 -0700 (PDT)
Received: by 10.83.48.81 with HTTP; Tue, 17 May 2016 23:11:58 -0700 (PDT)
In-Reply-To: 
References: 
Date: Wed, 18 May 2016 08:11:58 +0200
Message-ID: 
From: Steve Lhomme 
To: Ashley Blewer 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] MatroskaOrg on Github Pages
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 06:12:01 -0000

2016-05-18 3:55 GMT+02:00 Ashley Blewer :
> Hi all,
>
> I opened up three pull requests on the matroska-specification github site.
>
> https://github.com/Matroska-Org/matroska-specification/pull/4 Adds the Order
> Guidelines page, which seeks to resolve Dave Rice's open issue.

Github comments:
Do we want to reference actual softwares like mkvpropedit ?

The second meta seek should be discouraged IMO. There's no need to
keep a reference of all Clusters, the Cues have that. And if you can
edit backward to set the position of the second meta seek, you can
surely have a
placeholder for the Cues in there.

CRC: Should say that it must be even before the Cluster Timecode.

> https://github.com/Matroska-Org/matroska-specification/pull/5 -- modified
> the config so links would not be broken. The base url is based on the repo
> name, which changed when moving to Matroska-Org.

Merged.

> https://github.com/Matroska-Org/matroska-specification/pull/6 -- converts a
> few more pages to Markdown. Specifically, Diagram, Specification Notes, and
> Tagging.

Too large to comment possible issues infinitely. We will update/fix
with pull requests. So I merged it.

> Please review (and/or contribute with me)! I also plan to revisit the
> Markdown > RFC issue this week so we can make more progress there.
>
> My best,
> Ashley Blewer
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
>



-- 
Steve Lhomme
Matroska association Chairman


From nobody Tue May 17 23:23:30 2016
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 C644112B03E for ; Tue, 17 May 2016 23:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 1KKq8hgPGpie for ; Tue, 17 May 2016 23:23:28 -0700 (PDT)
Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 9F98912B037 for ; Tue, 17 May 2016 23:23:28 -0700 (PDT)
Received: by mail-yw0-x231.google.com with SMTP id x194so38596396ywd.0 for ; Tue, 17 May 2016 23:23:28 -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:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=k+Wknwaz44ZYh7hbhNDGmsepnCawlnr+9UMx5rNM+ss=; b=V8w9glyChxPwAPcllH08iT+0yCGaFIo3mcG3v1s+HzP38fCwbSUVVlsrA5N0RmcwGC KmE45vj3HSuss8Ie1R/5pun2sYLz8GaKzLh8O8FG2JQ9zlihWcBDBHLF31FegyRxD1gk HKHIrnRuVngP9RmV1QTHoI6YCeP/8MUVQdJ1ZJNC26v2RXDj/tjZhSBvU0NKredQCX3M PjbeuZXif4CA060tKrmCWufWufnEWP5gQpSu8I4MP2TMFuRi2roSQWgcN3FVIfc5uOh5 H6nEOydGyQLPtmdnufNSVV8YCnUk1EMgjvPUalVLJ8EUDJxP/5KIGlD6hCMqbwJui3rP vOrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=k+Wknwaz44ZYh7hbhNDGmsepnCawlnr+9UMx5rNM+ss=; b=mJJo1w72LhDGtL4bXWc35V1nWj81luyCNe1dVFf0EOrZQteNrZpSOtFd+yuVDAmUAP ccQHrkskVLgOibKPV0hvvn525GwggbxxAdPqxOEPLdyMZySnOn8hkBjv9j5P4XTvGc9s b3J6YknOuqPEumyhSCg9u6q2SgOC1jgHF7BYOTvd2s+jvYct9x2ZIhkZQ8CKSfy+d7x3 xPU9fB/wFfpqrsBDH13EDR1i6WmuxJbhUxkPaDmLj0E5MP4EC+ELKJBtzS240lMkwMQy x5PDE1DJ2KqZTTpRxdANRoq1TMBUiPAXdrxiobFeX+bphpfh64WWomJxq1Caf/lm/3bM nuSQ==
X-Gm-Message-State: AOPr4FWt/8gQiohpMXCCETAZPZUZEl9SCb9E9/6vE2eLSfk7hMY4lHs+KN7IeyQPgjMYNqdSL7hBg4hYEbadGA==
MIME-Version: 1.0
X-Received: by 10.37.231.144 with SMTP id e138mr2707990ybh.11.1463552607950; Tue, 17 May 2016 23:23:27 -0700 (PDT)
Received: by 10.83.48.81 with HTTP; Tue, 17 May 2016 23:23:27 -0700 (PDT)
In-Reply-To: <5A551233-6AFF-4E70-ABA1-F5F2002CB9F9@dericed.com>
References: <1ED4498D-FC22-4D36-8163-BCA301FD4738@dericed.com>  <20160418155706.GI30912@bunkus.org> <08896C4C-F809-4614-9489-21A16D9BE12D@dericed.com>  <5A551233-6AFF-4E70-ABA1-F5F2002CB9F9@dericed.com>
Date: Wed, 18 May 2016 08:23:27 +0200
Message-ID: 
From: Steve Lhomme 
To: Dave Rice 
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: cellar@ietf.org, Moritz Bunkus 
Subject: Re: [Cellar] patch on textual expressions of floats in EBML Schema
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 06:23:29 -0000

2016-05-10 5:49 GMT+02:00 Dave Rice :
>
>> On May 8, 2016, at 7:42 AM, Steve Lhomme  wrote:
>>
>> 2016-04-18 18:00 GMT+02:00 Dave Rice :
>>>
>>>> On Apr 18, 2016, at 11:57 AM, Moritz Bunkus  wrote:
>>>>
>>>> Hey,
>>>>
>>>>>> I think the parser can resolve this issue without much trouble. In t=
his
>>>>> context, the hyphen expresses a negative binary power, when it is pre=
ceded
>>>>> by a 'P' or 'p'. On the other hand, the hyphen serves as the delimite=
r
>>>>> between the minimum and maximum values, when it is not preceded by a =
'P' or
>>>>> 'p'. This criterion can be used to distinguish the two cases.
>>>>
>>>> I agree. If a p occurs the following element must be the
>>>> exponent. Therefore there's no ambiguity.
>>>
>>> Regarding such interpretation, currently specdata.xml expresses float r=
ange in a style of "0.0-1.0". Should we say that both forms are valid as ra=
nges? Or that "0x0p+1-0x1p+0" is valid but "0.0-1.0" is invalid.
>>
>> For the moment the range value is not used to generate code. Only
>> "0-1" integers are assumed to be boolean. So these changes won't
>> affect the generated code.
>
> In that case I supplied a pull request here which changes > 0=E2=80=9D=
 to ">0x0p+1"
> https://github.com/Matroska-Org/foundation-source/pull/16/files.

I think 0x0p0 or 0x0p+0 is a clearer representation of 0.0.

> Also note that the definition of SamplingFrequency (a float element) incl=
udes a default of =E2=80=9C8000.0=E2=80=9D. My Hexadecimal Floating-Point C=
onstants skills are still new; Nithin, what is the Hexadecimal Floating-Poi=
nt Constants form of 8000?
>
>>>>> In this context, does 'float' mean only 32-bit floats, or does it mea=
n
>>>>> both 32-bit floats and 64-bit doubles? If it is the latter, then I th=
ink
>>>>> 'floating constant' (given in the C11 standard) may be a more unambig=
uous
>>>>> term.
>>>>
>>>> The specs always talk about the numerical types as they apply to EBML
>>>> (section "EBML Element Types" at [1]). We don't talk about data types =
in
>>>> a specific programming language; that's an implementation detail the
>>>> specs shouldn't care about. So "float" means up to 64bits, just as
>>>> "unsigned integer" does. We don't say "uint64_t" there either.
>>>>
>>>> Kind regards,
>>>> mosu
>>>>
>>>> [1]  https://github.com/Matroska-Org/ebml-specification/blob/master/sp=
ecification.markdown
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>>
>> --
>> Steve Lhomme
>> Matroska association Chairman
>



--=20
Steve Lhomme
Matroska association Chairman


From nobody Tue May 17 23:35:33 2016
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 5161812D0E3 for ; Tue, 17 May 2016 23:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 u7drWjW1-17z for ; Tue, 17 May 2016 23:35:27 -0700 (PDT)
Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 2A59212D0DA for ; Tue, 17 May 2016 23:35:27 -0700 (PDT)
Received: by mail-yw0-x236.google.com with SMTP id x194so38793632ywd.0 for ; Tue, 17 May 2016 23:35:27 -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:date:message-id:subject:from:to :cc; bh=PNSR8ltXuF3nosPd7WFzWZOnx08EggB7xpE4NwwbCo0=; b=Ietic2h37eXE3aFeY7xULBoxPG/Db3M9Va/QST52/b9oQlKXVwPMCIB1c6oCjxsbDi ZT+zCQkP1S88fUMjiNYJrU0X1L6pWPWd+tA7l1tP1Vky+CNtZH+hoQ+/tmcdQsYieur/ 0CXnd5fUx83d2WzjgOWrTM7WyECoYfY+12opcf15iUdkjIMyWEXT8H5EpE3j2SLqQWCv PWb/7CzJ/YTHzvkIk6yyHvc9VcbShiUnDTNbbjFc31b1dCIaV4NpKJn7j4Ut4WqYKtQh dR3VFhoW+W/XJqFQOaDmDV8DXhQaLj4qvqgNdC/TdhUw8CO7MUXkA8rERm/YwsiiQeC/ a3AQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=PNSR8ltXuF3nosPd7WFzWZOnx08EggB7xpE4NwwbCo0=; b=VLL2mgpT7nq4ofX0DVYQaFbrdDuzY0OBJqNR921oZttKmpQAujJUyfoXBivTDDmHxO VAYGxeYX9W5HI2KlvqRgpoQectUPDdKdYclbXjRGNY5hDiJv1+4zAUfnFKpEJqjzPvX5 xSerp0HNxgQaYRTHssK/3bEsqrcojQXZZ1ko28CCG6irHWYfjFZYrhqhn63FyidoPqxL /O9xrDNDNPtvGbKKNMB9swMoOjZ1kduXa5DW9lRs6dUmSmghS1JWBJKFrImCGt5mwbRo P4caKx8aoAWzRkl5WkNrjyWaIYqMro1MkpwS65rlynZvXY0vcZowrFo3sDCP0J0nZB+k iX8w==
X-Gm-Message-State: AOPr4FU/1sqeBLIcXlEI2dIcpF0lr2XqIK+0obbaC2ySc7JvVNaangC55OEg+72jpquzTaHAWPYzYBSV/S0HYQ==
MIME-Version: 1.0
X-Received: by 10.129.43.68 with SMTP id r65mr3033746ywr.327.1463553326526; Tue, 17 May 2016 23:35:26 -0700 (PDT)
Received: by 10.83.48.81 with HTTP; Tue, 17 May 2016 23:35:26 -0700 (PDT)
In-Reply-To: <573B4EBB.4020309@xiph.org>
References: <573113B8.6070702@xiph.org> <573B4EBB.4020309@xiph.org>
Date: Wed, 18 May 2016 08:35:26 +0200
Message-ID: 
From: Steve Lhomme 
To: "Timothy B. Terriberry" 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] Call for consensus to add a milestone for EBML
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 06:35:31 -0000

Sorry for not answering earlier.
I support this milestone too.

2016-05-17 19:02 GMT+02:00 Timothy B. Terriberry :
> Timothy B. Terriberry wrote:
>>
>> This will be a one-week call for consensus. Please respond to this
>> message on or before 16 May if you support or oppose adding this
>> milestone.
>
>
> I was hoping we could have a consensus call that was shorter than the usual
> 2 weeks, but given that I've only seen one response, and it was from the
> person proposing the milestone, I'd like to extend this another week.
> Hopefully we'll get enough input to be able to declare consensus.
>
> Please send a message to the list indicating whether or not you support
> adding this milestone on or before May 23rd.
>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar



-- 
Steve Lhomme
Matroska association Chairman


From nobody Tue May 17 23:37:47 2016
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 10DE212D0DA for ; Tue, 17 May 2016 23:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YzpUsZKedHfB for ; Tue, 17 May 2016 23:37:45 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002: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 D689C12D0B1 for ; Tue, 17 May 2016 23:37:44 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id g133so38844168ywb.2 for ; Tue, 17 May 2016 23:37:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=ee2qRvQd5PXezOQyur8QEk6IFCngBogUnjN34J7eZg0=; b=INrdntalB+tcSNNfhM+9hKdJ8IygF5/e4QAVMpVEq4f1bYYQ+80SY/ThaMXvOv7rbu 796rLC72XLjT/nNG3clOB0Vycg2EJgkRyDA+0uA3C6JK4phO3ypOcvJj2NHgwXc7Oo1x EWx9Bpz12+uVjh/Q0kl1UNG4no8mWQ7PH2OwvqwA8YOtidZTzIOo11l5ziTcnYuE7MMT uB9N/M/TlOiPXorfO2F7uV0iUg5FkKjRMGN8rIUt93MTroO/nPyqdvMGwSlJ7S38NJ0j BEMCcDfY2uFOMFt4upCsx2fFEKFCxLxk4iSsqukPiHN0aknvE8la9CzRIRnshDslPnpE 285g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=ee2qRvQd5PXezOQyur8QEk6IFCngBogUnjN34J7eZg0=; b=bVsQIPuwtiByeD3HYFBx4a2POE8M3gSu5N3caozcmX7g/iZTE1t44riBnw8IrZldan +/ftkuYN/qme1WrNQWwdVxZf5b89zBTJGxhgkRmeACpK/z5I/41L2dynoTKtSYimnHgG vqzhraBRM7BfXHcaMRzO77EIjqEM7TxdO7M82iwxj5m4oifQB+RkbfsKYGiYrsKCClKW jNxv7gpIUt3Fik46N5abkTg/sK1Xfj0eTRHoaIKhnVSp7YN0MvsfwGoXtdKMlhhXtF83 ZrAa0vGTs3GdtYAno3Pmr9IslLmn5WR4ZOPfGXsCiHdK33WvaH4kAsdFSRA8H5WrtvzX vfFg==
X-Gm-Message-State: AOPr4FX1IIXGryLbTg/5UlrI6BNZJAJYlUtxF6Lcy1LKKaPG9tU/WSXov/smdqmb0YoxiCbi25mNLNhxMP1cQA==
MIME-Version: 1.0
X-Received: by 10.129.117.70 with SMTP id q67mr3396555ywc.63.1463553464241; Tue, 17 May 2016 23:37:44 -0700 (PDT)
Sender: markh.sj@gmail.com
Received: by 10.129.72.16 with HTTP; Tue, 17 May 2016 23:37:44 -0700 (PDT)
In-Reply-To: <573B4EBB.4020309@xiph.org>
References: <573113B8.6070702@xiph.org> <573B4EBB.4020309@xiph.org>
Date: Tue, 17 May 2016 23:37:44 -0700
X-Google-Sender-Auth: 0ufqnK2fgz78bOfLPeGxxbOgQTs
Message-ID: 
From: Mark Harris 
To: cellar@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Subject: Re: [Cellar] Call for consensus to add a milestone for EBML
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 06:37:46 -0000

> Please send a message to the list indicating whether or not you support
> adding this milestone on or before May 23rd.

I support the addition of the EBML milestone.

 - Mark


From nobody Tue May 17 23:38:47 2016
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 7191312D0E5 for ; Tue, 17 May 2016 23:38:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 rCwwp9oiM-F2 for ; Tue, 17 May 2016 23:38:43 -0700 (PDT)
Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002: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 B351412D0DA for ; Tue, 17 May 2016 23:38:43 -0700 (PDT)
Received: by mail-yw0-x22e.google.com with SMTP id x189so38750050ywe.3 for ; Tue, 17 May 2016 23:38:43 -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:date:message-id:subject:from:to :cc; bh=z2Uq/zNBnLSqrFPteABg4JWeLEzKWAjkyg3t1zi4yzw=; b=Yc8LQoZ7sRAtrdJZmwweQ+tZzmBGhe5K/1jUBXBNovOqqlILz2Cpgoum59w3eeO3gX +Q3dFy16sST3fhOMx9X8cf6aTLewThcthgXd0CgJo6aZB7GyolWoyo8SVygieZpdjfnj Bag6NmMgBuz73ohDKmbA2VyHDxHGzyFszT77EZHfxyV9PLRuepe5BJRVr+PFfXnko7ZM A+griuyWwPyB64+43Njv55UoWIM2MCjHiO/fqDrFlZ6w0NWLYp0P9i4b6YVU9VErJceN KXTCwtvlRXiJXB5fPLf5Ue1AenKR9V14FeUdOkXtgUA7yDO+39zCgJs5I041W6QdLNW1 M41w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=z2Uq/zNBnLSqrFPteABg4JWeLEzKWAjkyg3t1zi4yzw=; b=jnC/ytNtdcABZ8J3cy/8wstky9EzqNpw0ixCpeqXQHbliHfal1SNluGAH2j5bRDya7 9lansgyzJRgjx2r1DpkJVDKnDN0RocbKYvuZxbnQLUsbpnSXhO5m/7/3rf1ri25PHqm0 scvN0VXXOj0y8FoXpWGVMq4mVxylzdLdRgcwSsqRRs7PV1YwwzHHGA8xAkA3A10XB9Vu nOGfq6dQXsRByTQZDNjsXKA3xohkQ/JBP0x7cvyJ8fp8Cc7HPo2Y26xNSEsbt85iEa00 tN3nt4BOPTlz3bYG8Ux3U6WmjeJtiqYsFQsvpx8wB7OgLIjfBz/KAelx7gaIsUufI8lJ DJOA==
X-Gm-Message-State: AOPr4FWUl0RRf7T9UNwImFYOBCk3HbU8ssfZhsPu74T/ZLCPTkeMVdfjy+iWWKlLirYDLgqsV9MpugVpX8IwOA==
MIME-Version: 1.0
X-Received: by 10.37.231.144 with SMTP id e138mr2732535ybh.11.1463553522979; Tue, 17 May 2016 23:38:42 -0700 (PDT)
Received: by 10.83.48.81 with HTTP; Tue, 17 May 2016 23:38:42 -0700 (PDT)
In-Reply-To: 
References:   
Date: Wed, 18 May 2016 08:38:42 +0200
Message-ID: 
From: Steve Lhomme 
To: Nithin Mathew Kurien 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Discussion about the current and future development of Matroska , cellar@ietf.org
Subject: Re: [Cellar] Channel Positions for Multichannel LPCM Track Inside Matroska
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 06:38:45 -0000

2016-05-10 11:17 GMT+02:00 Nithin Mathew Kurien :
> Hi,
>
> On Sun, May 8, 2016 at 5:35 PM, Steve Lhomme  wrote:
>>
>> 2016-04-24 17:39 GMT+02:00 Nithin Mathew Kurien :
>> > Hi,
>> >
>> > Currently the specification for storing a multichannel LPCM track
>> > (CodecID
>> > A_PCM/INT/LIT) inside a Matroska file [1, 2], does not specify a way to
>> > indicate the channel positions of the track. Due to this, players find
>> > it
>> > difficult to map the channels to the correct speaker positions when
>> > playing
>> > such a track. MakeMKV employs a workaround for this problem. It stores
>> > the
>> > track under the CodecID A_MS/ACM, along with a WAVEFORMATEXTENSIBLE
>> > structure in CodecPrivate. This structure contains a field called
>> > dwChannelMask which specifies the channel positions [3]. This is
>> > identical
>> > to the way LPCM is stored inside AVI files. The problem with this
>> > approach
>> > is that most players do not recognise the CodecID A_MS/ACM, except for a
>> > few
>> > open-source players like Kodi [4].
>>
>> We used to have a field for that but it was never used AFAIK
>> https://matroska.org/technical/specs/index.html#ChannelPositions
>>
>> This is how it used to be, describing each speaker position with an
>> angle. I don't know there is a standard way to express this. I'd
>> assume the distance to the center should play a role too.
>>
>> https://web.archive.org/web/20071211091532/http://www.matroska.org/technical/specs/channelposition/index.html
>
>
> This notation is appropriate for speaker positions in the horizontal plane,
> but there is a problem. The LFE channel is omni-directional; so how do we
> denote whether the LFE channel is present or not, in this notation?

I agree, it's not sufficient. The idea was that it would be universal
enough to cover mapping from all existing formats (which should be our
goal). But missing LFE is a problem. Also you're right, there could be
speakers up and down. So maybe a spherical position (2 angles ?), the
type of frequency carried (LFE or all or all except LFE) and maybe an
optional distance ?

>> > In the case of a FLAC track (inside either a raw .FLAC file or a .MKA
>> > file),
>> > we can specify an optional WAVEFORMATEXTENSIBLE_CHANNEL_MASK tag [5].
>> > Could
>> > a similar solution be implemented for LPCM inside Matroska too?
>> >
>> > On a related note, the ffmpeg documentation [6] specifies additional
>> > channel
>> > positions which are not found in the Microsoft documentation [3], like
>> > Wide
>> > Left and Wide Right speakers. Are these speaker positions recognised by
>> > players when reading WAV files?
>>
>> VLC currently handles 'only' 9 speaker positions out of the 18 MS ones.
>>
>> > [1] https://matroska.org/technical/specs/codecid/index.html
>> > [2] http://haali.su/mkv/codecs.pdf
>> > [3]
>> >
>> > https://msdn.microsoft.com/en-us/library/windows/hardware/dn653308(v=vs.85).aspx
>> > [4] http://www.makemkv.com/forum2/viewtopic.php?f=8&t=2530
>> > [5]
>> > https://sourceforge.net/p/mediainfo/discussion/297609/thread/164b4fb3/
>> > [6] https://ffmpeg.org/doxygen/2.2/channel__layout_8h_source.html
>> >
>> > Thanks and regards,
>> > Nithin
>> >
>> > _______________________________________________
>> > Cellar mailing list
>> > Cellar@ietf.org
>> > https://www.ietf.org/mailman/listinfo/cellar
>> >
>>
>>
>>
>> --
>> Steve Lhomme
>> Matroska association Chairman
>
>
> Thanks and regards,
> Nithin



-- 
Steve Lhomme
Matroska association Chairman


From nobody Wed May 18 00:15:41 2016
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 B98BB12D114 for ; Wed, 18 May 2016 00:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 gqZj6CBYwoik for ; Wed, 18 May 2016 00:15:37 -0700 (PDT)
Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 1212D12D10D for ; Wed, 18 May 2016 00:15:37 -0700 (PDT)
Received: by mail-yw0-x22d.google.com with SMTP id g133so39512931ywb.2 for ; Wed, 18 May 2016 00:15:37 -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:date:message-id:subject:from:to :cc; bh=L+fwwWIOBnji1OTy3AU0x5nVsxZvxOxacFkvfHs4IA4=; b=pS4vSDxYHhF5GjKCqZqlXJfsmALBgoXAp+f+m9aLAKT7eW8osGP75deVKHOggCIAJ1 1AHorK9AwNd24CAvylPxrIyCMNxJMuiBFLgA0DP7dz0iuiPCU5nrXmNpBhbYlrHkl12+ iIO4DFLaDJCQOHW02LDTJ12PfVIfZaq7ru5Ji3AXEUzLptZBN9vC951D65a3cyPavs0D ZK05MIUjNEuhBani5yYdDRguvFjYKsBk98JPAPCmRD1iwEayi8VFbFGifdynVsjkzd7h WmwXSOo6JND8q7fczAkGDHHXOa0LzxlFAHFXj2+cR7x14DLbvZ5xYuVWi9noJ53MeY7l dL5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=L+fwwWIOBnji1OTy3AU0x5nVsxZvxOxacFkvfHs4IA4=; b=UR5u2qGnJLUPDLBFEnDbwEQ26S73Nnt0LFUUFwPYz3APoXjSz4WOz7smIBRndLp868 VnbKGXSOehA6oVZF82dHvh45EOAGFeoCnreCiS+s5Fpsy/O7u2YLgJ5uWTpJ1vMJCTcZ PX2Y/7WUv+op4Yef94cbKDAIf0ZZmyQaNaXRx5d2wA0OyGv5GWaRAo94CGrD48GAG4lW npiw9XAKiKdRbgnkHXwXvjNwfHOFPBQUMTty/dTvoVGPYbtCHXUnYWqqbcDlNvY0FeUM mVpHJv5F0xkvMMRziCuL3Qovnvc860VkgQVorjD/9Res8GuOc6QNrpYVnVwSCWbtCOoM rEIA==
X-Gm-Message-State: AOPr4FWFyet6SXp0s0+5OKyYWDjh6QVg0Bw/t/SqnP4PZFBI/ppnxaXjSjLMgnt17RwbgZtVoXVUD9cmWeSctQ==
MIME-Version: 1.0
X-Received: by 10.13.229.195 with SMTP id o186mr3033429ywe.117.1463555736235;  Wed, 18 May 2016 00:15:36 -0700 (PDT)
Received: by 10.83.48.81 with HTTP; Wed, 18 May 2016 00:15:36 -0700 (PDT)
In-Reply-To: 
References:   <56B8CD1A.20307@mediaarea.net>   <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com>  <9CE0170E-E63D-411D-AFAF-EE5CBB4B56D7@dericed.com>   <20160219214538.GL4557@nb4>      
Date: Wed, 18 May 2016 09:15:36 +0200
Message-ID: 
From: Steve Lhomme 
To: Dave Rice 
Content-Type: text/plain; charset=UTF-8
Archived-At: 
Cc: Discussion about the current and future development of Matroska , Hendrik Leppkes , Discussion about the current and future development of Matroska , Frank Galligan , Reto Kromer , cellar@ietf.org
Subject: Re: [Cellar] [Matroska-devel]  Colour Format proposal
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 07:15:40 -0000

2016-05-17 19:52 GMT+02:00 Dave Rice :
> Hi Steve, Frank, Reto, and all,
>
> On Apr 18, 2016, at 4:29 AM, Steve Lhomme via Matroska-devel
>  wrote:
>
> Following the Videolan Colorimetry workshop from this week-end, I have
> a better understanding of this whole subject.
>
>
> I wanted to bump this conversation and topic. I'm curious to hear more of
> what came out of the Videolan Coloimetry workshop, but I also see that the

The result can be summarized in the introduction of these 4 enums:
http://git.videolan.org/?p=vlc.git;a=blob;f=include/vlc_es.h;h=9c0feb9f81257a1f628096f914d5ecb79eea4011;hb=HEAD#l195

Since the VLC code is basically for playing or converting videos,
there was no need to support everything under the sun, as it should
with Matroska.

We identified these 4 pieces to be the data needed for proper
rendering of various color formats.

Also playback support is not yet fully implemented, for example
BT.2020 is not there yet.

> color format proposed elements are now integrated into
> https://matroska.org/technical/specs/index.html, as well as in process in
> Libav and FFmpeg, and the webm project. I don't mean to rush the
> specification work but wanted to note that the proposed color elements are
> in use. I suggest that we give this work a status to say if it is complete
> or needs more work (and if so, identify what work remains).
>
> I think it's good if we can have as much information in Matroska as we
> can. But they probably should be split between elements that are
> necessary for accurate playback (list to be defined) and the other
> information like how the content was captured on camera. The first
> group should be in the TrackInfo while the others should be just tags
> (so with string names) that target the whole file or some chapters
> (each scene probably has different capture characteristics).
>
> From Frank's list I would put those in the TrackInfo:
> - MatrixCoefficients
> - Range
> - TransferFunction
> - Primaries
>
> - BitsPerChannel
> - ChromaSubsamplingHorz / ChromaSubsamplingVert
> - CbSubsamplingHorz / CbSubsamplingVert
>
> I'm not sure about the Luminance min/max but maybe it's needed for HDR ?

Yes, although I haven't found much information on how to support HDR
yet (not handled by VLC).

> Not sure either about arbitrary RGB chromacity values of the
> primaries. Are people deviating from the few norms that are available
> ? And have tools for playback ? That seems to provide the same
> information as the "Primaries" field and it's never good to have 2
> different set of values describing the same thing. You never know if
> you have to write both and which to use for playback especially when
> you need 8 values to make one set to compare...
>
>
> I'm interested in hearing about the use cases for these (ping to Reto). Are
> we certain that the "Primaries" element overlaps semantically with the
> Primary[R|G|B]Chromaticity[X|Y] elements? Perhaps we should define one to
> overrule the other.
>
> Are MaxCLL and MaxFALL exclusive ? Are they needed for HDR playback ?

IMO we shouldn't have elements we don't understand, or they should be
explained, possibly with external links.

> I think MasteringMetadata is not needed for playback.

Agreed.

> For list of possible values, we shouldn't follow lists from standards
> that are not freely available. We should also have the default value
> be 0 when possible.

As for the audio sampling frequency, we should put the default value
for SD content. That is files that are intentionally (or historically)
small so they stay small. The other (more) important rule is that old
files without the value should fall into the default value in the
majority of cases.

> For much of the semantics used in the proposed colour elements, '2' rather
> than '0' has been used to express an 'undetermined' state whereas '0' has a
> specific meaning. I think it's consistent to keep it this way as it better
> aligns with existing specification (even if non-free) and existing
> implementations (free and not free).
>
> And no "reserved" values.
>
>
> Same comment as above. If we are deriving a vocabulary from an established
> existing standard then I think adopting traditional reserved values is okay.
> Best Regards,
> Dave Rice
>
> 2016-03-29 19:12 GMT+02:00 Hendrik Leppkes via Matroska-devel
> :
>
> On Tue, Mar 29, 2016 at 6:11 PM, Frank Galligan via Matroska-devel
>  wrote:
>
>
>
> On Mon, Mar 28, 2016 at 5:05 AM, Steve Lhomme  wrote:
>
>
> 2016-03-17 5:46 GMT+01:00 Frank Galligan :
>
> OK really no comments for a long time.
>
> On Fri, Feb 19, 2016 at 1:45 PM, Michael Niedermayer
>  wrote:
>
>
> Hi
>
> On Thu, Feb 18, 2016 at 11:50:27AM -0800, Frank Galligan wrote:
>
> Here is the current proposal, minus the reference to the 265 doc.
>
> The parent element would be Video [E0].
>
>
> Element Name: Colour
>
> Level:        4
>
> ID:           [55][B0]
>
> Mandatory:    -
>
> Multiple:     -
>
> Default:      -
>
> Type:         m
>
> Description:  Settings describing the colour format.
>
>
> Element Name: MatrixCoefficients
>
> Level:        5
>
> ID:           [55][B1]
>
> Mandatory:    -
>
> Multiple:     -
>
> Default:      2
>
> Type:         u
>
> Description:  The Matrix Coefficients of the video used to derive
> luma
> and
>
>             chroma values from reg, green, and blue color primaries.
> For
>
>             clarity, the value and meanings for MatrixCoefficients
> are
> adopted
>
>             from Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0:GBR, 1:
> BT709,
>
>             2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6:
> SMPTE
> 170M,
>
>             7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant
> Luminance,
>
>             10: BT2020 Constant Luminance)
>
>
>
> Element Name: BitsPerChannel
>
> Level:        5
>
> ID:           [55][B2]
>
> Mandatory:    -
>
> Multiple:     -
>
> Default:      0
>
> Type:         u
>
> Description:  Number of decoded bits per channel. A value of 0
> indicates
> that
>
>             the BitsPerChannel is unspecified.
>
>
> what would this be set to for old 16bit rgb, that is 5 bit red
> 6 bit green, 5 bit blue rawvideo.
> This maybe does not matter and iam not strongly suggesting to add it,
> rather i want to point it out so its not unintentionally forgotten
>
>
>
> I didn't get into RGB here. As you said 565, 551, there are a good
> amount of
> combinations. I think DirectShow (or maybe it was DirectDraw) that had
> R,G,B, and A masks to show which bits belonged to which channel. I also
> worked with formats like RGBBGR repeating.
>
>
>
>
> [...]
>
> Element Name: CbSubsamplingHorz
>
> Level:        5
>
> ID:           [55][B5]
>
> Mandatory:    -
>
> Multiple:     -
>
> Default:      -
>
> Type:         u
>
> Description:  The amount of pixels to remove in the Cb channel for
> every
> pixel
>
>             not removed horizontally. This is additive with
>
>             ChromaSubsamplingHorz. Example: For video with 4:2:1
> chroma
>
>             subsampling, the ChromaSubsamplingHorz should be set to
> 1
> and
>
>             CbSubsamplingHorz should be set to 1.
>
>
> Element Name: CbSubsamplingVert
>
> Level:        5
>
> ID:           [55][B6]
>
> Mandatory:    -
>
> Multiple:     -
>
> Default:      -
>
> Type:         u
>
> Description:  The amount of pixels to remove in the Cb channel for
> every
> pixel
>
>             not removed vertically. This is additive with
>
>             ChromaSubsamplingVert.
>
>
> What if Cr is subsampled more than Cb ?
> That too is rather obscure, but theres code in FFmpeg to handle such
> jpegs, so i suspect this case while very rare is not entirely non
> existent ...
>
>
>
> I guess we can add that as well if more people really want it. Actually
> I
> didn't even have CbSubsampling* elements at first. I only added that to
> support the 4:2:1 format that was defined in the first enum.
>
>
>
>
>
>
> Element Name: ChromaSitingHorz
>
> Level:        5
>
> ID:           [55][B7]
>
> Mandatory:    -
>
> Multiple:     -
>
> Default:      0
>
> Type:         u
>
> Description:  How Chroma is subsampled horizontally. (0: Unspecified,
> 1:
> Left
>
>             collocated , 2: Half)
>
> Element Name: ChromaSitingVert
>
> Level:        5
>
> ID:           [55][B8]
>
> Mandatory:    -
>
> Multiple:     -
>
> Default:      0
>
> Type:         u
>
> Description:  How Chroma is subsampled vertically. (0: Unspecified,
> 1:
> Top
>
>             collocated , 2: Half)
>
>
> iam not sure this is enough to specify all variants
> for 4:2:0 alone there are a few different variants
> theres mpeg1 style
> mpeg2 progressive and interlaced
> the mpeg2/mpeg4 style also differs from itself if the image is fliped
> right-left
> cropping 1 or 2 lines of the top of mpeg2 yuv420 also results in
> different variants
>
>
>
>
> I also didn't get into interlaced.
>
>
>
> I don't think we should add enough elements to support every format that
> was
> ever produced. Opinions?
>
>
> For archival (one of the main goal here) I think we should.
>
> I think we should probably strive to support 99% of what is currently
> produced today. Opinions?
>
>
> The problem is that when you leave 1% out, you need to be sure it's
> possible to integrate it later. Usually the best approach is to know
> beforehand how you're going to do it. So in the end it's just like
> covering it. That's just a general remark though.
>
>
> I don't want to exclude anything in the future, but I also don't want to
> make something overly complex/over specified to support a format that will
> barely see any use.
>
> I want to move forward with this, so how about we make a list and then vote
> on what we think should be added to the sepc?
> 1. Raw RGB
> 2. Raw YUV
> 3. Interlaced
> 4. mpeg1 style
> 5. mpeg2 pogessive
> 6. mpeg2 interlaced
> 7. image flipped right-left
> 8. jpeg Cr subsampled more than Cb
> 9. non-linear color values (DPX scans)
>
> Anything else we should add?
>
>
> Just my 2 cents, but if you want to support everything and the kitchen
> sink, you should use string fields that can be arbitrarily expanded,
> instead of integer enumerations.
>
> - Hendrik
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel@lists.matroska.org
> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane:
> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>
>
>
>
> --
> Steve Lhomme
> Matroska association Chairman
> _______________________________________________
> Matroska-devel mailing list
> Matroska-devel@polgara.bunkus.org
> https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel
> Read Matroska-Devel on GMane:
> http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
>
>



-- 
Steve Lhomme
Matroska association Chairman


From nobody Wed May 18 03:38:28 2016
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 60CF712D1B6 for ; Wed, 18 May 2016 03:38:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 g52VkbaU4Hwv for ; Wed, 18 May 2016 03:38:26 -0700 (PDT)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBDB512D0EC for ; Wed, 18 May 2016 03:38:25 -0700 (PDT)
Received: from mfilter34-d.gandi.net (mfilter34-d.gandi.net [217.70.178.165]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 3BF8FFB8D2 for ; Wed, 18 May 2016 12:38:24 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter34-d.gandi.net
Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter34-d.gandi.net (mfilter34-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id bj5vJL1-g4fI for ; Wed, 18 May 2016 12:38:22 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 89509FB8D6 for ; Wed, 18 May 2016 12:38:22 +0200 (CEST)
Date: Wed, 18 May 2016 12:36:12 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160518103612.GY25812@nb4>
References: <573113B8.6070702@xiph.org> <573B4EBB.4020309@xiph.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Uv/zEe6/f7FNxHZa"
Content-Disposition: inline
In-Reply-To: <573B4EBB.4020309@xiph.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] Call for consensus to add a milestone for EBML
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 10:38:27 -0000

--Uv/zEe6/f7FNxHZa
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 17, 2016 at 10:02:51AM -0700, Timothy B. Terriberry wrote:
> Timothy B. Terriberry wrote:
> >This will be a one-week call for consensus. Please respond to this
> >message on or before 16 May if you support or oppose adding this milesto=
ne.
>=20
> I was hoping we could have a consensus call that was shorter than
> the usual 2 weeks, but given that I've only seen one response, and
> it was from the person proposing the milestone, I'd like to extend
> this another week. Hopefully we'll get enough input to be able to
> declare consensus.
>=20
> Please send a message to the list indicating whether or not you
> support adding this milestone on or before May 23rd.

I support this milestone.

[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato

--Uv/zEe6/f7FNxHZa
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc8RZwACgkQYR7HhwQLD6ueowCfU6oEZKu4DcEiXSg43Lbw5rql
9yUAn0fzlY9UZnvqeeiC/4K9gPUxLVH0
=Z3LK
-----END PGP SIGNATURE-----

--Uv/zEe6/f7FNxHZa--


From nobody Wed May 18 05:29:43 2016
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 C5D6F12D133 for ; Wed, 18 May 2016 05:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.703
X-Spam-Level: 
X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 8u48ryYxFv3D for ; Wed, 18 May 2016 05:29:39 -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 47B1B12D123 for ; Wed, 18 May 2016 05:29:38 -0700 (PDT)
Received: from smtp3.infomaniak.ch (smtp3.infomaniak.ch [84.16.68.91]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u4ICTal1020081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 18 May 2016 14:29:36 +0200
Received: from Castor.local (dynamic.wline.6rd.res.cust.swisscom.ch [IPv6:2a02:1205:5049:560:6c04:d937:e962:e3f3] (may be forged)) (authenticated bits=0) by smtp3.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u4ICTZjY031073 for ; Wed, 18 May 2016 14:29:36 +0200
Date: Wed, 18 May 2016 14:29:36 +0200
From: Reto Kromer 
To: cellar@ietf.org
X-Priority: 3
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.4 (470)
Archived-At: 
Subject: Re: [Cellar] Call for consensus to add a milestone for EBML
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 12:29:42 -0000

Michael Niedermayer wrote:

>> Please send a message to the list indicating whether or
>> not you support adding this milestone on or before May
>> 23rd.

I support this milestone. Best regards, Reto


AV Preservation by reto.ch
chemin du Suchet 5 | 1024 Ecublens | Switzerland
Web: https://reto.ch | Twitter: @retoch


From nobody Wed May 18 06:29:11 2016
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 E918E12B059 for ; Wed, 18 May 2016 06:29:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3slWjPYi55ti for ; Wed, 18 May 2016 06:29:08 -0700 (PDT)
Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001: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 59E4412B050 for ; Wed, 18 May 2016 06:29:08 -0700 (PDT)
Received: by mail-ig0-x22a.google.com with SMTP id qe5so90027806igc.1 for ; Wed, 18 May 2016 06:29:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=AIimeTb6bnxGbjhyun8iZ+df045nUek+mBBUjbpdwJ8=; b=kXL15mJsyO55rzXD3iwKn5oylf9OPprqcb8DZ/d6aAa4pKR7HHq1xl5bSrhxnbzMuA vjOsxD87ofjMUtJODwEnO1e89oLeD8Gti4RWg8PhX70WxrknzvWWnPe6Cj9B+mZxZ8rX axRuQAZy+Rq0Uzr3YHBgTS1hUrRXaaTWUkyuBPgbn/Hnwk4w0zXKG9EH1QokZlMMGH1l Z3Uq/QcSz0180SnDlwYlQae/1fZWYkw9lqdGWnY9K3Pg/KsztiSWAODbMAyNqcqFx2/M bKMCx0gOLAsc5V3e7tnLB1hV2HRiQFQQORpmp9F/tsB23Y8SUiEl/ra2W7iXbcIRs5Or NTbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=AIimeTb6bnxGbjhyun8iZ+df045nUek+mBBUjbpdwJ8=; b=LwDrapSYJhjwwjk+wYftUgdSQas30CsywQFhlXKwcY6n4M1l/v5tgbraoOtZ/vc9qi aB38T3FXdPSG4uBk9FAw/+iPaIwx9iC1DvPcICyoUc98OrJ1R51jUlm3HUVI+3tNLIlK +4oY8ks+VU/tWHCMfg4ZU3MzAdAcnrCI6xj4vbBDps1bg1PG5ezaW2aDgkeStCGCUjdq WBNd+ysRI/hBgp6Mt25vmnw/hTBXafmcblTyRX3Gna3DDHqZEOd1z3coQIqL1w4Y3KmO nxESy1nD6ErERwRbRL5jeYvOMNaDkdQ8cgpNcENMAleN8Kb1wfoC8hW7lB89O+6H+ChE 2ZfA==
X-Gm-Message-State: AOPr4FV3usN6/mI7V05XWqGWAxL7Ii1/2kZzLOgdyHuFc3DbU6AtxtooA4OSXi+tggyOeMTVhyV8ZXBiS1WcNQ==
MIME-Version: 1.0
X-Received: by 10.50.67.113 with SMTP id m17mr17729601igt.62.1463578147744; Wed, 18 May 2016 06:29:07 -0700 (PDT)
Received: by 10.79.114.210 with HTTP; Wed, 18 May 2016 06:29:07 -0700 (PDT)
In-Reply-To: 
References:  
Date: Wed, 18 May 2016 09:29:07 -0400
Message-ID: 
From: Ashley Blewer 
To: Steve Lhomme 
Content-Type: multipart/alternative; boundary=047d7bd753ea9915ae05331dd76d
Archived-At: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] MatroskaOrg on Github Pages
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 18 May 2016 13:29:10 -0000

--047d7bd753ea9915ae05331dd76d
Content-Type: text/plain; charset=UTF-8

Thanks Steve! I meant for these just to be about moving and converting the
content so we can get to work on improvements. I can move them over in a
different way if you'd prefer, or open one PR for each page.

Ashley

On Wed, May 18, 2016 at 2:11 AM, Steve Lhomme  wrote:

> 2016-05-18 3:55 GMT+02:00 Ashley Blewer :
> > Hi all,
> >
> > I opened up three pull requests on the matroska-specification github
> site.
> >
> > https://github.com/Matroska-Org/matroska-specification/pull/4 Adds the
> Order
> > Guidelines page, which seeks to resolve Dave Rice's open issue.
>
> Github comments:
> Do we want to reference actual softwares like mkvpropedit ?
>
> The second meta seek should be discouraged IMO. There's no need to
> keep a reference of all Clusters, the Cues have that. And if you can
> edit backward to set the position of the second meta seek, you can
> surely have a
> placeholder for the Cues in there.
>
> CRC: Should say that it must be even before the Cluster Timecode.
>
> > https://github.com/Matroska-Org/matroska-specification/pull/5 --
> modified
> > the config so links would not be broken. The base url is based on the
> repo
> > name, which changed when moving to Matroska-Org.
>
> Merged.
>
> > https://github.com/Matroska-Org/matroska-specification/pull/6 --
> converts a
> > few more pages to Markdown. Specifically, Diagram, Specification Notes,
> and
> > Tagging.
>
> Too large to comment possible issues infinitely. We will update/fix
> with pull requests. So I merged it.
>
> > Please review (and/or contribute with me)! I also plan to revisit the
> > Markdown > RFC issue this week so we can make more progress there.
> >
> > My best,
> > Ashley Blewer
> >
> > _______________________________________________
> > Cellar mailing list
> > Cellar@ietf.org
> > https://www.ietf.org/mailman/listinfo/cellar
> >
>
>
>
> --
> Steve Lhomme
> Matroska association Chairman
>

--047d7bd753ea9915ae05331dd76d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Thanks Steve! I meant for these just to be about moving an=
d converting the content so we can get to work on improvements. I can move =
them over in a different way if you'd prefer, or open one PR for each p=
age.

Ashley

On Wed, May 18, 2016 at 2:11 AM, Steve Lhomme <slhomme@matroska.org> wrote:
2016-05-18 3:55 GMT+02:00 Ashley Blewer <ashley.blewer@gmail.com>:

> Hi all,

>

> I opened up three pull requests on the matroska-specification github s=
ite.

>

> https://github.com/Matroska-Org/ma=
troska-specification/pull/4 Adds the Order

> Guidelines page, which seeks to resolve Dave Rice's open issue.


Github comments:

Do we want to reference actual softwares like mkvpropedit ?



The second meta seek should be discouraged IMO. There's no need to

keep a reference of all Clusters, the Cues have that. And if you can

edit backward to set the position of the second meta seek, you can

surely have a

placeholder for the Cues in there.



CRC: Should say that it must be even before the Cluster Timecode.



> https://github.com/Matroska-Org/ma=
troska-specification/pull/5 -- modified

> the config so links would not be broken. The base url is based on the =
repo

> name, which changed when moving to Matroska-Org.



Merged.



> https://github.com/Matroska-Org/ma=
troska-specification/pull/6 -- converts a

> few more pages to Markdown. Specifically, Diagram, Specification Notes=
, and

> Tagging.



Too large to comment possible issues infinitely. We will update/fix<=
br>
with pull requests. So I merged it.



> Please review (and/or contribute with me)! I also plan to revisit the<=
br>
> Markdown > RFC issue this week so we can make more progress there.<=
br>
>

> My best,

> Ashley Blewer

>

> _______________________________________________

> Cellar mailing list

> Cellar@ietf.org

> https://www.ietf.org/mailman/listinfo/cellar
>







--

Steve Lhomme

Matroska association Chairman





--047d7bd753ea9915ae05331dd76d--


From nobody Wed May 18 19:34:49 2016
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 8E16312D554 for ; Wed, 18 May 2016 19:34:48 -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 pwRxK837LFBF for ; Wed, 18 May 2016 19:34:46 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 E943712D548 for ; Wed, 18 May 2016 19:34:46 -0700 (PDT)
Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:45619 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b3DnQ-000IDs-LF; Wed, 18 May 2016 22:34:46 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dave Rice 
In-Reply-To: 
Date: Wed, 18 May 2016 22:34:41 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <1ED4498D-FC22-4D36-8163-BCA301FD4738@dericed.com>  <20160418155706.GI30912@bunkus.org> <08896C4C-F809-4614-9489-21A16D9BE12D@dericed.com>  <5A551233-6AFF-4E70-ABA1-F5F2002CB9F9@dericed.com> 
To: Steve Lhomme , Nithin Mathew Kurien 
X-Mailer: Apple Mail (2.3124)
X-OutGoing-Spam-Status: No, score=-2.1
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: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] patch on textual expressions of floats in EBML Schema
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 19 May 2016 02:34:48 -0000

> On May 18, 2016, at 2:23 AM, Steve Lhomme  =
wrote:
>=20
> 2016-05-10 5:49 GMT+02:00 Dave Rice :
>>=20
>>> On May 8, 2016, at 7:42 AM, Steve Lhomme  =
wrote:
>>>=20
>>> 2016-04-18 18:00 GMT+02:00 Dave Rice :
>>>>=20
>>>>> On Apr 18, 2016, at 11:57 AM, Moritz Bunkus  =
wrote:
>>>>>=20
>>>>> Hey,
>>>>>=20
>>>>>>> I think the parser can resolve this issue without much trouble. =
In this
>>>>>> context, the hyphen expresses a negative binary power, when it is =
preceded
>>>>>> by a 'P' or 'p'. On the other hand, the hyphen serves as the =
delimiter
>>>>>> between the minimum and maximum values, when it is not preceded =
by a 'P' or
>>>>>> 'p'. This criterion can be used to distinguish the two cases.
>>>>>=20
>>>>> I agree. If a p occurs the following element must be the
>>>>> exponent. Therefore there's no ambiguity.
>>>>=20
>>>> Regarding such interpretation, currently specdata.xml expresses =
float range in a style of "0.0-1.0". Should we say that both forms are =
valid as ranges? Or that "0x0p+1-0x1p+0" is valid but "0.0-1.0" is =
invalid.
>>>=20
>>> For the moment the range value is not used to generate code. Only
>>> "0-1" integers are assumed to be boolean. So these changes won't
>>> affect the generated code.
>>=20
>> In that case I supplied a pull request here which changes > 0=E2=80=9D=
 to ">0x0p+1"
>> https://github.com/Matroska-Org/foundation-source/pull/16/files.
>=20
> I think 0x0p0 or 0x0p+0 is a clearer representation of 0.0.

I updated the PR based on this comment, rebased, and pushed.

>> Also note that the definition of SamplingFrequency (a float element) =
includes a default of =E2=80=9C8000.0=E2=80=9D. My Hexadecimal =
Floating-Point Constants skills are still new; Nithin, what is the =
Hexadecimal Floating-Point Constants form of 8000?

ping. What is 8000.0 as a Hexadecimal Floating-Point Constant?

>>>>>> In this context, does 'float' mean only 32-bit floats, or does it =
mean
>>>>>> both 32-bit floats and 64-bit doubles? If it is the latter, then =
I think
>>>>>> 'floating constant' (given in the C11 standard) may be a more =
unambiguous
>>>>>> term.
>>>>>=20
>>>>> The specs always talk about the numerical types as they apply to =
EBML
>>>>> (section "EBML Element Types" at [1]). We don't talk about data =
types in
>>>>> a specific programming language; that's an implementation detail =
the
>>>>> specs shouldn't care about. So "float" means up to 64bits, just as
>>>>> "unsigned integer" does. We don't say "uint64_t" there either.
>>>>>=20
>>>>> Kind regards,
>>>>> mosu
>>>>>=20
>>>>> [1]  =
https://github.com/Matroska-Org/ebml-specification/blob/master/specificati=
on.markdown
>>>>> _______________________________________________
>>>>> Cellar mailing list
>>>>> Cellar@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/cellar
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> Cellar mailing list
>>>> Cellar@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/cellar
>>>>=20
>>>=20
>>>=20
>>>=20
>>> --
>>> Steve Lhomme
>>> Matroska association Chairman
>>=20
>=20
>=20
>=20
> --=20
> Steve Lhomme
> Matroska association Chairman
>=20
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar


From nobody Wed May 18 19:44:13 2016
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 35EB212D548 for ; Wed, 18 May 2016 19:44:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 EH3c4v31-T9D for ; Wed, 18 May 2016 19:44:09 -0700 (PDT)
Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::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 931B312B05A for ; Wed, 18 May 2016 19:44:09 -0700 (PDT)
Received: by mail-ig0-x235.google.com with SMTP id s8so37911042ign.0 for ; Wed, 18 May 2016 19:44:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=QMnkGiTwRZjXFY8hkhhrSoJGnfvvn7R94gPjL0qSYTQ=; b=LH3lntYkkciAgH2MsPFSJ1LidWWvzDKIux6OFlIVHpfT2CBQJDbvll+/Zp5yrvI6TB +DnzThfycD6JuG2WjB/QfpmW8RLUcNEMmIH20FtVONa2fxVDAaSfu1uIF2q2W1Nh/bJ/ H5LafhXdAzy+zqFyFSjelyi7mGouWuQXobzV8/ungVG8ifdlC098ZZy2vJqT8Uajh5xC pHVQ1dgkKaV+0zOXMInT+HWZ2AYeMYoBsf4YB4DslH2rbl2G8RZxKDsFag5W0s5SA4xe eUo4OwZRgor4GRz+s44/jAUCDSuAY6d6neeKeO7m/ILScBn/0zQAJLtvvnvFT8kYCo2a eu+w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=QMnkGiTwRZjXFY8hkhhrSoJGnfvvn7R94gPjL0qSYTQ=; b=Zdy/X3GuQeHREEYmn30Fmnp8M8M9xvxE0ab/3bm3oRL5AQhhkyokn/Jb1E1GdYT+LD YaD59ZLZZ1wEWyXcLdTn/+/xkS8jMDxtvV77E3tB4DyoxK9gXg3k5dFRA5h6kUKDDEqA p114YnEc3zBbgnIBdlPZUn3Eqkw1TII4j8v9m0FVuGKER3tXZJgpA9V0kveebGNArUTG mDQUYkObeOUtK0MiJ/nJUAnSeX5bkEg0FhybFBjQO/8kqFegw9gJtnalJIsZF/PHh6VK bzafyU/4Yhe/dUf7BmDGpHd6sLdw/UzPWYgvAeI0Jm8F/SldxY9Ow7WVsxsv77R/NaB6 yjPw==
X-Gm-Message-State: AOPr4FWWvjzczUnGR5xL5r9FXMYjVf0koBC90zKfxrCumDzqoUve457sW2YsYy/5Wbc1YYAMNL4Mcnqfrjgwtw==
MIME-Version: 1.0
X-Received: by 10.50.190.138 with SMTP id gq10mr872403igc.44.1463625848493; Wed, 18 May 2016 19:44:08 -0700 (PDT)
Received: by 10.79.114.210 with HTTP; Wed, 18 May 2016 19:44:08 -0700 (PDT)
In-Reply-To: 
References:   
Date: Wed, 18 May 2016 22:44:08 -0400
Message-ID: 
From: Ashley Blewer 
To: Steve Lhomme 
Content-Type: multipart/alternative; boundary=f46d0447f12cc8c598053328f2c3
Archived-At: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] MatroskaOrg on Github Pages
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 19 May 2016 02:44:11 -0000

--f46d0447f12cc8c598053328f2c3
Content-Type: text/plain; charset=UTF-8

Hello!

I added a few more pages and submitted pull requests for each (except the
audio and video examples of tagging, which are lumped together as one).

I spent some time trying to work out the aforementioned i-d template
, the kramdown rfc gem, and
pandoc2rfc  / mmark
 but didn't have any initial luck with any
of them. Although my experience with writing RFCs for IETF is zero, so that
may be why I didn't make any progress. I didn't really crack open any of
these to investigate the underlying parts that might be useful to build an
RFC Makefile!

Ashley



On Wed, May 18, 2016 at 9:29 AM, Ashley Blewer 
wrote:

> Thanks Steve! I meant for these just to be about moving and converting the
> content so we can get to work on improvements. I can move them over in a
> different way if you'd prefer, or open one PR for each page.
>
> Ashley
>
> On Wed, May 18, 2016 at 2:11 AM, Steve Lhomme 
> wrote:
>
>> 2016-05-18 3:55 GMT+02:00 Ashley Blewer :
>> > Hi all,
>> >
>> > I opened up three pull requests on the matroska-specification github
>> site.
>> >
>> > https://github.com/Matroska-Org/matroska-specification/pull/4 Adds the
>> Order
>> > Guidelines page, which seeks to resolve Dave Rice's open issue.
>>
>> Github comments:
>> Do we want to reference actual softwares like mkvpropedit ?
>>
>> The second meta seek should be discouraged IMO. There's no need to
>> keep a reference of all Clusters, the Cues have that. And if you can
>> edit backward to set the position of the second meta seek, you can
>> surely have a
>> placeholder for the Cues in there.
>>
>> CRC: Should say that it must be even before the Cluster Timecode.
>>
>> > https://github.com/Matroska-Org/matroska-specification/pull/5 --
>> modified
>> > the config so links would not be broken. The base url is based on the
>> repo
>> > name, which changed when moving to Matroska-Org.
>>
>> Merged.
>>
>> > https://github.com/Matroska-Org/matroska-specification/pull/6 --
>> converts a
>> > few more pages to Markdown. Specifically, Diagram, Specification Notes,
>> and
>> > Tagging.
>>
>> Too large to comment possible issues infinitely. We will update/fix
>> with pull requests. So I merged it.
>>
>> > Please review (and/or contribute with me)! I also plan to revisit the
>> > Markdown > RFC issue this week so we can make more progress there.
>> >
>> > My best,
>> > Ashley Blewer
>> >
>> > _______________________________________________
>> > Cellar mailing list
>> > Cellar@ietf.org
>> > https://www.ietf.org/mailman/listinfo/cellar
>> >
>>
>>
>>
>> --
>> Steve Lhomme
>> Matroska association Chairman
>>
>
>

--f46d0447f12cc8c598053328f2c3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hello!

I added a few more pages and sub=
mitted pull requests for each (except the audio and video examples of taggi=
ng, which are lumped together as one).=C2=A0

I spe=
nt some time trying to work out the aforementioned i-d template, the kramdown rfc gem, a=
nd pandoc2rfc / mmark=C2=A0but didn't have any=
 initial luck with any of them. Although my experience with writing RFCs fo=
r IETF is zero, so that may be why I didn't make any progress. I didn&#=
39;t really crack open any of these to investigate the underlying parts tha=
t might be useful to build an RFC Makefile!

Ashley=




On Wed, May 18, 2016 at 9:29 AM, Ashley Blewer <ashley.blewer@gmail.com> wrote:
Thanks Steve! I meant for these just to be about=
 moving and converting the content so we can get to work on improvements. I=
 can move them over in a different way if you'd prefer, or open one PR =
for each page.

Ashley

On Wed, May 18=
, 2016 at 2:11 AM, Steve Lhomme <slhomme@matroska.org> wr=
ote:
2016-05-18 3:55 GMT+02:00 Ashl=
ey Blewer <=
ashley.blewer@gmail.com>:

> Hi all,

>

> I opened up three pull requests on the matroska-specification github s=
ite.

>

> https://github.com/Matroska-Org/ma=
troska-specification/pull/4 Adds the Order

> Guidelines page, which seeks to resolve Dave Rice's open issue.


Github comments:

Do we want to reference actual softwares like mkvpropedit ?



The second meta seek should be discouraged IMO. There's no need to

keep a reference of all Clusters, the Cues have that. And if you can

edit backward to set the position of the second meta seek, you can

surely have a

placeholder for the Cues in there.



CRC: Should say that it must be even before the Cluster Timecode.



> https://github.com/Matroska-Org/ma=
troska-specification/pull/5 -- modified

> the config so links would not be broken. The base url is based on the =
repo

> name, which changed when moving to Matroska-Org.



Merged.



> https://github.com/Matroska-Org/ma=
troska-specification/pull/6 -- converts a

> few more pages to Markdown. Specifically, Diagram, Specification Notes=
, and

> Tagging.



Too large to comment possible issues infinitely. We will update/fix<=
br>
with pull requests. So I merged it.



> Please review (and/or contribute with me)! I also plan to revisit the<=
br>
> Markdown > RFC issue this week so we can make more progress there.<=
br>
>

> My best,

> Ashley Blewer

>

> _______________________________________________

> Cellar mailing list

> Cellar@ietf.org

> https://www.ietf.org/mailman/listinfo/cellar
>







--

Steve Lhomme

Matroska association Chairman








--f46d0447f12cc8c598053328f2c3--


From nobody Wed May 18 20:08:23 2016
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 0270512B03C for ; Wed, 18 May 2016 20:08:22 -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 EjyVHSP6ivM1 for ; Wed, 18 May 2016 20:08:19 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 A1C3812B032 for ; Wed, 18 May 2016 20:08:19 -0700 (PDT)
Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:39447 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b3EJr-0018sC-JP for cellar@ietf.org; Wed, 18 May 2016 23:08:18 -0400
From: Dave Rice 
Content-Type: multipart/alternative; boundary="Apple-Mail=_B0A99E16-9FA5-4524-9898-82BD29156A65"
Message-Id: <13C43671-E7FC-4011-B759-0E4F0E003D98@dericed.com>
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Date: Wed, 18 May 2016 23:08:13 -0400
References: <1687ED1D-AF44-4BC5-B1E5-89F2CD7440E7@dericed.com>
To: cellar@ietf.org
In-Reply-To: <1687ED1D-AF44-4BC5-B1E5-89F2CD7440E7@dericed.com>
X-Mailer: Apple Mail (2.3124)
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 Ordering Guidelines
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 19 May 2016 03:08:22 -0000

--Apple-Mail=_B0A99E16-9FA5-4524-9898-82BD29156A65
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On Feb 27, 2016, at 4:02 PM, Dave Rice  wrote:
>=20
> Hi all,
> I'm reviewing the documentation at =
https://matroska.org/technical/order/index.html =
 and have some =
questions and comments.
>=20
> The Order Guidelines say
>> Matroska only needs a few level 1 elements to be playable: Segment =
Info, Track Info, Clusters. These elements have to be present in a =
Matroska file.
>=20
> However, the specdata.xml lists Info as the only mandatory Level 1 =
Matroska Element. =46rom specdata.xml it appears that a Matroska can be =
valid even without Tracks or Clusters Level 1 Elements. So are Level 1 =
Track and Cluster elements mandatory or not. Should there be a =
distinction between a =E2=80=9Cplayable Matroska=E2=80=9D and a =
=E2=80=9Cnon-playable Matroksa=E2=80=9D?
>=20
> This sentence:
>> All the other elements can be omitted although Cues (index) improve =
the playback experience greatly.
>=20
> seems far too broad. I suspect that it should be "All the other Level =
1 elements...".
>=20
> Regarding,
>> After a Matroska file has been created it may still be edited. For =
example chapters, tags or cover art attachments can be added. To do that =
the Meta Seek needs to be updated and also some elements may be voided =
or extended.
>=20
> These sentences imply that if Chapters, Tags, or Attachments are aded =
then MetaSeek is mandatory, but is this true? Also IIRC MetaSeek doesn't =
need to reference all Level 1 elements, so Attachments could be added =
without creating or updating MetaSeek?
>=20
> Regarding,
>> When 1 Meta Seek Head is present, it should be the first element in a =
Segment=E2=80=A6
>=20
> Is this true? If MetaSeek is present a MetaSeek element MUST be the =
first element of the Segment? This conflicts with the rules for CRC =
which must also be first.
>=20
> Regarding:
>> The second Meta Seek is placed at the end and contains a lengthy list =
of all Clusters (and not the other level 1 elements).
>=20
> To clarify if a second MetaSeek is used under Segment than it must be =
the last element of the Segment? If the second MetaSeek is used it can =
only reference Clusters and not any other level 1 element? I thought =
that a second MetaSeek could be used to list any other type of level 1 =
element that didn't fit in the first existing MetaSeek to avoid =
rewrites. Which is true? Also is a third or greater MetaSeek element =
ever allowed?
>=20
> Regarding
>> Placing the first Meta Seek Head other than the first position of the =
Segment would make it a lot less useful So it must be the first =
element of a Cluster.
>=20
> I think this should read "be the first element of a Cluster=E2=80=9D, =
right?
>=20
> Regarding:
>> So the Cues should always be written after the Clusters. =
However the Cues could also appear at the =
front.
>=20
> I'm confused by the way this is written. In what cases should Cues be =
written before or after Cluster?
>=20
> Overall the documentation seems to suggest that multiple different =
elements all belong at the "end". Does the "end" mean "the last Level 1 =
element" or simply "after the last Cluster element=E2=80=9D?

Now that the Matroska Ordering Guidelines is in the =
matroska-specification repo, I wrote a pull request to update the =
existing documentation to use the vocabulary style of the EBML =
specification. This is probably most easily reviewed in this layout on =
GitHub =
https://github.com/Matroska-Org/matroska-specification/pull/11/files?short=
_path=3De54a0c6#diff-e54a0c68b10a172d7d578cd64ffbbc82 =
 though this view =
is also available =
https://github.com/Matroska-Org/matroska-specification/pull/11/files =
. =
To summarize I capitalized =E2=80=98Element=E2=80=99 as tilde-quoted the =
Element names. I also changed reference to Level 1 Elements to =
=E2=80=9CTop-Level Elements=E2=80=9D which is specifically defined in =
the EBML Specification.

The SeekHead Element is often referred to as =E2=80=9CMeta Seek=E2=80=9D, =
I changed much of this to SeekHead, but is there a preference or =
distinction between these two terms?

Dave Rice


--Apple-Mail=_B0A99E16-9FA5-4524-9898-82BD29156A65
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On Feb 27, 2016, at 4:02 PM, Dave Rice <dave@dericed.com> =
wrote:

Hi all,
I'm=
 reviewing the documentation at https://matroska.org/technical/order/index.html and =
have some questions and comments.

The =
Order Guidelines say
Matroska only needs a few level 1 elements to be playable: =
Segment Info, Track Info, Clusters. These elements have to be present in =
a Matroska file.
However, the =
specdata.xml lists Info as the only mandatory Level 1 Matroska Element. =
=46rom specdata.xml it appears that a Matroska can be valid even without =
Tracks or Clusters Level 1 Elements. So are Level 1 Track and Cluster =
elements mandatory or not. Should there be a distinction between a =
=E2=80=9Cplayable Matroska=E2=80=9D and a =E2=80=9Cnon-playable =
Matroksa=E2=80=9D?

This=
 sentence:
All =
the other elements can be omitted although Cues (index) improve the =
playback experience greatly.
seems far =
too broad. I suspect that it should be "All the other Level 1 =
elements...".

Regarding,
After a Matroska file has been created it may still be =
edited. For example chapters, tags or cover art attachments can be =
added. To do that the Meta Seek needs to be updated and also some =
elements may be voided or extended.
These sentences imply that if Chapters, Tags, or Attachments =
are aded then MetaSeek is mandatory, but is this true? Also IIRC =
MetaSeek doesn't need to reference all Level 1 elements, so Attachments =
could be added without creating or updating MetaSeek?

Regarding,
When 1 Meta Seek Head is =
present, it should be the first element in a =
Segment=E2=80=A6
Is this true? If =
MetaSeek is present a MetaSeek element MUST be the first element of the =
Segment? This conflicts with the rules for CRC which must also be =
first.

Regarding:
The second Meta Seek is placed at the end and contains a =
lengthy list of all Clusters (and not the other level 1 =
elements).
To clarify if a second =
MetaSeek is used under Segment than it must be the last element of the =
Segment? If the second MetaSeek is used it can only reference Clusters =
and not any other level 1 element? I thought that a second MetaSeek =
could be used to list any other type of level 1 element that didn't fit =
in the first existing MetaSeek to avoid rewrites. Which is true? Also is =
a third or greater MetaSeek element ever allowed?

Regarding
Placing the first Meta =
Seek Head other than the first position of the Segment would make it a =
lot less useful So it <em>must</em> be the first element of =
a Cluster.
I think this should read =
"be the first element of a Cluster=E2=80=9D, right?

Regarding:
So the Cues =
<em>should</em> always be written after the Clusters. =
However the <a href=3D"#cues_front">Cues could also appear at the =
front</a>.
I'm confused by the =
way this is written. In what cases should Cues be written before or =
after Cluster?

Overall =
the documentation seems to suggest that multiple different elements all =
belong at the "end". Does the "end" mean "the last Level 1 element" or =
simply "after the last Cluster =
element=E2=80=9D?

Now that the Matroska Ordering Guidelines is in =
the matroska-specification repo, I wrote a pull request to update the =
existing documentation to use the vocabulary style of the EBML =
specification. This is probably most easily reviewed in this layout on =
GitHub https://github.com/Matroska-Org/matroska-specification/pull/11/=
files?short_path=3De54a0c6#diff-e54a0c68b10a172d7d578cd64ffbbc82 =
though this view is also available https://github.com/Matroska-Org/matroska-specification/pull/11/=
files. To summarize I capitalized =E2=80=98Element=E2=80=99 as =
tilde-quoted the Element names. I also changed reference to Level 1 =
Elements to =E2=80=9CTop-Level Elements=E2=80=9D which is specifically =
defined in the EBML Specification.

The=
 SeekHead Element is often referred to as =E2=80=9CMeta Seek=E2=80=9D, I =
changed much of this to SeekHead, but is there a preference or =
distinction between these two terms?

Dave Rice

=

--Apple-Mail=_B0A99E16-9FA5-4524-9898-82BD29156A65--


From nobody Thu May 19 01:27:23 2016
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 69D1812D0E3 for ; Thu, 19 May 2016 01:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level: 
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 brgUlx0Nj5rn for ; Thu, 19 May 2016 01:27:20 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::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 65FCF12B03F for ; Thu, 19 May 2016 01:27:20 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id j74so71028247ywg.1 for ; Thu, 19 May 2016 01:27:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=jq08EfFBxwdeAbtlpxeWlqqCdLtIZWSexZ6NW+nhu6g=; b=Xs6M5xLMrjwiiXNKTlcgQsSoRCkjqbI3+2dPmwrut27TcVHE/saDzjUm38jcmDF/SR 4NTfhB6Czfiw+ZI9p/zWtDWvemNluqU6t3kwl5oT0zOe+10K5/TNkU7kE+JczpbkIntP 1xbpsf7lFgDp8ZrJEMT9nz1cK1EpMyM1ERoqtRTntZdzAG5PnRKajVjlPapHf+4lO3AB jlOsfN4iyS8Sm6pNrNrbCHosKhK9Vvq93IiAYnMkQusuwPRR0+Oh523ek/ji1bzydV2X dTcRCpDCiTs4jtgpBNpn57RKumI2Jx9O9hdo6XjCvtLLHKKKCzfytgulUWpUfpR2czQB StCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=jq08EfFBxwdeAbtlpxeWlqqCdLtIZWSexZ6NW+nhu6g=; b=McEXSmh+NntNDqxmyMY7m3i+xpKOUxTN7zwcJgVRGsrBayac61Cgd1Ecfj5jkW9Hlt 0yKWGaoUy6tStoJp4aqCcgLxvQQ1GDQWnfoUBFvOq8UFs6gBYvtP/h0snB5pBzr64A42 62X2CDBiDwQFN4JQS+k4AxQhbLq9K2c2UQ74AzEgCrbVRxeOpCWeGAo8UNZTaRV2tXYj NfA4+CCuET2bJn0T4S2SqvTwVw4lsgyYFXwkBAeFzrlgZg8CrEk+QTP/UjUsvvsiQ99w pkKgFvIUhvrJfahNv3CRd8Wg7IRcax4ic65cF8NU4yVh/PxaJFYQi2IUbi2SBXSlKfVr SLbQ==
X-Gm-Message-State: AOPr4FXwm2R6GR/c/Wkr2c+6lSuh9RBo0fsWi1gIh82Lvcz5AnNJC4OklR3zwNhpKYNrQctkqQ//IeTrd23uKQ==
MIME-Version: 1.0
X-Received: by 10.37.115.146 with SMTP id o140mr6295212ybc.177.1463646439736;  Thu, 19 May 2016 01:27:19 -0700 (PDT)
Received: by 10.129.108.68 with HTTP; Thu, 19 May 2016 01:27:19 -0700 (PDT)
In-Reply-To: 
References: <1ED4498D-FC22-4D36-8163-BCA301FD4738@dericed.com>  <20160418155706.GI30912@bunkus.org> <08896C4C-F809-4614-9489-21A16D9BE12D@dericed.com>  <5A551233-6AFF-4E70-ABA1-F5F2002CB9F9@dericed.com>  
Date: Thu, 19 May 2016 13:57:19 +0530
Message-ID: 
From: Nithin Mathew Kurien 
To: Dave Rice , Steve Lhomme 
Content-Type: multipart/alternative; boundary=94eb2c095d321e0d3605332dbe27
Archived-At: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] patch on textual expressions of floats in EBML Schema
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 19 May 2016 08:27:22 -0000

--94eb2c095d321e0d3605332dbe27
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, May 19, 2016 at 8:04 AM, Dave Rice  wrote:

>
> > On May 18, 2016, at 2:23 AM, Steve Lhomme  wrote:
> >
> > 2016-05-10 5:49 GMT+02:00 Dave Rice :
> >>
> >>> On May 8, 2016, at 7:42 AM, Steve Lhomme  wrote=
:
> >>>
> >>> 2016-04-18 18:00 GMT+02:00 Dave Rice :
> >>>>
> >>>>> On Apr 18, 2016, at 11:57 AM, Moritz Bunkus 
> wrote:
> >>>>>
> >>>>> Hey,
> >>>>>
> >>>>>>> I think the parser can resolve this issue without much trouble. I=
n
> this
> >>>>>> context, the hyphen expresses a negative binary power, when it is
> preceded
> >>>>>> by a 'P' or 'p'. On the other hand, the hyphen serves as the
> delimiter
> >>>>>> between the minimum and maximum values, when it is not preceded by
> a 'P' or
> >>>>>> 'p'. This criterion can be used to distinguish the two cases.
> >>>>>
> >>>>> I agree. If a p occurs the following element must be the
> >>>>> exponent. Therefore there's no ambiguity.
> >>>>
> >>>> Regarding such interpretation, currently specdata.xml expresses floa=
t
> range in a style of "0.0-1.0". Should we say that both forms are valid as
> ranges? Or that "0x0p+1-0x1p+0" is valid but "0.0-1.0" is invalid.
> >>>
> >>> For the moment the range value is not used to generate code. Only
> >>> "0-1" integers are assumed to be boolean. So these changes won't
> >>> affect the generated code.
> >>
> >> In that case I supplied a pull request here which changes > 0=E2=80=
=9D to
> ">0x0p+1"
> >> https://github.com/Matroska-Org/foundation-source/pull/16/files.
> >
> > I think 0x0p0 or 0x0p+0 is a clearer representation of 0.0.
>
> I updated the PR based on this comment, rebased, and pushed.
>
> >> Also note that the definition of SamplingFrequency (a float element)
> includes a default of =E2=80=9C8000.0=E2=80=9D. My Hexadecimal Floating-P=
oint Constants
> skills are still new; Nithin, what is the Hexadecimal Floating-Point
> Constants form of 8000?
>
> ping. What is 8000.0 as a Hexadecimal Floating-Point Constant?


8000.0 =3D 0x1.f4p+12. Also, I've created a pull request
https://github.com/Matroska-Org/ebml-specification/pull/63 regarding a typo
in the following sentence in section "Textual expression of Floats" in
file specification.markdown; please review if necessary.

"Within a float range, when a `-` (hyphen) is immediately preceded by a
letter `p`, then the `-` (hyphen) represents the separator between the
minimal and maximum value permitted by the range."

This sentence should have been "Within a float range, when a `-` (hyphen)
is not immediately preceded by a letter `p`, then the `-` (hyphen)
represents the separator between the minimal and maximum value permitted by
the range."

Thanks and regards,
Nithin

--94eb2c095d321e0d3605332dbe27
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

On Thu, May 19, 2016 at 8:04 AM, Dave Rice <dave@dericed.com> wrote:


> On May 18, 2016, at 2:23 AM, Steve Lhomme <slhomme@matroska.org> wrote:

>

> 2016-05-10 5:49 GMT+02:00 Dave Rice <dave@dericed.com>:

>>

>>> On May 8, 2016, at 7:42 AM, Steve Lhomme <slhomme@matroska.org> wrote:

>>>

>>> 2016-04-18 18:00 GMT+02:00 Dave Rice <dave@dericed.com>:

>>>>

>>>>> On Apr 18, 2016, at 11:57 AM, Moritz Bunkus <moritz@bunkus.org> wrote:

>>>>>

>>>>> Hey,

>>>>>

>>>>>>> I think the parser can resolve this issue with=
out much trouble. In this

>>>>>> context, the hyphen expresses a negative binary po=
wer, when it is preceded

>>>>>> by a 'P' or 'p'. On the other hand=
, the hyphen serves as the delimiter

>>>>>> between the minimum and maximum values, when it is=
 not preceded by a 'P' or

>>>>>> 'p'. This criterion can be used to disting=
uish the two cases.

>>>>>

>>>>> I agree. If a p occurs the following element must be t=
he

>>>>> exponent. Therefore there's no ambiguity.

>>>>

>>>> Regarding such interpretation, currently specdata.xml expr=
esses float range in a style of "0.0-1.0". Should we say that bot=
h forms are valid as ranges? Or that "0x0p+1-0x1p+0" is valid but=
 "0.0-1.0" is invalid.

>>>

>>> For the moment the range value is not used to generate code. O=
nly

>>> "0-1" integers are assumed to be boolean. So these c=
hanges won't

>>> affect the generated code.

>>

>> In that case I supplied a pull request here which changes &gt;=
 0=E2=80=9D to "&gt;0x0p+1"

>> https://github.com/Matroska-=
Org/foundation-source/pull/16/files.

>

> I think 0x0p0 or 0x0p+0 is a clearer representation of 0.0.



I updated the PR based on this comment, rebased, and pushed.



>> Also note that the definition of SamplingFrequency (a float elemen=
t) includes a default of =E2=80=9C8000.0=E2=80=9D. My Hexadecimal Floating-=
Point Constants skills are still new; Nithin, what is the Hexadecimal Float=
ing-Point Constants form of 8000?



ping. What is 8000.0 as a Hexadecimal Floating-Point Constant?
=C2=A0
8000.0 =3D 0x=
1.f4p+12. Also, I've created a pull request=C2=A0https://github.com/Matrosk=
a-Org/ebml-specification/pull/63 regarding a typo in the following sent=
ence in section "Textual expression of Floats"=C2=A0in file=
=C2=A0specification.markdown; please review if necessary.
=

"Within a float range, when a `-` (hyphen) is immediately=
 preceded by a letter `p`, then the `-` (hyphen) represents the separator b=
etween the minimal and maximum value permitted by the range."

This sentence should have been "Within a float r=
ange, when a `-` (hyphen) is not=C2=A0immediately preceded by a letter `p`, then the `-` (hyphen) represents t=
he separator between the minimal and maximum value permitted by the range.&=
quot;

Thanks and regards,
=
Nithin


--94eb2c095d321e0d3605332dbe27--


From nobody Thu May 19 11:56:34 2016
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 F2BF012DB8D for ; Thu, 19 May 2016 11:56:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 87ZgvHZuDMpb for ; Thu, 19 May 2016 11:56:28 -0700 (PDT)
Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001: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 3B5C512DB2A for ; Thu, 19 May 2016 11:56:28 -0700 (PDT)
Received: by mail-io0-x232.google.com with SMTP id b78so2485494ioj.3 for ; Thu, 19 May 2016 11:56:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ILicLQwMc85l6UogRVlRONZKcw6rOHia9hQjZVcQYck=; b=OaXUQcET1de9ndnLX83ZFfoGMqHLl5duCrxNtmR3545Ghr1/aCyUD5Z5k8iVGee80Y 5M0Z1P7eR2HRh7aC35/Doa45v7I7mFcB2MlVBhcwpRvawwKD5RKEkXvEvPZP+2byE4C9 P9lCXt4xe4/hmTIcpUznwjMdSFFtqe+GW4M2+UyAx3TFryoJHSRHquTHuxYaMesDlyMw 1pkgFRY+uJfx2PBgljWgFYgarW4jehXx4JfBHsvwvxCpXStnu/YvLAmUpDDvX5+RZ0Lb aPcoUZ+tKXGMb7bA0Xr6Tf9bYqqn1Z86JLOsxzwMj5ZEQoirM7/DZ7GF+4BARyDfNuKO S0hA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ILicLQwMc85l6UogRVlRONZKcw6rOHia9hQjZVcQYck=; b=XzARy2Qe5olskN4ervKA4ffMhC7Pvxyy4ngVzUqeaiLGmf8B+HYqi5YqxWf2A7fRWa tovG90HAGI6ODAtuYvJMxBjmNE5ayzNyZXN/A8OoI6pNmKE/j0YS0tzPDgbNoJ4ulT0j 2MyTT9bod/kfJNv30Gj+Vrhma75NTUn8OudlUh6Y7Sajpz7rXxCTolBXMZwsqy8kxPk4 hC0lVamR/nfkQJP7QYUbuCohn0m3ANPudwRnpMcYTTNFHyys6u19RWnoojAMwiTJTAB4 jn+mCpfgJcaTWWPcEjvxlXJRvCeokY3fbao4luyNW8aJKW7ntv6h8ZHn780aMtB1ZeRd V7yw==
X-Gm-Message-State: AOPr4FUuxCOXzzuucQBjzpYYohLOnliOBrlUpEoYf4lmXLvn9Tsp/Jut9NI+UHNJkhARb0htEE4p0GVk3MI7u9Jf
X-Received: by 10.36.219.70 with SMTP id c67mr4507544itg.46.1463684187203; Thu, 19 May 2016 11:56:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.7.137 with HTTP; Thu, 19 May 2016 11:56:07 -0700 (PDT)
In-Reply-To: <56990853.4000404@xiph.org>
References:     <56981134.3080607@xiph.org>  <56990853.4000404@xiph.org>
From: Michael Bradshaw 
Date: Thu, 19 May 2016 11:56:07 -0700
Message-ID: 
To: "Timothy B. Terriberry" 
Content-Type: multipart/alternative; boundary=94eb2c05750a0b1fcb053336887d
Archived-At: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] Clarification on blocks with a negative timecode
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 19 May 2016 18:56:33 -0000

--94eb2c05750a0b1fcb053336887d
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 15, 2016 at 6:55 AM, Timothy B. Terriberry 
wrote:

> Steve Lhomme wrote:
>
>> OK, so do we agree that negative timecodes should not be "rendered"
>> (play any audio) ?
>>
>
> I think the meaning of CodecDelay is clear: you should throw away the
> first "CodecDelay" worth of samples. What would be the behavior if the
> first block's timecode (before adjusting for CodecDelay) was positive? If
> it was already negative (again, before adjusting for CodecDelay)?
>
> To my mind, this should be thought of as if the first "CodecDelay" worth
> of samples are simply deleted. They don't have a negative timecode. They
> don't exist. After doing that, the behavior should be the same as in the
> no-CodecDelay case. The problem here is that we currently talk about the
> timecode of a block, not of individual samples.


I think the reason that the meaning of CodecDelay isn't entirely clear is
because the Matroska specification only talks about subtracting timestamps
(it never mentions discarding samples, which I think it should). I propose
the following change to CodecDelay's definition:

CodecDelay is the duration of the codec-built-in delay in nanoseconds. The
decoded frames from the beginning of a stream should be discarded until
CodecDelay duration has passed, and CodecDelay must be subtracted from each
block timestamp in order to get the presentation timestamp. The value
should be small so the muxing of tracks with the same presentation
timestamp are in the same Cluster.

--94eb2c05750a0b1fcb053336887d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On F=
ri, Jan 15, 2016 at 6:55 AM, Timothy B. Terriberry <tterribe@xiph.org> wrote:<=
br>
Steve Lhomme wrote:



OK, so do we agree that negative timecodes should not be "rendered&quo=
t;

(play any audio) ?





I think the meaning of CodecDelay is clear: you should throw away the first=
 "CodecDelay" worth of samples. What would be the behavior if the=
 first block's timecode (before adjusting for CodecDelay) was positive?=
 If it was already negative (again, before adjusting for CodecDelay)?



To my mind, this should be thought of as if the first "CodecDelay"=
; worth of samples are simply deleted. They don't have a negative timec=
ode. They don't exist. After doing that, the behavior should be the sam=
e as in the no-CodecDelay case. The problem here is that we currently talk =
about the timecode of a block, not of individual samples.
=

I think the reason that the meaning of CodecDelay isn't =
entirely clear is because the Matroska specification only talks about subtr=
acting timestamps (it never mentions discarding samples, which I think it s=
hould). I propose the following change to CodecDelay's definition:

CodecDelay is the duration of the codec-built-in delay=
 in nanoseconds. The decoded frames from the beginning of a stream should b=
e discarded until CodecDelay duration has passed, and CodecDelay must be su=
btracted from each block timestamp in order to get the presentation timesta=
mp. The value should be small so the muxing of tracks with the same present=
ation timestamp are in the same Cluster.


--94eb2c05750a0b1fcb053336887d--


From nobody Fri May 20 03:15:56 2016
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 ABFCC12D135 for ; Fri, 20 May 2016 03:15:54 -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, RCVD_IN_MSPIKE_H2=-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 gGPV5I_L7-pG for ; Fri, 20 May 2016 03:15:52 -0700 (PDT)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0D9F12DC7F for ; Fri, 20 May 2016 03:15:49 -0700 (PDT)
Received: from mfilter40-d.gandi.net (mfilter40-d.gandi.net [217.70.178.171]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 42B7A41C10D for ; Fri, 20 May 2016 12:15:48 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter40-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter40-d.gandi.net (mfilter40-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 9NDm6X6zJacP for ; Fri, 20 May 2016 12:15:46 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 46E2541C0AB for ; Fri, 20 May 2016 12:15:46 +0200 (CEST)
Date: Fri, 20 May 2016 12:13:34 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160520101333.GH25812@nb4>
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net> <20160517155242.GW25812@nb4> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XO/xUml0E8yzr4dJ"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Replace slice_count because it is not precisely defined
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 20 May 2016 10:15:55 -0000

--XO/xUml0E8yzr4dJ
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 17, 2016 at 06:12:08PM +0200, Jerome Martinez wrote:
> Le 17/05/2016 =E0 17:52, Michael Niedermayer a =E9crit :
> >On Tue, May 17, 2016 at 11:08:20AM +0200, Jerome Martinez wrote:
> >[...]
> >
> >>@@ -761,10 +765,10 @@ Decoders SHOULD accept and interpret bits_per_raw=
_sample =3D 0 as 8.
> >>  | 0     | transparency plane is not present|
> >>  | 1     | transparency plane is present    |
> >>-**num\_h\_slices** indicates the number of horizontal elements of the =
slice raster.
> >>+**num\_h\_slices** indicates the horizontal size of the slice raster.
> >>  Inferred to be 1 if not present.
> >is this really clearer ?
> >size could be in anything from pixels, elements, even inch
>=20
> It is for me but I understand that it is not for others, I
> definitely didn't find a good way for having it obvious.
> I remove the change for the moment.
>=20
> >
> >
> >
> >>-**num\_v\_slices** indicates the number of vertical elements of the sl=
ice raster.
> >>+**num\_v\_slices** indicates the vertical size of the slice raster.
> >>  Inferred to be 1 if not present.
> >>  **quant\_table\_count** indicates the number of quantization table se=
ts.
> >>@@ -782,8 +786,6 @@ Inferred to be 0 if not present.
> >>  pred =3D j ? initial\_states[ i ][j - 1][ k ] : 128
> >>  initial\_state[ i ][ j ][ k ] =3D ( pred + initial\_state\_delta[ i ]=
[ j ][ k ] ) & 255
> >>-**slice\_count** indicates the number of slices in the current frame, =
slice\_count is 1 if it is not explicitly coded.
> >>-
> >>  **ec** indicates the error detection/correction type.
> >>  |value | error detection/correction type          |
> >>@@ -852,6 +854,10 @@ MAX\_CONTEXT\_INPUTS is 5.
> >>  To ensure that fast multithreaded decoding is possible, starting vers=
ion 2 and if frame\_width * frame\_height is more than 101376, slice\_width=
 * slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices /=
 4.
> >>  Note: 101376 is the frame size in pixels of a 352x288 frame also know=
n as CIF ("Common Intermediate Format") frame size format.
> >>+For each frame, each position in the slice raster MUST be filled by on=
e and only one slice of the frame (no missing slice position, no slice over=
lapping).
> >>+
> >>+For each Frame with keyframe value of 0, each slice MUST have the same=
 value of slice\_x, slice\_y, slice\_width, slice\_height as a slice in the=
 previous frame.
> >i was wondering if reset_contexts =3D 1 should allow changing the layout
> >it doesnt use the previous so it should be fine in terms of being
> >well specified, but maybe i miss something
>=20
> My role for the moment is to write the specification based on what
> exists, not to create the future bitstream.
> I currently mainly focus on FFV1 "frozen" versions, and
> reset_contexts does not exist in frozen versions.
> Anyway, I added "except if reset_contexts is 1" but note that I plan
> to remove (in a specific branch) any reference to FFV1 >=3D version 4
> before proposing the spec to IETF, so this addition would be removed
> (and we'll be able to change it before version 4 freeze if
> necessary).
>=20
> New patch attached.

>  ffv1.md |   28 +++++++++++++++++-----------
>  1 file changed, 17 insertions(+), 11 deletions(-)
> 7010297ac6631ec16f5ea3a4f5fd525b2a47fc54  0001-Replace-slice_count-becaus=
e-it-is-not-precisely-defi.patch
> >From cdd324b2db682ecf600890a8b07bda8d32fc28a1 Mon Sep 17 00:00:00 2001
> From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D 
> Date: Tue, 17 May 2016 18:09:21 +0200
> Subject: [PATCH] Replace slice_count because it is not precisely defined
>=20
> - remove slice_count definition and replace it by a test about
> the presence of remaining bytes at the end of the frame
> - replace "[i]" by "[slice_x][slice_y]"
> - add byte alignment test
> - add restrictions about slice_x, slice_y, slice_width,
> slice_height
> ---

please split this in one patch per issue


>  ffv1.md | 28 +++++++++++++++++-----------
>  1 file changed, 17 insertions(+), 11 deletions(-)
>=20
> diff --git a/ffv1.md b/ffv1.md
> index 80e3cf9..8298c6d 100644
> --- a/ffv1.md
> +++ b/ffv1.md
> @@ -153,6 +153,8 @@ __a...b__ means any value starting from a to b, inclu=
sive.
> =20
>  **remaining\_bits\_in\_bitstream(=A0)** means the count of remaining bit=
s after the current position in the bitstream. It is computed from the NumB=
ytes value multiplied by 8 minus the count of bits already read by the bits=
tream parser.
> =20
> +**byte\_aligned(=A0)** means the last parsed bit in the bitstream is the=
 last bit in a byte.

"last bit in a byte" is unclear


> +
>  \pagebreak
> =20
>  # General Description
> @@ -522,17 +524,17 @@ See [NUT](#references) for more information about e=
lements.
>  |=A0=A0=A0=A0keyframe                                       |  br|
>  |=A0=A0=A0=A0if( keyframe && !ConfigurationRecordIsPresent )|    |
>  |=A0=A0=A0=A0=A0=A0=A0=A0=A0Parameters( )                             | =
   |
> -|=A0=A0=A0=A0for( i =3D 0; i \< slice\_count; i++ )           |    |
> -|=A0=A0=A0=A0=A0=A0=A0=A0Slice( i )                                 |   =
 |
> +|=A0=A0=A0=A0while ( remaining_bits_in_bitstream() )        |    |
> +|=A0=A0=A0=A0=A0=A0=A0=A0Slice( )                                   |   =
 |
>  |}                                                  |    |

has it been tested that this works with both coders ?

The text should also mention that decoders SHOULD parse slices using
the slice_size as it allows multthreading and is independant of
errors within slices


> =20
>  ## Slice
> =20
>  |                                                                    |
>  |------------------------------------------------------------|:------|
> -|Slice( i ) {                                                | type  |
> +|Slice( )   {                                                | type  |
>  |=A0=A0=A0=A0if( version \> 2 )                                      |  =
     |
> -|=A0=A0=A0=A0=A0=A0=A0=A0SliceHeader( i )                               =
     |       |
> +|=A0=A0=A0=A0=A0=A0=A0=A0SliceHeader( )                                 =
     |       |
>  |=A0=A0=A0=A0if( colorspace\_type =3D=3D 0) {                           =
 |       |
>  |=A0=A0=A0=A0=A0=A0=A0=A0for( p =3D 0; p \< primary\_color\_count; p++ )=
 {     |       |
>  |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Plane( p )                         =
             |       |
> @@ -541,7 +543,9 @@ See [NUT](#references) for more information about ele=
ments.
>  |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0for( p =3D 0; p \< primary\_color\_=
count; p++ ) { |       |
>  |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Line( p, y )           =
                     |       |
>  |=A0=A0=A0=A0}                                                       |  =
     |
> -|=A0=A0=A0=A0if( i \|\| version \> 2 )                               |  =
     |
> +|=A0=A0=A0=A0while ( !byte_aligned() )                               |  =
     |

> +|=A0=A0=A0=A0=A0=A0=A0=A0padding                                        =
     |  u(1) |

There is no Description in the spec what "padding" is


> +|=A0=A0=A0=A0if( slice_x \|\| slice_y \|\| version \> 2 )            |  =
     |
>  |=A0=A0=A0=A0=A0=A0=A0=A0slice\_size                                    =
     | u(24) |
>  |=A0=A0=A0=A0if( ec ) {                                              |  =
     |
>  |=A0=A0=A0=A0=A0=A0=A0=A0error\_status                                  =
     |  u(8) |
> @@ -571,13 +575,13 @@ The CRC generator polynom used is the standard IEEE=
 CRC polynom (0x104C11DB7) wi
> =20
>  |                                                            |    |
>  |------------------------------------------------------------|---:|
> -| SliceHeader( i ) {                                         |type|
> +| SliceHeader( ) {                                           |type|
>  | =A0=A0=A0slice\_x                                                | ur |
>  | =A0=A0=A0slice\_y                                                | ur |
>  | =A0=A0=A0slice\_width - 1                                        | ur |
>  | =A0=A0=A0slice\_height - 1                                       | ur |
>  | =A0=A0=A0for( j =3D 0; j \< quant\_table\_index\_count; j++ )      |  =
  |

> -| =A0=A0=A0=A0=A0=A0=A0quant\_table\_index [ i ][ j ]                   =
   | ur |
> +| =A0=A0=A0=A0=A0=A0=A0quant\_table\_index [ slice\_x ][ slice\_y ][ j ]=
   | ur |

This raises an interresting related question

If most arrays are based on slice coordinates in the raster and
not slices the arrays would become much larger if the entries are
not conditionally allocated. Theres alot of state per slice

of course this is a spec and not an implementation but implementations
might follow the wording used in the spec rather closely=20

This problem should be mentioned in the spec so implementations avoid
having problems with files with fine rasters and slices spaning many
raster elements


>  | =A0=A0=A0picture\_structure                                      | ur |
>  | =A0=A0=A0sar\_num                                                | ur |
>  | =A0=A0=A0sar\_den                                                | ur |

> @@ -593,10 +597,10 @@ Inferred to be 0 if not present.
>  **slice_y** indicates the y position on the slice raster formed by num_v=
_slices.
>  Inferred to be 0 if not present.
> =20
> -**slice_width** indicates the width on the slice raster.
> +**slice_width** indicates the width on the slice raster formed by num_h_=
slices.

slice_width The width of the slice in slice raster elements
>  Inferred to be 1 if not present.

[...]


--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. U=
ser
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.

--XO/xUml0E8yzr4dJ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc+400ACgkQYR7HhwQLD6uLxwCfZ8k/Ejh8bCccof9hzB4n6lmn
KH0An3RXtUL/8mvsdM3RRkMTTQUkqAGt
=DIeU
-----END PGP SIGNATURE-----

--XO/xUml0E8yzr4dJ--


From nobody Fri May 20 04:20:22 2016
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 3F41512D868 for ; Fri, 20 May 2016 04:20:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 z-luH273kOyk for ; Fri, 20 May 2016 04:20:19 -0700 (PDT)
Received: from 5.mo177.mail-out.ovh.net (5.mo177.mail-out.ovh.net [46.105.39.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C086B12D85F for ; Fri, 20 May 2016 04:20:18 -0700 (PDT)
Received: from player716.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id A77B6FF9277 for ; Fri, 20 May 2016 13:20:16 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player716.ha.ovh.net (Postfix) with ESMTPSA id 0E1EB560079 for ; Fri, 20 May 2016 13:20:15 +0200 (CEST)
To: cellar@ietf.org
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net> <20160517155242.GW25812@nb4>  <20160520101333.GH25812@nb4>
From: Jerome Martinez 
Message-ID: 
Date: Fri, 20 May 2016 13:20:07 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160520101333.GH25812@nb4>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 17505491755293216913
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrfeeggdefiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Replace slice_count because it is not precisely defined
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 20 May 2016 11:20:21 -0000

Le 20/05/2016  12:13, Michael Niedermayer a crit :
> [...]
>>   ffv1.md |   28 +++++++++++++++++-----------
>>   1 file changed, 17 insertions(+), 11 deletions(-)
>> 7010297ac6631ec16f5ea3a4f5fd525b2a47fc54  0001-Replace-slice_count-because-it-is-not-precisely-defi.patch
>> >From cdd324b2db682ecf600890a8b07bda8d32fc28a1 Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
>> Date: Tue, 17 May 2016 18:09:21 +0200
>> Subject: [PATCH] Replace slice_count because it is not precisely defined
>>
>> - remove slice_count definition and replace it by a test about
>> the presence of remaining bytes at the end of the frame
>> - replace "[i]" by "[slice_x][slice_y]"
>> - add byte alignment test
>> - add restrictions about slice_x, slice_y, slice_width,
>> slice_height
>> ---
> please split this in one patch per issue

Will do.

>
>
>>   ffv1.md | 28 +++++++++++++++++-----------
>>   1 file changed, 17 insertions(+), 11 deletions(-)
>>
>> diff --git a/ffv1.md b/ffv1.md
>> index 80e3cf9..8298c6d 100644
>> --- a/ffv1.md
>> +++ b/ffv1.md
>> @@ -153,6 +153,8 @@ __a...b__ means any value starting from a to b, inclusive.
>>   
>>   **remaining\_bits\_in\_bitstream( )** means the count of remaining bits after the current position in the bitstream. It is computed from the NumBytes value multiplied by 8 minus the count of bits already read by the bitstream parser.
>>   
>> +**byte\_aligned( )** means the last parsed bit in the bitstream is the last bit in a byte.
> "last bit in a byte" is unclear

Will change to "means remaining\_bits\_in\_bitstream( ) % 8 is 0" ("%" 
is defined in arithmetic operators)

>
>
>> +
>>   \pagebreak
>>   
>>   # General Description
>> @@ -522,17 +524,17 @@ See [NUT](#references) for more information about elements.
>>   |    keyframe                                       |  br|
>>   |    if( keyframe && !ConfigurationRecordIsPresent )|    |
>>   |         Parameters( )                             |    |
>> -|    for( i = 0; i \< slice\_count; i++ )           |    |
>> -|        Slice( i )                                 |    |
>> +|    while ( remaining_bits_in_bitstream() )        |    |
>> +|        Slice( )                                   |    |
>>   |}                                                  |    |
> has it been tested that this works with both coders ?

Yes. Actually because there is no change impacting the decoding compared 
to previous specification (which was not defining slice_count).
It just clarifies it.

>
> The text should also mention that decoders SHOULD parse slices using
> the slice_size as it allows multthreading and is independant of
> errors within slices

 From my point of view, we describe a bitstream and not how a decoder 
should decode it, so such sentence should not be in the specification: 
we specify a bitstream and we should not try to force a decoder to 
choose one way rather than another one (as the H264 specification does 
not say that a decoder should find slices boundaries before doing the 
decoding). The feature of FFV1 is to permit multithreading, not that 
decoder should do mutlithreading (for various reasons)


>
>
>>   
>>   ## Slice
>>   
>>   |                                                                    |
>>   |------------------------------------------------------------|:------|
>> -|Slice( i ) {                                                | type  |
>> +|Slice( )   {                                                | type  |
>>   |    if( version \> 2 )                                      |       |
>> -|        SliceHeader( i )                                    |       |
>> +|        SliceHeader( )                                      |       |
>>   |    if( colorspace\_type == 0) {                            |       |
>>   |        for( p = 0; p \< primary\_color\_count; p++ ) {     |       |
>>   |            Plane( p )                                      |       |
>> @@ -541,7 +543,9 @@ See [NUT](#references) for more information about elements.
>>   |            for( p = 0; p \< primary\_color\_count; p++ ) { |       |
>>   |                Line( p, y )                                |       |
>>   |    }                                                       |       |
>> -|    if( i \|\| version \> 2 )                               |       |
>> +|    while ( !byte_aligned() )                               |       |
>> +|        padding                                             |  u(1) |
> There is no Description in the spec what "padding" is

I can add something like:
"**padding** bit without any significance and used only for byte alignment"

That said, I am not sure this is needed, the issue is about we switch 
from the range coder to a more classical bit/bytestream.
for the moment, I use br/ur/sr for the range coder and u(n) for the 
classic bitstream.
I would like to have comments/proposals about how to define this switch. 
Is such padding bit info coherent and enough from your point of view?

>
>
>> +|    if( slice_x \|\| slice_y \|\| version \> 2 )            |       |
>>   |        slice\_size                                         | u(24) |
>>   |    if( ec ) {                                              |       |
>>   |        error\_status                                       |  u(8) |
>> @@ -571,13 +575,13 @@ The CRC generator polynom used is the standard IEEE CRC polynom (0x104C11DB7) wi
>>   
>>   |                                                            |    |
>>   |------------------------------------------------------------|---:|
>> -| SliceHeader( i ) {                                         |type|
>> +| SliceHeader( ) {                                           |type|
>>   |    slice\_x                                                | ur |
>>   |    slice\_y                                                | ur |
>>   |    slice\_width - 1                                        | ur |
>>   |    slice\_height - 1                                       | ur |
>>   |    for( j = 0; j \< quant\_table\_index\_count; j++ )      |    |
>> -|        quant\_table\_index [ i ][ j ]                      | ur |
>> +|        quant\_table\_index [ slice\_x ][ slice\_y ][ j ]   | ur |
> This raises an interresting related question
>
> If most arrays are based on slice coordinates in the raster and
> not slices the arrays would become much larger if the entries are
> not conditionally allocated. Theres alot of state per slice
>
> of course this is a spec and not an implementation but implementations
> might follow the wording used in the spec rather closely
>
> This problem should be mentioned in the spec so implementations avoid
> having problems with files with fine rasters and slices spaning many
> raster elements

 From my point of view, the spec should not go to that level, because it 
is optimization. The spec should be clear about what is forbidden and 
this is the reason I added the restriction paragraph. I think that the 
restriction paragraph (copied below for reference) is the answer to this 
question.
In the future, we should think to add profiles with restrictions about 
the count of slices per frame instead of limits about num_h_slices / 
num_v_slices and it will be even more clear.

+For each frame, each position in the slice raster MUST be filled by one and only one slice of the frame (no missing slice position, no slice overlapping).
+
+For each Frame with keyframe value of 0, each slice MUST have the same value of slice\_x, slice\_y, slice\_width, slice\_height as a slice in the previous frame, except if reset\_contexts is 1.
+



[...]


From nobody Fri May 20 04:59:10 2016
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 E203012D8D7 for ; Fri, 20 May 2016 04:59:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 djVRAr4KDybG for ; Fri, 20 May 2016 04:59:06 -0700 (PDT)
Received: from 6.mo177.mail-out.ovh.net (6.mo177.mail-out.ovh.net [46.105.51.249]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E23912D8D5 for ; Fri, 20 May 2016 04:59:05 -0700 (PDT)
Received: from player716.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id 180F9FF9B25 for ; Fri, 20 May 2016 13:59:04 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player716.ha.ovh.net (Postfix) with ESMTPSA id EB0FE56006E for ; Fri, 20 May 2016 13:59:03 +0200 (CEST)
To: cellar@ietf.org
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net> <20160517155242.GW25812@nb4>  <20160520101333.GH25812@nb4>
From: Jerome Martinez 
Message-ID: 
Date: Fri, 20 May 2016 13:58:55 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160520101333.GH25812@nb4>
Content-Type: multipart/mixed; boundary="------------3F144A2217C94FF1615D71AF"
X-Ovh-Tracer-Id: 18160765501253030033
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrfeeggdeghecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Archived-At: 
Subject: [Cellar] [PATCH FFV1] Slice header members restrictions
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 20 May 2016 11:59:08 -0000

This is a multi-part message in MIME format.
--------------3F144A2217C94FF1615D71AF
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit



--------------3F144A2217C94FF1615D71AF
Content-Type: text/plain; charset=UTF-8;
 name="0001-Slice-header-members-restrictions.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="0001-Slice-header-members-restrictions.patch"

>From c0f2da9aa007332ac123bea6ee0159170ef5faa4 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Fri, 20 May 2016 13:48:58 +0200
Subject: [PATCH 1/3] Slice header members restrictions

slice_x, slice_y, slice_width, slice_height restrictions are explicit.
---
 ffv1.md | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/ffv1.md b/ffv1.md
index 80e3cf9..738f68e 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -852,6 +852,10 @@ MAX\_CONTEXT\_INPUTS is 5.
 To ensure that fast multithreaded decoding is possible, starting version 2 and if frame\_width * frame\_height is more than 101376, slice\_width * slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4.
 Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF ("Common Intermediate Format") frame size format.
 
+For each frame, each position in the slice raster MUST be filled by one and only one slice of the frame (no missing slice position, no slice overlapping).
+
+For each Frame with keyframe value of 0, each slice MUST have the same value of slice\_x, slice\_y, slice\_width, slice\_height as a slice in the previous frame, except if reset\_contexts is 1.
+
 # Changelog
 
 See 
-- 
2.7.0.windows.1


--------------3F144A2217C94FF1615D71AF--


From nobody Fri May 20 04:59:40 2016
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 8BCD812D8D5 for ; Fri, 20 May 2016 04:59:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 d98e64LckOcm for ; Fri, 20 May 2016 04:59:36 -0700 (PDT)
Received: from 7.mo177.mail-out.ovh.net (7.mo177.mail-out.ovh.net [46.105.61.149]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4965F12D8DD for ; Fri, 20 May 2016 04:59:33 -0700 (PDT)
Received: from player716.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id DF947FF9B25 for ; Fri, 20 May 2016 13:59:31 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player716.ha.ovh.net (Postfix) with ESMTPSA id C54E85600A8 for ; Fri, 20 May 2016 13:59:31 +0200 (CEST)
To: cellar@ietf.org
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net> <20160517155242.GW25812@nb4>  <20160520101333.GH25812@nb4>
From: Jerome Martinez 
Message-ID: 
Date: Fri, 20 May 2016 13:59:22 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160520101333.GH25812@nb4>
Content-Type: multipart/mixed; boundary="------------CF56B73AECB960360108ACEE"
X-Ovh-Tracer-Id: 18168365322418983057
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrfeeggdeghecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Archived-At: 
Subject: [Cellar] [PATCH FFV1] slice_width and slice_height definition update
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 20 May 2016 11:59:38 -0000

This is a multi-part message in MIME format.
--------------CF56B73AECB960360108ACEE
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit



--------------CF56B73AECB960360108ACEE
Content-Type: text/plain; charset=UTF-8;
 name="0002-slice_width-and-slice_height-definition-update.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="0002-slice_width-and-slice_height-definition-update.patch"

>From 79e1aac0bf021758672524e0e3cbd3c67abca237 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Fri, 20 May 2016 13:50:55 +0200
Subject: [PATCH 2/3] slice_width and slice_height definition update

More coherency with slice_x and slice_y definitions.
---
 ffv1.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ffv1.md b/ffv1.md
index 738f68e..cf26a10 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -593,10 +593,10 @@ Inferred to be 0 if not present.
 **slice_y** indicates the y position on the slice raster formed by num_v_slices.
 Inferred to be 0 if not present.
 
-**slice_width** indicates the width on the slice raster.
+**slice_width** indicates the width on the slice raster formed by num_h_slices.
 Inferred to be 1 if not present.
 
-**slice_height** indicates the height on the slice raster.
+**slice_height** indicates the height on the slice raster formed by num_v_slices.
 Inferred to be 1 if not present.
 
 **quant\_table\_index\_count** is defined as 1 + ( ( chroma_planes || version \< 4 ) ? 1 : 0 ) + ( alpha_plane ? 1 : 0 ).
-- 
2.7.0.windows.1


--------------CF56B73AECB960360108ACEE--


From nobody Fri May 20 05:00:52 2016
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 9466912D8C5 for ; Fri, 20 May 2016 05:00:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 9hHcCskG_5Tk for ; Fri, 20 May 2016 05:00:49 -0700 (PDT)
Received: from 7.mo177.mail-out.ovh.net (7.mo177.mail-out.ovh.net [46.105.61.149]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D45512D5F7 for ; Fri, 20 May 2016 05:00:46 -0700 (PDT)
Received: from player716.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id E1F7BFF9673 for ; Fri, 20 May 2016 14:00:44 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player716.ha.ovh.net (Postfix) with ESMTPSA id C7BBB560092 for ; Fri, 20 May 2016 14:00:44 +0200 (CEST)
To: cellar@ietf.org
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net> <20160517155242.GW25812@nb4>  <20160520101333.GH25812@nb4>
From: Jerome Martinez 
Message-ID: <6ecaa1f5-ac1e-b922-571a-03fc84beadc5@mediaarea.net>
Date: Fri, 20 May 2016 14:00:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160520101333.GH25812@nb4>
Content-Type: multipart/mixed; boundary="------------075C222F28C03D93D6BD1A0D"
X-Ovh-Tracer-Id: 18188912997666853009
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrfeeggdeghecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Archived-At: 
Subject: [Cellar] [PATCH FFV1] Add byte alignment test
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 20 May 2016 12:00:50 -0000

This is a multi-part message in MIME format.
--------------075C222F28C03D93D6BD1A0D
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

Request for comments, as I am not sure it is the best method for a 
switch between Range Coder and classic bitstream.

--------------075C222F28C03D93D6BD1A0D
Content-Type: text/plain; charset=UTF-8;
 name="0003-Add-byte-alignment-test.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename="0003-Add-byte-alignment-test.patch"

>From cbd66f3955c2e6709765250927b2ded46e090b8e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Fri, 20 May 2016 13:55:31 +0200
Subject: [PATCH 3/3] Add byte alignment test

This is a method for defining the switch from a Range Coder parsing
(br/ur/sr) to a classic bitstream parsing (u(n)).
---
 ffv1.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/ffv1.md b/ffv1.md
index cf26a10..d8a9328 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -153,6 +153,8 @@ __a...b__ means any value starting from a to b, inclusive.
 
 **remaining\_bits\_in\_bitstream( )** means the count of remaining bits after the current position in the bitstream. It is computed from the NumBytes value multiplied by 8 minus the count of bits already read by the bitstream parser.
 
+**byte\_aligned( )** means remaining\_bits\_in\_bitstream( ) % 8 is 0.
+
 \pagebreak
 
 # General Description
@@ -541,6 +543,8 @@ See [NUT](#references) for more information about elements.
 |            for( p = 0; p \< primary\_color\_count; p++ ) { |       |
 |                Line( p, y )                                |       |
 |    }                                                       |       |
+|    while ( !byte_aligned() )                               |       |
+|        padding                                             |  u(1) |
 |    if( i \|\| version \> 2 )                               |       |
 |        slice\_size                                         | u(24) |
 |    if( ec ) {                                              |       |
@@ -551,6 +555,8 @@ See [NUT](#references) for more information about elements.
 
 **primary\_color\_count** is defined as 1 + ( chroma_planes ? 2 : 0 ) + ( alpha_plane ? 1 : 0 ).
 
+**padding** specifies a bit without any significance and used only for byte alignment.
+
 **slice_size** indicates the size of the slice in bytes.
 Note: this allows finding the start of slices before previous slices have been fully decoded. And allows this way parallel decoding as well as error resilience.
 
-- 
2.7.0.windows.1


--------------075C222F28C03D93D6BD1A0D--


From nobody Fri May 20 06:25:10 2016
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 DED5712D95F for ; Fri, 20 May 2016 06:25:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 WD20ajyXmT52 for ; Fri, 20 May 2016 06:25:06 -0700 (PDT)
Received: from 2.mo177.mail-out.ovh.net (2.mo177.mail-out.ovh.net [178.33.109.80]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A4C12D961 for ; Fri, 20 May 2016 06:25:05 -0700 (PDT)
Received: from player716.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id 3AF5BFF926C for ; Fri, 20 May 2016 15:25:04 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player716.ha.ovh.net (Postfix) with ESMTPSA id AFDB85600A5 for ; Fri, 20 May 2016 15:25:02 +0200 (CEST)
To: cellar@ietf.org
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net> <20160517155242.GW25812@nb4>  <20160520101333.GH25812@nb4> <6ecaa1f5-ac1e-b922-571a-03fc84beadc5@mediaarea.net>
From: Jerome Martinez 
Message-ID: <85f021e0-e83f-0626-e162-e39e7e5d7d83@mediaarea.net>
Date: Fri, 20 May 2016 15:24:54 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <6ecaa1f5-ac1e-b922-571a-03fc84beadc5@mediaarea.net>
Content-Type: multipart/mixed; boundary="------------A6B1017900A931B9202C20F4"
X-Ovh-Tracer-Id: 1166150831336984721
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrfeeggdeifecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Add byte alignment test
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 20 May 2016 13:25:09 -0000

This is a multi-part message in MIME format.
--------------A6B1017900A931B9202C20F4
Content-Type: multipart/alternative;
 boundary="------------62993F80FA8C7C463AA58FB7"


--------------62993F80FA8C7C463AA58FB7
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

 From a remark I received, I add "MUST be 0".

Le 20/05/2016  14:00, Jerome Martinez a crit :
> Request for comments, as I am not sure it is the best method for a 
> switch between Range Coder and classic bitstream.
>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar



--------------62993F80FA8C7C463AA58FB7
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
From a remark I received, I add "MUST
      be 0".

      

      Le 20/05/2016  14:00, Jerome Martinez a crit:

    

    
Request for comments, as I am not sure it is the best
      method for a switch between Range Coder and classic bitstream.
      

      

      

      

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


    

    


    

  


--------------62993F80FA8C7C463AA58FB7--

--------------A6B1017900A931B9202C20F4
Content-Type: text/plain; charset=UTF-8;
 name="0003-Add-byte-alignment-test.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename="0003-Add-byte-alignment-test.patch"

>From 686345ac408f4f30c4b71b04823ce01a19059d5c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Fri, 20 May 2016 15:00:05 +0200
Subject: [PATCH 3/3] Add byte alignment test

This is a method for defining the switch from a Range Coder parsing
(br/ur/sr) to a classic bitstream parsing (u(n)).
---
 ffv1.md | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/ffv1.md b/ffv1.md
index cf26a10..db149d4 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -153,6 +153,8 @@ __a...b__ means any value starting from a to b, inclusive.
 
 **remaining\_bits\_in\_bitstream( )** means the count of remaining bits after the current position in the bitstream. It is computed from the NumBytes value multiplied by 8 minus the count of bits already read by the bitstream parser.
 
+**byte\_aligned( )** means remaining\_bits\_in\_bitstream( ) % 8 is 0.
+
 \pagebreak
 
 # General Description
@@ -541,6 +543,8 @@ See [NUT](#references) for more information about elements.
 |            for( p = 0; p \< primary\_color\_count; p++ ) { |       |
 |                Line( p, y )                                |       |
 |    }                                                       |       |
+|    while ( !byte_aligned() )                               |       |
+|        padding                                             |  u(1) |
 |    if( i \|\| version \> 2 )                               |       |
 |        slice\_size                                         | u(24) |
 |    if( ec ) {                                              |       |
@@ -551,6 +555,9 @@ See [NUT](#references) for more information about elements.
 
 **primary\_color\_count** is defined as 1 + ( chroma_planes ? 2 : 0 ) + ( alpha_plane ? 1 : 0 ).
 
+**padding** specifies a bit without any significance and used only for byte alignment.
+MUST be 0.
+
 **slice_size** indicates the size of the slice in bytes.
 Note: this allows finding the start of slices before previous slices have been fully decoded. And allows this way parallel decoding as well as error resilience.
 
-- 
2.7.0.windows.1


--------------A6B1017900A931B9202C20F4--


From nobody Fri May 20 09:35:38 2016
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 972FF12D122 for ; Fri, 20 May 2016 09:35:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 m7DKr0G7ypt4 for ; Fri, 20 May 2016 09:35:34 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E972712D17D for ; Fri, 20 May 2016 09:35:33 -0700 (PDT)
Received: from mfilter27-d.gandi.net (mfilter27-d.gandi.net [217.70.178.155]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 4C8CD1720BC for ; Fri, 20 May 2016 18:35:32 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter27-d.gandi.net
Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter27-d.gandi.net (mfilter27-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 56r89HLXFSks for ; Fri, 20 May 2016 18:35:30 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 5B1A21720BD for ; Fri, 20 May 2016 18:35:30 +0200 (CEST)
Date: Fri, 20 May 2016 18:33:17 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160520163317.GI25812@nb4>
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net> <20160517155242.GW25812@nb4>  <20160520101333.GH25812@nb4> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="rcKjJ9iUZvPFJAUK"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Replace slice_count because it is not precisely defined
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 20 May 2016 16:35:37 -0000

--rcKjJ9iUZvPFJAUK
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 20, 2016 at 01:20:07PM +0200, Jerome Martinez wrote:
> Le 20/05/2016 =E0 12:13, Michael Niedermayer a =E9crit :
[...]
> >
> >The text should also mention that decoders SHOULD parse slices using
> >the slice_size as it allows multthreading and is independant of
> >errors within slices
>=20
> From my point of view, we describe a bitstream and not how a decoder
> should decode it, so such sentence should not be in the
> specification: we specify a bitstream and we should not try to force
> a decoder to choose one way rather than another one (as the H264
> specification does not say that a decoder should find slices
> boundaries before doing the decoding). The feature of FFV1 is to
> permit multithreading, not that decoder should do mutlithreading
> (for various reasons)

I dont like the idea that someone follwing the spec and implementing
everyhing it mentions would end up with a decoder that doesnt work
(for some cases like realtime playback of some streams)

One shouldnt need to fully understand everything in a spec and then
twist it backward to end up with a good implementation



>=20
>=20
> >
> >
> >>  ## Slice
> >>  |                                                                    |
> >>  |------------------------------------------------------------|:------|
> >>-|Slice( i ) {                                                | type  |
> >>+|Slice( )   {                                                | type  |
> >>  |    if( version \> 2 )                                      |       |
> >>-|        SliceHeader( i )                                    |       |
> >>+|        SliceHeader( )                                      |       |
> >>  |    if( colorspace\_type =3D=3D 0) {                            |   =
    |
> >>  |        for( p =3D 0; p \< primary\_color\_count; p++ ) {     |     =
  |
> >>  |            Plane( p )                                      |       |
> >>@@ -541,7 +543,9 @@ See [NUT](#references) for more information about e=
lements.
> >>  |            for( p =3D 0; p \< primary\_color\_count; p++ ) { |     =
  |
> >>  |                Line( p, y )                                |       |
> >>  |    }                                                       |       |
> >>-|    if( i \|\| version \> 2 )                               |       |
> >>+|    while ( !byte_aligned() )                               |       |
> >>+|        padding                                             |  u(1) |
> >There is no Description in the spec what "padding" is
>=20
> I can add something like:
> "**padding** bit without any significance and used only for byte alignmen=
t"
>=20
> That said, I am not sure this is needed, the issue is about we
> switch from the range coder to a more classical bit/bytestream.
> for the moment, I use br/ur/sr for the range coder and u(n) for the
> classic bitstream.
> I would like to have comments/proposals about how to define this
> switch. Is such padding bit info coherent and enough from your point
> of view?

our implementation works in bytes, also the specification seems to
work in bytes for the range coder
so iam not sure where this padding comes from if its for RC->VLC


>=20
> >
> >
> >>+|    if( slice_x \|\| slice_y \|\| version \> 2 )            |       |
> >>  |        slice\_size                                         | u(24) |
> >>  |    if( ec ) {                                              |       |
> >>  |        error\_status                                       |  u(8) |
> >>@@ -571,13 +575,13 @@ The CRC generator polynom used is the standard IE=
EE CRC polynom (0x104C11DB7) wi
> >>  |                                                            |    |
> >>  |------------------------------------------------------------|---:|
> >>-| SliceHeader( i ) {                                         |type|
> >>+| SliceHeader( ) {                                           |type|
> >>  |    slice\_x                                                | ur |
> >>  |    slice\_y                                                | ur |
> >>  |    slice\_width - 1                                        | ur |
> >>  |    slice\_height - 1                                       | ur |
> >>  |    for( j =3D 0; j \< quant\_table\_index\_count; j++ )      |    |
> >>-|        quant\_table\_index [ i ][ j ]                      | ur |
> >>+|        quant\_table\_index [ slice\_x ][ slice\_y ][ j ]   | ur |
> >This raises an interresting related question
> >
> >If most arrays are based on slice coordinates in the raster and
> >not slices the arrays would become much larger if the entries are
> >not conditionally allocated. Theres alot of state per slice
> >
> >of course this is a spec and not an implementation but implementations
> >might follow the wording used in the spec rather closely
> >
> >This problem should be mentioned in the spec so implementations avoid
> >having problems with files with fine rasters and slices spaning many
> >raster elements
>=20
> From my point of view, the spec should not go to that level, because
> it is optimization. The spec should be clear about what is forbidden
> and this is the reason I added the restriction paragraph. I think
> that the restriction paragraph (copied below for reference) is the
> answer to this question.
> In the future, we should think to add profiles with restrictions
> about the count of slices per frame instead of limits about
> num_h_slices / num_v_slices and it will be even more clear.
>=20
> +For each frame, each position in the slice raster MUST be filled by one =
and only one slice of the frame (no missing slice position, no slice overla=
pping).
> +
> +For each Frame with keyframe value of 0, each slice MUST have the same v=
alue of slice\_x, slice\_y, slice\_width, slice\_height as a slice in the p=
revious frame, except if reset\_contexts is 1.

it matters for someone implementing the spec if an array could have
10 million entryies with only 100 used or not
that is if you want things to interoperate well then the kind of
values that encoders are allowed to set must be known by the one
writing a decoder
as is its easy for a encoder author to write a raster of 1000x1000
in which a few slices are defined. While a decoder author could easily
think that this doesnt occur and the current implementation also
doesnt produce this so he wouldnt notice when testing

[...]
--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle

--rcKjJ9iUZvPFJAUK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc/PE0ACgkQYR7HhwQLD6uHlQCgmXBtSJ5X/9Y18fQV7VrTELqM
u8oAnAk42GRibxBQwNsnyy6+RP2q6gpq
=b3Yi
-----END PGP SIGNATURE-----

--rcKjJ9iUZvPFJAUK--


From nobody Fri May 20 09:45:17 2016
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 38A2A12DE11 for ; Fri, 20 May 2016 09:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 JpEPvIcOb8ZH for ; Fri, 20 May 2016 09:45:09 -0700 (PDT)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0AD12DE18 for ; Fri, 20 May 2016 09:45:03 -0700 (PDT)
Received: from mfilter30-d.gandi.net (mfilter30-d.gandi.net [217.70.178.161]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 8A8C141C0A8 for ; Fri, 20 May 2016 18:45:01 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter30-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter30-d.gandi.net (mfilter30-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id zrVRWKwJL2AO for ; Fri, 20 May 2016 18:45:00 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 0193141C0AA for ; Fri, 20 May 2016 18:44:59 +0200 (CEST)
Date: Fri, 20 May 2016 18:42:47 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160520164247.GJ25812@nb4>
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net> <20160517155242.GW25812@nb4>  <20160520101333.GH25812@nb4> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IaIPRMtxYixpPwAj"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Slice header members restrictions
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 20 May 2016 16:45:17 -0000

--IaIPRMtxYixpPwAj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 20, 2016 at 01:58:55PM +0200, Jerome Martinez wrote:
>=20

>  ffv1.md |    4 ++++
>  1 file changed, 4 insertions(+)
> 04bc9c65d1240c797956476b50d4e1d12e1c3f88  0001-Slice-header-members-restr=
ictions.patch
> >From c0f2da9aa007332ac123bea6ee0159170ef5faa4 Mon Sep 17 00:00:00 2001
> From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D 
> Date: Fri, 20 May 2016 13:48:58 +0200
> Subject: [PATCH 1/3] Slice header members restrictions
>=20
> slice_x, slice_y, slice_width, slice_height restrictions are explicit.
> ---
>  ffv1.md | 4 ++++
>  1 file changed, 4 insertions(+)

applied

thx

[...]


--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus

--IaIPRMtxYixpPwAj
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc/PocACgkQYR7HhwQLD6tFowCgka+JxOAs8L59zMObK/HH0P0o
ei0An1k3sXekyPp/BEqPM6HxLalyiekx
=Ce7q
-----END PGP SIGNATURE-----

--IaIPRMtxYixpPwAj--


From nobody Fri May 20 11:26:02 2016
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 AB35912D584 for ; Fri, 20 May 2016 11:26:00 -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 VrJfCjwF0Kqc for ; Fri, 20 May 2016 11:25:58 -0700 (PDT)
Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 CD3AF12D56E for ; Fri, 20 May 2016 11:25:58 -0700 (PDT)
Received: from eris.local (dynamic-adsl-84-220-81-12.clienti.tiscali.it [84.220.81.12]) (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 14231340ADB for ; Fri, 20 May 2016 18:25:54 +0000 (UTC)
To: cellar@ietf.org
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net> <20160517155242.GW25812@nb4>  <20160520101333.GH25812@nb4>  <20160520163317.GI25812@nb4>
From: Luca Barbato 
Message-ID: 
Date: Fri, 20 May 2016 20:25:51 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1
MIME-Version: 1.0
In-Reply-To: <20160520163317.GI25812@nb4>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Replace slice_count because it is not precisely defined
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 20 May 2016 18:26:01 -0000

On 20/05/16 18:33, Michael Niedermayer wrote:
> On Fri, May 20, 2016 at 01:20:07PM +0200, Jerome Martinez wrote:
>> Le 20/05/2016  12:13, Michael Niedermayer a crit :
> [...]
>>>
>>> The text should also mention that decoders SHOULD parse slices using
>>> the slice_size as it allows multthreading and is independant of
>>> errors within slices
>>
>> From my point of view, we describe a bitstream and not how a decoder
>> should decode it, so such sentence should not be in the
>> specification: we specify a bitstream and we should not try to force
>> a decoder to choose one way rather than another one (as the H264
>> specification does not say that a decoder should find slices
>> boundaries before doing the decoding). The feature of FFV1 is to
>> permit multithreading, not that decoder should do mutlithreading
>> (for various reasons)
> 
> I dont like the idea that someone follwing the spec and implementing
> everyhing it mentions would end up with a decoder that doesnt work
> (for some cases like realtime playback of some streams)
> 
> One shouldnt need to fully understand everything in a spec and then
> twist it backward to end up with a good implementation

That could be another document or an appendix. Mixing implementation
advises with the bitstream description can result in quite a bit of
confusion.

> our implementation works in bytes, also the specification seems to
> work in bytes for the range coder
> so iam not sure where this padding comes from if its for RC->VLC

Keep in mind that an independent implementer would be legally bound not
to read any code by third parties and might decide that there wouldn't
be any padding in case you end up with some spare bits.

Being explicit or even pedantic doesn't hurt.

lu


From nobody Fri May 20 11:45:26 2016
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 1247312D5FD for ; Fri, 20 May 2016 11:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Level: 
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 lSPhaMgUX2Iz for ; Fri, 20 May 2016 11:45:23 -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 C277912D5C9 for ; Fri, 20 May 2016 11:45:23 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 5CEFCC0F92 for ; Fri, 20 May 2016 18:45:23 +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 VEP7LbiNPBSO for ; Fri, 20 May 2016 18:45:23 +0000 (UTC)
Received: from [10.252.28.103] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 4A99CC0B12 for ; Fri, 20 May 2016 18:45:23 +0000 (UTC)
Message-ID: <573F5B43.8090507@xiph.org>
Date: Fri, 20 May 2016 11:45:23 -0700
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: cellar@ietf.org
References:     <56981134.3080607@xiph.org>  <56990853.4000404@xiph.org> 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Cellar] Clarification on blocks with a negative timecode
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 20 May 2016 18:45:25 -0000

Michael Bradshaw wrote:
> CodecDelay is the duration of the codec-built-in delay in nanoseconds.
> The decoded frames from the beginning of a stream should be discarded
> until CodecDelay duration has passed, and CodecDelay must be subtracted
> from each block timestamp in order to get the presentation timestamp.
> The value should be small so the muxing of tracks with the same
> presentation timestamp are in the same Cluster.

The idea seems pretty reasonable, but I think it's important to be 
precise here. What does "until CodecDelay duration has passed" actually 
mean when "decoded frames" are in units of 1/48,000th of a second, and 
CodecDelay is in nanoseconds? How do you compare times in two different 
units (or derive times in one unit from another)? Are you comparing with 
the timestamp of the start of the frame or the end, and is this even the 
same for audio vs. video?


From nobody Fri May 20 12:46:30 2016
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 9382D12B01C for ; Fri, 20 May 2016 12:46:28 -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, RCVD_IN_MSPIKE_H2=-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 GLm179zY4JlS for ; Fri, 20 May 2016 12:46:27 -0700 (PDT)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE57E12D16F for ; Fri, 20 May 2016 12:46:26 -0700 (PDT)
Received: from mfilter16-d.gandi.net (mfilter16-d.gandi.net [217.70.178.144]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 076A1FB89F for ; Fri, 20 May 2016 21:46:25 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter16-d.gandi.net
Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter16-d.gandi.net (mfilter16-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id mtCMLDjlu33F for ; Fri, 20 May 2016 21:46:23 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 67974FB8A1 for ; Fri, 20 May 2016 21:46:23 +0200 (CEST)
Date: Fri, 20 May 2016 21:44:10 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160520194410.GK25812@nb4>
References: <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net> <20160517155242.GW25812@nb4>  <20160520101333.GH25812@nb4>  <20160520163317.GI25812@nb4> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VuEt896L1IynaGjl"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Replace slice_count because it is not precisely defined
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 20 May 2016 19:46:28 -0000

--VuEt896L1IynaGjl
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 20, 2016 at 08:25:51PM +0200, Luca Barbato wrote:
> On 20/05/16 18:33, Michael Niedermayer wrote:
> > On Fri, May 20, 2016 at 01:20:07PM +0200, Jerome Martinez wrote:
> >> Le 20/05/2016 =E0 12:13, Michael Niedermayer a =E9crit :
> > [...]
> >>>
> >>> The text should also mention that decoders SHOULD parse slices using
> >>> the slice_size as it allows multthreading and is independant of
> >>> errors within slices
> >>
> >> From my point of view, we describe a bitstream and not how a decoder
> >> should decode it, so such sentence should not be in the
> >> specification: we specify a bitstream and we should not try to force
> >> a decoder to choose one way rather than another one (as the H264
> >> specification does not say that a decoder should find slices
> >> boundaries before doing the decoding). The feature of FFV1 is to
> >> permit multithreading, not that decoder should do mutlithreading
> >> (for various reasons)
> >=20
> > I dont like the idea that someone follwing the spec and implementing
> > everyhing it mentions would end up with a decoder that doesnt work
> > (for some cases like realtime playback of some streams)
> >=20
> > One shouldnt need to fully understand everything in a spec and then
> > twist it backward to end up with a good implementation
>=20
> That could be another document or an appendix. Mixing implementation
> advises with the bitstream description can result in quite a bit of
> confusion.

I was also thinking of puting it in another document, didnt think
of an appendix, that might indeed be even better


[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin

--VuEt896L1IynaGjl
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc/aQoACgkQYR7HhwQLD6tBdACdGO/+BlQaWDua87A3h0y64xrY
gc0An1O5p8vl3KTl5RTtM7ANlVrKyITz
=1WEW
-----END PGP SIGNATURE-----

--VuEt896L1IynaGjl--


From nobody Fri May 20 16:11:55 2016
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 D692E12D1B7 for ; Fri, 20 May 2016 16:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 7hr9sTjy3MYn for ; Fri, 20 May 2016 16:11:52 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32A9512D0A5 for ; Fri, 20 May 2016 16:11:52 -0700 (PDT)
Received: from mfilter24-d.gandi.net (mfilter24-d.gandi.net [217.70.178.152]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 5107CA80C7 for ; Sat, 21 May 2016 01:11:50 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter24-d.gandi.net
Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter24-d.gandi.net (mfilter24-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id eLtdYXwdAyLA for ; Sat, 21 May 2016 01:11:48 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id C2C60A80C0 for ; Sat, 21 May 2016 01:11:48 +0200 (CEST)
Date: Sat, 21 May 2016 01:09:35 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160520230935.GL25812@nb4>
References:  <20160513180437.GI25812@nb4>  <20160513215213.GL25812@nb4> <578e3f0b-d27f-47d7-95c8-7de1fd3ef42c@mediaarea.net> <20160517155242.GW25812@nb4>  <20160520101333.GH25812@nb4> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="YboV3ebCI2NnqdfB"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] slice_width and slice_height definition update
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 20 May 2016 23:11:54 -0000

--YboV3ebCI2NnqdfB
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 20, 2016 at 01:59:22PM +0200, Jerome Martinez wrote:
>=20

>  ffv1.md |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> eea29be2530a26d6e845b81d54dd97d8461c3dc5  0002-slice_width-and-slice_heig=
ht-definition-update.patch
> >From 79e1aac0bf021758672524e0e3cbd3c67abca237 Mon Sep 17 00:00:00 2001
> From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D 
> Date: Fri, 20 May 2016 13:50:55 +0200
> Subject: [PATCH 2/3] slice_width and slice_height definition update
>=20
> More coherency with slice_x and slice_y definitions.

applied

thanks

[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Democracy is the form of government in which you can choose your dictator

--YboV3ebCI2NnqdfB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlc/mS8ACgkQYR7HhwQLD6u3mgCfZapHURAgg3diRZU5kl/1mj2L
hHYAniAr1vkuOJ/3RbflF7y0h0vgDeW8
=a8v8
-----END PGP SIGNATURE-----

--YboV3ebCI2NnqdfB--


From nobody Fri May 20 16:36:28 2016
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 CA7C412D662 for ; Fri, 20 May 2016 16:36:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.426
X-Spam-Level: 
X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 AUV2i9H1tf5d for ; Fri, 20 May 2016 16:36:25 -0700 (PDT)
Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 65A7412D0DA for ; Fri, 20 May 2016 16:36:25 -0700 (PDT)
Received: by mail-it0-x234.google.com with SMTP id e62so1297917ita.1 for ; Fri, 20 May 2016 16:36:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=gpZEE3PNlv0ii0egJMAkvw836aQAoCxtSAPrvAU/4Qc=; b=BDW+jrkDBAqKHHMLrtepAhwBnZVzeaL3jYUuJQWldAJYTi3kisJGUVYnic4bYVB4/i Q6efLU3TvCutBY22xx3XFnI5xZXYrDDIqWqp2ZF1/lEzyNdGHzulDFQWITqrVJ4Tn1Jl 4PUqKKAyqQdnj0VS1h53hrRyzG0q9lF33340EeraInQg0XYdN+qWrVOzeewkfgRa1pbE tfAiFFfwKSjsxRG2JtbLfHSyL3alf7qjtAtSe4o+0BH8CZfoYPI7kbJ5pPwumy7N21TW BvmjCdGqV/qxeksrQr+w/lwE5YowFH1hXJviQoDNYgAcU5YK6Jrimp1fhkI1AC7ii1++ RhrA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=gpZEE3PNlv0ii0egJMAkvw836aQAoCxtSAPrvAU/4Qc=; b=lnRhZS+EB2W7KRxxHmTQE+rnaaof7jupNJY56Kb7qn7oS3me+CMVjgixGXVywvgyQW tdHD/O9z/ob1TsXnDD1PnhRddLTxEcBFGtr3tb1vqf6oOKdNZj2uXoLPVZu0w+5dp5ak MIKVVe5zX8pwL63eUHHiFLBX0ofmgo/qtQg94kREYSkjiZUR6jcQ7cxOkr2JU3PmWpQi wKmXytkDvn5aDXL+YdDUcSHNMWHfDzhAie/gXgIca8C9rTuZwc+g7fVZf5MP2pb1cTNn 74mBMDNIpJrTIFIQ0WP2MhkFctYf/rxhNu9S8N9Vp67ri2aSB0cYwUurXfM1jIPo5kQd POTA==
X-Gm-Message-State: AOPr4FUfBjPGnWguLN0106irbs5zxLZey7DpIOA5n+7X3WLJ6HFmSuUArwby1rjOuq9MS0HvnT0TXeXJOrsETerc
X-Received: by 10.36.246.130 with SMTP id u124mr4696098ith.46.1463787384579; Fri, 20 May 2016 16:36:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.7.137 with HTTP; Fri, 20 May 2016 16:36:05 -0700 (PDT)
In-Reply-To: <573F5B43.8090507@xiph.org>
References:     <56981134.3080607@xiph.org>  <56990853.4000404@xiph.org>  <573F5B43.8090507@xiph.org>
From: Michael Bradshaw 
Date: Fri, 20 May 2016 16:36:05 -0700
Message-ID: 
To: cellar@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c03cd9215eb5905334e8ff7
Archived-At: 
Subject: Re: [Cellar] Clarification on blocks with a negative timecode
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 20 May 2016 23:36:27 -0000

--94eb2c03cd9215eb5905334e8ff7
Content-Type: text/plain; charset=UTF-8

Timothy B. Terriberry wrote:
>
> Michael Bradshaw wrote:
>>
>> CodecDelay is the duration of the codec-built-in delay in nanoseconds.
>> The decoded frames from the beginning of a stream should be discarded
>> until CodecDelay duration has passed, and CodecDelay must be subtracted
>> from each block timestamp in order to get the presentation timestamp.
>> The value should be small so the muxing of tracks with the same
>> presentation timestamp are in the same Cluster.
>
> The idea seems pretty reasonable, but I think it's important to be
precise here. What does "until CodecDelay duration has passed" actually
mean when "decoded frames" are in units of 1/48,000th of a second, and
CodecDelay is in nanoseconds? How do you compare times in two different
units (or derive times in one unit from another)? Are you comparing with
the timestamp of the start of the frame or the end, and is this even the
same for audio vs. video?

This is a good question. If CodecDelay is convertible to the sampling rate
without rounding (that is to say, if CodecDelay *  /
1,000,000,000 is an integer), then the answer is trivial as CodecDelay ends
on a frame boundary. But if not, I would be in favor of comparing time
based on the start of the frame and discarding whole frames. And do it
consistently for audio/video/whatever.

I think that's simplest to understand and implement correctly. Arguments
could be made for some other approach, but so far I find this approach the
most logically convincing.

Thoughts/opinions?

--94eb2c03cd9215eb5905334e8ff7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Timothy B. Terriberry wrote:
>
> Michael Brads=
haw wrote:
>>
>> CodecDelay is the duration of the codec-=
built-in delay in nanoseconds.
>> The decoded frames from the begi=
nning of a stream should be discarded
>> until CodecDelay duration=
 has passed, and CodecDelay must be subtracted
>> from each block =
timestamp in order to get the presentation timestamp.
>> The value=
 should be small so the muxing of tracks with the same
>> presenta=
tion timestamp are in the same Cluster.
>
> The idea seems pret=
ty reasonable, but I think it's important to be precise here. What does=
 "until CodecDelay duration has passed" actually mean when "=
decoded frames" are in units of 1/48,000th of a second, and CodecDelay=
 is in nanoseconds? How do you compare times in two different units (or der=
ive times in one unit from another)? Are you comparing with the timestamp o=
f the start of the frame or the end, and is this even the same for audio vs=
. video?

This is a good question. If CodecDelay is convertible to th=
e sampling rate without rounding (that is to say, if CodecDelay * <sampl=
e_rate> / 1,000,000,000 is an integer), then the answer is trivial as Co=
decDelay ends on a frame boundary. But if not, I would be in favor of compa=
ring time based on the start of the frame and discarding whole frames. And =
do it consistently for audio/video/whatever.

I think tha=
t's simplest to understand and implement correctly. Arguments could be =
made for some other approach, but so far I find this approach the most logi=
cally convincing.

Thoughts/opinions?


--94eb2c03cd9215eb5905334e8ff7--


From nobody Sat May 21 17:37:28 2016
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 B82A412D5BF for ; Sat, 21 May 2016 17:37:26 -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 fytrPymZ_0K7 for ; Sat, 21 May 2016 17:37:25 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 2EAD812D13F for ; Sat, 21 May 2016 17:37:25 -0700 (PDT)
Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:48059 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b4HOU-002ops-6W for cellar@ietf.org; Sat, 21 May 2016 20:37:24 -0400
From: Dave Rice 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B706BE7-C5B1-4A02-998F-D94656961C58@dericed.com>
Date: Sat, 21 May 2016 20:37:19 -0400
To: cellar@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
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: [Cellar] notes on Matroska.org's Specification Notes
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 22 May 2016 00:37:27 -0000

Hi all,

These notes are specifically about =
http://matroska.org/technical/specs/notes.html which is now being worked =
on in the Matroska specification repository at =
https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/notes=
.md.

Here are comments and questions according to sections of =
https://github.com/Matroska-Org/matroska-specification/blob/gh-pages/notes=
.md

Beginning of File:

The section notes "An EBML file always starts with 0x1A. The 0x1A makes =
the DOS command "type" ends display. That way you can include ASCII text =
before the EBML data and it can be displayed.=E2=80=9D=20

The concept of appending raw ASCII to the beginning of an EBML file is =
not part of the EBML spec. Is this feature intended to be a EBML feature =
or is it a specific feature of Matroska? Also I note that FFmpeg =
misdetects the format, when ASCII is prepended to the beginning of the =
file. VLC seems to work with ASCII at the beginning of the file. Is this =
feature used? IMHO, allowing potential garbage to be prepended to an =
EMBL or Matroska file should have more constraints if it is allowed.

Block Timecodes:

This section was discussed earlier as it states: "Blocks with a negative =
Raw Timecode are not valid.=E2=80=9D Is this still considered to be =
true?

The phrases =E2=80=9CRaw Timecode=E2=80=9D and =E2=80=9Ctimecode=E2=80=9D =
are mixed here but is there any distinction? =E2=80=A6 Nevermind I see a =
definition of =E2=80=9CRaw Timecode=E2=80=9D later in the notes, I=E2=80=99=
ll re-order that section so that it precedes Block Timecodes.

Default decoded field duration:

The note for this Element says that it "can signal to the displaying =
application how often fields of a video sequence will be available for =
displaying=E2=80=9D. But it is understand this correct the element is =
not about "how often=E2=80=9D the field is available but for what =
default duration it is available. Is this right?

Is this field used at all during playback or it just here to allow for =
quick fps calculations? What are the consequences if this Element =
contains an incorrect value?

An example here uses the phrase "repeat_first_field =3D 1=E2=80=9D, but =
in the context of a Matroska specification I=E2=80=99m not sure what =
this means.

Default Values and EBML Class: I suggest removing these sections and =
consolidating them into the EBML specification. Possibly in their place =
we can have a section which calls out specific parts of the EBML spec to =
read.

Matroska version:

There=E2=80=99s some language in this section about how a file with =
CueRelativePosition (a version 4 Matroska Element) could be used within =
a Matroska file and the DocTypeReadVersion could be set to 2 since  =
CueRelativePosition isn=E2=80=99t essential for playback. I think this =
approach leaves too much up to the judgement of the muxer. Should we =
have an attribute in EBML Schema that defines what DocTypeReadVersion =
should be used for a given Element? For instance, to have an official =
way to say how the use of any Element impacts DocTypeReadVersion?

Mime Types:
"There is no IETF endorsed MIME type for Matroska files.=E2=80=9D
I=E2=80=99m curious how we could propose official MIME Types for =
Matroska.

Segment UID:
Here there=E2=80=99s a recommendation to use a computed MD5 of =E2=80=9Cso=
me data parts of the file=E2=80=9D as a unique id; however this =
doesn=E2=80=99t sounds like a good strategy to make a value that is =
=E2=80=9Cas unique as possible=E2=80=9D.

Table Columns:
I think eventually this can be removed in favor of =
https://github.com/Matroska-Org/ebml-specification/blob/master/specificati=
on.markdown#ebml-schema-element-attributes.

TimecodeScale Rounding:
The last paragraph has a broken link to =
https://www.matroska.org/technical/specs/matroska-tcscale.c. Is this =
needed or can the paragraph be cut?

I reviewed the Specification Notes document and send a pull request at =
https://github.com/Matroska-Org/matroska-specification/pull/12.
This contains two patches:

=
https://github.com/Matroska-Org/matroska-specification/pull/12/commits/fee=
c6f43f289f917cdc7ba34c4e4dcd0dca231ec
cleans up some line breaks, spacing, and url issues from the html to =
markdown conversion.

=
https://github.com/Matroska-Org/matroska-specification/pull/12/commits/fb9=
53df90731b2d56976c61333f4f62524d0ccb4
updates some of the vocabulary to EBML terminology and makes a few =
spelling and grammatical fixes.

Best Regards,
Dave Rice=


From nobody Sat May 21 21:23:25 2016
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 56D8E12D1D7 for ; Sat, 21 May 2016 21:23:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 yiiB0ITP2Y0f for ; Sat, 21 May 2016 21:23:22 -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 A03A312D141 for ; Sat, 21 May 2016 21:23:21 -0700 (PDT)
Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u4M4NIfF031477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sun, 22 May 2016 06:23:18 +0200
Received: from Castor.local (77-56-128-186.dclient.hispeed.ch [77.56.128.186]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u4M4NHUZ014261 for ; Sun, 22 May 2016 06:23:18 +0200
Date: Sun, 22 May 2016 06:23:18 +0200
From: Reto Kromer 
To: cellar@ietf.org
X-Priority: 3
In-Reply-To: <6B706BE7-C5B1-4A02-998F-D94656961C58@dericed.com>
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailer: Mailsmith 2.4 (470)
X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8
X-Antivirus-Code: 0x100000
Archived-At: 
Subject: Re: [Cellar] notes on Matroska.org's Specification Notes
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 22 May 2016 04:23:24 -0000

Dave Rice wrote:

>Mime Types:
>"There is no IETF endorsed MIME type for Matroska files.=E2=80=9D
>I=E2=80=99m curious how we could propose official MIME Types for
>Matroska.

IANA (Internet Assigned Numbers Authority) is the official
authority for the standardisation of media type
classifications:

  https://www.iana.org/assignments/media-types/media-types.xhtml

And they refer to:

  https://tools.ietf.org/html/rfc6838
  https://tools.ietf.org/html/rfc4855

Hope this helps! Reto


From nobody Mon May 23 06:39:00 2016
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 5511512D8E4 for ; Mon, 23 May 2016 06:38:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Level: 
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 bjkL0ZkWlD5X for ; Mon, 23 May 2016 06:38:56 -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 CFC1912D8E0 for ; Mon, 23 May 2016 06:38:56 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 574BEC1A0C for ; Mon, 23 May 2016 13:38:56 +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 sHTSMTlnbu7o for ; Mon, 23 May 2016 13:38:56 +0000 (UTC)
Received: from [172.17.0.83] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 09613C0949 for ; Mon, 23 May 2016 13:38:55 +0000 (UTC)
Message-ID: <574307ED.2050802@xiph.org>
Date: Mon, 23 May 2016 06:38:53 -0700
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: cellar@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Cellar] notes on Matroska.org's Specification Notes
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 23 May 2016 13:38:58 -0000

Reto Kromer wrote:
> IANA (Internet Assigned Numbers Authority) is the official
> authority for the standardisation of media type
> classifications:

Specifically, RFCs which wish to update the IANA registry typically 
include an "IANA Considerations" section with details on what IANA is 
supposed to do.

For examples, see
https://tools.ietf.org/html/rfc5334#section-9 and
https://tools.ietf.org/html/rfc7845#section-10


From nobody Mon May 23 08:42:19 2016
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 8A3D412D99E for ; Mon, 23 May 2016 08:42:18 -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 mBVk8GTBWKe7 for ; Mon, 23 May 2016 08:42:14 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 82DF012D1AD for ; Mon, 23 May 2016 08:41:57 -0700 (PDT)
Received: from [146.96.19.240] (port=31865 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b4rzM-0046jC-BA; Mon, 23 May 2016 11:41:56 -0400
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dave Rice 
In-Reply-To: <574307ED.2050802@xiph.org>
Date: Mon, 23 May 2016 11:41:50 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <643F6DA5-B505-457B-89E9-51F85BD1E0FB@dericed.com>
References:  <574307ED.2050802@xiph.org>
To: cellar@ietf.org
X-Mailer: Apple Mail (2.3112)
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: 
Cc: "Timothy B. Terriberry" 
Subject: Re: [Cellar] notes on Matroska.org's Specification Notes
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 23 May 2016 15:42:18 -0000

> On May 23, 2016, at 9:38 AM, Timothy B. Terriberry  =
wrote:
>=20
> Reto Kromer wrote:
>> IANA (Internet Assigned Numbers Authority) is the official
>> authority for the standardisation of media type
>> classifications:
>=20
> Specifically, RFCs which wish to update the IANA registry typically =
include an "IANA Considerations" section with details on what IANA is =
supposed to do.
>=20
> For examples, see
> https://tools.ietf.org/html/rfc5334#section-9 and
> https://tools.ietf.org/html/rfc7845#section-10

Thanks, is there any preference in the group between focusing mime types =
on EBML or the EBML DocType? Such as:

application/ebml; doctype=3Dmatroska
application/ebml; doctype=3Dwebm

vs

audio/matroska
video/matroska
video/webm

Also what is recommended for .mks?
Dave Rice=


From nobody Mon May 23 14:34:42 2016
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 564F512D587 for ; Mon, 23 May 2016 14:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Level: 
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 X38xGwehX7Sn for ; Mon, 23 May 2016 14:34:39 -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 E1CE112D52A for ; Mon, 23 May 2016 14:34:39 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id 651EFC0BDC for ; Mon, 23 May 2016 21:34:39 +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 Z3buCZ5W_Gp4 for ; Mon, 23 May 2016 21:34:39 +0000 (UTC)
Received: from [10.252.27.93] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 4EC67C09F9 for ; Mon, 23 May 2016 21:34:39 +0000 (UTC)
Message-ID: <5743776F.5090904@xiph.org>
Date: Mon, 23 May 2016 14:34:39 -0700
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: cellar@ietf.org
References:  <574307ED.2050802@xiph.org> <643F6DA5-B505-457B-89E9-51F85BD1E0FB@dericed.com>
In-Reply-To: <643F6DA5-B505-457B-89E9-51F85BD1E0FB@dericed.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Cellar] notes on Matroska.org's Specification Notes
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 23 May 2016 21:34:41 -0000

Dave Rice wrote:
> application/ebml; doctype=matroska
> application/ebml; doctype=webm
>
> vs
>
> audio/matroska
> video/matroska
> video/webm

Speaking as a browser vendor, I think experience has taught us that the 
latter is by-far preferred. The codecs= parameter is bad enough.


From nobody Mon May 23 17:41:28 2016
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 ED35212DAB1 for ; Mon, 23 May 2016 17:41:26 -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 43WXWZIN-iLP for ; Mon, 23 May 2016 17:41:25 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 BADEA12D168 for ; Mon, 23 May 2016 17:41:25 -0700 (PDT)
Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:40130 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b50PU-0004wr-7E for cellar@ietf.org; Mon, 23 May 2016 20:41:24 -0400
From: Dave Rice 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Mon, 23 May 2016 20:41:22 -0400
To: cellar@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
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: [Cellar] can Mandatory Elements be Empty Elements?
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 00:41:27 -0000

Hi all,
I=E2=80=99m not sure if this has been addressed but the EBML =
specification didn=E2=80=99t appear to make this clear. In some cases =
mandatory elements have no default defined, as is the case with =
MuxingApp and WritingApp. For instance here is an empty element for =
MuxingApp: 0x4D8080. Is it valid if an element like this is Empty? When =
I create an empty mandatory element that has no defined default, =
mkvalidator seem to mind.
Dave Rice=


From nobody Mon May 23 17:59:25 2016
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 A2D3412DBB7 for ; Mon, 23 May 2016 17:59:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 zX1u-y9djDpq for ; Mon, 23 May 2016 17:59:23 -0700 (PDT)
Received: from mail-ig0-x234.google.com (mail-ig0-x234.google.com [IPv6:2607:f8b0:4001:c05::234]) (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 DC91612D0A5 for ; Mon, 23 May 2016 17:59:22 -0700 (PDT)
Received: by mail-ig0-x234.google.com with SMTP id u5so6452525igk.1 for ; Mon, 23 May 2016 17:59:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HJnV5TY29eb0dCfAdT593wgdj0naZqqB8oxWuBa20vE=; b=UF61cP0TIYkHP1KkOWhvfS2+mneGzs7dXt/99oY0+urI+DCos3No9Rj+p4DIpffy3c WU/KRgyHaupI5/h0N+HN6FWaOdNRSfle+3gcCp6Mazj/W42YlaOr6F0Lj2Iz3WXKsK67 fD+gnT44ze1WEvR4rwiyWF/fNUK2ZSi+OyvFkzmYG+jrg6ZTf2wdMSoxAmJhFLdhz4NZ 0ptGaDl0DJBJEGLgsQiHJ4/m8s0WtcMk3IuBAsUgQVRpzIthrvSsE/wxJDtPXGbbTIbg qu8eoN4a+XvF1s8n+6V0fxM0OESPO/pQoFT77o3EEAuIrDb/FtGCk3/dxThVM1fB8OGE f/3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HJnV5TY29eb0dCfAdT593wgdj0naZqqB8oxWuBa20vE=; b=IfMFd/Db4l1BKPIDGB5Ms2LWuf0o8Us1iBuY+1877IjzKWzus+sTiuFtr+pKJVbXWR MuEgOf/OJ1t3DSjP/LGZYmpdC6/Yr4ugd2BJPXy8TUuWhYlmFuCkUIsmtO5/5uszq4Ps t/XSycpm7U15lZgtAyLezSsN9Gu0zjka7txJWzDshMWHROh8oC61d8nIgcCINkxiKwvh hGz1aOx0bxXs6S/udKT34kEo/b6LqZpoDAvfbsUujDaCy63hoYh8JqA87qdRyyrafWzI UNTwbEkcqUkWaJxOr8VBO6d8tSOOK5DFso6xVjQ7UH99MNBZcqhmV+o/38/gPANWA26p 1GYA==
X-Gm-Message-State: AOPr4FUuwoidUFPL0Le5bYQaGcLkFktNmaby77vZWFme+2rmCuHIJhGK7n/8sfmnPauvfLSbYzozLiSu/ES4hTRO
X-Received: by 10.50.140.193 with SMTP id ri1mr15588688igb.60.1464051562127; Mon, 23 May 2016 17:59:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.15.22 with HTTP; Mon, 23 May 2016 17:59:02 -0700 (PDT)
In-Reply-To: 
References: 
From: Michael Bradshaw 
Date: Mon, 23 May 2016 17:59:02 -0700
Message-ID: 
To: Dave Rice 
Content-Type: multipart/alternative; boundary=001a1132fe084b90f505338c1179
Archived-At: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] can Mandatory Elements be Empty Elements?
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 00:59:24 -0000

--001a1132fe084b90f505338c1179
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, May 23, 2016 at 5:41 PM, Dave Rice  wrote:

> Hi all,
> I=E2=80=99m not sure if this has been addressed but the EBML specificatio=
n didn=E2=80=99t
> appear to make this clear. In some cases mandatory elements have no defau=
lt
> defined, as is the case with MuxingApp and WritingApp. For instance here =
is
> an empty element for MuxingApp: 0x4D8080. Is it valid if an element like
> this is Empty? When I create an empty mandatory element that has no defin=
ed
> default, mkvalidator seem to mind.


>From the current reading, mandatory elements should be able to be empty
elements. In this situation, for UTF-8/String elements, the EBML spec says
the elements may declare any length from zero to `VINTMAX`, so an empty
value for MuxingApp/WritingApp should be considered as valid.

--001a1132fe084b90f505338c1179
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, May 23, 2016 at 5:41 PM, Dave Rice <dave@dericed.com> wrote:
Hi all,

I=E2=80=99m not sure if this has been addressed but the EBML specification =
didn=E2=80=99t appear to make this clear. In some cases mandatory elements =
have no default defined, as is the case with MuxingApp and WritingApp. For =
instance here is an empty element for MuxingApp: 0x4D8080. Is it valid if a=
n element like this is Empty? When I create an empty mandatory element that=
 has no defined default, mkvalidator seem to mind.

From the current reading, mandatory elements should be able to be e=
mpty elements. In this situation, for=C2=A0UTF-8/String elements, the EBML =
spec says the elements may declare any length from zero to `VINTMAX`, so an=
 empty value for MuxingApp/WritingApp should be considered as valid.
<=
/div>


--001a1132fe084b90f505338c1179--


From nobody Mon May 23 18:03:28 2016
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 D369012D151 for ; Mon, 23 May 2016 18:03:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.186
X-Spam-Level: 
X-Spam-Status: No, score=0.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, TRACKER_ID=1.306] 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 9helEucUyEIX for ; Mon, 23 May 2016 18:03:25 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 2BEC912D0A5 for ; Mon, 23 May 2016 18:03:25 -0700 (PDT)
Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:40394 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b50kk-000T1S-Sw; Mon, 23 May 2016 21:03:24 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_F7409F70-AC9B-4623-85E5-133481332E52"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dave Rice 
In-Reply-To: 
Date: Mon, 23 May 2016 21:03:21 -0400
Message-Id: <9746989A-2BBF-4F08-BA48-99BEDF7A56E7@dericed.com>
References:  
To: Michael Bradshaw 
X-Mailer: Apple Mail (2.3124)
X-OutGoing-Spam-Status: No, score=-1.6
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: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] can Mandatory Elements be Empty Elements?
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 01:03:27 -0000

--Apple-Mail=_F7409F70-AC9B-4623-85E5-133481332E52
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On May 23, 2016, at 8:59 PM, Michael Bradshaw  =
wrote:
>=20
> On Mon, May 23, 2016 at 5:41 PM, Dave Rice > wrote:
> Hi all,
> I=E2=80=99m not sure if this has been addressed but the EBML =
specification didn=E2=80=99t appear to make this clear. In some cases =
mandatory elements have no default defined, as is the case with =
MuxingApp and WritingApp. For instance here is an empty element for =
MuxingApp: 0x4D8080. Is it valid if an element like this is Empty? When =
I create an empty mandatory element that has no defined default, =
mkvalidator seem to mind.
>=20
> =46rom the current reading, mandatory elements should be able to be =
empty elements. In this situation, for UTF-8/String elements, the EBML =
spec says the elements may declare any length from zero to `VINTMAX`, so =
an empty value for MuxingApp/WritingApp should be considered as valid.

Thanks. I agree. With all the requirements, this is the smallest valid =
Matroska file. Only 21 bytes!

0x1A45DFA380185380678B1549A966864D8080574180

The smallest valid webm file would be a little larger.

Dave Rice=

--Apple-Mail=_F7409F70-AC9B-4623-85E5-133481332E52
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On May 23, 2016, at 8:59 PM, Michael Bradshaw <mjbshaw@google.com> =
wrote:

On Mon, May 23, 2016 at 5:41 PM, Dave Rice <dave@dericed.com> wrote:
Hi all,

I=E2=80=99m not sure if this has been addressed but the EBML =
specification didn=E2=80=99t appear to make this clear. In some cases =
mandatory elements have no default defined, as is the case with =
MuxingApp and WritingApp. For instance here is an empty element for =
MuxingApp: 0x4D8080. Is it valid if an element like this is Empty? When =
I create an empty mandatory element that has no defined default, =
mkvalidator seem to mind.

=46rom the current reading, mandatory =
elements should be able to be empty elements. In this situation, =
for UTF-8/String elements, the EBML spec says the elements may =
declare any length from zero to `VINTMAX`, so an empty value for =
MuxingApp/WritingApp should be considered as =
valid.



Thanks. I agree. =
With all the requirements, this is the smallest valid Matroska file. =
Only 21 bytes!

0x1A45DFA380185380678B1549A966864D8080574180

The smallest valid webm =
file would be a little larger.

Dave Rice
=

--Apple-Mail=_F7409F70-AC9B-4623-85E5-133481332E52--


From nobody Mon May 23 20:07:23 2016
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 469E312D604 for ; Mon, 23 May 2016 20:07:21 -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 6IhTgcTbHM79 for ; Mon, 23 May 2016 20:07:18 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 A8B3212D5FC for ; Mon, 23 May 2016 20:07:17 -0700 (PDT)
Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:34002 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b52gY-003Kd2-74 for cellar@ietf.org; Mon, 23 May 2016 23:07:16 -0400
From: Dave Rice 
Content-Type: multipart/alternative; boundary="Apple-Mail=_7D1152E7-EA99-4CD0-919F-F624926099F7"
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Date: Mon, 23 May 2016 23:07:07 -0400
References: <1687ED1D-AF44-4BC5-B1E5-89F2CD7440E7@dericed.com> <13C43671-E7FC-4011-B759-0E4F0E003D98@dericed.com>
To: cellar@ietf.org
In-Reply-To: <13C43671-E7FC-4011-B759-0E4F0E003D98@dericed.com>
X-Mailer: Apple Mail (2.3124)
X-OutGoing-Spam-Status: No, score=-2.6
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 Ordering Guidelines
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 03:07:21 -0000

--Apple-Mail=_7D1152E7-EA99-4CD0-919F-F624926099F7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi all,

> On May 18, 2016, at 11:08 PM, Dave Rice  wrote:
>=20
>>=20
>> On Feb 27, 2016, at 4:02 PM, Dave Rice > wrote:
>>=20
>> Hi all,
>> I'm reviewing the documentation at =
https://matroska.org/technical/order/index.html =
 and have some =
questions and comments.
>>=20
>> The Order Guidelines say
>>> Matroska only needs a few level 1 elements to be playable: Segment =
Info, Track Info, Clusters. These elements have to be present in a =
Matroska file.
>>=20
>> However, the specdata.xml lists Info as the only mandatory Level 1 =
Matroska Element. =46rom specdata.xml it appears that a Matroska can be =
valid even without Tracks or Clusters Level 1 Elements. So are Level 1 =
Track and Cluster elements mandatory or not. Should there be a =
distinction between a =E2=80=9Cplayable Matroska=E2=80=9D and a =
=E2=80=9Cnon-playable Matroksa=E2=80=9D?
>>=20
>> This sentence:
>>> All the other elements can be omitted although Cues (index) improve =
the playback experience greatly.
>>=20
>> seems far too broad. I suspect that it should be "All the other Level =
1 elements...".
>>=20
>> Regarding,
>>> After a Matroska file has been created it may still be edited. For =
example chapters, tags or cover art attachments can be added. To do that =
the Meta Seek needs to be updated and also some elements may be voided =
or extended.
>>=20
>> These sentences imply that if Chapters, Tags, or Attachments are aded =
then MetaSeek is mandatory, but is this true? Also IIRC MetaSeek doesn't =
need to reference all Level 1 elements, so Attachments could be added =
without creating or updating MetaSeek?
>>=20
>> Regarding,
>>> When 1 Meta Seek Head is present, it should be the first element in =
a Segment=E2=80=A6
>>=20
>> Is this true? If MetaSeek is present a MetaSeek element MUST be the =
first element of the Segment? This conflicts with the rules for CRC =
which must also be first.
>>=20
>> Regarding:
>>> The second Meta Seek is placed at the end and contains a lengthy =
list of all Clusters (and not the other level 1 elements).
>>=20
>> To clarify if a second MetaSeek is used under Segment than it must be =
the last element of the Segment? If the second MetaSeek is used it can =
only reference Clusters and not any other level 1 element? I thought =
that a second MetaSeek could be used to list any other type of level 1 =
element that didn't fit in the first existing MetaSeek to avoid =
rewrites. Which is true? Also is a third or greater MetaSeek element =
ever allowed?
>>=20
>> Regarding
>>> Placing the first Meta Seek Head other than the first position of =
the Segment would make it a lot less useful So it must be the =
first element of a Cluster.
>>=20
>> I think this should read "be the first element of a Cluster=E2=80=9D, =
right?
>>=20
>> Regarding:
>>> So the Cues should always be written after the Clusters. =
However the Cues could also appear at the =
front.
>>=20
>> I'm confused by the way this is written. In what cases should Cues be =
written before or after Cluster?
>>=20
>> Overall the documentation seems to suggest that multiple different =
elements all belong at the "end". Does the "end" mean "the last Level 1 =
element" or simply "after the last Cluster element=E2=80=9D?
>=20
> Now that the Matroska Ordering Guidelines is in the =
matroska-specification repo, I wrote a pull request to update the =
existing documentation to use the vocabulary style of the EBML =
specification. This is probably most easily reviewed in this layout on =
GitHub =
https://github.com/Matroska-Org/matroska-specification/pull/11/files?short=
_path=3De54a0c6#diff-e54a0c68b10a172d7d578cd64ffbbc82 =
 though this view =
is also available =
https://github.com/Matroska-Org/matroska-specification/pull/11/files =
. =
To summarize I capitalized =E2=80=98Element=E2=80=99 as tilde-quoted the =
Element names. I also changed reference to Level 1 Elements to =
=E2=80=9CTop-Level Elements=E2=80=9D which is specifically defined in =
the EBML Specification.
>=20
> The SeekHead Element is often referred to as =E2=80=9CMeta Seek=E2=80=9D=
, I changed much of this to SeekHead, but is there a preference or =
distinction between these two terms?

I started a rewrite of the Matroska Ordering Guideilnes in order to =
correct and clarify the recommendations and mandates of the section. =
I=E2=80=99ll include the updated text below and it is also reviewable as =
a pull request at =
https://github.com/Matroska-Org/matroska-specification/pull/16. Because =
this is a rewrite, it is difficult to diff, but please review what parts =
are deleted. This link is probably the most readable diff: =
https://github.com/Matroska-Org/matroska-specification/pull/16/commits/9fd=
95b3a0ad75ee49ac56b9f09efbebb7c08f1e3. Overall I=E2=80=99ve intended to =
keep the same meaning but form it more clearly, but this needs a review.

In addition to a rewrite I added a few more recommendations or mandates =
which include:

- "The Matroska specification recommends that `CRC-32` Elements SHOULD =
NOT be used as an immediate Child Element of the `Segment` Element=E2=80=9D=
. The EBML spec permits CRC-32 within Level 0 Elements and I=E2=80=99ve =
seen files before with CRC-32 as a Child Element of the EBML Header.

The `Info` Element doesn=E2=80=99t have it=E2=80=99s own ordering =
suggestions but the `Chapters` Element section infers it, so I added an =
`Info` ordering section based on what is inferred.

I removed use of gendered pronouns about the user.

Some questions:

I=E2=80=99m confused about the mandates of referencing `Clusters` in =
`SeekHead`. Is it required that ALL Cluster are referenced by the =
`SeekHead` Element(s)? Or is only the first Cluster a mandate and the =
rest of the Clusters suggested? If two `SeekHead` Elements are used, is =
the first `SeekHead` allowed to reference all `Cluster` Element?

The EBML specification gives a distinction between Level 1 Elements and =
Top-Level Elements in that Top-Level Elements are Elements that may only =
occur at Level 1. Thus CRC-32 and Void (as global elements) are not =
considered Top-Level Elements. If Void and CRC-32 are used at Level 1, =
is it clear that these Elements do not have to be referenced in the =
SeekHead Element(s)?

I=E2=80=99m also realizing that in the EBML specification we should =
clarify that the Child Elements of the EBML Header are not considered =
Top-Level Elements even though they are defined only at Level 1.

I=E2=80=99d like to verify that it is a requirement that the second =
`SeekHead`, if used, only contain reference to `Cluster` Elements. For =
instance if the first `SeekHead` is not followed by some padding, then =
this requirement makes it difficult to edit a file (to add an =
attachment, tags, or chapters) without re-writing most of it.

We should recommend a certain amount of padding to follow the first =
SeekHead. Any recommendations?

The recommendations about the `Cues` Element placement seemed =
contradictory (should be at the end, but could be at the beginning), so =
I revised this a bit. However I think this section should more clearly =
explain the advantages and disadvantages of storing the Cues Element =
near the beginning or near the end. Any advice?

Any existing good documentation on Ordered Chapters?

The Tags ordering section suggests that if a Tags Element is at the =
beginning of the file and needs to be edited/expanded, then the Tags =
Element can be Voided, and a new one written at the end. But the Tags =
Element is allowed to occur multiple times. If someone is just added a =
new tag, could the new Tags Element just be written at the end of the =
Segment and the first Tags element left as is?

And now here=E2=80=99s a darft rewrite of the section on ordering =
requirements within Matroska:

---
layout: default
---
Except for the EBML Header and the CRC-32 Element, the EBML =
specification does not require any particular storage order for =
Elements. The Matroska specification however defines mandates and =
recommendations for the ordering certain Elements in order facilitate =
better playback, seeking, and editing efficiency. This section describes =
and offers rationale for ordering requirements and recommendations for =
Matroska.

# Top-Level Elements

A valid Matroska file requires only one Top-Level Element, the `Info` =
Element; however, to be playable Matroska MUST also contain at least one =
`Tracks` and `Cluster` Element. The first `Info` Element and the first =
`Tracks` Element MUST either be stored before the first `Cluster` =
Element or both be referenced by a `SeekHead` Element which occurs =
before the first `Cluster` Element.

After a Matroska file has been created it may still be edited. For =
example chapters, tags or attachments may be added. When new Top-Level =
Elements are added to a Matroska file the `SeekHead` Element(s) MUST be =
updated so that the `SeekHead` Element(s) itemize the identify and =
position of all Top-Level Elements. Editing, removing, or adding =
Elements to a Matroska file often requires that some existing Elements =
be voided or extended; therefore, it is recommended to use Void Elements =
as padding in between Top-Level Elements.

# CRC-32

As noted by the EBML specification, if a `CRC-32` Element is used then the `CRC-32` =
Element MUST be the first ordered Element within its Parent Element. The =
Matroska specification recommends that `CRC-32` Elements SHOULD NOT be =
used as an immediate Child Element of the `Segment` Element; however all =
Top-Level Elements of an EBML Document SHOULD include a CRC-32 Element =
as a Child Element.

## SeekHead

If used, the first `SeekHead` Element SHOULD be the first non-`CRC-32` =
Child Element of the `Segment` Element. If a second `SeekHead` Element =
is used then the first `SeekHead` MUST reference the identity and =
position of the second `SeekHead`, the second `SeekHead` MUST only =
reference `Cluster` Elements and not any other Top-Level Element, and =
the second `SeekHead` MAY be stored in any order relative to the other =
Top-Level Elements. Whether one or two `SeekHead` Elements is used, the =
`SeekHead` Element(s) MUST reference the identify and position of all =
Top-Level Elements except for the first `SeekHead`.

It is recommended that the first `SeekHead` Element be followed by some =
padding (a `Void` Element) to allow for the `SeekHead` Element to be =
expanded to cover new Top-Level Elements that may be added to the =
Matroska file, such as `Tags`, `Chapters` and `Attachments` Elements.

## Cues (index)

The `Cues` Element is recommended to optimize seeking access in =
Matroska. It is programmatically simpler to add the `Cues` Element after =
all of the `Cluster` Elements are written because this does not require =
a prediction of how much space to reserve before writing the `Cluster` =
Elements. On the other hand, storing the `Cues` Element before the =
`Clusters` can provide some seeking advantages.

## Info

The first `Info` Element SHOULD occur before the first `Tracks` and =
first `Cluster` Element.

## Chapters

The `Chapters` Element SHOULD be placed before the `Cluster` Element(s). =
The `Chapters` Element can be used during playback even if the user =
doesn't need to seek. It immediately gives the user information of what =
section is being read and what other sections are available. In the case =
of Ordered Chapters it recommended to evaluate the logical linking even =
before starting playing anything. The `Chapters` Element SHOULD be =
placed before the first `Tracks` Element and after the first `Info` =
Element.

## Attachments

The `Attachments` Element is not meant to use by default when playing =
the file, but may contain the cover art and/or fonts. Cover art is =
useful even before the file is played and fonts may be needed before =
playback starts for initialization of subtitles that may use them. The =
`Attachments` Element MAY be placed before the first `Cluster` Element; =
however if the `Attachments` Element is likely to be edited, then it =
SHOULD be placed after the last `Cluster` Element.

## Tags

The `Tags` Element is the one that is most subject to changes after the =
file was originally created. So for easier editing the `Tags` Element =
SHOULD be placed at the end of the `Segment` Element, even after the =
`Attachments` Element. On the other hand, it is inconvenient to have to =
seek in the `Segment` for tags especially for network streams. So it's =
better if the `Tags` Element(s) are found early in the stream. When =
editing the `Tags` Element(s), the original `Tags` Element at the =
beginning can be voided =
and a new one written right at the end of the =
`Segment` Element. The file size will only marginally change.

## Optimum layout from a muxer

* SeekHead
* Info
* Tracks
* Chapters
* Attachments
* Tags
* Clusters
* Cues

## Optimum layout after editing tags

* SeekHead
* Info
* Tracks
* Chapters
* Attachments
* Void
* Clusters
* Cues
* Tags

## Optimum layout with Cues at the front
* SeekHead
* Info
* Tracks
* Chapters
* Attachments
* Tags
* Cues
* Clusters

# Cluster Timecode

As each `BlockGroup` and `SimpleBlock` of a `Cluster` Element needs the =
Cluster `Timecode`, the `Timecode` Element MUST occur as the first Child =
Element within the `Cluster` Element.

Comments welcome in this thread of in the pull request, such as line =
comments on =
https://github.com/Matroska-Org/matroska-specification/pull/16/commits/9fd=
95b3a0ad75ee49ac56b9f09efbebb7c08f1e3.

Best Regards,
Dave Rice=

--Apple-Mail=_7D1152E7-EA99-4CD0-919F-F624926099F7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Hi all,

On May 18, 2016, at 11:08 PM, =
Dave Rice <dave@dericed.com> wrote:


On =
Feb 27, 2016, at 4:02 PM, Dave Rice <dave@dericed.com> =
wrote:

Hi all,
I'm reviewing the =
documentation at https://matroska.org/technical/order/index.html and =
have some questions and comments.

The =
Order Guidelines say
Matroska only needs a few level 1 elements to be playable: =
Segment Info, Track Info, Clusters. These elements have to be present in =
a Matroska file.
However, the =
specdata.xml lists Info as the only mandatory Level 1 Matroska Element. =
=46rom specdata.xml it appears that a Matroska can be valid even without =
Tracks or Clusters Level 1 Elements. So are Level 1 Track and Cluster =
elements mandatory or not. Should there be a distinction between a =
=E2=80=9Cplayable Matroska=E2=80=9D and a =E2=80=9Cnon-playable =
Matroksa=E2=80=9D?

This=
 sentence:
All =
the other elements can be omitted although Cues (index) improve the =
playback experience greatly.
seems far =
too broad. I suspect that it should be "All the other Level 1 =
elements...".

Regarding,
After a Matroska file has been created it may still be =
edited. For example chapters, tags or cover art attachments can be =
added. To do that the Meta Seek needs to be updated and also some =
elements may be voided or extended.
These sentences imply that if Chapters, Tags, or Attachments =
are aded then MetaSeek is mandatory, but is this true? Also IIRC =
MetaSeek doesn't need to reference all Level 1 elements, so Attachments =
could be added without creating or updating MetaSeek?

Regarding,
When 1 Meta Seek Head is =
present, it should be the first element in a =
Segment=E2=80=A6
Is this true? If =
MetaSeek is present a MetaSeek element MUST be the first element of the =
Segment? This conflicts with the rules for CRC which must also be =
first.

Regarding:
The second Meta Seek is placed at the end and contains a =
lengthy list of all Clusters (and not the other level 1 =
elements).
To clarify if a second =
MetaSeek is used under Segment than it must be the last element of the =
Segment? If the second MetaSeek is used it can only reference Clusters =
and not any other level 1 element? I thought that a second MetaSeek =
could be used to list any other type of level 1 element that didn't fit =
in the first existing MetaSeek to avoid rewrites. Which is true? Also is =
a third or greater MetaSeek element ever allowed?

Regarding
Placing the first Meta =
Seek Head other than the first position of the Segment would make it a =
lot less useful So it <em>must</em> be the first element of =
a Cluster.
I think this should read =
"be the first element of a Cluster=E2=80=9D, right?

Regarding:
So the Cues =
<em>should</em> always be written after the Clusters. =
However the <a href=3D"#cues_front">Cues could also appear at the =
front</a>.
I'm confused by the =
way this is written. In what cases should Cues be written before or =
after Cluster?

Overall =
the documentation seems to suggest that multiple different elements all =
belong at the "end". Does the "end" mean "the last Level 1 element" or =
simply "after the last Cluster =
element=E2=80=9D?

Now that the Matroska =
Ordering Guidelines is in the matroska-specification repo, I wrote a =
pull request to update the existing documentation to use the vocabulary =
style of the EBML specification. This is probably most easily reviewed =
in this layout on GitHub https://github.com/Matroska-Org/matroska-specification/pull/11/=
files?short_path=3De54a0c6#diff-e54a0c68b10a172d7d578cd64ffbbc82 =
though this view is also available https://github.com/Matroska-Org/matroska-specification/pull/11/=
files. To summarize I capitalized =E2=80=98Element=E2=80=99 as =
tilde-quoted the Element names. I also changed reference to Level 1 =
Elements to =E2=80=9CTop-Level Elements=E2=80=9D which is specifically =
defined in the EBML Specification.

The SeekHead Element is often referred to as =E2=80=9CMet=
a Seek=E2=80=9D, I changed much of this to SeekHead, but is there a =
preference or distinction between these two =
terms?

I started a =
rewrite of the Matroska Ordering Guideilnes in order to correct and =
clarify the recommendations and mandates of the section. I=E2=80=99ll =
include the updated text below and it is also reviewable as a pull =
request at https://github.com/Matroska-Org/matroska-specification/pull/16<=
/a>. Because this is a rewrite, it is difficult to diff, but please =
review what parts are deleted. This link is probably the most readable =
diff: https://github.com/Matroska-Org/matroska-specification/pull/16/=
commits/9fd95b3a0ad75ee49ac56b9f09efbebb7c08f1e3. Overall I=E2=80=99ve=
 intended to keep the same meaning but form it more clearly, but this =
needs a review.

In addition to a =
rewrite I added a few more recommendations or mandates which =
include:

- "The Matroska =
specification recommends that `CRC-32` Elements SHOULD NOT be used as an =
immediate Child Element of the `Segment` Element=E2=80=9D. The EBML spec =
permits CRC-32 within Level 0 Elements and I=E2=80=99ve seen files =
before with CRC-32 as a Child Element of the EBML Header.

The `Info` Element doesn=E2=80=99t have it=E2=80=99s=
 own ordering suggestions but the `Chapters` Element section infers it, =
so I added an `Info` ordering section based on what is =
inferred.

I removed use of gendered =
pronouns about the user.

Some =
questions:

I=E2=80=
=99m confused about the mandates of referencing `Clusters` in =
`SeekHead`. Is it required that ALL Cluster are referenced by the =
`SeekHead` Element(s)? Or is only the first Cluster a mandate and the =
rest of the Clusters suggested? If two `SeekHead` Elements are used, is =
the first `SeekHead` allowed to reference all `Cluster` =
Element?

The =
EBML specification gives a distinction between Level 1 Elements and =
Top-Level Elements in that Top-Level Elements are Elements that may only =
occur at Level 1. Thus CRC-32 and Void (as global elements) are not =
considered Top-Level Elements. If Void and CRC-32 are used at Level 1, =
is it clear that these Elements do not have to be referenced in the =
SeekHead Element(s)?

I=E2=80=99m also realizing that in the EBML specification we =
should clarify that the Child Elements of the EBML Header are not =
considered Top-Level Elements even though they are defined only at Level =
1.

I=E2=80=99d =
like to verify that it is a requirement that the second `SeekHead`, if =
used, only contain reference to `Cluster` Elements. For instance if the =
first `SeekHead` is not followed by some padding, then this requirement =
makes it difficult to edit a file (to add an attachment, tags, or =
chapters) without re-writing most of it.

We should recommend a certain amount of =
padding to follow the first SeekHead. Any recommendations?

The recommendations =
about the `Cues` Element placement seemed contradictory (should be at =
the end, but could be at the beginning), so I revised this a bit. =
However I think this section should more clearly explain the advantages =
and disadvantages of storing the Cues Element near the beginning or near =
the end. Any advice?

Any existing good documentation on Ordered =
Chapters?

The =
Tags ordering section suggests that if a Tags Element is at the =
beginning of the file and needs to be edited/expanded, then the Tags =
Element can be Voided, and a new one written at the end. But the Tags =
Element is allowed to occur multiple times. If someone is just added a =
new tag, could the new Tags Element just be written at the end of the =
Segment and the first Tags element left as is?

And now here=E2=80=99s a darft rewrite =
of the section on ordering requirements within Matroska:

---
layout: default
---
Except for the EBML Header and the =
CRC-32 Element, the EBML specification does not require any particular =
storage order for Elements. The Matroska specification however defines =
mandates and recommendations for the ordering certain Elements in order =
facilitate better playback, seeking, and editing efficiency. This =
section describes and offers rationale for ordering requirements and =
recommendations for Matroska.

# Top-Level Elements

A valid Matroska file =
requires only one Top-Level Element, the `Info` Element; however, to be =
playable Matroska MUST also contain at least one `Tracks` and `Cluster` =
Element. The first `Info` Element and the first `Tracks` Element MUST =
either be stored before the first `Cluster` Element or both be =
referenced by a `SeekHead` Element which occurs before the first =
`Cluster` Element.

After a Matroska file has been created it may still be =
edited. For example chapters, tags or attachments may be added. When new =
Top-Level Elements are added to a Matroska file the `SeekHead` =
Element(s) MUST be updated so that the `SeekHead` Element(s) itemize the =
identify and position of all Top-Level Elements. Editing, removing, or =
adding Elements to a Matroska file often requires that some existing =
Elements be voided or extended; therefore, it is recommended to use Void =
Elements as padding in between Top-Level Elements.

# CRC-32

As noted by the EBML =
specification, if a <a href=3D"https://github.com/Matroska-Org/ebml-specification/blob/master/=
specification.markdown">`CRC-32` Element</a> is used then =
the `CRC-32` Element MUST be the first ordered Element within its Parent =
Element. The Matroska specification recommends that `CRC-32` Elements =
SHOULD NOT be used as an immediate Child Element of the `Segment` =
Element; however all Top-Level Elements of an EBML Document SHOULD =
include a CRC-32 Element as a Child Element.

## SeekHead

If used, the first `SeekHead` Element =
SHOULD be the first non-`CRC-32` Child Element of the `Segment` Element. =
If a second `SeekHead` Element is used then the first `SeekHead` MUST =
reference the identity and position of the second `SeekHead`, the second =
`SeekHead` MUST only reference `Cluster` Elements and not any other =
Top-Level Element, and the second `SeekHead` MAY be stored in any order =
relative to the other Top-Level Elements. Whether one or two `SeekHead` =
Elements is used, the `SeekHead` Element(s) MUST reference the identify =
and position of all Top-Level Elements except for the first =
`SeekHead`.

It =
is recommended that the first `SeekHead` Element be followed by some =
padding (a `Void` Element) to allow for the `SeekHead` Element to be =
expanded to cover new Top-Level Elements that may be added to the =
Matroska file, such as `Tags`, `Chapters` and `Attachments` =
Elements.

## =
Cues (index)

The=
 `Cues` Element is recommended to optimize seeking access in Matroska. =
It is programmatically simpler to add the `Cues` Element after all of =
the `Cluster` Elements are written because this does not require a =
prediction of how much space to reserve before writing the `Cluster` =
Elements. On the other hand, storing the `Cues` Element before the =
`Clusters` can provide some seeking advantages.

## Info

The first `Info` Element SHOULD occur =
before the first `Tracks` and first `Cluster` Element.

## Chapters

The `Chapters` Element =
SHOULD be placed before the `Cluster` Element(s). The `Chapters` Element =
can be used during playback even if the user doesn't need to seek. It =
immediately gives the user information of what section is being read and =
what other sections are available. In the case of Ordered Chapters it =
recommended to evaluate the logical linking even before starting playing =
anything. The `Chapters` Element SHOULD be placed before the first =
`Tracks` Element and after the first `Info` Element.

## Attachments

The `Attachments` =
Element is not meant to use by default when playing the file, but may =
contain the cover art and/or fonts. Cover art is useful even before the =
file is played and fonts may be needed before playback starts for =
initialization of subtitles that may use them. The `Attachments` Element =
MAY be placed before the first `Cluster` Element; however if the =
`Attachments` Element is likely to be edited, then it SHOULD be placed =
after the last `Cluster` Element.

## Tags

The `Tags` Element is the one that is =
most subject to changes after the file was originally created. So for =
easier editing the `Tags` Element SHOULD be placed at the end of the =
`Segment` Element, even after the `Attachments` Element. On the other =
hand, it is inconvenient to have to seek in the `Segment` for tags =
especially for network streams. So it's better if the `Tags` Element(s) =
are found early in the stream. When editing the `Tags` Element(s), the =
original `Tags` Element at the beginning can be <a =
href=3D"/technical/specs/index.html#void">voided</a> and a new =
one <a href=3D"#tags_end">written right at the end</a> of =
the `Segment` Element. The file size will only marginally =
change.

## =
Optimum layout from a muxer

* SeekHead
* Info
* =
Tracks
* Chapters
* =
Attachments
* Tags
* =
Clusters
* Cues

## Optimum layout after editing =
tags

* =
SeekHead
* Info
* =
Tracks
* Chapters
* =
Attachments
* Void
* =
Clusters
* Cues
* =
Tags

## =
Optimum layout with Cues at the front
* =
SeekHead
* Info
* =
Tracks
* Chapters
* =
Attachments
* Tags
* =
Cues
* Clusters

# Cluster Timecode

As each `BlockGroup` and =
`SimpleBlock` of a `Cluster` Element needs the Cluster `Timecode`, the =
`Timecode` Element MUST occur as the first Child Element within the =
`Cluster` Element.

Comments welcome in this thread of in the pull request, such =
as line comments on https://github.com/Matroska-Org/matroska-specification/pull/16/=
commits/9fd95b3a0ad75ee49ac56b9f09efbebb7c08f1e3.

Best Regards,
Dave Rice
=

--Apple-Mail=_7D1152E7-EA99-4CD0-919F-F624926099F7--


From nobody Mon May 23 20:38:54 2016
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 ED26A12DC3A for ; Mon, 23 May 2016 20:38:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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=gmail.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 z0WFpIpwxXuh for ; Mon, 23 May 2016 20:38:50 -0700 (PDT)
Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 7154A12DC4A for ; Mon, 23 May 2016 20:38:31 -0700 (PDT)
Received: by mail-it0-x22c.google.com with SMTP id e62so43607906ita.1 for ; Mon, 23 May 2016 20:38:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to; bh=T4yV4Upu7hdWJEGubG9s3wPS9RSNgbUaZe6tmS9130o=; b=ggpO/zvc5Aovlhr+UhKf7SjPLWaZubqoqFe4UnJJDgIalogc6hA/Z38TQSW0gpgh/R 0sXIIEWj49yoXU2etyC+Jvrwiwrgj1VoAsipw/7Qxy0U986tsa2M5CxKJB3wO/IAHBqv RtrOXiZDxX8EgxmhrPQX61Rj1lNEnj1TCmSJo53psVOzXDBFqRY/4nfAiiD+lE3Q5kBE TKtajsaPxpXLl9ksbzZRXhLj6SvUq3dHHHLf6sH65V3M/RRaDrcgjaGr6rm8X6g+3YxD hJUw5Hpr1P927bwkMl1Fd0Cqc9FIsvF+0d0BD0mXX9UVxkHUuIN2iPVz5Nz2V6ev6mmQ ZTYQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=T4yV4Upu7hdWJEGubG9s3wPS9RSNgbUaZe6tmS9130o=; b=f+KX5uXnhp2IUn2TOazvfhgg2Je5Ha8gjezqYnUMFT2unzk9D02aS4EBaJa6uk/kOd YWH5z8IYOaqq1RpfmWMlnjVJ8QtHIAQMdkxHJYPcnh3a/OnBRQc3admrWgZksD7RDX+l EQS/Q9XHctu0jTv5ys8mNokJsCDAjMkiAHkpNr2IeAxEAHQLdySzSD3d43hOzlHGvHN+ rVzwyttSbSLoA7IxCBCxmA4zWLJVyxvnxbrPfCZ475/2wGQ2LXHU84MbNsrqjS9ydhKY Ff37r3kDzgMuQHOXofZBAvNAtQhL3XzpdOqVVdNZY4rLomg2h1mPwCfWRAAB/KxuS8TN Dvsw==
X-Gm-Message-State: ALyK8tLgBHMv+hmV6S4QSMUJs8OcKD+n4nVgb1QizOtXXIe4N1DIhRDNiQiIqL2k3dPWQWpWWGNYm3VzdLpFBQ==
MIME-Version: 1.0
X-Received: by 10.36.120.12 with SMTP id p12mr10571474itc.22.1464061110581; Mon, 23 May 2016 20:38:30 -0700 (PDT)
Received: by 10.79.113.7 with HTTP; Mon, 23 May 2016 20:38:30 -0700 (PDT)
Date: Mon, 23 May 2016 23:38:30 -0400
Message-ID: 
From: Ashley Blewer 
To: cellar@ietf.org
Content-Type: multipart/alternative; boundary=001a114ab6ca6d264805338e4aa1
Archived-At: 
Subject: [Cellar] Matroska on Github Pages
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 03:38:52 -0000

--001a114ab6ca6d264805338e4aa1
Content-Type: text/plain; charset=UTF-8

Hello! I finished converting the Matroska page to Markdown and bundled all
of the pages into one PR here:
https://github.com/Matroska-Org/matroska-specification/pull/15

Looking forward to cleaning up this and making it a cohesive page but
wanted to get these in first so we can move on towards the discussion of
the content!

My best,

Ashley

--001a114ab6ca6d264805338e4aa1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hello! I finished converting the Matroska page to Markdown=
 and bundled all of the pages into one PR here:=C2=A0https://github.com/Mat=
roska-Org/matroska-specification/pull/15

Looking for=
ward to cleaning up this and making it a cohesive page but wanted to get th=
ese in first so we can move on towards the discussion of the content!
=


My best,

Ashley


--001a114ab6ca6d264805338e4aa1--


From nobody Tue May 24 00:18:14 2016
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 7444C12DC7C for ; Tue, 24 May 2016 00:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.427
X-Spam-Level: 
X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_HELO_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 7xWHKhUt78F9 for ; Tue, 24 May 2016 00:18:10 -0700 (PDT)
Received: from liselle.bunkus.org (liselle.bunkus.org [IPv6:2a01:4f8:151:7310::105:1]) (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 BCA0412B05A for ; Tue, 24 May 2016 00:18:09 -0700 (PDT)
Received: by liselle.bunkus.org (Postfix, from userid 1002) id 1B35E322FA41; Tue, 24 May 2016 09:18:07 +0200 (CEST)
Received: from sweet-chili.local (unknown [10.55.1.18]) by liselle.bunkus.org (Postfix) with ESMTPS id 8449C322FA38 for ; Tue, 24 May 2016 09:18:04 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2016040101; t=1464074284; bh=AlYwpzOFUqTd2Rs/p6jRaMLGvJDVPObmhz4rrD9MSXA=; h=Date:From:To:Subject:References:In-Reply-To; b=taeMx1RQTNl65P6+qDTVCLxIPHTWWAqOPhWSAHakoGxVd7gvDyAohrk0LI/iU4geU vdlc5R9qVEqHc+ODXm7INBIWS0GbyoPYHzB44Vm2HM81M01czzXTwGqQyS0NeEbNxQ eL57YhFUwbkSRevZJOgMwNNNF1VXe5GEg5SIoWZeQOz1CsFfek7J+e97FtUZ4cLDwD fpYBHd+EXqret4o+DTkWBKjnwZotI6d/ghZCVQIbTQFWT1xWo9qlgqLSB4DeOm2EBc dquexwID2t2+ahhJHKF465yy4dlqxnxPuDPkJgIdXGTvsc1n2zMUvb01MBBIglVx5E G1gMTyNBXdXPqUn074B4iOjZrT6oP/8TNA+rfGdzmypQmg54eW9VzKV2dkVF1gMW6u ipegMdSM+3smtQEWaeIV7OgcT+fVe7B3OQ4v5nfmhx1pwt5sOA/nN5IWodhp6hujE7 7jWFBDaYLf7iKHQgTZ8kXIqmpnHvenCkQiRYDbdpuzrqE7MZXTd/MpkZ2IaF1VD8oj xi4fD0LvFqAYjrjHu04BBiL7A6tUvmz1b3uA5H13DMYS/MX+3HKc4lVCpN/+DSbHqU 4maznYk+YyQcalGrTvz8px4YU5n75rp5WpmuGnT4TJ+489vr7fR2rA51x7WNzw4MF3 MI26pwJEINPFE0KhhsBzu6jI=
Received: by sweet-chili.local (Postfix, from userid 1000) id F3825662CA8; Tue, 24 May 2016 09:18:03 +0200 (CEST)
Date: Tue, 24 May 2016 09:18:03 +0200
From: Moritz Bunkus 
To: cellar@ietf.org
Message-ID: <20160524071803.hcwlq4yu2s2djcxk@bunkus.org>
References: <1687ED1D-AF44-4BC5-B1E5-89F2CD7440E7@dericed.com> <13C43671-E7FC-4011-B759-0E4F0E003D98@dericed.com> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bk7m53oc3f3gsf4n"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.6.1-neo ()
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4
X-Virus-Scanned: clamav-milter 0.98.7 at liselle
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [Cellar] Matroska Ordering Guidelines
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 07:18:12 -0000

--bk7m53oc3f3gsf4n
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hey,

> - "The Matroska specification recommends that `CRC-32` Elements SHOULD
>   NOT be used as an immediate Child Element of the `Segment`
>   Element=E2=80=9D. The EBML spec permits CRC-32 within Level 0 Elements =
and
>   I=E2=80=99ve seen files before with CRC-32 as a Child Element of the EB=
ML
>   Header.

I'd like to keep the wording "SHOULD NOT =E2=80=A6 as a child of =E2=80=A6 =
segment" for
several reasons:

- If such an element is present updating any part of the file (changing
  header values, adding attachments, removing chapters=E2=80=A6) requires
  re-calculating the CRC-32 element.
- Verifying the element requires reading the whole file which requires a
  lot of time and resources.
- It doesn't provide a lot of value. If it is invalid all you can say is
  that the whole, arbitrarily large file is damaged somewhere. With
  libEBML you cannot even verify the CRC-32 properly because it requires
  the whole element to be present in memory at the moment=E2=80=A6

> The `Info` Element doesn=E2=80=99t have it=E2=80=99s own ordering suggest=
ions but the
> `Chapters` Element section infers it, so I added an `Info` ordering
> section based on what is inferred.

Sounds fine.

> I=E2=80=99m confused about the mandates of referencing `Clusters` in
> `SeekHead`. Is it required that ALL Cluster are referenced by the
> `SeekHead` Element(s)?

No, we never mandated that. It doesn't provide much value over having
`Cues` elements anyway. I prefer guidelines to reflect what works well
in practice, and in practice you don't need `Clusters` to be referenced
by `SeekHead` elements.

> Or is only the first Cluster a mandate and the rest of the Clusters
> suggested? If two `SeekHead` Elements are used, is the first
> `SeekHead` allowed to reference all `Cluster` Element?

Additionally I don't see any benefit of restricting which `SeekHead` can
contain the clusters seeing how little benefit referencing the clusters
provides.

In fact I don't like imposing real restrictions on where to reference
elements from. If a player can read `SeekHead` elements then it should
not matter which `SeekHead` references which element =E2=80=93 the player s=
hould
process them all.

Now from a perspective of being able to edit the file after it's been
created putting most content into a `SeekHead` at the end of the file is
more sensible as an editor has much more options to deal with such a
structure than if they're all part of the first `SeekHead` at the front
of the file.

> The EBML specification gives a distinction between Level 1 Elements
> and Top-Level Elements in that Top-Level Elements are Elements that
> may only occur at Level 1. Thus CRC-32 and Void (as global elements)
> are not considered Top-Level Elements. If Void and CRC-32 are used at
> Level 1, is it clear that these Elements do not have to be referenced
> in the SeekHead Element(s)?

Huh=E2=80=A6 Interesting question. As they're not required for playback I d=
on't
consider them to be candidates for mandatory referencing; though it is
obvious that knowing their location is beneficial for certain kinds of
applications (CRC-32: structure verification & editing; Voids: editing).

> I=E2=80=99d like to verify that it is a requirement that the second
> `SeekHead`, if used, only contain reference to `Cluster` Elements. For
> instance if the first `SeekHead` is not followed by some padding, then
> this requirement makes it difficult to edit a file (to add an
> attachment, tags, or chapters) without re-writing most of it.

I completely agree. This wording is one I've always disagreed
with. Steve & I where always opposites regarding the use of more than
one `SeekHead`. As I've stated above I strongly prefer to allow two
`SeekHeads` with almost arbitrary placement (the first one must be
located before the first cluster and it must reference the second one)
and, more important, arbitrary content.

In writing mkvpropedit and the GUI's header editor it became painfully
obvious that editing existing files is simply not possible without
allowing a second `SeekHead` and using it for all types of 1
elements. If we disallow it then that would pretty much end all uses of
in-place editing of existing files without remuxing, something the users
would definitely not appreciate. Files that strictly follow the
guidelines are of course still editable, but my past experience is that
a very big percentage do not follow those guidelines and would not allow
editing (e.g. because there's no space after the first `SeekHead`).

> We should recommend a certain amount of padding to follow the first
> SeekHead. Any recommendations?

If we disregard the clusters: maybe 100 bytes or something like that?
One `SeekHead` entry is ~18 bytes in size, and leaving 100 bytes would
be plenty (adding attachments, chapters, tags are probably the most
interesting and most common use cases; the extra bytes would be a
reserve for future additions).

> The Tags ordering section suggests that if a Tags Element is at the
> beginning of the file and needs to be edited/expanded, then the Tags
> Element can be Voided, and a new one written at the end. But the Tags
> Element is allowed to occur multiple times. If someone is just added a
> new tag, could the new Tags Element just be written at the end of the
> Segment and the first Tags element left as is?

No. You'll have to relocate the whole element and add the new element to
the freshly moved `Tags` element.

Got to stop here as I have to go.

Kind regards,
mosu

--bk7m53oc3f3gsf4n
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIcBAABCgAGBQJXRAAnAAoJEHSvAK3y4yyFGFIP/RCBIyqQM1qLiX21d6wKVKat
XSwo0l2AAxaalwS2AdH5OZ8u0xEIwBMmgtxuPus2JMg9RmOtB9uDiJTrMrXOb8TT
qfb41Mh26CDL6rMSu8XTS2mynKZLs5voTBi4Ow7ZFAQ0UOFAqYgaI8EOfOKBPPTb
/rgZ+kwAbKbf1IqmZb/Ohvzp6OtPYOnQgCuzhFNn/KjKQ0f3yt/TVKWkidGMtgTx
h9eLFYgKo14tRjtaEJHBAHvkwWcuKZodduzATdFx3R+4A7Qk4rl744sLUP4YZkAU
xrPIei3xe8E6WKGz108I2kc6onGI440IBtsN5gCghMYlgxjmDiRBVUA3dh06FJ2x
9UO2n9d1ZzCkLHyoMGwhc0dhMVas8iHl2rYbmCNKxoZsAgWgqz1ohAX3sFUfmPmJ
cLSE3ZsJDjhbKXnfeHsukmFwP/PJQmoXFYtQ8Rw+txogbcfPF5GxkDrEIRp1lDyN
wrF2Z6gxHWK61pvfBS4PdBXasTVLF9BMFVlUHdPsDx/ZbUieOI2xLCKIZ/qsdCPx
Y61VkYgx7vOohdtiI4ctVVb3cbPV5UI2AMK5ZC+I2q4dOHWIUdWYhJ/iknhuZrNw
YVVxAiibANwbKZ6+Jm/UJfLztp45ZVaZlluct1FLU1FDHWP7EPFpEZd+Ml0ustkK
J3ge704dK+QtljjM/jwG
=Umif
-----END PGP SIGNATURE-----

--bk7m53oc3f3gsf4n--


From nobody Tue May 24 00:19:22 2016
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 4D48312DC84 for ; Tue, 24 May 2016 00:19:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 8bIiFMjqTuOq for ; Tue, 24 May 2016 00:19:18 -0700 (PDT)
Received: from 17.mo5.mail-out.ovh.net (17.mo5.mail-out.ovh.net [46.105.56.132]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA31212B05A for ; Tue, 24 May 2016 00:19:17 -0700 (PDT)
Received: from player763.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo5.mail-out.ovh.net (Postfix) with ESMTP id 083981018776 for ; Tue, 24 May 2016 09:19:15 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player763.ha.ovh.net (Postfix) with ESMTPSA id B9E203C00AE for ; Tue, 24 May 2016 09:19:15 +0200 (CEST)
To: cellar@ietf.org
References:  
From: Jerome Martinez 
Message-ID: 
Date: Tue, 24 May 2016 09:19:15 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------8CA735531ACD3B45BFFBFAFB"
X-Ovh-Tracer-Id: 32369624391028881
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrgedtgdehudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Archived-At: 
Subject: Re: [Cellar] can Mandatory Elements be Empty Elements?
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 07:19:20 -0000

This is a multi-part message in MIME format.
--------------8CA735531ACD3B45BFFBFAFB
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Le 24/05/2016  02:59, Michael Bradshaw a crit :
> On Mon, May 23, 2016 at 5:41 PM, Dave Rice  > wrote:
>
>     Hi all,
>     Im not sure if this has been addressed but the EBML specification
>     didnt appear to make this clear. In some cases mandatory elements
>     have no default defined, as is the case with MuxingApp and
>     WritingApp. For instance here is an empty element for MuxingApp:
>     0x4D8080. Is it valid if an element like this is Empty? When I
>     create an empty mandatory element that has no defined default,
>     mkvalidator seem to mind.
>
>
> From the current reading, mandatory elements should be able to be 
> empty elements. In this situation, for UTF-8/String elements, the EBML 
> spec says the elements may declare any length from zero to `VINTMAX`, 
> so an empty value for MuxingApp/WritingApp should be considered as valid.

I propose that MuxingApp/WritingApp should be optional, as it is not 
relevant for generic demuxing/parsing of the file and a muxer could 
avoid to fill it with empty data (or junk if we forbid empty mandatory 
elements, bad in both cases), or mandatory with "" as default.

Bonus: the tiniest valid file would be just 0x1A45DFA3801853806780.

--------------8CA735531ACD3B45BFFBFAFB
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Le 24/05/2016  02:59, Michael Bradshaw
      a crit:

    

    

      

        

          
On Mon, May 23, 2016 at 5:41 PM, Dave
            Rice <dave@dericed.com>
            wrote:

            
Hi
              all,

              Im not sure if this has been addressed but the EBML
              specification didnt appear to make this clear. In some
              cases mandatory elements have no default defined, as is
              the case with MuxingApp and WritingApp. For instance here
              is an empty element for MuxingApp: 0x4D8080. Is it valid
              if an element like this is Empty? When I create an empty
              mandatory element that has no defined default, mkvalidator
              seem to mind.

            


            

            
From the current reading, mandatory elements should be
              able to be empty elements. In this situation,
              forUTF-8/String elements, the EBML spec says the elements
              may declare any length from zero to `VINTMAX`, so an empty
              value for MuxingApp/WritingApp should be considered as
              valid.

          

        

      

    

    

    I propose that MuxingApp/WritingApp should be optional, as it is not
    relevant for generic demuxing/parsing of the file and a muxer could
    avoid to fill it with empty data (or junk if we forbid empty
    mandatory elements, bad in both cases), or mandatory with "" as
    default.

    

    Bonus: the tiniest valid file would be just 0x1A45DFA3801853806780.

  


--------------8CA735531ACD3B45BFFBFAFB--


From nobody Tue May 24 06:21:26 2016
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 F23E212D795 for ; Tue, 24 May 2016 06:21:22 -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 oKbae3L-mfDH for ; Tue, 24 May 2016 06:21:21 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 1B77712D830 for ; Tue, 24 May 2016 06:16:22 -0700 (PDT)
Received: from [146.96.19.240] (port=11496 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b5CC3-000AMG-Oj; Tue, 24 May 2016 09:16:21 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_8B3F1A53-0DE0-4B5A-97E4-B0997D7AD7A0"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dave Rice 
In-Reply-To: 
Date: Tue, 24 May 2016 09:16:18 -0400
Message-Id: 
References:   
To: Jerome Martinez 
X-Mailer: Apple Mail (2.3112)
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: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] can Mandatory Elements be Empty Elements?
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 13:21:23 -0000

--Apple-Mail=_8B3F1A53-0DE0-4B5A-97E4-B0997D7AD7A0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


> On May 24, 2016, at 3:19 AM, Jerome Martinez  =
wrote:
>=20
> Le 24/05/2016 =E0 02:59, Michael Bradshaw a =E9crit :
>> On Mon, May 23, 2016 at 5:41 PM, Dave Rice > wrote:
>> Hi all,
>> I=92m not sure if this has been addressed but the EBML specification =
didn=92t appear to make this clear. In some cases mandatory elements =
have no default defined, as is the case with MuxingApp and WritingApp. =
For instance here is an empty element for MuxingApp: 0x4D8080. Is it =
valid if an element like this is Empty? When I create an empty mandatory =
element that has no defined default, mkvalidator seem to mind.
>>=20
>> =46rom the current reading, mandatory elements should be able to be =
empty elements. In this situation, for UTF-8/String elements, the EBML =
spec says the elements may declare any length from zero to `VINTMAX`, so =
an empty value for MuxingApp/WritingApp should be considered as valid.
>=20
> I propose that MuxingApp/WritingApp should be optional, as it is not =
relevant for generic demuxing/parsing of the file and a muxer could =
avoid to fill it with empty data (or junk if we forbid empty mandatory =
elements, bad in both cases), or mandatory with "" as default.

Removing this requirement would reduce a tiny amount of space but cause =
a lot of confusion. Compared to other audiovisual containers, I'm glad =
that almost all Matroska files can be traced back to the tools used to =
create them. Also nearly every Matroska file follows the requirement and =
uses MuxingApp and WritingApp. Some Handbrake files do not follow the =
rule though.

> Bonus: the tiniest valid file would be just 0x1A45DFA3801853806780.

Not a very valuable bonus.
Dave Rice


--Apple-Mail=_8B3F1A53-0DE0-4B5A-97E4-B0997D7AD7A0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252


On May 24, 2016, at 3:19 AM, Jerome Martinez <Jerome@MediaArea.net> wrote:


 =20
    
 =20
  

    
Le 24/05/2016 =E0 02:59, Michael =
Bradshaw
      a =E9crit :

    

    

      

        

          
On Mon, May 23, 2016 at 5:41 PM, =
Dave
            Rice <dave@dericed.com>
            wrote:

            
Hi
              all,

              I=92m not sure if this has been addressed but the EBML
              specification didn=92t appear to make this clear. In some
              cases mandatory elements have no default defined, as is
              the case with MuxingApp and WritingApp. For instance here
              is an empty element for MuxingApp: 0x4D8080. Is it valid
              if an element like this is Empty? When I create an empty
              mandatory element that has no defined default, mkvalidator
              seem to mind.

            


            

            
=46rom the current reading, mandatory =
elements should be
              able to be empty elements. In this situation,
              for UTF-8/String elements, the EBML spec says the =
elements
              may declare any length from zero to `VINTMAX`, so an empty
              value for MuxingApp/WritingApp should be considered as
              valid.

          

        

      

    

    

    I propose that MuxingApp/WritingApp should be optional, as it is not
    relevant for generic demuxing/parsing of the file and a muxer could
    avoid to fill it with empty data (or junk if we forbid empty
    mandatory elements, bad in both cases), or mandatory with "" as
    default.

Removing this requirement would reduce a tiny =
amount of space but cause a lot of confusion. Compared to other =
audiovisual containers, I'm glad that almost all Matroska files can be =
traced back to the tools used to create them. Also nearly every Matroska =
file follows the requirement and uses MuxingApp and WritingApp. Some =
Handbrake files do not follow the rule though.


    Bonus: the tiniest valid file would be just =
0x1A45DFA3801853806780.

  

Not a very valuable =
bonus.
Dave Rice

=

--Apple-Mail=_8B3F1A53-0DE0-4B5A-97E4-B0997D7AD7A0--


From nobody Tue May 24 06:29:26 2016
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 8B86F12DD15 for ; Tue, 24 May 2016 06:29:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 EGLVvh1mT0Mw for ; Tue, 24 May 2016 06:29:20 -0700 (PDT)
Received: from 20.mo5.mail-out.ovh.net (20.mo5.mail-out.ovh.net [91.121.55.239]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DEDC12D708 for ; Tue, 24 May 2016 06:24:31 -0700 (PDT)
Received: from player763.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo5.mail-out.ovh.net (Postfix) with ESMTP id 8768F1010F57 for ; Tue, 24 May 2016 15:24:29 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB4E05.dip0.t-ipconnect.de [93.219.78.5]) (Authenticated sender: jerome@francoallemand.eu) by player763.ha.ovh.net (Postfix) with ESMTPSA id 426933C00BA for ; Tue, 24 May 2016 15:24:29 +0200 (CEST)
References:    
To: cellar@ietf.org
From: Jerome Martinez 
Message-ID: 
Date: Tue, 24 May 2016 15:24:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------9234CD9BAB1638218DDA9DD1"
X-Ovh-Tracer-Id: 6200612265380090001
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrgedugdeivdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Archived-At: 
Subject: Re: [Cellar] can Mandatory Elements be Empty Elements?
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 13:29:25 -0000

This is a multi-part message in MIME format.
--------------9234CD9BAB1638218DDA9DD1
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Le 24/05/2016  15:16, Dave Rice a crit :
>
>> On May 24, 2016, at 3:19 AM, Jerome Martinez > > wrote:
>>
>> Le 24/05/2016  02:59, Michael Bradshaw a crit :
>>> On Mon, May 23, 2016 at 5:41 PM, Dave Rice >> > wrote:
>>>
>>>     Hi all,
>>>     Im not sure if this has been addressed but the EBML
>>>     specification didnt appear to make this clear. In some cases
>>>     mandatory elements have no default defined, as is the case with
>>>     MuxingApp and WritingApp. For instance here is an empty element
>>>     for MuxingApp: 0x4D8080. Is it valid if an element like this is
>>>     Empty? When I create an empty mandatory element that has no
>>>     defined default, mkvalidator seem to mind.
>>>
>>>
>>> From the current reading, mandatory elements should be able to be 
>>> empty elements. In this situation, for UTF-8/String elements, the 
>>> EBML spec says the elements may declare any length from zero to 
>>> `VINTMAX`, so an empty value for MuxingApp/WritingApp should be 
>>> considered as valid.
>>
>> I propose that MuxingApp/WritingApp should be optional, as it is not 
>> relevant for generic demuxing/parsing of the file and a muxer could 
>> avoid to fill it with empty data (or junk if we forbid empty 
>> mandatory elements, bad in both cases), or mandatory with "" as default.
>
> Removing this requirement would reduce a tiny amount of space but 
> cause a lot of confusion.

A tool willing to hide without having an implementation checker failure 
will just put an empty string. You'll still get the confusion.

> Compared to other audiovisual containers, I'm glad that almost all 
> Matroska files can be traced back to the tools used to create them. 
> Also nearly every Matroska file follows the requirement and uses 
> MuxingApp and WritingApp. Some Handbrake files do not follow the rule 
> though.

And they are playable without problem. Not sure it is worth that an 
implementation checker says that the file is invalid in the case this 
piece of info is missing.
Maybe a "SHOULD" so we put a warning instead of an error in an 
implementation checker?

>
>> Bonus: the tiniest valid file would be just 0x1A45DFA3801853806780.
>
> Not a very valuable bonus.
> Dave Rice
>


--------------9234CD9BAB1638218DDA9DD1
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Le 24/05/2016  15:16, Dave Rice a
      crit:

    

    

      
      

      

        

          
On May 24, 2016, at 3:19 AM, Jerome Martinez
            <Jerome@MediaArea.net>
            wrote:

          

          

            
            

              
Le 24/05/2016  02:59,
                Michael Bradshaw a crit:

              

              

                

                  

                    
On Mon, May 23, 2016 at
                      5:41 PM, Dave Rice <dave@dericed.com>
                      wrote:

                      
Hi
                        all,

                        Im not sure if this has been addressed but the
                        EBML specification didnt appear to make this
                        clear. In some cases mandatory elements have no
                        default defined, as is the case with MuxingApp
                        and WritingApp. For instance here is an empty
                        element for MuxingApp: 0x4D8080. Is it valid if
                        an element like this is Empty? When I create an
                        empty mandatory element that has no defined
                        default, mkvalidator seem to mind.

                      


                      

                      
From the current reading, mandatory
                        elements should be able to be empty elements. In
                        this situation, forUTF-8/String elements, the
                        EBML spec says the elements may declare any
                        length from zero to `VINTMAX`, so an empty value
                        for MuxingApp/WritingApp should be considered as
                        valid.

                    

                  

                

              

              

              I propose that MuxingApp/WritingApp should be optional, as
              it is not relevant for generic demuxing/parsing of the
              file and a muxer could avoid to fill it with empty data
              (or junk if we forbid empty mandatory elements, bad in
              both cases), or mandatory with "" as default.

            

          

        

        


        

        
Removing this requirement would reduce a tiny amount of
          space but cause a lot of confusion.

      

    

    

    A tool willing to hide without having an implementation checker
    failure will just put an empty string. You'll still get the
    confusion.

    

    

      

        
 Compared to other audiovisual containers, I'm glad that
          almost all Matroska files can be traced back to the tools used
          to create them. Also nearly every Matroska file follows the
          requirement and uses MuxingApp and WritingApp. Some Handbrake
          files do not follow the rule though.

      

    

    

    And they are playable without problem. Not sure it is worth that an
    implementation checker says that the file is invalid in the case
    this piece of info is missing.

    Maybe a "SHOULD" so we put a warning instead of an error in an
    implementation checker?

    

    

      


        

          

            
 Bonus: the
              tiniest valid file would be just 0x1A45DFA3801853806780.

            

          

        

        

      

      
Not a very valuable bonus.

      
Dave Rice

      

    

    


    

  


--------------9234CD9BAB1638218DDA9DD1--


From nobody Tue May 24 06:41:50 2016
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 0C42212D118 for ; Tue, 24 May 2016 06:41:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 zDucaN0um01j for ; Tue, 24 May 2016 06:41:47 -0700 (PDT)
Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 EBA6012D73B for ; Tue, 24 May 2016 06:39:34 -0700 (PDT)
Received: from eris.local (dynamic-adsl-84-220-81-12.clienti.tiscali.it [84.220.81.12]) (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 5ED39340B46 for ; Tue, 24 May 2016 13:39:33 +0000 (UTC)
To: cellar@ietf.org
References:    
From: Luca Barbato 
Message-ID: 
Date: Tue, 24 May 2016 15:39:29 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Cellar] can Mandatory Elements be Empty Elements?
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 13:41:49 -0000

On 24/05/16 15:16, Dave Rice wrote:
> Removing this requirement would reduce a tiny amount of space but
> cause a lot of confusion. Compared to other audiovisual containers,
> I'm glad that almost all Matroska files can be traced back to the
> tools used to create them. Also nearly every Matroska file follows
> the requirement and uses MuxingApp and WritingApp. Some Handbrake
> files do not follow the rule though.

The information is not trustworthy anyway.

If a file is readable w/out certain information it should stay optional
IMHO.

Usual warning:

"Relying on certain strings to enable quirk-modes is a recipe for a
disaster, please do not do that. If you want to support a quirk make so
you detect the quirk and fallback when possible"

lu


From nobody Tue May 24 07:02:07 2016
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 D59F612D1BC for ; Tue, 24 May 2016 07:02:05 -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 5unC-cg1O_Z1 for ; Tue, 24 May 2016 07:02:02 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 AA9BA12D180 for ; Tue, 24 May 2016 07:02:02 -0700 (PDT)
Received: from [146.96.19.240] (port=31988 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b5CuF-001GDl-Fa; Tue, 24 May 2016 10:02:02 -0400
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_F7665FB3-3F6D-4A4D-BB11-8B552EF16179"; protocol="application/pgp-signature"; micalg=pgp-sha256
X-Pgp-Agent: GPGMail 2.6b2
From: Dave Rice 
In-Reply-To: <20160524071803.hcwlq4yu2s2djcxk@bunkus.org>
Date: Tue, 24 May 2016 10:01:56 -0400
Message-Id: <04409161-02A4-471F-9EFE-9DC612D1361B@dericed.com>
References: <1687ED1D-AF44-4BC5-B1E5-89F2CD7440E7@dericed.com> <13C43671-E7FC-4011-B759-0E4F0E003D98@dericed.com>  <20160524071803.hcwlq4yu2s2djcxk@bunkus.org>
To: Moritz Bunkus 
X-Mailer: Apple Mail (2.3112)
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: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] Matroska Ordering Guidelines
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 14:02:06 -0000

--Apple-Mail=_F7665FB3-3F6D-4A4D-BB11-8B552EF16179
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi,

> On May 24, 2016, at 3:18 AM, Moritz Bunkus  wrote:
>=20
> Hey,
>=20
>> - "The Matroska specification recommends that `CRC-32` Elements =
SHOULD
>>  NOT be used as an immediate Child Element of the `Segment`
>>  Element=E2=80=9D. The EBML spec permits CRC-32 within Level 0 =
Elements and
>>  I=E2=80=99ve seen files before with CRC-32 as a Child Element of the =
EBML
>>  Header.
>=20
> I'd like to keep the wording "SHOULD NOT =E2=80=A6 as a child of =E2=80=A6=
 segment" for
> several reasons:

Sorry to not clarify this well. The quote "The Matroska specification =
recommends that `CRC-32` Elements SHOULD
 NOT be used as an immediate Child Element of the `Segment` Element=E2=80=9D=
 is a proposal of mine. The current Matroska specification seems to =
permit a CRC-32 Element as an immediate Child Element of Segment.

> - If such an element is present updating any part of the file =
(changing
>  header values, adding attachments, removing chapters=E2=80=A6) =
requires
>  re-calculating the CRC-32 element.
> - Verifying the element requires reading the whole file which requires =
a
>  lot of time and resources.

Agreed.

> - It doesn't provide a lot of value. If it is invalid all you can say =
is
>  that the whole, arbitrarily large file is damaged somewhere. With
>  libEBML you cannot even verify the CRC-32 properly because it =
requires
>  the whole element to be present in memory at the moment=E2=80=A6

Agreed, but what if a non-Master-element was defined at Level 1 as an =
immediate child of Segment. Using a CRC-32 as a child of Segment would =
be the only way to represent the fixity of a non-Master-element at Level =
1.

>> The `Info` Element doesn=E2=80=99t have it=E2=80=99s own ordering =
suggestions but the
>> `Chapters` Element section infers it, so I added an `Info` ordering
>> section based on what is inferred.
>=20
> Sounds fine.
>=20
>> I=E2=80=99m confused about the mandates of referencing `Clusters` in
>> `SeekHead`. Is it required that ALL Cluster are referenced by the
>> `SeekHead` Element(s)?
>=20
> No, we never mandated that. It doesn't provide much value over having
> `Cues` elements anyway. I prefer guidelines to reflect what works well
> in practice, and in practice you don't need `Clusters` to be =
referenced
> by `SeekHead` elements.

Right, bad presumption of mine that SeekHead(s) should document all Top =
Level Elements. The current SeekHead definition does not mandate that =
all Top-Level Elements are referenced, but says "Contains the position =
of other Top-Level Elements." Steve confirmed that it is not a mandate =
to document all Top Level Elements here: =
https://mailarchive.ietf.org/arch/msg/cellar/UZMYejpNV7roYBsrXDzQKDfJSd0. =
I'll remove the mandate, rebase, and resubmit.

>> Or is only the first Cluster a mandate and the rest of the Clusters
>> suggested? If two `SeekHead` Elements are used, is the first
>> `SeekHead` allowed to reference all `Cluster` Element?
>=20
> Additionally I don't see any benefit of restricting which `SeekHead` =
can
> contain the clusters seeing how little benefit referencing the =
clusters
> provides.
>=20
> In fact I don't like imposing real restrictions on where to reference
> elements from. If a player can read `SeekHead` elements then it should
> not matter which `SeekHead` references which element =E2=80=93 the =
player should
> process them all.

This is a mandate from the original documentation at =
https://matroska.org/technical/order/index.html: "The second Meta Seek =
is placed at the end and contains a lengthy list of all Clusters (and =
not the other level 1 elements)." Is the parenthetical part at the end =
indeed a mandate about the second SeekHead?

> Now from a perspective of being able to edit the file after it's been
> created putting most content into a `SeekHead` at the end of the file =
is
> more sensible as an editor has much more options to deal with such a
> structure than if they're all part of the first `SeekHead` at the =
front
> of the file.
>=20
>> The EBML specification gives a distinction between Level 1 Elements
>> and Top-Level Elements in that Top-Level Elements are Elements that
>> may only occur at Level 1. Thus CRC-32 and Void (as global elements)
>> are not considered Top-Level Elements. If Void and CRC-32 are used at
>> Level 1, is it clear that these Elements do not have to be referenced
>> in the SeekHead Element(s)?
>=20
> Huh=E2=80=A6 Interesting question. As they're not required for =
playback I don't
> consider them to be candidates for mandatory referencing; though it is
> obvious that knowing their location is beneficial for certain kinds of
> applications (CRC-32: structure verification & editing; Voids: =
editing).

OK, without a mandate to reference all Top-Level Elements this question =
is less significant, but I could adjust this to say that the SeekHead =
should only reference Level 1 Elements, so that Void Elements may be =
listed in SeekHead.

>> I=E2=80=99d like to verify that it is a requirement that the second
>> `SeekHead`, if used, only contain reference to `Cluster` Elements. =
For
>> instance if the first `SeekHead` is not followed by some padding, =
then
>> this requirement makes it difficult to edit a file (to add an
>> attachment, tags, or chapters) without re-writing most of it.
>=20
> I completely agree. This wording is one I've always disagreed
> with. Steve & I where always opposites regarding the use of more than
> one `SeekHead`. As I've stated above I strongly prefer to allow two
> `SeekHeads` with almost arbitrary placement (the first one must be
> located before the first cluster and it must reference the second one)
> and, more important, arbitrary content.

I agree that two SeekHeads is sensible. Once the Matroska specdata.xml =
is updated as an EBML Schema we can use maxOccurs=3D"2" for SeekHead as =
it seems that no one wants a third SeekHead. Going back to a quote from =
the original specification: "The second Meta Seek is placed at the end =
and contains a lengthy list of all Clusters (and not the other level 1 =
elements)." Are we agreed to remove this mandate that the second =
SeekHead not contain any non-Cluster Elements?

> In writing mkvpropedit and the GUI's header editor it became painfully
> obvious that editing existing files is simply not possible without
> allowing a second `SeekHead` and using it for all types of 1
> elements. If we disallow it then that would pretty much end all uses =
of
> in-place editing of existing files without remuxing, something the =
users
> would definitely not appreciate. Files that strictly follow the
> guidelines are of course still editable, but my past experience is =
that
> a very big percentage do not follow those guidelines and would not =
allow
> editing (e.g. because there's no space after the first `SeekHead`).

It seems though that there are two bad options permitted when editing a =
file with one SeekHead that do not use a second SeekHead.

1. Void the SeekHead and add a new SeekHead at the end. This doesn't =
follow the recommendation of the Matroska specification but does not =
violate any mandate. Putting SeekHead before Clusters is a SHOULD and =
not a MUST.

2. Just Void the SeekHead and have no SeekHead at all. It presence is =
not a mandate.

>> We should recommend a certain amount of padding to follow the first
>> SeekHead. Any recommendations?
>=20
> If we disregard the clusters: maybe 100 bytes or something like that?
> One `SeekHead` entry is ~18 bytes in size, and leaving 100 bytes would
> be plenty (adding attachments, chapters, tags are probably the most
> interesting and most common use cases; the extra bytes would be a
> reserve for future additions).

Seems sensible, I'll add it as a suggestion.

>> The Tags ordering section suggests that if a Tags Element is at the
>> beginning of the file and needs to be edited/expanded, then the Tags
>> Element can be Voided, and a new one written at the end. But the Tags
>> Element is allowed to occur multiple times. If someone is just added =
a
>> new tag, could the new Tags Element just be written at the end of the
>> Segment and the first Tags element left as is?
>=20
> No. You'll have to relocate the whole element and add the new element =
to
> the freshly moved `Tags` element.

The "Tags" element is set to multiple. If not this case, when is it =
recommended to use more than one "Tags" Element?

> Got to stop here as I have to go.

[...]

Same here. Bye,
Dave Rice


--Apple-Mail=_F7665FB3-3F6D-4A4D-BB11-8B552EF16179
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCAAGBQJXRF7VAAoJEIlM1Sx2ptr5rngP/itRYa/HU7mXVk6H7fFMlf1t
dmbEXgRDb+drkN61IK+xt0ScW597jY1+mxtVDAPna5m+D6el7sF2WewPoRwsHGRy
8sNOfZ804zy6JxNKAT+Yifsy3pCpML8OSiUKRKhB2EgywI1tYLEIa4BbZA3AfvOP
l2p64ckTYel6Q8smcx+g4KLM0rxVtVZQQNbXSAEl3S5rUhajUqVdpJst8xS8D9eS
RrVNSU0hgHrqaqIvoGHNN3L+iuZlkH8HnfRU1wLv+u9wM1tkA9z6iOe3mwavj6Ho
+l2nE2mKSShYbspMn+AKgyui5F4fO5aJ3s0/1DwStv9mU40LfrKaJfPGiDrSvMlR
Objo4hWOKsLYgYCr7gG5d2oxNkxWIwX9Em+/oio13+dbkdaM1+S1VBRhCzaA9gvN
KC8iKjmBYzVYI3hAZgoMAKBxgRNTOiNgcIncTJivVz36hO+iTYKK4PoJbj/BXQ+o
riDG6oov0cNcX7nD+/5cqbLsGiJ7Js5IKxhKK8vH3yJJ5pJFDmz/F4tSOw9j/GTU
ErFjv8rbWbu7m1fu7oxtIjhINaLGv5tOhYswB1ztd1utAGJg4ktYclq0bfsHSL54
XnniaSkU5J3bEsxIpVXHcLfb8/H5qNLrDmOogjNjiba1IlU/4Y7OMkq+16ybUN5R
nrxxqiDBnMd/znjqCu7k
=VVhA
-----END PGP SIGNATURE-----

--Apple-Mail=_F7665FB3-3F6D-4A4D-BB11-8B552EF16179--


From nobody Tue May 24 13:52:26 2016
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 03F3812D52C for ; Tue, 24 May 2016 13:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.426
X-Spam-Level: 
X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 zI4WdqGE8YrU for ; Tue, 24 May 2016 13:52:23 -0700 (PDT)
Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 756E612D51A for ; Tue, 24 May 2016 13:52:23 -0700 (PDT)
Received: by mail-it0-x233.google.com with SMTP id l63so19971902ita.1 for ; Tue, 24 May 2016 13:52:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=nGntc4+Ju673h8sKfEk2EKylAwXHCrLHcOcLuLNtDAs=; b=h71th+ln9ynbQVlOwDKNcpjAXvXfC7cosxedcvJx9tseUXZZMLoElvvmMAn7JTLL1a mgrOiPcl1bBpVa2U5GL6iVQ+zDpMMeMlO7UH7WaMZG/ACYekGThKoyEYz5VjcFd3DFc/ ZSa1gdZ19QHwmbWlJpqRbQXFM4PbVUozkru9HxQYcNiEy4rEq1ybgjMYcGz3wi8DzdDh yi6en3S04F+5iLEqLsFllI9qR2OEyasGaFwjyaxKEIoP7HOgLrma6cJLiJpy1NCuz8uB RFWrtjamu9j+cQ+pr5O/O3ppJ3X41Hr2Yi9CXvFGqAA+5U/eW3eXRD+tyhZKhzuuSX/H Fktg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nGntc4+Ju673h8sKfEk2EKylAwXHCrLHcOcLuLNtDAs=; b=Vwpm2hBAthhHnnMDVz5gtEwigIDwdVNFxcq+qWG1jjjQanNqwi3jR6f11yb6IxeAY0 4IebMT7pplvPVKXS/vodkP7KAHs3eDQhKcaUdFnNBUrrKLz89dtJamhy20IVnJPEMWkn QYnYn+laITZ2u19p5uiQHAP5dTMoURM3exvTGcnHDZzrJ7P0bIRUusinnPhpZMjK7k4N jX4Yrh8n8SLbN9q6lH4E6YQCiBguJdbk0jnoHmSCRmjnj235zVA7n/hkEuSur8OajQ8M cvdQFwGO8qxCejwXSNDH2ZuQ6wwD+oyRrgmjz7NCrjeQgysvc4c+JBT3f23wzMsjm7mh 1bmQ==
X-Gm-Message-State: AOPr4FW0jyW3lE8hf6l/5wQyMnPS07rtXVKMOonKkhqlA9tecqOb2rGvXGuJ7YBydCJO1D5746VC86d9P4Hz1NQN
X-Received: by 10.36.219.70 with SMTP id c67mr20464280itg.46.1464123142611; Tue, 24 May 2016 13:52:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.15.22 with HTTP; Tue, 24 May 2016 13:52:03 -0700 (PDT)
From: Michael Bradshaw 
Date: Tue, 24 May 2016 13:52:03 -0700
Message-ID: 
To: cellar@ietf.org
Content-Type: multipart/alternative; boundary=94eb2c05750ad302d505339cbbd0
Archived-At: 
Subject: [Cellar] [PATCH 1/1] Specify a range of >0 for EBMLVersion/EBMLReadVersion
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 20:52:25 -0000

--94eb2c05750ad302d505339cbbd0
Content-Type: text/plain; charset=UTF-8

Hi,

I propose the following patch for the EBML specification. Currently,
EBMLVersion and EBMLReadVersion do not have a range specified, suggesting
the value 0 should be legal (albeit probably nonsensical).


>From f0e547502890fa9efa0b966a08544f5b91f8ccd7 Mon Sep 17 00:00:00 2001
From: Michael Bradshaw 
Date: Tue, 17 May 2016 10:14:42 -0700
Subject: [PATCH 1/1] Specify a range of >0 for EBMLVersion/EBMLReadVersion

---
 specification.markdown | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/specification.markdown b/specification.markdown
index 3f262b9..3fb4b01 100644
--- a/specification.markdown
+++ b/specification.markdown
@@ -336,7 +336,7 @@ Element Name:   EBMLVersion
     EBML ID:        [42][86]
     Mandatory:      Yes
     Multiple:       No
-    Range:          -
+    Range:          >0
     Default:        1
     Element Type:   Unsigned Integer
     Description:    The version of EBML parser used to create the EBML
Document.
@@ -347,7 +347,7 @@ Element Name:   EBMLReadVersion
     EBML ID:        [42][F7]
     Mandatory:      Yes
     Multiple:       No
-    Range:          -
+    Range:          >0
     Default:        1
     Element Type:   Unsigned Integer
     Description:    The minimum EBML version a parser has to support to
read this EBML Document.
--
2.8.0.rc2

--94eb2c05750ad302d505339cbbd0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I propose the following patch for t=
he EBML specification. Currently, EBMLVersion and EBMLReadVersion do not ha=
ve a range specified, suggesting the value 0 should be legal (albeit probab=
ly nonsensical).


From f0e547502890fa=
9efa0b966a08544f5b91f8ccd7 Mon Sep 17 00:00:00 2001
From: Michael=
 Bradshaw <mjbsh=
aw@google.com>
Date: Tue, 17 May 2016 10:14:42 -0700
=

Subject: [PATCH 1/1] Specify a range of >0 for EBMLVersion/EBMLRead=
Version

---
=C2=A0specification.markdown=
 | 4 ++--
=C2=A01 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/specification.markdown b/specification=
.markdown
index 3f262b9..3fb4b01 100644
--- a/specifica=
tion.markdown
+++ b/specification.markdown
@@ -336,7 +3=
36,7 @@ Element Name: =C2=A0 EBMLVersion
=C2=A0 =C2=A0 =C2=A0EBML=
 ID: =C2=A0 =C2=A0 =C2=A0 =C2=A0[42][86]
=C2=A0 =C2=A0 =C2=A0Mand=
atory: =C2=A0 =C2=A0 =C2=A0Yes
=C2=A0 =C2=A0 =C2=A0Multiple: =C2=
=A0 =C2=A0 =C2=A0 No
- =C2=A0 =C2=A0Range: =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0-
+ =C2=A0 =C2=A0Range: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0>0
=C2=A0 =C2=A0 =C2=A0Default: =C2=A0 =C2=A0 =C2=A0 =C2=
=A01
=C2=A0 =C2=A0 =C2=A0Element Type: =C2=A0 Unsigned Integer
=C2=A0 =C2=A0 =C2=A0Description: =C2=A0 =C2=A0The version of EBML p=
arser used to create the EBML Document.
@@ -347,7 +347,7 @@ Eleme=
nt Name: =C2=A0 EBMLReadVersion
=C2=A0 =C2=A0 =C2=A0EBML ID: =C2=
=A0 =C2=A0 =C2=A0 =C2=A0[42][F7]
=C2=A0 =C2=A0 =C2=A0Mandatory: =
=C2=A0 =C2=A0 =C2=A0Yes
=C2=A0 =C2=A0 =C2=A0Multiple: =C2=A0 =C2=
=A0 =C2=A0 No
- =C2=A0 =C2=A0Range: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0-
+ =C2=A0 =C2=A0Range: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&=
gt;0
=C2=A0 =C2=A0 =C2=A0Default: =C2=A0 =C2=A0 =C2=A0 =C2=A01
=C2=A0 =C2=A0 =C2=A0Element Type: =C2=A0 Unsigned Integer
=C2=A0 =C2=A0 =C2=A0Description: =C2=A0 =C2=A0The minimum EBML version a p=
arser has to support to read this EBML Document.
--
2.8=
.0.rc2


--94eb2c05750ad302d505339cbbd0--


From nobody Tue May 24 13:58:40 2016
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 CED8612D557 for ; Tue, 24 May 2016 13:58:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 0TY6ocyIFqK5 for ; Tue, 24 May 2016 13:58:36 -0700 (PDT)
Received: from 9.mo179.mail-out.ovh.net (9.mo179.mail-out.ovh.net [46.105.76.148]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73CEC12D555 for ; Tue, 24 May 2016 13:58:36 -0700 (PDT)
Received: from player792.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id 30764FF932E for ; Tue, 24 May 2016 22:58:30 +0200 (CEST)
Received: from [192.168.2.101] (p508BA9FB.dip0.t-ipconnect.de [80.139.169.251]) (Authenticated sender: jerome@francoallemand.eu) by player792.ha.ovh.net (Postfix) with ESMTPSA id D88F2A007B for ; Tue, 24 May 2016 22:58:29 +0200 (CEST)
From: Jerome Martinez 
To: cellar@ietf.org
Message-ID: <30dd9d6b-34ab-35fc-a88f-4aa5f3bd7df2@mediaarea.net>
Date: Tue, 24 May 2016 22:58:28 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------CD422D7979F67942400DD186"
X-Ovh-Tracer-Id: 13867990630382506129
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrgedugdduheegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc
Archived-At: 
Subject: [Cellar] [PATCH FFV1] Byte alignment is made explicit
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 20:58:39 -0000

This is a multi-part message in MIME format.
--------------CD422D7979F67942400DD186
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Currently, if we follow the specification, slice_size error_status, 
slice_crc_parity are not at the right place compared to what is written 
by the FFmpeg encoder because the specified bitstream is not aligned 
after the parsing of the last Line() in the case the count of bits 
written in the bitstream is not a multiple of 8, for Golomb Rice coding.
FFmpeg encoder just "closes" the bitstream with zero padding for the 
last byte of the bitstream then writes bytes. As the bitstream 
description does not do any difference between bits and bytes, this 
padding is not caught by the specification.

If we don't add such information in the specification, a decoder relying 
on the specification will not be able to read correctly slice_size 
error_status, slice_crc_parity in case it reads the bitstream in 
sequential order (e.g. no seek support and/or no complete frame 
available and/or corrupted slice_size).

This byte alignment procedure is not used for the Range Coder because 
the Range Coder uses bytes. Explicit definition about how to switch from 
Range Coder to Golomb Rice and vice versa will be added in a later patch.


--------------CD422D7979F67942400DD186
Content-Type: text/plain; charset=UTF-8;
 name="0001-Byte-alignment-is-made-explicit.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="0001-Byte-alignment-is-made-explicit.patch"

RnJvbSBmYmVkNDZhZDM4OTAwMTJjMGE2MDNkNzRmMWZiYjNkZGEyM2MyNDViIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Sj1DMz1BOXI9QzM9QjRtZT0yME1h
cnRpbmV6Pz0gPGplcm9tZUBtZWRpYWFyZWEubmV0PgpEYXRlOiBUdWUsIDI0IE1heSAyMDE2
IDIxOjMzOjE4ICswMjAwClN1YmplY3Q6IFtQQVRDSF0gQnl0ZSBhbGlnbm1lbnQgaXMgbWFk
ZSBleHBsaWNpdAoKV2l0aCBHb2xvbWIgUmljZSBjb2RpbmcgbW9kZSwgYml0cyBhcmUgY29u
c3VtZWQgb25lIHBlciBvbmUKYnV0IHRoZSBsYXN0IGJpdHMgaW4gdGhlIGJpdHN0cmVhbSAo
c2xpY2Vfc2l6ZSwgZXJyb3Jfc3RhdHVzLApzbGljZV9jcmNfcGFyaXR5KSBhcmUgYnl0ZSBh
bGlnbmVkLCBzbyB0aGVyZSBpcyBzb21lIHBhZGRpbmcKaW4gdGhlIGJpdHN0cmVhbSBiZWZv
cmUgc2xpY2Vfc2l6ZS4KLS0tCiBmZnYxLm1kIHwgOCArKysrKysrKwogMSBmaWxlIGNoYW5n
ZWQsIDggaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL2ZmdjEubWQgYi9mZnYxLm1kCmlu
ZGV4IGNmMjZhMTAuLjJkNWIzMzkgMTAwNjQ0Ci0tLSBhL2ZmdjEubWQKKysrIGIvZmZ2MS5t
ZApAQCAtMTUzLDYgKzE1Myw4IEBAIF9fYS4uLmJfXyBtZWFucyBhbnkgdmFsdWUgc3RhcnRp
bmcgZnJvbSBhIHRvIGIsIGluY2x1c2l2ZS4KIAogKipyZW1haW5pbmdcX2JpdHNcX2luXF9i
aXRzdHJlYW0owqApKiogbWVhbnMgdGhlIGNvdW50IG9mIHJlbWFpbmluZyBiaXRzIGFmdGVy
IHRoZSBjdXJyZW50IHBvc2l0aW9uIGluIHRoZSBiaXRzdHJlYW0uIEl0IGlzIGNvbXB1dGVk
IGZyb20gdGhlIE51bUJ5dGVzIHZhbHVlIG11bHRpcGxpZWQgYnkgOCBtaW51cyB0aGUgY291
bnQgb2YgYml0cyBhbHJlYWR5IHJlYWQgYnkgdGhlIGJpdHN0cmVhbSBwYXJzZXIuCiAKKyoq
Ynl0ZVxfYWxpZ25lZCjCoCkqKiBtZWFucyByZW1haW5pbmdcX2JpdHNcX2luXF9iaXRzdHJl
YW0oICkgJSA4IGlzIDAuCisKIFxwYWdlYnJlYWsKIAogIyBHZW5lcmFsIERlc2NyaXB0aW9u
CkBAIC01NDEsNiArNTQzLDkgQEAgU2VlIFtOVVRdKCNyZWZlcmVuY2VzKSBmb3IgbW9yZSBp
bmZvcm1hdGlvbiBhYm91dCBlbGVtZW50cy4KIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBm
b3IoIHAgPSAwOyBwIFw8IHByaW1hcnlcX2NvbG9yXF9jb3VudDsgcCsrICkgeyB8ICAgICAg
IHwKIHzCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoExpbmUoIHAsIHkgKSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8CiB8wqDCoMKgwqB9ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAg
ICAgfAorfMKgwqDCoMKgaWYgKCBjb2RlclxfdHlwZSApICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB8ICAgICAgIHwKK3wgICAgICAgIHdoaWxlICggIWJ5dGVcX2Fs
aWduZWQoKSApICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKK3zCoMKgwqDC
oMKgwqDCoMKgICAgIHBhZGRpbmcgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHwgIHUoMSkgfAogfMKgwqDCoMKgaWYoIGkgXHxcfCB2ZXJzaW9uIFw+IDIgKSAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKIHzCoMKgwqDCoMKgwqDC
oMKgc2xpY2VcX3NpemUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHwgdSgyNCkgfAogfMKgwqDCoMKgaWYoIGVjICkgeyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKQEAgLTU1MSw2ICs1NTYsOSBAQCBT
ZWUgW05VVF0oI3JlZmVyZW5jZXMpIGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IGVsZW1l
bnRzLgogCiAqKnByaW1hcnlcX2NvbG9yXF9jb3VudCoqIGlzIGRlZmluZWQgYXMgMSArICgg
Y2hyb21hX3BsYW5lcyA/IDIgOiAwICkgKyAoIGFscGhhX3BsYW5lID8gMSA6IDAgKS4KIAor
KipwYWRkaW5nKiogc3BlY2lmaWVzIGEgYml0IHdpdGhvdXQgYW55IHNpZ25pZmljYW5jZSBh
bmQgdXNlZCBvbmx5IGZvciBieXRlIGFsaWdubWVudC4KK01VU1QgYmUgMC4KKwogKipzbGlj
ZV9zaXplKiogaW5kaWNhdGVzIHRoZSBzaXplIG9mIHRoZSBzbGljZSBpbiBieXRlcy4KIE5v
dGU6IHRoaXMgYWxsb3dzIGZpbmRpbmcgdGhlIHN0YXJ0IG9mIHNsaWNlcyBiZWZvcmUgcHJl
dmlvdXMgc2xpY2VzIGhhdmUgYmVlbiBmdWxseSBkZWNvZGVkLiBBbmQgYWxsb3dzIHRoaXMg
d2F5IHBhcmFsbGVsIGRlY29kaW5nIGFzIHdlbGwgYXMgZXJyb3IgcmVzaWxpZW5jZS4KIAot
LSAKMi43LjAud2luZG93cy4xCgo=
--------------CD422D7979F67942400DD186--


From nobody Tue May 24 13:58:55 2016
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 99F2212D557 for ; Tue, 24 May 2016 13:58:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 FEdz_OWa_hF4 for ; Tue, 24 May 2016 13:58:51 -0700 (PDT)
Received: from 2.mo179.mail-out.ovh.net (2.mo179.mail-out.ovh.net [178.33.250.45]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DA6F12D515 for ; Tue, 24 May 2016 13:58:51 -0700 (PDT)
Received: from player792.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id D0708FF9364 for ; Tue, 24 May 2016 22:58:44 +0200 (CEST)
Received: from [192.168.2.101] (p508BA9FB.dip0.t-ipconnect.de [80.139.169.251]) (Authenticated sender: jerome@francoallemand.eu) by player792.ha.ovh.net (Postfix) with ESMTPSA id B3EC3A0068 for ; Tue, 24 May 2016 22:58:44 +0200 (CEST)
From: Jerome Martinez 
To: cellar@ietf.org
Message-ID: <2c72211a-372c-61b5-7eea-015eca939bd0@mediaarea.net>
Date: Tue, 24 May 2016 22:58:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------2D61F97E40F6014E7D739FB0"
X-Ovh-Tracer-Id: 13872212752646213777
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrgedugdduheegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc
Archived-At: 
Subject: [Cellar] [PATCH FFV1] Multi-threading support and independence of slices
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 20:58:53 -0000

This is a multi-part message in MIME format.
--------------2D61F97E40F6014E7D739FB0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

This patch adds an appendix with some sentences about how to have 
multi-thread support in the decoder.

--------------2D61F97E40F6014E7D739FB0
Content-Type: text/plain; charset=UTF-8;
 name="0001-Multi-threading-support-and-independence-of-slices.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename*0="0001-Multi-threading-support-and-independence-of-slices.patc";
 filename*1="h"

RnJvbSAwMGQ2OTg4N2JlZGM1ZDkyYmQxZGY3NTI5ZTY3YTUwMGE5ZDc4MDQwIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Sj1DMz1BOXI9QzM9QjRtZT0yME1h
cnRpbmV6Pz0gPGplcm9tZUBtZWRpYWFyZWEubmV0PgpEYXRlOiBUdWUsIDI0IE1heSAyMDE2
IDIyOjUzOjI3ICswMjAwClN1YmplY3Q6IFtQQVRDSF0gTXVsdGktdGhyZWFkaW5nIHN1cHBv
cnQgYW5kIGluZGVwZW5kZW5jZSBvZiBzbGljZXMKCkFkZCBhbiBhcHBlbmRpeCB3aXRoIHN1
Z2dlc3Rpb24gYWJvdXQgaG93IHRvIHBhcnNlIHNsaWNlcyBpbiBvcmRlcgp0byBoYXZlIE11
bHRpLXRocmVhZGluZyBzdXBwb3J0IGFuZCBpbmRlcGVuZGVuY2Ugb2Ygc2xpY2VzLgotLS0K
IGZmdjEubWQgfCAyNiArKysrKysrKysrKysrKysrKysrKysrKysrKwogMSBmaWxlIGNoYW5n
ZWQsIDI2IGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9mZnYxLm1kIGIvZmZ2MS5tZApp
bmRleCBjZjI2YTEwLi41MGM5OTY2IDEwMDY0NAotLS0gYS9mZnYxLm1kCisrKyBiL2ZmdjEu
bWQKQEAgLTg1Niw2ICs4NTYsMzIgQEAgRm9yIGVhY2ggZnJhbWUsIGVhY2ggcG9zaXRpb24g
aW4gdGhlIHNsaWNlIHJhc3RlciBNVVNUIGJlIGZpbGxlZCBieSBvbmUgYW5kIG9ubHkKIAog
Rm9yIGVhY2ggRnJhbWUgd2l0aCBrZXlmcmFtZSB2YWx1ZSBvZiAwLCBlYWNoIHNsaWNlIE1V
U1QgaGF2ZSB0aGUgc2FtZSB2YWx1ZSBvZiBzbGljZVxfeCwgc2xpY2VcX3ksIHNsaWNlXF93
aWR0aCwgc2xpY2VcX2hlaWdodCBhcyBhIHNsaWNlIGluIHRoZSBwcmV2aW91cyBmcmFtZSwg
ZXhjZXB0IGlmIHJlc2V0XF9jb250ZXh0cyBpcyAxLgogCisjIEFwcGVuZGl4ZXMKKworIyMg
RGVjb2RlciBpbXBsZW1lbnRhdGlvbiBzdWdnZXN0aW9ucworCisjIyMgTXVsdGktdGhyZWFk
aW5nIHN1cHBvcnQgYW5kIGluZGVwZW5kZW5jZSBvZiBzbGljZXMKKworVGhlIGJpdHN0cmVh
bSBpcyBwYXJzYWJsZSBpbiB0d28gd2F5czogaW4gc2VxdWVudGlhbCBvcmRlciBhcyBkZXNj
cmliZWQgaW4gdGhpcyBkb2N1bWVudCBvciB3aXRoIHRoZSBwcmUtYW5hbHlzaXMgb2Ygc2xp
Y2VcX3NpemUgZmllbGRzLiBzbGljZVxfc2l6ZSBmaWVsZHMgcHJlLWFuYWx5c2lzIGFsbG93
cyBtdWx0aS10aHJlYWRpbmcgYXMgd2VsbCBhcyBpbmRlcGVuZGVuY2Ugb2Ygc2xpY2UgY29u
dGVudCAoYSBiaXRzdHJlYW0gZXJyb3IgaW4gYSBzbGljZSBjb250ZW50IGhhcyBubyBpbXBh
Y3Qgb24gdGhlIGRlY29kaW5nIG9mIHRoZSBvdGhlciBzbGljZXMpLgorCitBZnRlciBoYXZp
bmcgY2hlY2tlZCBrZXlmcmFtZSBmaWVsZCwgYSBkZWNvZGVyIFNIT1VMRCBwYXJzZSBzbGlj
ZV9zaXplIGZpZWxkcywgZnJvbSBzbGljZVxfc2l6ZSBvZiB0aGUgbGFzdCBzbGljZSBhdCB0
aGUgZW5kIG9mIHRoZSBmcmFtZSB1cCB0byBzbGljZVxfc2l6ZSBvZiB0aGUgZmlyc3Qgc2xp
Y2UgYXQgdGhlIGJlZ2lubmluZyBvZiB0aGUgZnJhbWUsIGJlZm9yZSBwYXJzaW5nIHNsaWNl
cywgaW4gb3JkZXIgdG8gaGF2ZSBzbGljZXMgYm91bmRhcmllcy4gQSBkZWNvZGVyIE1BWSBm
YWxsYmFjayBvbiBzZXF1ZW50aWFsIG9yZGVyIGUuZy4gaW4gY2FzZSBvZiBjb3JydXB0ZWQg
ZnJhbWUgKGZyYW1lIHNpemUgdW5rbm93biwgc2xpY2VcX3NpemUgb2Ygc2xpY2VzIG5vdCBj
b2hlcmFudC4uLikgb3IgaWYgdGhlcmUgaXMgbm8gcG9zc2liaWxpdHkgb2Ygc2VlayBpbnRv
IHRoZSBzdHJlYW0uCisKK0FyY2hpdGVjdHVyZSBvdmVyd2lldyBvZiBzbGljZXMgaW4gYSBm
cmFtZToKKworfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIHwKK3w6LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18Cit8IGZpcnN0IHNsaWNlIGNvbnRl
bnQgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAorfCBmaXJz
dCBzbGljZSBzbGljZVxfc2l6ZSArIGVycm9yXF9zdGF0dXMgKyBzbGljZVxfY3JjXF9wYXJp
dHkgIHwKK3wtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS18Cit8IHNlY29uZCBzbGljZSBjb250ZW50ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAorfCBzZWNvbmQgc2xpY2Ugc2xpY2Vc
X3NpemUgKyBlcnJvclxfc3RhdHVzICsgc2xpY2VcX2NyY1xfcGFyaXR5IHwKK3wtLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS18Cit8IC4uLiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgfAorfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwKK3wgbGFzdCBzbGljZSBjb250ZW50ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8Cit8IGxhc3Qgc2xp
Y2Ugc2xpY2VcX3NpemUgKyBlcnJvclxfc3RhdHVzICsgc2xpY2VcX2NyY1xfcGFyaXR5ICAg
fAorCisKICMgQ2hhbmdlbG9nCiAKIFNlZSA8aHR0cHM6Ly9naXRodWIuY29tL0ZGbXBlZy9G
RlYxL2NvbW1pdHMvbWFzdGVyPgotLSAKMi43LjAud2luZG93cy4xCgo=
--------------2D61F97E40F6014E7D739FB0--


From nobody Tue May 24 14:47:50 2016
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 E86B312D817 for ; Tue, 24 May 2016 14:47:48 -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 Vq-2sMxKIVXf for ; Tue, 24 May 2016 14:47:47 -0700 (PDT)
Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 8E0ED12D612 for ; Tue, 24 May 2016 14:47:47 -0700 (PDT)
Received: from eris.local (dynamic-adsl-84-220-81-12.clienti.tiscali.it [84.220.81.12]) (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 4D1FC340CF8 for ; Tue, 24 May 2016 21:47:45 +0000 (UTC)
To: cellar@ietf.org
References: 
From: Luca Barbato 
Message-ID: 
Date: Tue, 24 May 2016 23:47:40 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Cellar] [PATCH 1/1] Specify a range of >0 for EBMLVersion/EBMLReadVersion
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 21:47:49 -0000

On 24/05/16 22:52, Michael Bradshaw wrote:
> Hi,
> 
> I propose the following patch for the EBML specification. Currently,
> EBMLVersion and EBMLReadVersion do not have a range specified, suggesting
> the value 0 should be legal (albeit probably nonsensical).
> 
> 
>>From f0e547502890fa9efa0b966a08544f5b91f8ccd7 Mon Sep 17 00:00:00 2001
> From: Michael Bradshaw 
> Date: Tue, 17 May 2016 10:14:42 -0700
> Subject: [PATCH 1/1] Specify a range of >0 for EBMLVersion/EBMLReadVersion
> 
> ---
>  specification.markdown | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/specification.markdown b/specification.markdown
> index 3f262b9..3fb4b01 100644
> --- a/specification.markdown
> +++ b/specification.markdown
> @@ -336,7 +336,7 @@ Element Name:   EBMLVersion
>      EBML ID:        [42][86]
>      Mandatory:      Yes
>      Multiple:       No
> -    Range:          -
> +    Range:          >0
>      Default:        1
>      Element Type:   Unsigned Integer
>      Description:    The version of EBML parser used to create the EBML
> Document.
> @@ -347,7 +347,7 @@ Element Name:   EBMLReadVersion
>      EBML ID:        [42][F7]
>      Mandatory:      Yes
>      Multiple:       No
> -    Range:          -
> +    Range:          >0
>      Default:        1
>      Element Type:   Unsigned Integer
>      Description:    The minimum EBML version a parser has to support to
> read this EBML Document.
> --
> 2.8.0.rc2
> 

>=0 then ?


From nobody Tue May 24 14:50:47 2016
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 A4DDE12D9E0 for ; Tue, 24 May 2016 14:50:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.426
X-Spam-Level: 
X-Spam-Status: No, score=-3.426 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 u7Vb7Pk3yM28 for ; Tue, 24 May 2016 14:50:44 -0700 (PDT)
Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 A57B312D9CA for ; Tue, 24 May 2016 14:50:44 -0700 (PDT)
Received: by mail-it0-x229.google.com with SMTP id e62so60332207ita.1 for ; Tue, 24 May 2016 14:50:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N9oinmxRRmCMjc63P+pPmLPm9x8OyWsk3YaT4t3XhTI=; b=ZIRp5dCAgeoi+kENX3PmrjCe4D4fHSNjS1LqKh2AvpSKvUFEclmcrhYIGelEL7eCxP XfPdWIMamMU7WrH6JcOvj0pVmVZ0PswpnGdRTpXve4rQqaNjvCoLknkagslm3RElY2YU iSPzGQDsObFaSvnaDVYtWQ0aAKZ8Bs3utaweGQRmIZ/oaFyYOS+gFwAdRcJg+cJIfF+Y xPKRkUHgS4suOU7rT1UJHuU1V63VXCCb8YAtAbJkF3Py3Nz8WkiY2WjK//VGKdjzn/59 q72f3ifuJfNUgbXgqFb86tB5JaU1QfvgapM0xz1s1xi3E4g1QgX5rmWKvHSw34h9Gnco ThAQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N9oinmxRRmCMjc63P+pPmLPm9x8OyWsk3YaT4t3XhTI=; b=ORMxTyKjOYpe8PUG630wgf0Hlwr56lJZcPaWYjAjgXKewa2UhnFiZRFhSSIAXQjoAu vF/QViyqUfle4egW02awLh4ysDDXAUD7zS6+msXXw3QEq5ifCwYcgxR0+RDB0mTPA4or /akw4Vesng73kYu4g0zDFUVaYKpN6FNxL7haqbDuWmqfuAs8bV9oqs9A6lpTdugzTDlw /5rnHmPd6f7+cZcpietYYDyLStJoHj6FNltuXCwA3zJfvjKoTgJwyaf1vV4Om/2ezGLc mUhOfDOLYYRP7MG9bu+uiDflLoIb6/gEnnsLZrgP2nMvWL01BeE1jJ2rq5fDxOWcDU4w 4Rhg==
X-Gm-Message-State: ALyK8tI92UpRoNYpk/F8nPt9yJO0cgZgOWap4TTl0pgb4yNDcDUj/Z5dzm6CEpj+OnNMXX29CtMsTijGVVMNlMNY
X-Received: by 10.36.120.83 with SMTP id p80mr958243itc.46.1464126643950; Tue, 24 May 2016 14:50:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.15.22 with HTTP; Tue, 24 May 2016 14:50:24 -0700 (PDT)
In-Reply-To: 
References:  
From: Michael Bradshaw 
Date: Tue, 24 May 2016 14:50:24 -0700
Message-ID: 
To: Luca Barbato 
Content-Type: multipart/alternative; boundary=001a114abc36851fdc05339d8c91
Archived-At: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] [PATCH 1/1] Specify a range of >0 for EBMLVersion/EBMLReadVersion
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 21:50:45 -0000

--001a114abc36851fdc05339d8c91
Content-Type: text/plain; charset=UTF-8

On Tue, May 24, 2016 at 2:47 PM, Luca Barbato 
wrote:
>
> >=0 then ?


But what does EBML version 0 even mean? I'm not aware of it being a valid
EBML version.

--001a114abc36851fdc05339d8c91
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On T=
ue, May 24, 2016 at 2:47 PM, Luca Barbato <luca.barbato@libav.org=
> wrote:
>=3D0 then ?

But what does EBML version 0 even mean? I'm not a=
ware of it being a valid EBML version.


--001a114abc36851fdc05339d8c91--


From nobody Tue May 24 14:54:34 2016
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 41AE312D9D5 for ; Tue, 24 May 2016 14:54:33 -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 j_ITmA7XMft7 for ; Tue, 24 May 2016 14:54:31 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 B5C6B12D55D for ; Tue, 24 May 2016 14:54:31 -0700 (PDT)
Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:42608 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b5KHV-003QkL-SG for cellar@ietf.org; Tue, 24 May 2016 17:54:31 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dave Rice 
In-Reply-To: 
Date: Tue, 24 May 2016 17:54:27 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <99F7F8B9-86D7-4A91-99A8-B700C7857EDE@dericed.com>
References:  
To: cellar@ietf.org
X-Mailer: Apple Mail (2.3124)
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] [PATCH 1/1] Specify a range of >0 for EBMLVersion/EBMLReadVersion
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 21:54:33 -0000

> On May 24, 2016, at 5:47 PM, Luca Barbato  =
wrote:
>=20
> On 24/05/16 22:52, Michael Bradshaw wrote:
>> Hi,
>>=20
>> I propose the following patch for the EBML specification. Currently,
>> EBMLVersion and EBMLReadVersion do not have a range specified, =
suggesting
>> the value 0 should be legal (albeit probably nonsensical).
>>=20
>>=20
>>> =46rom f0e547502890fa9efa0b966a08544f5b91f8ccd7 Mon Sep 17 00:00:00 =
2001
>> From: Michael Bradshaw 
>> Date: Tue, 17 May 2016 10:14:42 -0700
>> Subject: [PATCH 1/1] Specify a range of >0 for =
EBMLVersion/EBMLReadVersion
>>=20
>> ---
>> specification.markdown | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>=20
>> diff --git a/specification.markdown b/specification.markdown
>> index 3f262b9..3fb4b01 100644
>> --- a/specification.markdown
>> +++ b/specification.markdown
>> @@ -336,7 +336,7 @@ Element Name:   EBMLVersion
>>     EBML ID:        [42][86]
>>     Mandatory:      Yes
>>     Multiple:       No
>> -    Range:          -
>> +    Range:          >0

AFAIK there have only ever been one version of EBML. With EBMLVersion=3D1.=
 Perhaps instead of ">0=E2=80=9D, we could simply say =E2=80=9C1=E2=80=9D =
as no other value is valid. Someday if IETF defines a version 2 of EBML =
than the Range can be updated to =E2=80=9C1-2=E2=80=9D and so on.

>>     Default:        1
>>     Element Type:   Unsigned Integer
>>     Description:    The version of EBML parser used to create the =
EBML
>> Document.

I never really looked at this description too closely but perhaps this =
should reference the version of the EBML specification rather than the =
EBML parser. The version of the parser (i.e. libebml) is not what is =
intended here.

>> @@ -347,7 +347,7 @@ Element Name:   EBMLReadVersion
>>     EBML ID:        [42][F7]
>>     Mandatory:      Yes
>>     Multiple:       No
>> -    Range:          -
>> +    Range:          >0

Same comment as above.

>>     Default:        1
>>     Element Type:   Unsigned Integer
>>     Description:    The minimum EBML version a parser has to support =
to
>> read this EBML Document.
>> --
>> 2.8.0.rc2
>>=20
>=20
>> =3D0 then ?
>=20
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar


From nobody Tue May 24 16:34:39 2016
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 E5FDA12D5CD for ; Tue, 24 May 2016 16:34:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 oJYdjzYgWelo for ; Tue, 24 May 2016 16:34:36 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EFD12D5CE for ; Tue, 24 May 2016 16:34:33 -0700 (PDT)
Received: from mfilter48-d.gandi.net (mfilter48-d.gandi.net [217.70.178.179]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 2F343A80BF for ; Wed, 25 May 2016 01:34:32 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter48-d.gandi.net
Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter48-d.gandi.net (mfilter48-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id heLqlbHbk9aa for ; Wed, 25 May 2016 01:34:30 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 6B81FA80CD for ; Wed, 25 May 2016 01:34:29 +0200 (CEST)
Date: Wed, 25 May 2016 01:32:12 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160524233212.GR25812@nb4>
References: <30dd9d6b-34ab-35fc-a88f-4aa5f3bd7df2@mediaarea.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M+f5tIRTKmS7LOkh"
Content-Disposition: inline
In-Reply-To: <30dd9d6b-34ab-35fc-a88f-4aa5f3bd7df2@mediaarea.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Byte alignment is made explicit
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 23:34:38 -0000

--M+f5tIRTKmS7LOkh
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 24, 2016 at 10:58:28PM +0200, Jerome Martinez wrote:
> Currently, if we follow the specification, slice_size error_status,
> slice_crc_parity are not at the right place compared to what is
> written by the FFmpeg encoder because the specified bitstream is not
> aligned after the parsing of the last Line() in the case the count
> of bits written in the bitstream is not a multiple of 8, for Golomb
> Rice coding.
> FFmpeg encoder just "closes" the bitstream with zero padding for the
> last byte of the bitstream then writes bytes. As the bitstream
> description does not do any difference between bits and bytes, this
> padding is not caught by the specification.
>=20
> If we don't add such information in the specification, a decoder
> relying on the specification will not be able to read correctly
> slice_size error_status, slice_crc_parity in case it reads the
> bitstream in sequential order (e.g. no seek support and/or no
> complete frame available and/or corrupted slice_size).
>=20
> This byte alignment procedure is not used for the Range Coder
> because the Range Coder uses bytes. Explicit definition about how to
> switch from Range Coder to Golomb Rice and vice versa will be added
> in a later patch.
>=20

>  ffv1.md |    8 ++++++++
>  1 file changed, 8 insertions(+)
> d7edd8f81e9f520bd632a3bc4933bbe2fd6e3e59  0001-Byte-alignment-is-made-exp=
licit.patch
> From fbed46ad3890012c0a603d74f1fbb3dda23c245b Mon Sep 17 00:00:00 2001
> From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D 
> Date: Tue, 24 May 2016 21:33:18 +0200
> Subject: [PATCH] Byte alignment is made explicit
>=20
> With Golomb Rice coding mode, bits are consumed one per one
> but the last bits in the bitstream (slice_size, error_status,
> slice_crc_parity) are byte aligned, so there is some padding
> in the bitstream before slice_size.
> ---
>  ffv1.md | 8 ++++++++
>  1 file changed, 8 insertions(+)
>=20
> diff --git a/ffv1.md b/ffv1.md
> index cf26a10..2d5b339 100644
> --- a/ffv1.md
> +++ b/ffv1.md
> @@ -153,6 +153,8 @@ __a...b__ means any value starting from a to b, inclu=
sive.
> =20
>  **remaining\_bits\_in\_bitstream(=A0)** means the count of remaining bit=
s after the current position in the bitstream. It is computed from the NumB=
ytes value multiplied by 8 minus the count of bits already read by the bits=
tream parser.
> =20
> +**byte\_aligned(=A0)** means remaining\_bits\_in\_bitstream( ) % 8 is 0.
> +
>  \pagebreak
> =20
>  # General Description
> @@ -541,6 +543,9 @@ See [NUT](#references) for more information about ele=
ments.
>  |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0for( p =3D 0; p \< primary\_color\_=
count; p++ ) { |       |
>  |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Line( p, y )           =
                     |       |
>  |=A0=A0=A0=A0}                                                       |  =
     |


> +|=A0=A0=A0=A0if ( coder\_type )                                      |  =
     |

coder_type =3D=3D 0


> +|        while ( !byte\_aligned() )                          |       |
> +|=A0=A0=A0=A0=A0=A0=A0=A0    padding                                    =
     |  u(1) |
>  |=A0=A0=A0=A0if( i \|\| version \> 2 )                               |  =
     |
>  |=A0=A0=A0=A0=A0=A0=A0=A0slice\_size                                    =
     | u(24) |
>  |=A0=A0=A0=A0if( ec ) {                                              |  =
     |
> @@ -551,6 +556,9 @@ See [NUT](#references) for more information about ele=
ments.
> =20
>  **primary\_color\_count** is defined as 1 + ( chroma_planes ? 2 : 0 ) + =
( alpha_plane ? 1 : 0 ).
> =20
> +**padding** specifies a bit without any significance and used only for b=
yte alignment.
> +MUST be 0.

ok, i suggest though to change this for the next version of the
bitstream
its better to write a 1 bit and then pad with 0 to a byte boundary
or (0 bit + padding with 1) that way the end of the previous bitstream
can be determind with certanity from the last byte

[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire

--M+f5tIRTKmS7LOkh
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAldE5HwACgkQYR7HhwQLD6vUvgCghDNJQB+rS2bV0/YFSdhD+YIa
JXwAn30lP3YCTEiyO5pZ3pzut6l/9TxI
=Kv4F
-----END PGP SIGNATURE-----

--M+f5tIRTKmS7LOkh--


From nobody Tue May 24 16:48:00 2016
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 7795F12D5D4 for ; Tue, 24 May 2016 16:47:58 -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 HemJr5R03qfQ for ; Tue, 24 May 2016 16:47:57 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 D6AF212D866 for ; Tue, 24 May 2016 16:47:56 -0700 (PDT)
Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:44608 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b5M3E-001mPe-68; Tue, 24 May 2016 19:47:55 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_D56713ED-FBCE-43CF-8789-95DA1C0363F4"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dave Rice 
In-Reply-To: 
Date: Tue, 24 May 2016 19:47:34 -0400
Message-Id: 
References:   
To: Michael Bradshaw 
X-Mailer: Apple Mail (2.3124)
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: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] [PATCH 1/1] Specify a range of >0 for EBMLVersion/EBMLReadVersion
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 24 May 2016 23:47:58 -0000

--Apple-Mail=_D56713ED-FBCE-43CF-8789-95DA1C0363F4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On May 24, 2016, at 5:50 PM, Michael Bradshaw  =
wrote:
>=20
> On Tue, May 24, 2016 at 2:47 PM, Luca Barbato > wrote:
> >=3D0 then ?
>=20
> But what does EBML version 0 even mean? I'm not aware of it being a =
valid EBML version.

Of a sample set of online 84,523 mkv files, 20,808 do not store the =
EBMLVersion element (so the default is =E2=80=981=E2=80=99) and 63,715 =
set EBMLVersion to 1, and no samples were found to have an EBMLVersion =
value that was not interpreted as version 1. Still I think it=E2=80=99s =
a good idea to discourage implementations of EBMLVersion that are =
confusing in meaning, so a range restriction makes sense to me.
Dave Rice=

--Apple-Mail=_D56713ED-FBCE-43CF-8789-95DA1C0363F4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On May 24, 2016, at 5:50 PM, Michael Bradshaw <mjbshaw@google.com> =
wrote:

On Tue, May 24, 2016 at 2:47 PM, Luca Barbato =
<luca.barbato@libav.org> =
wrote:
>=3D0 then =
?

But =
what does EBML version 0 even mean? I'm not aware of it being a valid =
EBML version.

Of a sample set of online 84,523 mkv files, 20,808 =
do not store the EBMLVersion element (so the default is =E2=80=981=E2=80=99=
) and 63,715 set EBMLVersion to 1, and no samples were found to have an =
EBMLVersion value that was not interpreted as version 1. Still I think =
it=E2=80=99s a good idea to discourage implementations of EBMLVersion =
that are confusing in meaning, so a range restriction makes sense to =
me.
Dave Rice
=

--Apple-Mail=_D56713ED-FBCE-43CF-8789-95DA1C0363F4--


From nobody Tue May 24 18:41:52 2016
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 CEEDF12DA18 for ; Tue, 24 May 2016 18:41:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 Bpu9Rl0zPl1e for ; Tue, 24 May 2016 18:41:49 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62C1A12D754 for ; Tue, 24 May 2016 18:41:49 -0700 (PDT)
Received: from mfilter38-d.gandi.net (mfilter38-d.gandi.net [217.70.178.169]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id BA3CF172094 for ; Wed, 25 May 2016 03:41:47 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter38-d.gandi.net
Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter38-d.gandi.net (mfilter38-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id ed0mxRt9G0MN for ; Wed, 25 May 2016 03:41:46 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 2A210172098 for ; Wed, 25 May 2016 03:41:45 +0200 (CEST)
Date: Wed, 25 May 2016 03:39:28 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160525013928.GS25812@nb4>
References: <2c72211a-372c-61b5-7eea-015eca939bd0@mediaarea.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CcEX1VDmJIG7NQW/"
Content-Disposition: inline
In-Reply-To: <2c72211a-372c-61b5-7eea-015eca939bd0@mediaarea.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Multi-threading support and independence of slices
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 01:41:51 -0000

--CcEX1VDmJIG7NQW/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 24, 2016 at 10:58:44PM +0200, Jerome Martinez wrote:
> This patch adds an appendix with some sentences about how to have
> multi-thread support in the decoder.

>  ffv1.md |   26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> dd63bcdf45a5687d57be9cf6b344ff7f38044c6b  0001-Multi-threading-support-an=
d-independence-of-slices.patch
> From 00d69887bedc5d92bd1df7529e67a500a9d78040 Mon Sep 17 00:00:00 2001
> From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D 
> Date: Tue, 24 May 2016 22:53:27 +0200
> Subject: [PATCH] Multi-threading support and independence of slices
>=20
> Add an appendix with suggestion about how to parse slices in order
> to have Multi-threading support and independence of slices.

applied

thanks

[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway

--CcEX1VDmJIG7NQW/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAldFAlAACgkQYR7HhwQLD6vUIgCcD+71pvDVrd7DchDnQ0W8v9JE
JsUAnjWkv2vPd3+wWWRf7X+OXwWFeAOe
=Qg3H
-----END PGP SIGNATURE-----

--CcEX1VDmJIG7NQW/--


From nobody Tue May 24 23:41:35 2016
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 A22A712D637 for ; Tue, 24 May 2016 23:41:33 -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 ojUFUTQHMu-V for ; Tue, 24 May 2016 23:41:30 -0700 (PDT)
Received: from 1.mo179.mail-out.ovh.net (1.mo179.mail-out.ovh.net [178.33.111.220]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE1B12D631 for ; Tue, 24 May 2016 23:41:24 -0700 (PDT)
Received: from player792.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id 812BBFF8C67 for ; Wed, 25 May 2016 08:41:22 +0200 (CEST)
Received: from [192.168.2.101] (p508BA9FB.dip0.t-ipconnect.de [80.139.169.251]) (Authenticated sender: jerome@francoallemand.eu) by player792.ha.ovh.net (Postfix) with ESMTPSA id 5AEECA0074 for ; Wed, 25 May 2016 08:41:22 +0200 (CEST)
To: cellar@ietf.org
References: <30dd9d6b-34ab-35fc-a88f-4aa5f3bd7df2@mediaarea.net> <20160524233212.GR25812@nb4>
From: Jerome Martinez 
Message-ID: <8a079bdb-749b-bb90-7539-ade377d5274f@mediaarea.net>
Date: Wed, 25 May 2016 08:41:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160524233212.GR25812@nb4>
Content-Type: multipart/mixed; boundary="------------16323633359D191BC5E75E1D"
X-Ovh-Tracer-Id: 5265270918236934289
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrgedvgdduudehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Byte alignment is made explicit
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 06:41:34 -0000

This is a multi-part message in MIME format.
--------------16323633359D191BC5E75E1D
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Le 25/05/2016  01:32, Michael Niedermayer a crit :
> On Tue, May 24, 2016 at 10:58:28PM +0200, Jerome Martinez wrote:
> [...]
>>   
>>   # General Description
>> @@ -541,6 +543,9 @@ See [NUT](#references) for more information about elements.
>>   |            for( p = 0; p \< primary\_color\_count; p++ ) { |       |
>>   |                Line( p, y )                                |       |
>>   |    }                                                       |       |
>> +|    if ( coder\_type )                                      |       |
> coder_type == 0

Oops, very stupid typo.
Fixed.

>
>
>> +|        while ( !byte\_aligned() )                          |       |
>> +|            padding                                         |  u(1) |
>>   |    if( i \|\| version \> 2 )                               |       |
>>   |        slice\_size                                         | u(24) |
>>   |    if( ec ) {                                              |       |
>> @@ -551,6 +556,9 @@ See [NUT](#references) for more information about elements.
>>   
>>   **primary\_color\_count** is defined as 1 + ( chroma_planes ? 2 : 0 ) + ( alpha_plane ? 1 : 0 ).
>>   
>> +**padding** specifies a bit without any significance and used only for byte alignment.
>> +MUST be 0.
> ok, i suggest though to change this for the next version of the
> bitstream
> its better to write a 1 bit and then pad with 0 to a byte boundary
> or (0 bit + padding with 1) that way the end of the previous bitstream
> can be determind with certanity from the last byte

I keep it in mind for when I open discussions about v4+ improvements.

Jrme

--------------16323633359D191BC5E75E1D
Content-Type: text/plain; charset=UTF-8;
 name="0001-PATCH-Byte-alignment-is-made-explicit.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename="0001-PATCH-Byte-alignment-is-made-explicit.patch"

>From ec4b9647c45834102e278d5f573e9180d13b6fde Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Wed, 25 May 2016 08:28:37 +0200
Subject: [PATCH] [PATCH] Byte alignment is made explicit

With Golomb Rice coding mode, bits are consumed one per one
but the last bits in the bitstream (slice_size, error_status,
slice_crc_parity) are byte aligned, so there is some padding
in the bitstream before slice_size.
---
 ffv1.md | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/ffv1.md b/ffv1.md
index cf26a10..f2e1a7c 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -153,6 +153,8 @@ __a...b__ means any value starting from a to b, inclusive.
 
 **remaining\_bits\_in\_bitstream( )** means the count of remaining bits after the current position in the bitstream. It is computed from the NumBytes value multiplied by 8 minus the count of bits already read by the bitstream parser.
 
+**byte\_aligned( )** means remaining\_bits\_in\_bitstream( ) % 8 is 0.
+
 \pagebreak
 
 # General Description
@@ -541,6 +543,9 @@ See [NUT](#references) for more information about elements.
 |            for( p = 0; p \< primary\_color\_count; p++ ) { |       |
 |                Line( p, y )                                |       |
 |    }                                                       |       |
+|    if ( coder\_type == 0 )                                 |       |
+|        while ( !byte\_aligned() )                          |       |
+|            padding                                         |  u(1) |
 |    if( i \|\| version \> 2 )                               |       |
 |        slice\_size                                         | u(24) |
 |    if( ec ) {                                              |       |
@@ -551,6 +556,9 @@ See [NUT](#references) for more information about elements.
 
 **primary\_color\_count** is defined as 1 + ( chroma_planes ? 2 : 0 ) + ( alpha_plane ? 1 : 0 ).
 
+**padding** specifies a bit without any significance and used only for byte alignment.
+MUST be 0.
+
 **slice_size** indicates the size of the slice in bytes.
 Note: this allows finding the start of slices before previous slices have been fully decoded. And allows this way parallel decoding as well as error resilience.
 
-- 
2.7.0.windows.1


--------------16323633359D191BC5E75E1D--


From nobody Wed May 25 07:07:41 2016
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 CBC3212DBB5 for ; Wed, 25 May 2016 07:07:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ISAnZHr9I4uJ for ; Wed, 25 May 2016 07:07:38 -0700 (PDT)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:c:538::198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A0812D6E4 for ; Wed, 25 May 2016 07:04:47 -0700 (PDT)
Received: from mfilter17-d.gandi.net (mfilter17-d.gandi.net [217.70.178.145]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 5DE8BFBA35 for ; Wed, 25 May 2016 16:04:46 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter17-d.gandi.net
Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter17-d.gandi.net (mfilter17-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id DZlAwgDpx1eb for ; Wed, 25 May 2016 16:04:44 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 84CC1FBA04 for ; Wed, 25 May 2016 16:04:44 +0200 (CEST)
Date: Wed, 25 May 2016 16:02:26 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160525140226.GT25812@nb4>
References: <30dd9d6b-34ab-35fc-a88f-4aa5f3bd7df2@mediaarea.net> <20160524233212.GR25812@nb4> <8a079bdb-749b-bb90-7539-ade377d5274f@mediaarea.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="h3lEC1ebzWnCI526"
Content-Disposition: inline
In-Reply-To: <8a079bdb-749b-bb90-7539-ade377d5274f@mediaarea.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1] Byte alignment is made explicit
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 14:07:40 -0000

--h3lEC1ebzWnCI526
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 25, 2016 at 08:41:21AM +0200, Jerome Martinez wrote:
> Le 25/05/2016 =E0 01:32, Michael Niedermayer a =E9crit :
> >On Tue, May 24, 2016 at 10:58:28PM +0200, Jerome Martinez wrote:
> >[...]
> >>  # General Description
> >>@@ -541,6 +543,9 @@ See [NUT](#references) for more information about e=
lements.
> >>  |            for( p =3D 0; p \< primary\_color\_count; p++ ) { |     =
  |
> >>  |                Line( p, y )                                |       |
> >>  |    }                                                       |       |
> >>+|    if ( coder\_type )                                      |       |
> >coder_type =3D=3D 0
>=20
> Oops, very stupid typo.
> Fixed.
>=20
> >
> >
> >>+|        while ( !byte\_aligned() )                          |       |
> >>+|            padding                                         |  u(1) |
> >>  |    if( i \|\| version \> 2 )                               |       |
> >>  |        slice\_size                                         | u(24) |
> >>  |    if( ec ) {                                              |       |
> >>@@ -551,6 +556,9 @@ See [NUT](#references) for more information about e=
lements.
> >>  **primary\_color\_count** is defined as 1 + ( chroma_planes ? 2 : 0 )=
 + ( alpha_plane ? 1 : 0 ).
> >>+**padding** specifies a bit without any significance and used only for=
 byte alignment.
> >>+MUST be 0.
> >ok, i suggest though to change this for the next version of the
> >bitstream
> >its better to write a 1 bit and then pad with 0 to a byte boundary
> >or (0 bit + padding with 1) that way the end of the previous bitstream
> >can be determind with certanity from the last byte
>=20
> I keep it in mind for when I open discussions about v4+ improvements.
>=20
> J=E9r=F4me

>  ffv1.md |    8 ++++++++
>  1 file changed, 8 insertions(+)
> fe47d32273bedfbe86a2d564af484e4687c311b7  0001-PATCH-Byte-alignment-is-ma=
de-explicit.patch
> >From ec4b9647c45834102e278d5f573e9180d13b6fde Mon Sep 17 00:00:00 2001
> From: =3D?UTF-8?q?J=3DC3=3DA9r=3DC3=3DB4me=3D20Martinez?=3D 
> Date: Wed, 25 May 2016 08:28:37 +0200
> Subject: [PATCH] [PATCH] Byte alignment is made explicit

applied

thanks

[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA

--h3lEC1ebzWnCI526
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAldFsHIACgkQYR7HhwQLD6uIMgCeO1d7jMvif4JNwoP/A5AOx6Z8
yPcAn3FoWt6BRaclCxeOiboT/O9o/Vei
=mxfw
-----END PGP SIGNATURE-----

--h3lEC1ebzWnCI526--


From nobody Wed May 25 09:19:29 2016
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 C29A312D7FA for ; Wed, 25 May 2016 09:19:27 -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 dxmgyyHjrd6l for ; Wed, 25 May 2016 09:19:26 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 09FF212D79D for ; Wed, 25 May 2016 09:19:25 -0700 (PDT)
Received: from [146.96.19.254] (port=52158 helo=[10.10.201.19]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b5bWk-003nZ3-Ry; Wed, 25 May 2016 12:19:24 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dave Rice 
In-Reply-To: <568EE224.8020101@das-werkstatt.com>
Date: Wed, 25 May 2016 12:19:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:   <20160105163439.GA13213@nb4> <568BF59B.6050106@mediaarea.net> <20160105174445.GC13213@nb4> <568C0516.3040605@mediaarea.net>  <568EA7D2.50503@das-werkstatt.com> <568EAFC3.1000202@mediaarea.net> <568EE224.8020101@das-werkstatt.com>
To: Peter Bubestinger 
X-Mailer: Apple Mail (2.3112)
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: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] FFV1 Version 4
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 16:19:28 -0000

> On Jan 7, 2016, at 5:09 PM, Peter B.  wrote:
>=20
> On 01/07/2016 07:34 PM, Jerome Martinez wrote:
>> PS: just to be clear, when you speak about "logarithmic", you speak
>> about DPX transfer characteristic value 3 "Logarithmic [to be defined
>> by SMPTE I23 Technology Committee,
>> sub-group on =E2=80=9CTransfer Characteristics=E2=80=9D]", right?
>> (note: the "to be defined" is in the spec from 2003 as well from the
>> spec from 2014 :), without further description)

The poster of the DPX file at =
https://github.com/epiil/dpxdepot/tree/master/test_files/dpx_frame =
claims that it is log. But the Transfer characteristic value is 0x01 aka =
"Printing density", rather than value 0x03 as Jerome supposes. Is =
"Printing density" also considered as log.

Is this data maintainable in Matroska with the new =
TransferCharacteristics element set to option 9 aka "Log" or should FFV1 =
contain this type of data.

> Well, personally I'd say I'm speaking about "color values that are
> non-linear".
> In practice, I've only encountered "quasi-log(TM)" (aka "logarithmic) =
-
> and DPX being the most popular case for these non-linear color values.
>=20
> So in order to stick to real-world use-cases I mentioned
> "logarithmic-DPX-to-FFV1-and-back".
> Could also be "Non-linear-Foo-to-FFV1-and-back" ;)
>=20
>=20
> Maybe it would make sense to collect what kind of non-linear color
> interpretations appear in the real world and derive some way of =
handling
> them.
> At least the most prominent ones?
>=20
> For example, like the ones Reto mentioned:
> // -------------------
> - log RGB (=3D "quasi-log", sometimes also called "pseudo-log") =
encodings:
> FilmStream (log60), ARRI log F, Panalog, Sony-log (=3D S-log), REDLOG, =
SI
> log90
> - log neg encodings: Cineon printing density (CPD), "DPX", ARRI log C
> // -------------------
>=20
>=20
> Regards,
> Pb
>=20
>=20
> PS: Maybe something like a CLUT could be stored as a self-contained =
way
> of interpreting the non-linearity of the color values?


For reference here is the list for DPX transfer characteristics which is =
quite different from the Matroska list.

0 User defined
1 Printing density
2 Linear
3 Logarithmic [to be defined by SMPTE I23 Technology Committee, =
sub-group on =E2=80=9CTransfer Characteristics=E2=80=9D]
4 Unspecified video
5 SMPTE 274M
6 ITU-R 709-4
7 ITU-R 601-5 system B or G (625)
8 ITU-R 601-5 system M (525)
9 Composite video (NTSC); see SMPTE 170M
10 Composite video (PAL); see ITU-R 624-4
11 Not applicable
12 Not applicable
13 =E2=80=93 254 Reserved for future use

Dave Rice


From nobody Wed May 25 09:50:17 2016
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 16FCC12D871 for ; Wed, 25 May 2016 09:50:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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=gmail.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 Rd1XUCOMI5CM for ; Wed, 25 May 2016 09:50:15 -0700 (PDT)
Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::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 DD17012D0CB for ; Wed, 25 May 2016 09:50:14 -0700 (PDT)
Received: by mail-it0-x22e.google.com with SMTP id z189so67003309itg.0 for ; Wed, 25 May 2016 09:50:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:date:message-id:subject:from:to; bh=8xcqoqxDHQNk3GtpCNb4G7uZ8rm4nw96FF0WwMTL1+E=; b=VVA6Rn18YJAKMsy3JmTtGWR5RcsYAkbdwEViI8tV4v9IgBHrAtdGbGLdulG8pWD4NE wj5zChci78tLo6BW+J3xq2CkagKi/57I8RT6Pejf5uCuiiw8jEqzdoK0GBpfb6AXW9Fa Rz3t/rZKVHumzQ6r3msShiQ4vOi8fzRIhD0MsT1re5KQygt3J9X7n2BwckyegUFxnHKT Q8WvN0SI6zr0DCq1NoPHEKoM+SQJqgV/8MQNXM+DKnJEfL2RO5KK2Dxn8KQfmTBHy0Ql iny0ET/NXJV85Q6bnEZFkZ4MN736MgeCI4RXfcgkZVpLNjw2yMdR4tU7kcB9cksC2oPo SjTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=8xcqoqxDHQNk3GtpCNb4G7uZ8rm4nw96FF0WwMTL1+E=; b=J8DsLR9hGDXaQnNkN3SshBnrClOJRxLDpnQbcaeTxI0VZ2VbRmYwc5K8DlRmxzFlCY m9oAtPmXie0qIT5Owu23VVBZjxWIIcxoOq86G/DJOXV9fXXuxO/5jFBeAvNoCTseX3Dp folAaa/dchtWvY+D0vJe6hqQklY+j7nbIQQnu7NbFFaB8IfE2De4SMn8UawGdpHIu+96 iA9kMO85NFrbLph+qPBHZYcF6e3JCfo+dm5vS0swlin4ONyqWG/stLeCPy3J2vfcUwlC su3yUwuodI9x9aWgnwudEd9w1zbZ8w4lCfCkacyzxmn63iRXcsfxusre0TyTaxbfJAhe bqAQ==
X-Gm-Message-State: ALyK8tKHT5qVyylwpAOBH2dfMY8v4CvDzIZvwUqx+t6mt6SmsS6jgncyIcocuIXvjTgzrKjz59PAq+1Cp8Cttw==
MIME-Version: 1.0
X-Received: by 10.36.57.211 with SMTP id l202mr4856204ita.22.1464195014119; Wed, 25 May 2016 09:50:14 -0700 (PDT)
Received: by 10.79.113.7 with HTTP; Wed, 25 May 2016 09:50:14 -0700 (PDT)
Date: Wed, 25 May 2016 12:50:14 -0400
Message-ID: 
From: Ashley Blewer 
To: cellar@ietf.org
Content-Type: multipart/alternative; boundary=001a114ab3cab2dab40533ad7719
Archived-At: 
Subject: [Cellar] Join us for our Pre-IETF Berlin Symposium!
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 16:50:16 -0000

--001a114ab3cab2dab40533ad7719
Content-Type: text/plain; charset=UTF-8

Hi everyone!

As maybe mentioned on the list before, MediaArea is holding a symposium to
be held in the days preceding IETF (with some overlap), dedicated to FFV1
and Matroska specifications and our IETF work. We hope to bring together
archivists who use this standards and designers/developers of the standards.

Here is the announcement (with registration link):
https://mediaarea.net/MediaConch/notimetowait.html

Much more to come in the following weeks!

My best,

Ashley Blewer

--001a114ab3cab2dab40533ad7719
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi everyone!=C2=A0

As maybe mentioned o=
n the list before, MediaArea is holding a symposium to be held in the days =
preceding IETF (with some overlap), dedicated to FFV1 and Matroska specific=
ations and our IETF work. We hope to bring together archivists who use this=
 standards and designers/developers of the standards.

<=
div>Here is the announcement (with registration link):=C2=A0https://mediaarea.net/Media=
Conch/notimetowait.html

Much more to come in t=
he following weeks!

My best,

<=
div>Ashley Blewer


--001a114ab3cab2dab40533ad7719--


From nobody Wed May 25 10:03:28 2016
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 AA21512D0B4 for ; Wed, 25 May 2016 10:03:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level: 
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] 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 28i2AF7WQX6b for ; Wed, 25 May 2016 10:03:24 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 605EC12D888 for ; Wed, 25 May 2016 10:03:24 -0700 (PDT)
Received: from [10.0.1.18] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u4PH3Lhk018263 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 25 May 2016 12:03:22 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.18]
From: "Ben Campbell" 
To: "Ashley Blewer" 
Date: Wed, 25 May 2016 12:03:21 -0500
Message-ID: 
In-Reply-To: 
References: 
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Mailer: MailMate (1.9.4r5234)
Archived-At: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] Join us for our Pre-IETF Berlin Symposium!
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 17:03:26 -0000

Hi,

The IETF meeting is July 17-22. The dates listed at the link seem to 
entirely overlap. Are they correct?

Thanks,

Ben.	

On 25 May 2016, at 11:50, Ashley Blewer wrote:

> Hi everyone!
>
> As maybe mentioned on the list before, MediaArea is holding a 
> symposium to
> be held in the days preceding IETF (with some overlap), dedicated to 
> FFV1
> and Matroska specifications and our IETF work. We hope to bring 
> together
> archivists who use this standards and designers/developers of the 
> standards.
>
> Here is the announcement (with registration link):
> https://mediaarea.net/MediaConch/notimetowait.html
>
> Much more to come in the following weeks!
>
> My best,
>
> Ashley Blewer
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar


From nobody Wed May 25 10:14:54 2016
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 871FB12D0AD for ; Wed, 25 May 2016 10:14:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 W1c4CcGNM9eB for ; Wed, 25 May 2016 10:14:52 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 5273112D13A for ; Wed, 25 May 2016 10:07:29 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id e62so76252525ita.1 for ; Wed, 25 May 2016 10:07:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Ijumi8HPrBF4wSKYsSvNIHCe26KWlc5G8i6QKrSvnjU=; b=lDixLrmBviJllilMO6LT3L1VJHkq537ILqiHYkbnaniyLzxEpjyvEiomDw0LYNLKkd eY0ahUVCPtsA6A1DW7cUR9XhcQGuqIZIwDDtup7HPeK68ZhcjNNN4L0faE4Pqtl+RlkA 2TDOaEGLJug5w1AdGV/QrQuz8RJ9qFxkIZ7f9TbKFU7/F3YuvwqImvNbvzpbdEVG7Afv kwZz8lnS2JSP8VryJk4qXwKyMMIavlWWJK2unPfitouPp/WZ8N7RlNOarBFqsFlEbMA3 GEbPQTSjMEjTMw66sGFa2JNTRJWckw9iIBZgEt4TYwSW9HYgduPlxIeKLclbx3EXWW8H YvGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Ijumi8HPrBF4wSKYsSvNIHCe26KWlc5G8i6QKrSvnjU=; b=EQgV0rDgIl78wsh+7yG/Q1brV2oN3hdXIixEyFQ8vUiOK4tcrbk28qNoPlvFwHDF2w uTpWKpDb8s584/Iee6zswdeH0vobjHvX2vmdMkz4+a2BgtjcQ2nh72NM9FJySYipXpLP OqMu5Cha1z7J7lVgJSZSCCL8ZIkRBkhCBWH2iOfoXvV5p0v4KZpL+y2zZbjWkBCefuH7 HKeGUa2srEZ9zfer3M4Fq7VuABJpJbv6UshxdfxXtJVbQYHB91MTwvh2Yi0UVRTm4X9G GaOdxAG7BOwIhoLkhThuis+HYqM6zoQl7ct2ote85qUEEVk8PD+fXqjY7dQzjidp/z14 iypA==
X-Gm-Message-State: ALyK8tIUJD2WTV3FZhQxv2kxASg2wP5D0QcANVkfKKNwzhF5+MKDeR69nlWdrAuVYhQ1WtxLlYG8d7NwlT8kMQ==
MIME-Version: 1.0
X-Received: by 10.36.57.211 with SMTP id l202mr4934124ita.22.1464196048709; Wed, 25 May 2016 10:07:28 -0700 (PDT)
Received: by 10.79.113.7 with HTTP; Wed, 25 May 2016 10:07:28 -0700 (PDT)
In-Reply-To: 
References:  
Date: Wed, 25 May 2016 13:07:28 -0400
Message-ID: 
From: Ashley Blewer 
To: Ben Campbell 
Content-Type: multipart/alternative; boundary=001a114ab3ca5d74990533adb507
Archived-At: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] Join us for our Pre-IETF Berlin Symposium!
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 17:14:53 -0000

--001a114ab3ca5d74990533adb507
Content-Type: text/plain; charset=UTF-8

Hi Ben,

Yep, that's right. We wanted to schedule it at the beginning portion of the
conference -- perhaps "pre" is being a bit misused as a prefix in this
context. If you are planning on attending IETF fully, do know that there
will be a conflict. Our target demographic will be people that are either
only or primarily attending IETF for the CELLAR working group, as well as
people who are nearby but do not have plans to attend IETF at all (but have
an interest in participating remotely or interest in these formats).

Ashley

On Wed, May 25, 2016 at 1:03 PM, Ben Campbell  wrote:

> Hi,
>
> The IETF meeting is July 17-22. The dates listed at the link seem to
> entirely overlap. Are they correct?
>
> Thanks,
>
> Ben.
>
> On 25 May 2016, at 11:50, Ashley Blewer wrote:
>
> Hi everyone!
>>
>> As maybe mentioned on the list before, MediaArea is holding a symposium to
>> be held in the days preceding IETF (with some overlap), dedicated to FFV1
>> and Matroska specifications and our IETF work. We hope to bring together
>> archivists who use this standards and designers/developers of the
>> standards.
>>
>> Here is the announcement (with registration link):
>> https://mediaarea.net/MediaConch/notimetowait.html
>>
>> Much more to come in the following weeks!
>>
>> My best,
>>
>> Ashley Blewer
>> _______________________________________________
>> Cellar mailing list
>> Cellar@ietf.org
>> https://www.ietf.org/mailman/listinfo/cellar
>>
>

--001a114ab3ca5d74990533adb507
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi Ben,

Yep, that's right. We wante=
d to schedule it at the beginning portion of the conference -- perhaps &quo=
t;pre" is being a bit misused as a prefix in this context. If you are =
planning on attending IETF fully, do know that there will be a conflict. Ou=
r target demographic will be people that are either only or primarily atten=
ding IETF for the CELLAR working group, as well as people who are nearby bu=
t do not have plans to attend IETF at all (but have an interest in particip=
ating remotely or interest in these formats).

Ashl=
ey

On =
Wed, May 25, 2016 at 1:03 PM, Ben Campbell <ben@nostrum.com> w=
rote:
Hi,



The IETF meeting is July 17-22. The dates listed at the link seem to entire=
ly overlap. Are they correct?



Thanks,



Ben.=C2=A0 =C2=A0 



On 25 May 2016, at 11:50, Ashley Blewer wrote:





Hi everyone!



As maybe mentioned on the list before, MediaArea is holding a symposium to<=
br>
be held in the days preceding IETF (with some overlap), dedicated to FFV1
and Matroska specifications and our IETF work. We hope to bring together
archivists who use this standards and designers/developers of the standards=
.



Here is the announcement (with registration link):

https://mediaarea.net/MediaConch/notimetowait.html=




Much more to come in the following weeks!



My best,



Ashley Blewer

_______________________________________________

Cellar mailing list

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







--001a114ab3ca5d74990533adb507--


From nobody Wed May 25 11:27:20 2016
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 EBFBC12D8B2 for ; Wed, 25 May 2016 11:27:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.202
X-Spam-Level: 
X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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 AAbKhh71-Y03 for ; Wed, 25 May 2016 11:27:16 -0700 (PDT)
Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (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 31C3312D8A9 for ; Wed, 25 May 2016 11:27:16 -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 u4PIRD9E022400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 25 May 2016 20:27:14 +0200
Received: from Castor.local (77-56-128-186.dclient.hispeed.ch [77.56.128.186]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u4PIRD6L012800 for ; Wed, 25 May 2016 20:27:13 +0200
Date: Wed, 25 May 2016 20:27:13 +0200
From: Reto Kromer 
To: cellar@ietf.org
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 (470)
X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8
X-Antivirus-Code: 0x100000
Archived-At: 
Subject: Re: [Cellar] FFV1 Version 4
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 18:27:19 -0000

Dave Rice wrote:

>The poster of the DPX file at=20
>https://github.com/epiil/dpxdepot/tree/master/test_files/dpx_frame
>claims that it is log. But the Transfer characteristic
>value is 0x01 aka "Printing density", rather than value
>0x03 as Jerome supposes. Is "Printing density" also
>considered as log.

I am speaking here from memory, as I don't have the time now
to check it (I'm taking off for the US very soon).

If I remember carefully, Kodak's original "printing density"
correlates

  2 ** {0, 1, 2, 3, =E2=80=A6}

with

  1.01 ** {0, 1, 2, 3, =E2=80=A6}

Yet I had a stroke five years ago and since then my memory
is not as good as before, therefore please enjoy this "cum
grano salis".

Best regards, Reto


AV Preservation by reto.ch
chemin du Suchet 5 | 1024 Ecublens | Switzerland
Web: https://reto.ch | Twitter: @retoch


From nobody Wed May 25 13:41:04 2016
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 EF28312D9C2 for ; Wed, 25 May 2016 13:40:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 3Cv4ll7bYxDo for ; Wed, 25 May 2016 13:40:51 -0700 (PDT)
Received: from 4.mo179.mail-out.ovh.net (4.mo179.mail-out.ovh.net [46.105.36.149]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEFFA12D906 for ; Wed, 25 May 2016 13:40:50 -0700 (PDT)
Received: from player792.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id 6913BFF8E23 for ; Wed, 25 May 2016 22:40:44 +0200 (CEST)
Received: from [192.168.2.101] (p508BA9FB.dip0.t-ipconnect.de [80.139.169.251]) (Authenticated sender: jerome@francoallemand.eu) by player792.ha.ovh.net (Postfix) with ESMTPSA id 2F98BA007A for ; Wed, 25 May 2016 22:40:44 +0200 (CEST)
From: Jerome Martinez 
To: cellar@ietf.org
Message-ID: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net>
Date: Wed, 25 May 2016 22:40:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Ovh-Tracer-Id: 994169620045762705
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrgeefgddugeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc
Archived-At: 
Subject: [Cellar] [PATCH FFV1 0/2] Clarification about versions and slice structure
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 20:40:53 -0000

This patch is for some formatting, because it is becoming slightly 
incoherent after some additions:
- version value of 2 is set as reserved but this value is seen in 
different places, I removed any reference to this value.
- applicable version is difficult to catch (e.g. sometimes >=2, 
sometimes >1), I think that showing the version number when a feature 
begins ("if >= 3") or stops (<=1) can avoid some mistakes by people who 
implement.
- there is a slice header element but no slice footer despite the fact a 
slice footer is clearly visible (not part of the decoding) and we 
discuss about it in the appendix. I propose to split in 3 parts (Header, 
Content, Footer) to better see the architecture of the slice, and we 
could add some text about each part in a future patch (in this patch, 
parts of the slice are moved to their own paragraph without any change)


From nobody Wed May 25 13:41:39 2016
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 2D96812DD6B for ; Wed, 25 May 2016 13:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 sbQL8_vLe_2h for ; Wed, 25 May 2016 13:41:33 -0700 (PDT)
Received: from 4.mo179.mail-out.ovh.net (4.mo179.mail-out.ovh.net [46.105.36.149]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BEF12D906 for ; Wed, 25 May 2016 13:41:25 -0700 (PDT)
Received: from player792.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id 9D054FF8DD0 for ; Wed, 25 May 2016 22:41:24 +0200 (CEST)
Received: from [192.168.2.101] (p508BA9FB.dip0.t-ipconnect.de [80.139.169.251]) (Authenticated sender: jerome@francoallemand.eu) by player792.ha.ovh.net (Postfix) with ESMTPSA id 78431A007D for ; Wed, 25 May 2016 22:41:24 +0200 (CEST)
To: cellar@ietf.org
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net>
From: Jerome Martinez 
Message-ID: 
Date: Wed, 25 May 2016 22:41:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net>
Content-Type: multipart/mixed; boundary="------------C8C52DD9E2780F1402F13774"
X-Ovh-Tracer-Id: 1005428619809394833
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrgeefgddugeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc
Archived-At: 
Subject: [Cellar] [PATCH FFV1 1/2] More explicit version tests
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 20:41:35 -0000

This is a multi-part message in MIME format.
--------------C8C52DD9E2780F1402F13774
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit



--------------C8C52DD9E2780F1402F13774
Content-Type: text/plain; charset=UTF-8;
 name="0001-More-explicit-version-tests.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="0001-More-explicit-version-tests.patch"

RnJvbSA5NTQ4OWJhMmI2ZDY3MGVmNjAyN2UxMzQ2MjVjNzQ0ODY5YmMxNTcyIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Sj1DMz1BOXI9QzM9QjRtZT0yME1h
cnRpbmV6Pz0gPGplcm9tZUBtZWRpYWFyZWEubmV0PgpEYXRlOiBXZWQsIDI1IE1heSAyMDE2
IDIwOjI0OjQwICswMjAwClN1YmplY3Q6IFtQQVRDSCAxLzJdIE1vcmUgZXhwbGljaXQgdmVy
c2lvbiB0ZXN0cwoKVXNlIGV2ZXJ5d2hlcmUgdGhlIHZlcnNpb24gbnVtYmVyIHdoZW4gYSBm
ZWF0dXJlIGJlZ2lucyBvciBzdG9wCkF2b2lkIHVzYWdlIG9mIHRoZSByZXNlcnZlZCB2ZXJz
aW9uIHZhbHVlIDIKUmVtb3ZlIHRlc3RzIHNwZWNpZmljIHRvIHJlc2VydmVkIHZlcnNpb24g
dmFsdWUgMgotLS0KIGZmdjEubWQgfCAyNCArKysrKysrKysrKystLS0tLS0tLS0tLS0KIDEg
ZmlsZSBjaGFuZ2VkLCAxMiBpbnNlcnRpb25zKCspLCAxMiBkZWxldGlvbnMoLSkKCmRpZmYg
LS1naXQgYS9mZnYxLm1kIGIvZmZ2MS5tZAppbmRleCAxMWQwZmFhLi41ODgzMzBmIDEwMDY0
NAotLS0gYS9mZnYxLm1kCisrKyBiL2ZmdjEubWQKQEAgLTQ3Miw3ICs0NzIsNyBAQCBEZWZh
dWx0IHZhbHVlcyBhdCB0aGUgZGVjb2RlciBpbml0aWFsaXphdGlvbiBwaGFzZToKIAogIyMg
Q29uZmlndXJhdGlvbiBSZWNvcmQKIAotSW4gdGhlIGNhc2Ugb2YgYSBiaXRzdHJlYW0gd2l0
aCB2ZXJzaW9uID49IDIsIGEgY29uZmlndXJhdGlvbiByZWNvcmQgaXMgc3RvcmVkIGluIHRo
ZSB1bmRlcmx5aW5nIGNvbnRhaW5lciwgYXQgdGhlIHRyYWNrIGhlYWRlciBsZXZlbC4KK0lu
IHRoZSBjYXNlIG9mIGEgYml0c3RyZWFtIHdpdGggdmVyc2lvbiA+PSAzLCBhIGNvbmZpZ3Vy
YXRpb24gcmVjb3JkIGlzIHN0b3JlZCBpbiB0aGUgdW5kZXJseWluZyBjb250YWluZXIsIGF0
IHRoZSB0cmFjayBoZWFkZXIgbGV2ZWwuCiBJdCBjb250YWlucyB0aGUgcGFyYW1ldGVycyB1
c2VkIGZvciBhbGwgZnJhbWVzLgogVGhlIHNpemUgb2YgdGhlIGNvbmZpZ3VyYXRpb24gcmVj
b3JkLCBOdW1CeXRlcywgaXMgc3VwcGxpZWQgYnkgdGhlIHVuZGVybHlpbmcgY29udGFpbmVy
LgogCkBAIC01MzMsNyArNTMzLDcgQEAgU2VlIFtOVVRdKCNyZWZlcmVuY2VzKSBmb3IgbW9y
ZSBpbmZvcm1hdGlvbiBhYm91dCBlbGVtZW50cy4KIHwgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKIHwtLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS18Oi0tLS0tLXwKIHxTbGljZSggaSApIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB8IHR5cGUgIHwKLXzCoMKgwqDCoGlmKCB2ZXJzaW9uIFw+
IDIgKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8Cit8
wqDCoMKgwqBpZiggdmVyc2lvbiBcPj0gMyApICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwgICAgICAgfAogfMKgwqDCoMKgwqDCoMKgwqBTbGljZUhlYWRlciggaSAp
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8CiB8wqDCoMKg
wqBpZiggY29sb3JzcGFjZVxfdHlwZSA9PSAwKSB7ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHwgICAgICAgfAogfMKgwqDCoMKgwqDCoMKgwqBmb3IoIHAgPSAwOyBwIFw8IHByaW1h
cnlcX2NvbG9yXF9jb3VudDsgcCsrICkgeyAgICAgfCAgICAgICB8CkBAIC01NDYsNyArNTQ2
LDcgQEAgU2VlIFtOVVRdKCNyZWZlcmVuY2VzKSBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91
dCBlbGVtZW50cy4KIHzCoMKgwqDCoGlmICggY29kZXJcX3R5cGUgPT0gMCApICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8CiB8ICAgICAgICB3aGlsZSAoICFi
eXRlXF9hbGlnbmVkKCkgKSAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8CiB8
wqDCoMKgwqDCoMKgwqDCoCAgICBwYWRkaW5nICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB8ICB1KDEpIHwKLXzCoMKgwqDCoGlmKCBpIFx8XHwgdmVyc2lvbiBc
PiAyICkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8Cit8wqDCoMKg
wqBpZiggdmVyc2lvbiBcPj0gMyApICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHwgICAgICAgfAogfMKgwqDCoMKgwqDCoMKgwqBzbGljZVxfc2l6ZSAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB1KDI0KSB8CiB8wqDCoMKgwqBpZigg
ZWMgKSB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
ICAgICAgfAogfMKgwqDCoMKgwqDCoMKgwqBlcnJvclxfc3RhdHVzICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfCAgdSg4KSB8CkBAIC01ODksNyArNTg5LDcgQEAg
VGhlIENSQyBnZW5lcmF0b3IgcG9seW5vbSB1c2VkIGlzIHRoZSBzdGFuZGFyZCBJRUVFIENS
QyBwb2x5bm9tICgweDEwNEMxMURCNykgd2kKIHwgwqDCoMKgcGljdHVyZVxfc3RydWN0dXJl
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHVyIHwKIHwgwqDCoMKg
c2FyXF9udW0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8IHVyIHwKIHwgwqDCoMKgc2FyXF9kZW4gICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB8IHVyIHwKLXwgwqDCoMKgaWYoIHZlcnNpb24gXD4gMyAp
IHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIHwKK3wgwqDCoMKg
aWYoIHZlcnNpb24gXD49IDQgKSB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8ICAgIHwKIHwgwqDCoMKgwqDCoMKgwqByZXNldFxfY29udGV4dHMgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfCBiciB8CiB8IMKgwqDCoMKgwqDCoMKgc2xpY2Vc
X2NvZGluZ1xfbW9kZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgdXIgfAog
fCDCoMKgwqB9ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwgICAgfApAQCAtNjA3LDcgKzYwNyw3IEBAIEluZmVycmVkIHRvIGJlIDEg
aWYgbm90IHByZXNlbnQuCiAqKnNsaWNlX2hlaWdodCoqIGluZGljYXRlcyB0aGUgaGVpZ2h0
IG9uIHRoZSBzbGljZSByYXN0ZXIgZm9ybWVkIGJ5IG51bV92X3NsaWNlcy4KIEluZmVycmVk
IHRvIGJlIDEgaWYgbm90IHByZXNlbnQuCiAKLSoqcXVhbnRcX3RhYmxlXF9pbmRleFxfY291
bnQqKiBpcyBkZWZpbmVkIGFzIDEgKyAoICggY2hyb21hX3BsYW5lcyB8fCB2ZXJzaW9uIFw8
IDQgKSA/IDEgOiAwICkgKyAoIGFscGhhX3BsYW5lID8gMSA6IDAgKS4KKyoqcXVhbnRcX3Rh
YmxlXF9pbmRleFxfY291bnQqKiBpcyBkZWZpbmVkIGFzIDEgKyAoICggY2hyb21hX3BsYW5l
cyB8fCB2ZXJzaW9uIFw8PSAzICkgPyAxIDogMCApICsgKCBhbHBoYV9wbGFuZSA/IDEgOiAw
ICkuCiAKICoqcXVhbnRcX3RhYmxlXF9pbmRleCoqIGluZGljYXRlcyB0aGUgaW5kZXggdG8g
c2VsZWN0IHRoZSBxdWFudGl6YXRpb24gdGFibGUgc2V0IGFuZCB0aGUgaW5pdGlhbCBzdGF0
ZXMgZm9yIHRoZSBzbGljZS4KIEluZmVycmVkIHRvIGJlIDAgaWYgbm90IHByZXNlbnQuCkBA
IC02NDksMjcgKzY0OSwyNyBAQCBJbmZlcnJlZCB0byBiZSAwIGlmIG5vdCBwcmVzZW50Lgog
fC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLXwtLS0tOnwKIHwgUGFyYW1ldGVycyggKSB7ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8IHR5cGV8CiB8wqDCoMKgdmVyc2lvbiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB1ciAgfAotfMKg
wqDCoGlmKCB2ZXJzaW9uIFw+IDIgKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHwgICAgIHwKK3zCoMKgwqBpZiggdmVyc2lvbiBcPj0gMyApICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICB8CiB8wqDCoMKgwqDCoMKgwqBtaWNy
b1xfdmVyc2lvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgdXIg
IHwKIHzCoMKgwqBjb2RlclxfdHlwZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB8IHVyICB8CiB8wqDCoMKgaWYoIGNvZGVyXF90eXBlIFw+IDEgKSAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgfAogfMKgwqDCoMKgwqDC
oMKgZm9yKCBpID0gMTsgaSBcPCAyNTY7IGkrKyApICAgICAgICAgICAgICAgICAgICAgICAg
ICB8ICAgICB8CiB8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoHN0YXRlXF90cmFuc2l0aW9uXF9k
ZWx0YVsgaSBdICAgICAgICAgICAgICAgICAgICB8IHNyICB8CiB8wqDCoMKgY29sb3JzcGFj
ZVxfdHlwZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB1ciAg
fAotfMKgwqDCoGlmKCB2ZXJzaW9uIFw+IDAgKSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwgICAgIHwKK3zCoMKgwqBpZiggdmVyc2lvbiBcPj0gMSApICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICB8CiB8wqDCoMKgwqDCoMKg
wqBiaXRzXF9wZXJcX3Jhd1xfc2FtcGxlICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHwgdXIgIHwKIHzCoMKgwqBjaHJvbWFcX3BsYW5lcyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB8IGJyICB8CiB8wqDCoMKgbG9nMiggaFxfY2hyb21hXF9z
dWJzYW1wbGUgKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB1ciAgfAogfMKgwqDC
oGxvZzIoIHZcX2Nocm9tYVxfc3Vic2FtcGxlICkgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIHwgdXIgIHwKIHzCoMKgwqBhbHBoYVxfcGxhbmUgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8IGJyICB8Ci18wqDCoMKgaWYoIHZlcnNpb24gXD4g
MSApIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgfAorfMKg
wqDCoGlmKCB2ZXJzaW9uIFw+PSAyICkgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIHwgICAgIHwKIHzCoMKgwqDCoMKgwqDCoG51bVxfaFxfc2xpY2VzIC0gMSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB1ciAgfAogfMKgwqDCoMKgwqDCoMKg
bnVtXF92XF9zbGljZXMgLSAxICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8
IHVyICB8CiB8wqDCoMKgwqDCoMKgwqBxdWFudFxfdGFibGVcX2NvdW50ICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHwgdXIgIHwKIHzCoMKgwqB9ICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICB8CiB8wqDC
oMKgZm9yKCBpID0gMDsgaSBcPCBxdWFudFxfdGFibGVcX2NvdW50OyBpKysgKSAgICAgICAg
ICAgICAgfCAgICAgfAogfMKgwqDCoMKgwqDCoMKgUXVhbnRpemF0aW9uVGFibGUoIGkgKSAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICB8Ci18wqDCoMKgaWYoIHZlcnNp
b24gXD4gMSApIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg
fAorfMKgwqDCoGlmKCB2ZXJzaW9uIFw+PSAyICkgeyAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgIHwgICAgIHwKIHzCoMKgwqDCoMKgwqDCoGZvciggaSA9IDA7IGkgXDwg
cXVhbnRcX3RhYmxlXF9jb3VudDsgaSsrICkgeyAgICAgICAgfCAgICAgfAogfMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqBzdGF0ZXNcX2NvZGVkICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgfCBiciAgfAogfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqBpZiggc3RhdGVzXF9j
b2RlZCApICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgfApAQCAtNjg0LDgg
KzY4NCw4IEBAIEluZmVycmVkIHRvIGJlIDAgaWYgbm90IHByZXNlbnQuCiAKICoqdmVyc2lv
bioqIHNwZWNpZmllcyB0aGUgdmVyc2lvbiBvZiB0aGUgYml0c3RyZWFtLgogRWFjaCB2ZXJz
aW9uIGlzIGluY29tcGF0aWJsZSB3aXRoIG90aGVycyB2ZXJzaW9uczogZGVjb2RlcnMgU0hP
VUxEIHJlamVjdCBhIGZpbGUgZHVlIHRvIHVua25vd24gdmVyc2lvbi4KLURlY29kZXJzIFNI
T1VMRCByZWplY3QgYSBmaWxlIHdpdGggdmVyc2lvbiA8IDIgJiYgQ29uZmlndXJhdGlvblJl
Y29yZElzUHJlc2VudCA9PSAxLgotRGVjb2RlcnMgU0hPVUxEIHJlamVjdCBhIGZpbGUgd2l0
aCB2ZXJzaW9uID49IDIgJiYgQ29uZmlndXJhdGlvblJlY29yZElzUHJlc2VudCA9PSAwLgor
RGVjb2RlcnMgU0hPVUxEIHJlamVjdCBhIGZpbGUgd2l0aCB2ZXJzaW9uID08IDEgJiYgQ29u
ZmlndXJhdGlvblJlY29yZElzUHJlc2VudCA9PSAxLgorRGVjb2RlcnMgU0hPVUxEIHJlamVj
dCBhIGZpbGUgd2l0aCB2ZXJzaW9uID49IDMgJiYgQ29uZmlndXJhdGlvblJlY29yZElzUHJl
c2VudCA9PSAwLgogCiB8dmFsdWUgICB8IHZlcnNpb24gICAgICAgICAgICAgICAgIHwKIHw6
LS0tLS0tLXw6LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfApAQCAtODU3LDcgKzg1Nyw3IEBA
IE1BWFxfQ09OVEVYVFxfSU5QVVRTIGlzIDUuCiAKICMjIyBSZXN0cmljdGlvbnMKIAotVG8g
ZW5zdXJlIHRoYXQgZmFzdCBtdWx0aXRocmVhZGVkIGRlY29kaW5nIGlzIHBvc3NpYmxlLCBz
dGFydGluZyB2ZXJzaW9uIDIgYW5kIGlmIGZyYW1lXF93aWR0aCAqIGZyYW1lXF9oZWlnaHQg
aXMgbW9yZSB0aGFuIDEwMTM3Niwgc2xpY2VcX3dpZHRoICogc2xpY2VcX2hlaWdodCBNVVNU
IGJlIGxlc3Mgb3IgZXF1YWwgdG8gbnVtXF9oXF9zbGljZXMgKiBudW1cX3ZcX3NsaWNlcyAv
IDQuCitUbyBlbnN1cmUgdGhhdCBmYXN0IG11bHRpdGhyZWFkZWQgZGVjb2RpbmcgaXMgcG9z
c2libGUsIHN0YXJ0aW5nIHZlcnNpb24gMyBhbmQgaWYgZnJhbWVcX3dpZHRoICogZnJhbWVc
X2hlaWdodCBpcyBtb3JlIHRoYW4gMTAxMzc2LCBzbGljZVxfd2lkdGggKiBzbGljZVxfaGVp
Z2h0IE1VU1QgYmUgbGVzcyBvciBlcXVhbCB0byBudW1cX2hcX3NsaWNlcyAqIG51bVxfdlxf
c2xpY2VzIC8gNC4KIE5vdGU6IDEwMTM3NiBpcyB0aGUgZnJhbWUgc2l6ZSBpbiBwaXhlbHMg
b2YgYSAzNTJ4Mjg4IGZyYW1lIGFsc28ga25vd24gYXMgQ0lGICgiQ29tbW9uIEludGVybWVk
aWF0ZSBGb3JtYXQiKSBmcmFtZSBzaXplIGZvcm1hdC4KIAogRm9yIGVhY2ggZnJhbWUsIGVh
Y2ggcG9zaXRpb24gaW4gdGhlIHNsaWNlIHJhc3RlciBNVVNUIGJlIGZpbGxlZCBieSBvbmUg
YW5kIG9ubHkgb25lIHNsaWNlIG9mIHRoZSBmcmFtZSAobm8gbWlzc2luZyBzbGljZSBwb3Np
dGlvbiwgbm8gc2xpY2Ugb3ZlcmxhcHBpbmcpLgotLSAKMi43LjAud2luZG93cy4xCgo=
--------------C8C52DD9E2780F1402F13774--


From nobody Wed May 25 13:42:07 2016
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 46AF612DD4E for ; Wed, 25 May 2016 13:42:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 e3lU7OqYEJYr for ; Wed, 25 May 2016 13:42:04 -0700 (PDT)
Received: from 4.mo179.mail-out.ovh.net (4.mo179.mail-out.ovh.net [46.105.36.149]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFB6212DD60 for ; Wed, 25 May 2016 13:41:53 -0700 (PDT)
Received: from player792.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id 7674EFF8EEC for ; Wed, 25 May 2016 22:41:52 +0200 (CEST)
Received: from [192.168.2.101] (p508BA9FB.dip0.t-ipconnect.de [80.139.169.251]) (Authenticated sender: jerome@francoallemand.eu) by player792.ha.ovh.net (Postfix) with ESMTPSA id 5AA7EA007B for ; Wed, 25 May 2016 22:41:52 +0200 (CEST)
To: cellar@ietf.org
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net>
From: Jerome Martinez 
Message-ID: <7697c88e-4376-015a-211c-41693c2a34a1@mediaarea.net>
Date: Wed, 25 May 2016 22:41:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Ovh-Tracer-Id: 1013309920065884305
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 50
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrgeefgddugeejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucfgmhhpthihucgsohguhiculdehtddm
Archived-At: 
Subject: [Cellar] [PATCH FFV1 2/2] Slice structure clarification
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 20:42:05 -0000


From nobody Wed May 25 14:02:11 2016
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 A6E1312DAA4 for ; Wed, 25 May 2016 14:02:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 qtRfwgsQAahb for ; Wed, 25 May 2016 14:02:07 -0700 (PDT)
Received: from 8.mo179.mail-out.ovh.net (8.mo179.mail-out.ovh.net [46.105.75.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E50DF12D1ED for ; Wed, 25 May 2016 14:02:05 -0700 (PDT)
Received: from player792.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id A009DFF9030 for ; Wed, 25 May 2016 23:01:59 +0200 (CEST)
Received: from [192.168.2.101] (p508BA9FB.dip0.t-ipconnect.de [80.139.169.251]) (Authenticated sender: jerome@francoallemand.eu) by player792.ha.ovh.net (Postfix) with ESMTPSA id 78291A0077 for ; Wed, 25 May 2016 23:01:59 +0200 (CEST)
To: cellar@ietf.org
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net>
From: Jerome Martinez 
Message-ID: <4b37aacc-10b9-3b04-d63b-79c8ba65a76f@mediaarea.net>
Date: Wed, 25 May 2016 23:01:58 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net>
Content-Type: multipart/mixed; boundary="------------277413BF2629140BD4637575"
X-Ovh-Tracer-Id: 1353050216471203985
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrgeefgdduhedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc
Archived-At: 
Subject: [Cellar] [PATCH FFV1 2/2] Slice structure clarification
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 21:02:09 -0000

This is a multi-part message in MIME format.
--------------277413BF2629140BD4637575
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit



--------------277413BF2629140BD4637575
Content-Type: text/plain; charset=UTF-8;
 name="0002-Slice-structure-clarification.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="0002-Slice-structure-clarification.patch"

RnJvbSAxZWJhMTgwNDY4NThkZjc2YzhmYTMyOWMzMTMzNWRlODE5ZmRkNzMwIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Sj1DMz1BOXI9QzM9QjRtZT0yME1h
cnRpbmV6Pz0gPGplcm9tZUBtZWRpYWFyZWEubmV0PgpEYXRlOiBXZWQsIDI1IE1heSAyMDE2
IDIyOjM2OjQ2ICswMjAwClN1YmplY3Q6IFtQQVRDSCAyLzJdIFNsaWNlIHN0cnVjdHVyZSBj
bGFyaWZpY2F0aW9uCgpTcGxpdCBvZiBTbGljZSgpIGluIDMgZGlmZmVyZW50IHBhcnRzIChI
ZWFkZXIsIENvbnRlbnQsIEZvb3RlcikuCi0tLQogZmZ2MS5tZCB8IDkzICsrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
CiAxIGZpbGUgY2hhbmdlZCwgNTcgaW5zZXJ0aW9ucygrKSwgMzYgZGVsZXRpb25zKC0pCgpk
aWZmIC0tZ2l0IGEvZmZ2MS5tZCBiL2ZmdjEubWQKaW5kZXggNTg4MzMwZi4uY2Y5OGY5YSAx
MDA2NDQKLS0tIGEvZmZ2MS5tZAorKysgYi9mZnYxLm1kCkBAIC01MzUsNDYgKzUzNSwxNyBA
QCBTZWUgW05VVF0oI3JlZmVyZW5jZXMpIGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IGVs
ZW1lbnRzLgogfFNsaWNlKCBpICkgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHwgdHlwZSAgfAogfMKgwqDCoMKgaWYoIHZlcnNpb24gXD49IDMg
KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKIHzCoMKg
wqDCoMKgwqDCoMKgU2xpY2VIZWFkZXIoIGkgKSAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwgICAgICAgfAotfMKgwqDCoMKgaWYoIGNvbG9yc3BhY2VcX3R5cGUgPT0g
MCkgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKLXzCoMKgwqDCoMKg
wqDCoMKgZm9yKCBwID0gMDsgcCBcPCBwcmltYXJ5XF9jb2xvclxfY291bnQ7IHArKyApIHsg
ICAgIHwgICAgICAgfAotfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoFBsYW5lKCBwICkgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfAotfMKgwqDCoMKg
fSBlbHNlIGlmKCBjb2xvcnNwYWNlXF90eXBlID09IDEgKSB7ICAgICAgICAgICAgICAgICAg
ICB8ICAgICAgIHwKLXzCoMKgwqDCoMKgwqDCoMKgZm9yKCB5ID0gMDsgeSBcPCBoZWlnaHQ7
IHkrKyApICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfAotfMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoGZvciggcCA9IDA7IHAgXDwgcHJpbWFyeVxfY29sb3JcX2NvdW50OyBwKysg
KSB7IHwgICAgICAgfAotfMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgTGluZSgg
cCwgeSApICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKLXzCoMKg
wqDCoH0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfCAgICAgICB8Cit8wqDCoMKgwqBTbGljZUNvbnRlbnQoICkgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfAogfMKgwqDCoMKgaWYgKCBj
b2RlclxfdHlwZSA9PSAwICkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAg
ICAgIHwKIHwgICAgICAgIHdoaWxlICggIWJ5dGVcX2FsaWduZWQoKSApICAgICAgICAgICAg
ICAgICAgICAgICAgICB8ICAgICAgIHwKIHzCoMKgwqDCoMKgwqDCoMKgICAgIHBhZGRpbmcg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIHUoMSkgfAogfMKg
wqDCoMKgaWYoIHZlcnNpb24gXD49IDMgKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8ICAgICAgIHwKLXzCoMKgwqDCoMKgwqDCoMKgc2xpY2VcX3NpemUgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgdSgyNCkgfAotfMKgwqDCoMKg
aWYoIGVjICkgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICB8ICAgICAgIHwKLXzCoMKgwqDCoMKgwqDCoMKgZXJyb3JcX3N0YXR1cyAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgIHUoOCkgfAotfMKgwqDCoMKgwqDCoMKg
wqBzbGljZVxfY3JjXF9wYXJpdHkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
fCB1KDMyKSB8Ci18wqDCoMKgwqB9ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfAorfMKgwqDCoMKgwqDCoMKgwqBTbGlj
ZUZvb3RlciggKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAg
ICB8CiB8fSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfCAgICAgICB8CiAKLSoqcHJpbWFyeVxfY29sb3JcX2NvdW50KiogaXMg
ZGVmaW5lZCBhcyAxICsgKCBjaHJvbWFfcGxhbmVzID8gMiA6IDAgKSArICggYWxwaGFfcGxh
bmUgPyAxIDogMCApLgotCiAqKnBhZGRpbmcqKiBzcGVjaWZpZXMgYSBiaXQgd2l0aG91dCBh
bnkgc2lnbmlmaWNhbmNlIGFuZCB1c2VkIG9ubHkgZm9yIGJ5dGUgYWxpZ25tZW50LgogTVVT
VCBiZSAwLgogCi0qKnNsaWNlX3NpemUqKiBpbmRpY2F0ZXMgdGhlIHNpemUgb2YgdGhlIHNs
aWNlIGluIGJ5dGVzLgotTm90ZTogdGhpcyBhbGxvd3MgZmluZGluZyB0aGUgc3RhcnQgb2Yg
c2xpY2VzIGJlZm9yZSBwcmV2aW91cyBzbGljZXMgaGF2ZSBiZWVuIGZ1bGx5IGRlY29kZWQu
IEFuZCBhbGxvd3MgdGhpcyB3YXkgcGFyYWxsZWwgZGVjb2RpbmcgYXMgd2VsbCBhcyBlcnJv
ciByZXNpbGllbmNlLgotCi0qKmVycm9yX3N0YXR1cyoqIHNwZWNpZmllcyB0aGUgZXJyb3Ig
c3RhdHVzLgotCi18IHZhbHVlIHwgICAgIGVycm9yIHN0YXR1cyAgICAgICAgICAgICAgICAg
ICAgIHwKLXwtLS0tLS0tfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
fAotfCAwICAgICB8IG5vIGVycm9yICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8Ci18
IDEgICAgIHwgc2xpY2UgY29udGFpbnMgYSBjb3JyZWN0YWJsZSBlcnJvciAgIHwKLXwgMiAg
ICAgfCBzbGljZSBjb250YWlucyBhIHVuY29ycmVjdGFibGUgZXJyb3IgfAotfCBPdGhlciB8
IHJlc2VydmVkIGZvciBmdXR1cmUgdXNlICAgICAgICAgICAgICB8Ci0KLSoqc2xpY2VcX2Ny
Y1xfcGFyaXR5KiogMzIgYml0cyB0aGF0IGFyZSBjaG9vc2VuIHNvIHRoYXQgdGhlIHNsaWNl
IGFzIGEgd2hvbGUgaGFzIGEgY3JjIHJlbWFpbmRlciBvZiAwLgotVGhpcyBpcyBlcXVpdmFs
ZW50IHRvIHN0b3JpbmcgdGhlIGNyYyByZW1haW5kZXIgaW4gdGhlIDMyLWJpdCBwYXJpdHku
Ci1UaGUgQ1JDIGdlbmVyYXRvciBwb2x5bm9tIHVzZWQgaXMgdGhlIHN0YW5kYXJkIElFRUUg
Q1JDIHBvbHlub20gKDB4MTA0QzExREI3KSB3aXRoIGluaXRpYWwgdmFsdWUgMC4KLQogIyMg
U2xpY2UgSGVhZGVyCiAKIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8ICAgIHwKQEAgLTY0Myw2ICs2MTQsNTMgQEAgSW5m
ZXJyZWQgdG8gYmUgMCBpZiBub3QgcHJlc2VudC4KIHwgMSAgICAgfCByYXcgUENNICAgICAg
ICAgICAgICAgICAgICAgIHwKIHwgT3RoZXIgfCByZXNlcnZlZCBmb3IgZnV0dXJlIHVzZSAg
ICAgIHwKIAorIyMgU2xpY2UgQ29udGVudAorCit8ICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8Cit8LS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
fDotLS0tLS18Cit8U2xpY2VDb250ZW50KCApIHsgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgfCB0eXBlICB8Cit8wqDCoMKgwqBpZiggY29sb3JzcGFjZVxf
dHlwZSA9PSAwKSB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfAorfMKg
wqDCoMKgwqDCoMKgwqBmb3IoIHAgPSAwOyBwIFw8IHByaW1hcnlcX2NvbG9yXF9jb3VudDsg
cCsrICkgeyAgICAgfCAgICAgICB8Cit8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgUGxhbmUo
IHAgKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8Cit8
wqDCoMKgwqB9IGVsc2UgaWYoIGNvbG9yc3BhY2VcX3R5cGUgPT0gMSApIHsgICAgICAgICAg
ICAgICAgICAgIHwgICAgICAgfAorfMKgwqDCoMKgwqDCoMKgwqBmb3IoIHkgPSAwOyB5IFw8
IGhlaWdodDsgeSsrICkgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8Cit8wqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgZm9yKCBwID0gMDsgcCBcPCBwcmltYXJ5XF9jb2xvclxfY291
bnQ7IHArKyApIHsgfCAgICAgICB8Cit8wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqBMaW5lKCBwLCB5ICkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg
fAorfMKgwqDCoMKgfSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICB8ICAgICAgIHwKK3x9ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKKworKipwcmltYXJ5
XF9jb2xvclxfY291bnQqKiBpcyBkZWZpbmVkIGFzIDEgKyAoIGNocm9tYV9wbGFuZXMgPyAy
IDogMCApICsgKCBhbHBoYV9wbGFuZSA/IDEgOiAwICkuCisKKyMjIFNsaWNlIEZvb3Rlcgor
CitOb3RlOiBzbGljZSBmb290ZXIgaXMgYWx3YXlzIGJ5dGUgYWxpZ25lZC4KKworfCAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgfAorfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLXw6LS0tLS0tfAorfFNsaWNlRm9vdGVyKCApIHsgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgdHlwZSAgfAorfMKgwqDC
oMKgc2xpY2VcX3NpemUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICB8IHUoMjQpIHwKK3zCoMKgwqDCoGlmKCBlYyApIHsgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgfCAgICAgICB8Cit8wqDCoMKgwqDCoMKgwqDC
oGVycm9yXF9zdGF0dXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8
ICB1KDgpIHwKK3zCoMKgwqDCoMKgwqDCoMKgc2xpY2VcX2NyY1xfcGFyaXR5ICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHwgdSgzMikgfAorfMKgwqDCoMKgfSAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAg
IHwKK3x9ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICB8ICAgICAgIHwKKworKipzbGljZV9zaXplKiogaW5kaWNhdGVzIHRoZSBz
aXplIG9mIHRoZSBzbGljZSBpbiBieXRlcy4KK05vdGU6IHRoaXMgYWxsb3dzIGZpbmRpbmcg
dGhlIHN0YXJ0IG9mIHNsaWNlcyBiZWZvcmUgcHJldmlvdXMgc2xpY2VzIGhhdmUgYmVlbiBm
dWxseSBkZWNvZGVkLiBBbmQgYWxsb3dzIHRoaXMgd2F5IHBhcmFsbGVsIGRlY29kaW5nIGFz
IHdlbGwgYXMgZXJyb3IgcmVzaWxpZW5jZS4KKworKiplcnJvcl9zdGF0dXMqKiBzcGVjaWZp
ZXMgdGhlIGVycm9yIHN0YXR1cy4KKworfCB2YWx1ZSB8ICAgICBlcnJvciBzdGF0dXMgICAg
ICAgICAgICAgICAgICAgICB8Cit8LS0tLS0tLXwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLXwKK3wgMCAgICAgfCBubyBlcnJvciAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgfAorfCAxICAgICB8IHNsaWNlIGNvbnRhaW5zIGEgY29ycmVjdGFibGUgZXJy
b3IgICB8Cit8IDIgICAgIHwgc2xpY2UgY29udGFpbnMgYSB1bmNvcnJlY3RhYmxlIGVycm9y
IHwKK3wgT3RoZXIgfCByZXNlcnZlZCBmb3IgZnV0dXJlIHVzZSAgICAgICAgICAgICAgfAor
CisqKnNsaWNlXF9jcmNcX3Bhcml0eSoqIDMyIGJpdHMgdGhhdCBhcmUgY2hvb3NlbiBzbyB0
aGF0IHRoZSBzbGljZSBhcyBhIHdob2xlIGhhcyBhIGNyYyByZW1haW5kZXIgb2YgMC4KK1Ro
aXMgaXMgZXF1aXZhbGVudCB0byBzdG9yaW5nIHRoZSBjcmMgcmVtYWluZGVyIGluIHRoZSAz
Mi1iaXQgcGFyaXR5LgorVGhlIENSQyBnZW5lcmF0b3IgcG9seW5vbSB1c2VkIGlzIHRoZSBz
dGFuZGFyZCBJRUVFIENSQyBwb2x5bm9tICgweDEwNEMxMURCNykgd2l0aCBpbml0aWFsIHZh
bHVlIDAuCisKICMjIFBhcmFtZXRlcnMKIAogfCAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgIHwKQEAgLTg3MCwyNCAr
ODg4LDI3IEBAIEZvciBlYWNoIEZyYW1lIHdpdGgga2V5ZnJhbWUgdmFsdWUgb2YgMCwgZWFj
aCBzbGljZSBNVVNUIGhhdmUgdGhlIHNhbWUgdmFsdWUgb2YKIAogIyMjIE11bHRpLXRocmVh
ZGluZyBzdXBwb3J0IGFuZCBpbmRlcGVuZGVuY2Ugb2Ygc2xpY2VzCiAKLVRoZSBiaXRzdHJl
YW0gaXMgcGFyc2FibGUgaW4gdHdvIHdheXM6IGluIHNlcXVlbnRpYWwgb3JkZXIgYXMgZGVz
Y3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgb3Igd2l0aCB0aGUgcHJlLWFuYWx5c2lzIG9mIHNs
aWNlXF9zaXplIGZpZWxkcy4gc2xpY2VcX3NpemUgZmllbGRzIHByZS1hbmFseXNpcyBhbGxv
d3MgbXVsdGktdGhyZWFkaW5nIGFzIHdlbGwgYXMgaW5kZXBlbmRlbmNlIG9mIHNsaWNlIGNv
bnRlbnQgKGEgYml0c3RyZWFtIGVycm9yIGluIGEgc2xpY2UgY29udGVudCBoYXMgbm8gaW1w
YWN0IG9uIHRoZSBkZWNvZGluZyBvZiB0aGUgb3RoZXIgc2xpY2VzKS4KK1RoZSBiaXRzdHJl
YW0gaXMgcGFyc2FibGUgaW4gdHdvIHdheXM6IGluIHNlcXVlbnRpYWwgb3JkZXIgYXMgZGVz
Y3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgb3Igd2l0aCB0aGUgcHJlLWFuYWx5c2lzIG9mIHRo
ZSBmb290ZXIgb2YgZWFjaCBzbGljZS4gRWFjaCBzbGljZSBmb290ZXIgY29udGFpbnMgYSBz
bGljZVxfc2l6ZSBmaWVsZCBzbyB0aGUgYm91bmRhcnkgb2YgZWFjaCBzbGljZSBpcyBjb21w
dXRhYmxlIHdpdGhvdXQgaGF2aW5nIHRvIHBhcnNlIHRoZSBzbGljZSBjb250ZW50LiBUaGF0
IGFsbG93cyBtdWx0aS10aHJlYWRpbmcgYXMgd2VsbCBhcyBpbmRlcGVuZGVuY2Ugb2Ygc2xp
Y2UgY29udGVudCAoYSBiaXRzdHJlYW0gZXJyb3IgaW4gYSBzbGljZSBoZWFkZXIgb3Igc2xp
Y2UgY29udGVudCBoYXMgbm8gaW1wYWN0IG9uIHRoZSBkZWNvZGluZyBvZiB0aGUgb3RoZXIg
c2xpY2VzKS4KIAogQWZ0ZXIgaGF2aW5nIGNoZWNrZWQga2V5ZnJhbWUgZmllbGQsIGEgZGVj
b2RlciBTSE9VTEQgcGFyc2Ugc2xpY2Vfc2l6ZSBmaWVsZHMsIGZyb20gc2xpY2VcX3NpemUg
b2YgdGhlIGxhc3Qgc2xpY2UgYXQgdGhlIGVuZCBvZiB0aGUgZnJhbWUgdXAgdG8gc2xpY2Vc
X3NpemUgb2YgdGhlIGZpcnN0IHNsaWNlIGF0IHRoZSBiZWdpbm5pbmcgb2YgdGhlIGZyYW1l
LCBiZWZvcmUgcGFyc2luZyBzbGljZXMsIGluIG9yZGVyIHRvIGhhdmUgc2xpY2VzIGJvdW5k
YXJpZXMuIEEgZGVjb2RlciBNQVkgZmFsbGJhY2sgb24gc2VxdWVudGlhbCBvcmRlciBlLmcu
IGluIGNhc2Ugb2YgY29ycnVwdGVkIGZyYW1lIChmcmFtZSBzaXplIHVua25vd24sIHNsaWNl
XF9zaXplIG9mIHNsaWNlcyBub3QgY29oZXJhbnQuLi4pIG9yIGlmIHRoZXJlIGlzIG5vIHBv
c3NpYmlsaXR5IG9mIHNlZWsgaW50byB0aGUgc3RyZWFtLgogCiBBcmNoaXRlY3R1cmUgb3Zl
cndpZXcgb2Ygc2xpY2VzIGluIGEgZnJhbWU6Ci0tCisKIHwgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiB8Oi0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tfAorfCBmaXJzdCBzbGljZSBoZWFkZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHwKIHwgZmlyc3Qgc2xpY2UgY29udGVudCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8Ci18IGZpcnN0IHNsaWNlIHNsaWNlXF9z
aXplICsgZXJyb3JcX3N0YXR1cyArIHNsaWNlXF9jcmNcX3Bhcml0eSAgfAorfCBmaXJzdCBz
bGljZSBmb290ZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHwKIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS18Cit8IHNlY29uZCBzbGljZSBoZWFkZXIgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgfAogfCBzZWNvbmQgc2xpY2UgY29udGVudCAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKLXwgc2Vjb25kIHNs
aWNlIHNsaWNlXF9zaXplICsgZXJyb3JcX3N0YXR1cyArIHNsaWNlXF9jcmNcX3Bhcml0eSB8
Cit8IHNlY29uZCBzbGljZSBmb290ZXIgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgfAogfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwKIHwgLi4uICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiB8LS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfAor
fCBsYXN0IHNsaWNlIGhlYWRlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgIHwKIHwgbGFzdCBzbGljZSBjb250ZW50ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8Ci18IGxhc3Qgc2xpY2Ugc2xpY2VcX3NpemUgKyBl
cnJvclxfc3RhdHVzICsgc2xpY2VcX2NyY1xfcGFyaXR5ICAgfAorfCBsYXN0IHNsaWNlIGZv
b3RlciAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKIAog
CiAjIENoYW5nZWxvZwotLSAKMi43LjAud2luZG93cy4xCgo=
--------------277413BF2629140BD4637575--


From nobody Wed May 25 14:19:03 2016
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 DBA8D12DDA4 for ; Wed, 25 May 2016 14:19:02 -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 M2ZCKLVwKVk5 for ; Wed, 25 May 2016 14:19:01 -0700 (PDT)
Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 7BF1B12DDA1 for ; Wed, 25 May 2016 14:19:01 -0700 (PDT)
Received: from eris.local (dynamic-adsl-84-220-81-12.clienti.tiscali.it [84.220.81.12]) (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 8E283340C18 for ; Wed, 25 May 2016 21:19:00 +0000 (UTC)
To: cellar@ietf.org
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net> <4b37aacc-10b9-3b04-d63b-79c8ba65a76f@mediaarea.net>
From: Luca Barbato 
Message-ID: <6c290042-7082-73df-96a3-543fd515d3c4@libav.org>
Date: Wed, 25 May 2016 23:18:56 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2
MIME-Version: 1.0
In-Reply-To: <4b37aacc-10b9-3b04-d63b-79c8ba65a76f@mediaarea.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1 2/2] Slice structure clarification
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 21:19:03 -0000

On 25/05/16 23:01, Jerome Martinez wrote:
>  |    if ( coder\_type == 0 )                                 |       |
>  |        while ( !byte\_aligned() )                          |       |
>  |            padding                                         |  u(1) |

Might go to the Slice Content section as well

so the Slice Content could specify the coder-specific details inside there.

About that, Michael, is it specified somewhere why the state 129 is used
to reset both coders and why 0 is put at the start in one case while in
the other it is used to pad and terminate?

lu


From nobody Wed May 25 14:59:26 2016
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 6627812DD78 for ; Wed, 25 May 2016 14:59:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.235
X-Spam-Level: 
X-Spam-Status: No, score=-6.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] 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 0kHW5llkCA3R for ; Wed, 25 May 2016 14:59:22 -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 5A52812D9DF for ; Wed, 25 May 2016 14:59:22 -0700 (PDT)
Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTP id DF866C299D for ; Wed, 25 May 2016 21:59:21 +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 66AvFCfEj-Pg for ; Wed, 25 May 2016 21:59:21 +0000 (UTC)
Received: from [10.252.25.214] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.scl3.mozilla.com (Postfix) with ESMTPSA id C8952C04BB for ; Wed, 25 May 2016 21:59:21 +0000 (UTC)
Message-ID: <57462039.90001@xiph.org>
Date: Wed, 25 May 2016 14:59:21 -0700
From: "Timothy B. Terriberry" 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26
MIME-Version: 1.0
To: cellar@ietf.org
References: <573113B8.6070702@xiph.org> <573B4EBB.4020309@xiph.org>
In-Reply-To: <573B4EBB.4020309@xiph.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Cellar] Call for consensus to add a milestone for EBML
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 21:59:24 -0000

Timothy B. Terriberry wrote:
> Please send a message to the list indicating whether or not you support
> adding this milestone on or before May 23rd.

Okay, I think we have consensus to add the milestone. After some 
discussion with our Area Director (Ben Campbell) and the authors, we 
decided it was more appropriate for this document to be Standards Track 
than Informational, so I've gone ahead and made that change in the 
milestone I submitted for IESG review.


From nobody Wed May 25 15:18:38 2016
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 7452712DDF5 for ; Wed, 25 May 2016 15:18:37 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20160525221837.18341.98808.idtracker@ietfa.amsl.com>
Date: Wed, 25 May 2016 15:18:37 -0700
From: IETF Secretariat 
Archived-At: 
Subject: [Cellar] Milestones changed for cellar WG
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 25 May 2016 22:18:37 -0000

Changed milestone "Submit specification for EBML to IESG (Standards
Track)", set state to active from review, accepting new milestone.

URL: https://datatracker.ietf.org/wg/cellar/charter/


From nobody Wed May 25 20:06:17 2016
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 B4DDD12D50C for ; Wed, 25 May 2016 20:06:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 p8My9aH2jltW for ; Wed, 25 May 2016 20:05:52 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6BD12D5BD for ; Wed, 25 May 2016 20:05:51 -0700 (PDT)
Received: from mfilter26-d.gandi.net (mfilter26-d.gandi.net [217.70.178.154]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id D8E9A17209B for ; Thu, 26 May 2016 05:05:49 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter26-d.gandi.net
Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter26-d.gandi.net (mfilter26-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id LPr770e5zPgf for ; Thu, 26 May 2016 05:05:48 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 1048617209C for ; Thu, 26 May 2016 05:05:47 +0200 (CEST)
Date: Thu, 26 May 2016 05:03:29 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160526030329.GA4558@nb4>
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ"
Content-Disposition: inline
In-Reply-To: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1 0/2] Clarification about versions and slice structure
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 03:06:02 -0000

--lrZ03NoBR/3+SXJZ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 25, 2016 at 10:40:43PM +0200, Jerome Martinez wrote:
> This patch is for some formatting, because it is becoming slightly
> incoherent after some additions:

> - version value of 2 is set as reserved but this value is seen in
> different places, I removed any reference to this value.

does "version >=3D3"  really refer less to version 2 than version >=3D2 ?
i think in cases like above its better to choose the point so that
its most correct

[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.

--lrZ03NoBR/3+SXJZ
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAldGZ4EACgkQYR7HhwQLD6tbRQCeKTx/nSzCpr+DMukhGdRqbuKN
IjAAnAnR/FP9nvTzWfnrdMtn+Br146oR
=Xsty
-----END PGP SIGNATURE-----

--lrZ03NoBR/3+SXJZ--


From nobody Wed May 25 20:16:23 2016
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 64A3F12D53F for ; Wed, 25 May 2016 20:16:23 -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 Fyshpsw5GmOD for ; Wed, 25 May 2016 20:16:21 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 CFE6C12D539 for ; Wed, 25 May 2016 20:16:21 -0700 (PDT)
Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:42106 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b5lmV-002TOr-VE; Wed, 25 May 2016 23:16:20 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dave Rice 
In-Reply-To: <20160526030329.GA4558@nb4>
Date: Wed, 25 May 2016 23:16:18 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net> <20160526030329.GA4558@nb4>
To: Michael Niedermayer 
X-Mailer: Apple Mail (2.3124)
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: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] [PATCH FFV1 0/2] Clarification about versions and slice structure
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 03:16:23 -0000

> On May 25, 2016, at 11:03 PM, Michael Niedermayer =
 wrote:
>=20
> On Wed, May 25, 2016 at 10:40:43PM +0200, Jerome Martinez wrote:
>> This patch is for some formatting, because it is becoming slightly
>> incoherent after some additions:
>=20
>> - version value of 2 is set as reserved but this value is seen in
>> different places, I removed any reference to this value.
>=20
> does "version >=3D3"  really refer less to version 2 than version >=3D2 =
?
> i think in cases like above its better to choose the point so that
> its most correct

I think you mean ">=3D3" versus ">2=E2=80=9D.

I prefer the references such as >=3D3. In cases where version is set to =
=E2=80=982=E2=80=99, the spec implies that this means a =E2=80=98reserved=E2=
=80=99 value rather than any implication of a =E2=80=98version 2=E2=80=99.=
 Since 2 is reserved as a version value, I=E2=80=99d prefer not make any =
reference to "version 2=E2=80=9D excepting the existing side note =
comment that says that version 2 files shouldn=E2=80=99t exist. Since =
they shouldn=E2=80=99t exist and the value is reserved, it seems =
contradictory for the specification to also define or infer to a =
=E2=80=9Cversion 2=E2=80=9D and make references such as =E2=80=9Cgreater =
than version 2=E2=80=9D, whereas =E2=80=9Cgreater than or equal to =
version 3=E2=80=9D makes clearer sense to me.

Dave Rice=


From nobody Wed May 25 20:41:17 2016
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 B261A12D170 for ; Wed, 25 May 2016 20:41:16 -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, RCVD_IN_MSPIKE_H2=-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 TPjpla72Egs6 for ; Wed, 25 May 2016 20:41:14 -0700 (PDT)
Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF1112D583 for ; Wed, 25 May 2016 20:41:14 -0700 (PDT)
Received: from mfilter10-d.gandi.net (mfilter10-d.gandi.net [217.70.178.139]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id E4AA9FB88B for ; Thu, 26 May 2016 05:41:12 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter10-d.gandi.net
Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter10-d.gandi.net (mfilter10-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id qS1JChZDmwzt for ; Thu, 26 May 2016 05:41:11 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay6-d.mail.gandi.net (Postfix) with ESMTPSA id 1B15AFB8A0 for ; Thu, 26 May 2016 05:41:10 +0200 (CEST)
Date: Thu, 26 May 2016 05:38:52 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160526033852.GB4558@nb4>
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net> <20160526030329.GA4558@nb4> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="6sX45UoQRIJXqkqR"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1 0/2] Clarification about versions and slice structure
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 03:41:17 -0000

--6sX45UoQRIJXqkqR
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 25, 2016 at 11:16:18PM -0400, Dave Rice wrote:
>=20
> > On May 25, 2016, at 11:03 PM, Michael Niedermayer  wrote:
> >=20
> > On Wed, May 25, 2016 at 10:40:43PM +0200, Jerome Martinez wrote:
> >> This patch is for some formatting, because it is becoming slightly
> >> incoherent after some additions:
> >=20
> >> - version value of 2 is set as reserved but this value is seen in
> >> different places, I removed any reference to this value.
> >=20
> > does "version >=3D3"  really refer less to version 2 than version >=3D2=
 ?
> > i think in cases like above its better to choose the point so that
> > its most correct
>=20
> I think you mean ">=3D3" versus ">2=E2=80=9D.

no, i meant for example:
> -To ensure that fast multithreaded decoding is possible, starting version=
 2 and if frame\_width * frame\_height is more than 101376, slice\_width * =
slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4.
> +To ensure that fast multithreaded decoding is possible, starting version=
 3 and if frame\_width * frame\_height is more than 101376, slice\_width * =
slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4.
                                                                    ^^^^^^^=
^^

>=20
> I prefer the references such as >=3D3. In cases where version is set to =
=E2=80=982=E2=80=99, the spec implies that this means a =E2=80=98reserved=
=E2=80=99 value rather than any implication of a =E2=80=98version 2=E2=80=
=99. Since 2 is reserved as a version value, I=E2=80=99d prefer not make an=
y reference to "version 2=E2=80=9D excepting the existing side note comment=
 that says that version 2 files shouldn=E2=80=99t exist. Since they shouldn=
=E2=80=99t exist and the value is reserved, it seems contradictory for the =
specification to also define or infer to a =E2=80=9Cversion 2=E2=80=9D and =
make references such as =E2=80=9Cgreater than version 2=E2=80=9D, whereas =
=E2=80=9Cgreater than or equal to version 3=E2=80=9D makes clearer sense to=
 me.
>=20
> Dave Rice
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.

--6sX45UoQRIJXqkqR
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAldGb8wACgkQYR7HhwQLD6uVxgCeMqzMVdGbLFjoa1i+tIW+mMKN
yvgAn3Sa+rS7Kwe/H8AkG4Snx1GMM42U
=vcwh
-----END PGP SIGNATURE-----

--6sX45UoQRIJXqkqR--


From nobody Wed May 25 20:49:09 2016
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 077C112D5D5 for ; Wed, 25 May 2016 20:49:07 -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 i5FZF0Jx3MXd for ; Wed, 25 May 2016 20:49:05 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 8339512D5D4 for ; Wed, 25 May 2016 20:49:05 -0700 (PDT)
Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:45898 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b5mIB-003FuD-D1; Wed, 25 May 2016 23:49:04 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dave Rice 
In-Reply-To: <20160526033852.GB4558@nb4>
Date: Wed, 25 May 2016 23:49:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <01F1FE51-5461-40F5-8617-2CEE63FE1852@dericed.com>
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net> <20160526030329.GA4558@nb4>  <20160526033852.GB4558@nb4>
To: Michael Niedermayer 
X-Mailer: Apple Mail (2.3124)
X-OutGoing-Spam-Status: No, score=-2.1
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: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] [PATCH FFV1 0/2] Clarification about versions and slice structure
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 03:49:07 -0000

> On May 25, 2016, at 11:38 PM, Michael Niedermayer =
 wrote:
>=20
> On Wed, May 25, 2016 at 11:16:18PM -0400, Dave Rice wrote:
>>=20
>>> On May 25, 2016, at 11:03 PM, Michael Niedermayer =
 wrote:
>>>=20
>>> On Wed, May 25, 2016 at 10:40:43PM +0200, Jerome Martinez wrote:
>>>> This patch is for some formatting, because it is becoming slightly
>>>> incoherent after some additions:
>>>=20
>>>> - version value of 2 is set as reserved but this value is seen in
>>>> different places, I removed any reference to this value.
>>>=20
>>> does "version >=3D3"  really refer less to version 2 than version =
>=3D2 ?
>>> i think in cases like above its better to choose the point so that
>>> its most correct
>>=20
>> I think you mean ">=3D3" versus ">2=E2=80=9D.
>=20
> no, i meant for example:
>> -To ensure that fast multithreaded decoding is possible, starting =
version 2 and if frame\_width * frame\_height is more than 101376, =
slice\_width * slice\_height MUST be less or equal to num\_h\_slices * =
num\_v\_slices / 4.
>> +To ensure that fast multithreaded decoding is possible, starting =
version 3 and if frame\_width * frame\_height is more than 101376, =
slice\_width * slice\_height MUST be less or equal to num\_h\_slices * =
num\_v\_slices / 4.
>                                                                    =
^^^^^^^^^

That makes sense to me. Since 2 as a version is reserved, I think that =
anchoring comparators to a version that should not exist is confusing. I =
suggest that the specification does not try to define an FFV1 version 2 =
except for remarking on why the version number is reserved. The cellar =
charter as well, https://datatracker.ietf.org/wg/cellar/charter/, only =
references FFV1 0, 1, and 3 to be defined in the specification.

>> I prefer the references such as >=3D3. In cases where version is set =
to =E2=80=982=E2=80=99, the spec implies that this means a =
=E2=80=98reserved=E2=80=99 value rather than any implication of a =
=E2=80=98version 2=E2=80=99. Since 2 is reserved as a version value, =
I=E2=80=99d prefer not make any reference to "version 2=E2=80=9D =
excepting the existing side note comment that says that version 2 files =
shouldn=E2=80=99t exist. Since they shouldn=E2=80=99t exist and the =
value is reserved, it seems contradictory for the specification to also =
define or infer to a =E2=80=9Cversion 2=E2=80=9D and make references =
such as =E2=80=9Cgreater than version 2=E2=80=9D, whereas =E2=80=9Cgreater=
 than or equal to version 3=E2=80=9D makes clearer sense to me.
>>=20
>> Dave Rice
>> _______________________________________________
>> Cellar mailing list
>> Cellar@ietf.org
>> https://www.ietf.org/mailman/listinfo/cellar
>=20
> --=20
> Michael     GnuPG fingerprint: =
9FF2128B147EF6730BADF133611EC787040B0FAB
>=20
> Those who are best at talking, realize last or never when they are =
wrong.
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar


From nobody Thu May 26 00:20:50 2016
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 ECEDB12D0A8 for ; Thu, 26 May 2016 00:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 nkoax5P06Emt for ; Thu, 26 May 2016 00:20:47 -0700 (PDT)
Received: from 8.mo179.mail-out.ovh.net (8.mo179.mail-out.ovh.net [46.105.75.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E947112D135 for ; Thu, 26 May 2016 00:20:46 -0700 (PDT)
Received: from player792.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id 1B9F7FF910F for ; Thu, 26 May 2016 09:20:44 +0200 (CEST)
Received: from [192.168.2.101] (p508BA9FB.dip0.t-ipconnect.de [80.139.169.251]) (Authenticated sender: jerome@francoallemand.eu) by player792.ha.ovh.net (Postfix) with ESMTPSA id 3FAF6A0091 for ; Thu, 26 May 2016 09:20:44 +0200 (CEST)
To: cellar@ietf.org
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net> <20160526030329.GA4558@nb4>
From: Jerome Martinez 
Message-ID: 
Date: Thu, 26 May 2016 09:20:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160526030329.GA4558@nb4>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 11802808727036891281
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrgeeggdduvdefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1 0/2] Clarification about versions and slice structure
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 07:20:49 -0000

Le 26/05/2016  05:03, Michael Niedermayer a crit :
> On Wed, May 25, 2016 at 10:40:43PM +0200, Jerome Martinez wrote:
>> This patch is for some formatting, because it is becoming slightly
>> incoherent after some additions:
>> - version value of 2 is set as reserved but this value is seen in
>> different places, I removed any reference to this value.
> does "version >=3"  really refer less to version 2 than version >=2 ?
> i think in cases like above its better to choose the point so that
> its most correct

This is on purpose : "version 2" is not defined (version field with 
value 2 is set as reserved), so it is difficult (it makes the spec less 
clear, it is not coherent) to refer to this undefined version.
The goal of this patch is to have coherency: we have the sentence 
"Version 2 was never enabled in the encoder thus version 2 files 
SHOULD NOT exist, and this document does not describe them to keep the 
text simpler", so any reference to version with a value 2 is removed.

As 2 does not exist, >=3 refers to the exact same versions of FFV1 as 
 >=2 or >2 without referencing a version of FFV1 which does not exist.


From nobody Thu May 26 04:42:29 2016
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 8D00F12DD6F for ; Thu, 26 May 2016 04:42:26 -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 GADPubpNdnD8 for ; Thu, 26 May 2016 04:42:21 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 6FD4112DA84 for ; Thu, 26 May 2016 04:42:21 -0700 (PDT)
Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:46404 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b5tfx-001cBA-4W for cellar@ietf.org; Thu, 26 May 2016 07:42:20 -0400
From: Dave Rice 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <33F32C57-17A9-4DDA-BF87-97C12596CA73@dericed.com>
Date: Thu, 26 May 2016 07:42:02 -0400
To: cellar@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
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: [Cellar] Matroska as EBML Schema
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 11:42:27 -0000

Hi all,

The EBML Specification documents how to express the elemental structure =
and constraints of an EBML DocType in a machine-readible XML format =
called the EBML Schema, =
https://github.com/Matroska-Org/ebml-specification/blob/master/specificati=
on.markdown#ebml-schema. Using specdata.xml from the matroska-foundation =
repo as a basis I drafted an EBML Schema for Matroska and made this pull =
request, https://github.com/Matroska-Org/matroska-specification/pull/20, =
to the matroska-specification repo. I=E2=80=99m also including the draft =
EBML Schema below.

Here=E2=80=99s some notes on how I converted specdata.xml to an EBML =
Schema:
I removed the elements defined by the EBML Spec (Header, Void, and =
CRC-32)
I removed experimental Signature elements.
Removed instances of `mandatory=3D"0"` as this is the default
Changed `mandatory=3D"1"` to `minOccurs=3D"1"`
Remove instances of `multiple=3D"0"` as this is the default
Changes multiple=3D"1" to maxOccurs=3D"unbounded"
Nested elements
Moved documentation into a sub-element  of element.

issues:
-   Whereas specdata.xml defines many docTypes simultaneously, this one =
just defines one. Could make a separate one for webm (here=E2=80=99s an =
example of this in webm form: =
https://gist.github.com/dericed/04330009278d0720e5316b8393937cb2).
-   the webm attribute is still here, so is the divx attribute
-   Is the cppname attribute needed?
-   the bytesize attribute is here, this should be defined in ebml spec
-   How should the recursive attribute be defined?
-   Need to define the  element to contain some =
whitelisted html tags.
-   Need to update maxOccurs to use 'identical=E2=80=99 option where =
relevant.
-   Should consider SeekHead with maxOccurs=3D"2"
-   Need to add in and utilize the "unknownsizeallowed" attribute
-   Should use maxver rather than DEPRECATED in the documentation.
-   In the new nested structure, is the level attribute necessary?

Very interested in comments. I think this structure allows for a lot of =
new possibilities and clarity. Once this is accepted to the =
matroska-specification repo, I=E2=80=99d like to make some makefiles to =
convert it into various human readible tables and forms.

Draft EBML Schema for Matroska:



  
    The Root Element that contains all other =
Top-Level Elements (Elements defined only at Level 1). A Matroska file =
is composed of 1 Segment.
    
      Contains the position of other Top-Level Elements.
      
        Contains a single seek entry to an =
EBML Element.
        
          The binary ID corresponding to the =
Element name.
        
        
          The position of the Element in the Segment in octets (0 =3D first =
level 1 Element).
        
      
    
    
      Contains miscellaneous general =
information and statistics on the file.
      
        A randomly generated unique ID to =
identify the current Segment between many others (128 =
bits).
      
      
        A filename corresponding to this =
Segment.
      
      
        A unique ID to identify the previous =
chained Segment (128 bits).
      
      
        An escaped filename corresponding to =
the previous Segment.
      
      
        A unique ID to identify the next =
chained Segment (128 bits).
      
      
        An escaped filename corresponding to =
the next Segment.
      
      
        A randomly generated unique ID that =
all Segments related to each other must use (128 bits).
      
      
        A tuple of corresponding ID used by =
chapter codecs to represent this Segment.
        
          Specify an edition UID on which =
this correspondance applies. When not specified, it means for all =
editions found in the Segment.
        
        
          The chapter codec using this ID (0: Matroska Script, 1: =
DVD-menu).
        
        
          The binary value used to represent =
this Segment in the chapter codec data. The format depends on the ChapProcessCodecID used.
        
      
      
        Timestamp scale in nanoseconds =
(1.000.000 means all timestamps in the Segment are expressed in =
milliseconds).
      
      
      
        Duration of the Segment (based on =
TimecodeScale).
      
      
        Date of the origin of timestamp =
(value 0), i.e. production date.
      
      
        General name of the =
Segment.
      
      
        Muxing application or library =
("libmatroska-0.4.3").
      
      
        Writing application =
("mkvmerge-0.3.3").
      
    
    
      The Top-Level Element containing the =
(monolithic) Block structure.
      
        Absolute timestamp of the cluster =
(based on TimecodeScale).
      
      
        The list of tracks that are not used =
in that part of the stream. It is useful when using overlay tracks on =
seeking. Then you should decide what track to use.
        
          One of the track number that are =
not used from now on in the stream. It could change later if not =
specified as silent in a further Cluster.
        
      
      
        The Position of the Cluster in the Segment (0 in live broadcast =
streams). It might help to resynchronise offset on damaged =
streams.
      
      
        Size of the previous Cluster, in =
octets. Can be useful for backward playing.
      
      
        Similar to Block but without all the extra information, mostly used to reduced overhead =
when no extra feature is needed. (see SimpleBlock Structure)
      
      
        Basic container of information =
containing a single Block or BlockVirtual, and information specific to =
that Block/VirtualBlock.
        
          Block containing the actual data to =
be rendered and a timestamp relative to the Cluster Timecode. (see Block Structure)
        
        
          A Block with no data. It must be =
stored in the stream at the place the real Block should be in display =
order. (see =
Block Virtual)
        
        
          Contain additional blocks to =
complete the main one. An EBML parser that has no knowledge of the Block =
structure could still see and use/skip these data.
          
            Contain the BlockAdditional and =
some parameters.
            
              An ID to identify the =
BlockAdditional level.
            
            
              Interpreted by the codec as it =
wishes (using the BlockAddID).
            
          
        
        
          The duration of the Block (based on =
TimecodeScale). This Element is mandatory when DefaultDuration is set =
for the track (but can be omitted as other default values). When not =
written and with no DefaultDuration, the value is assumed to be the =
difference between the timestamp of this Block and the timestamp of the =
next Block in "display" order (not coding order). This Element can be =
useful at the end of a Track (as there is not other Block available), or =
when there is a break in a track like for subtitle tracks. When set to 0 =
that means the frame is not a keyframe.
        
        
          This frame is referenced and has =
the specified cache priority. In cache only a frame of the same or =
higher priority can replace this frame. A value of 0 means the frame is =
not referenced.
        
        
          Timestamp of another frame used as =
a reference (ie: B or P frame). The timestamp is relative to the block =
it's attached to.
        
        
          Relative position of the data that should be in position of the virtual =
block.
        
        
          The new codec state to use. Data =
interpretation is private to the codec. This information should always =
be referenced by a seek entry.
        
        
          Duration in nanoseconds of the =
silent data added to the Block (padding at the end of the Block for =
positive value, at the beginning of the Block for negative value). The =
duration of DiscardPadding is not calculated in the duration of the =
TrackEntry and should be discarded during playback.
        
        
          Contains slices =
description.
          
            Contains extra time information =
about the data contained in the Block. While there are a few files in =
the wild with this Element, it is no longer in use and has been =
deprecated. Being able to interpret this Element is not required for =
playback.
            
              The reverse number of the frame =
in the lace (0 is the last frame, 1 is the next to last, etc). While =
there are a few files in the wild with this Element, it is no longer in =
use and has been deprecated. Being able to interpret this Element is not =
required for playback.
            
            
              The number of the frame to =
generate from this lace with this delay (allow you to generate many =
frames from the same Block/Frame).
            
            
              The ID of the BlockAdditional =
Element (0 is the main Block).
            
            
              The (scaled) delay to apply to =
the Element.
            
            
              The (scaled) duration to apply =
to the Element.
            
          
        
        
          DivX trick track extenstions
          
            DivX trick track extenstions
          
          
            DivX trick track extenstions
          
        
      
      
        Similar to Si=
mpleBlock but the data inside the Block are Transformed (encrypt =
and/or signed). (see EncryptedBlock Structure)
      
    
    
      A Top-Level Element of information with =
many tracks described.
      
        Describes a track with all =
Elements.
        
          The track number as used in the =
Block Header (using more than 127 tracks is not encouraged, though the =
design allows an unlimited number).
        
        
          A unique ID to identify the Track. =
This should be kept the same when making a direct stream copy of the =
Track to another file.
        
        
          A set of track types coded on 8 =
bits (1: video, 2: audio, 3: complex, 0x10: logo, 0x11: subtitle, 0x12: =
buttons, 0x20: control).
        
        
          Set if the track is usable. (1 =
bit)
        
        
          Set if that track (audio, video or =
subs) SHOULD be active if no language found matches the user preference. =
(1 bit)
        
        
          Set if that track MUST be active =
during playback. There can be many forced track for a kind (audio, video =
or subs), the player should select the one which language matches the =
user preference or the default + forced track. Overlay MAY happen =
between a forced and non-forced track of the same kind. (1 =
bit)
        
        
          Set if the track may contain blocks =
using lacing. (1 bit)
        
        
          The minimum number of frames a =
player should be able to cache during playback. If set to 0, the =
reference pseudo-cache system is not used.
        
        
          The maximum cache size required to =
store referenced frames in and the current frame. 0 means no cache is =
needed.
        
        
          Number of nanoseconds (not scaled =
via TimecodeScale) per frame ('frame' in the Matroska sense -- one =
Element put into a (Simple)Block).
        
        
          The period in nanoseconds (not =
scaled by TimcodeScale)
      between two successive fields at the output of the decoding =
process (see the notes)
        
        
          DEPRECATED, DO NOT USE. The scale =
to apply on this track to work at normal speed in relation with other =
tracks (mostly used to adjust video speed when the audio length =
differs).
        
        
          A value to add to the Block's =
Timestamp. This can be used to adjust the playback offset of a =
track.
        
        
          The maximum value of Blo=
ckAddID. A value 0 means there is no BlockAdditions for this track.
        
        
          A human-readable track =
name.
        
        
          Specifies the language of the track =
in the Matr=
oska languages form.
        
        
          An ID corresponding to the codec, =
see the codec =
page for more info.
        
        
          Private data only known to the =
codec.
        
        
          A human-readable string specifying =
the codec.
        
        
          The UID of an attachment that is =
used by this codec.
        
        
          A string describing the encoding =
setting used.
        
        
          A URL to find information about the =
codec used.
        
        
          A URL to download about the codec =
used.
        
        
          The codec can decode potentially =
damaged data (1 bit).
        
        
          Specify that this track is an =
overlay track for the Track specified (in the u-integer). That means =
when this track has a gap (see S=
ilentTracks) the overlay track should be used instead. The order of =
multiple TrackOverlay matters, the first one is the one that should be =
used. If not found it should be the second, etc.
        
        
          CodecDelay is The codec-built-in =
delay in nanoseconds. This value must be subtracted from each block =
timestamp in order to get the actual timestamp. The value should be =
small so the muxing of tracks with the same actual timestamp are in the =
same Cluster.
        
        
          After a discontinuity, SeekPreRoll =
is the duration in nanoseconds of the data the decoder must decode =
before the decoded data is valid.
        
        
          The track identification for the =
given Chapter Codec.
          
            Specify an edition UID on which =
this translation applies. When not specified, it means for all editions =
found in the Segment.
          
          
            The chapter codec using this ID (0: Matroska Script, 1: =
DVD-menu).
          
          
            The binary value used to =
represent this track in the chapter codec data. The format depends on =
the ChapProcessCodecID used.
          
        
        
          Video settings.
          
            A flag to declare is the video is =
known to be progressive or interlaced and if applicable to declare =
details about the interlacement. (0: undetermined, 1: interlaced, 2: =
progressive)
          
          
            Declare the field ordering of the =
video. If FlagInterlaced is not set to 1, this Element MUST be ignored. =
(0: Progressive, 1: Interlaced with top field display first and top =
field stored first, 2: Undetermined field order, 6: Interlaced with =
bottom field displayed first and bottom field stored first, 9: =
Interlaced with bottom field displayed first and top field stored first, =
14: Interlaced with top field displayed first and bottom field stored =
first)
          
          
            Stereo-3D video mode (0: mono, 1: =
side by side (left eye is first), 2: top-bottom (right eye is first), 3: =
top-bottom (left eye is first), 4: checkboard (right is first), 5: =
checkboard (left is first), 6: row interleaved (right is first), 7: row =
interleaved (left is first), 8: column interleaved (right is first), 9: =
column interleaved (left is first), 10: anaglyph (cyan/red), 11: side by =
side (right eye is first), 12: anaglyph (green/magenta), 13 both eyes =
laced in one Block (left eye is first), 14 both eyes laced in one Block =
(right eye is first)) . There are some more details on 3D =
support in the Specification Notes.
          
          
            Alpha Video Mode. Presence of =
this Element indicates that the BlockAdditional Element could contain =
Alpha data.
            
            DEPRECATED, DO NOT USE. Bogus =
StereoMode value used in old versions of libmatroska. (0: mono, 1: right =
eye, 2: left eye, 3: both eyes).
          
          
            Width of the encoded video frames =
in pixels.
          
          
            Height of the encoded video =
frames in pixels.
          
          
            The number of video pixels to =
remove at the bottom of the image (for HDTV content).
          
          
            The number of video pixels to =
remove at the top of the image.
          
          
            The number of video pixels to =
remove on the left of the image.
          
          
            The number of video pixels to =
remove on the right of the image.
          
          
            Width of the video frames to =
display. Applies to the video frame after cropping (PixelCrop* =
Elements). The default value is only valid when Di=
splayUnit is 0.
          
          
            Height of the video frames to =
display. Applies to the video frame after cropping (PixelCrop* =
Elements). The default value is only valid when Di=
splayUnit is 0.
          
          
            How DisplayWidth & =
DisplayHeight should be interpreted (0: pixels, 1: centimeters, 2: =
inches, 3: Display Aspect Ratio).
          
          
            Specify the possible =
modifications to the aspect ratio (0: free resizing, 1: keep aspect =
ratio, 2: fixed).
          
          
            Same value as in AVI (32 =
bits).
          
          
            Gamma Value.
          
          
            Number of frames per second. =
Informational only.
          
          
            Settings describing the colour =
format.
            
              The Matrix Coefficients of the =
video used to derive luma and chroma values from reg, green, and blue =
color primaries. For clarity, the value and meanings for =
MatrixCoefficients are adopted from Table 4 of ISO/IEC =
23001-8:2013/DCOR1. (0:GBR, 1: BT709, 2: Unspecified, 3: Reserved, 4: =
FCC, 5: BT470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: YCOCG, 9: BT2020 =
Non-constant Luminance, 10: BT2020 Constant Luminance)
            
            
              Number of decoded bits per =
channel. A value of 0 indicates that the BitsPerChannel is =
unspecified.
            
            
              The amount of pixels to remove =
in the Cr and Cb channels for every pixel not removed horizontally. =
Example: For video with 4:2:0 chroma subsampling, the =
ChromaSubsamplingHorz should be set to 1.
            
            
              The amount of pixels to remove =
in the Cr and Cb channels for every pixel not removed vertically. =
Example: For video with 4:2:0 chroma subsampling, the =
ChromaSubsamplingVert should be set to 1.
            
            
              The amount of pixels to remove =
in the Cb channel for every pixel not removed horizontally. This is =
additive with ChromaSubsamplingHorz. Example: For video with 4:2:1 =
chroma subsampling, the ChromaSubsamplingHorz should be set to 1 and =
CbSubsamplingHorz should be set to 1.
            
            
              The amount of pixels to remove =
in the Cb channel for every pixel not removed vertically. This is =
additive with ChromaSubsamplingVert.
            
            
              How chroma is subsampled =
horizontally. (0: Unspecified, 1: Left Collocated, 2: =
Half)
            
            
              How chroma is subsampled =
vertically. (0: Unspecified, 1: Top Collocated, 2: Half)
            
            
              Clipping of the color ranges. =
(0: Unspecified, 1: Broadcast Range, 2: Full range (no clipping), 3: =
Defined by MatrixCoefficients/TransferCharacteristics)
            
            
              The transfer characteristics of =
the video. For clarity, the value and meanings for =
TransferCharacteristics 1-15 are adopted from Table 3 of ISO/IEC =
23001-8:2013/DCOR1. TransferCharacteristics 16-18 are proposed values. =
(0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved, 4: Gamma 2.2 =
curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: =
Log, 10: Log Sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour =
Gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: ITU-R BT.2020 12 =
bit, 16: SMPTE ST 2084, 17: SMPTE ST 428-1 18: ARIB STD-B67 =
(HLG))
            
            
              The colour primaries of the =
video. For clarity, the value and meanings for Primaries are adopted =
from Table 2 of ISO/IEC 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R =
BT.709, 2: Unspecified, 3: Reserved, 4: ITU-R BT.470M, 5: ITU-R =
BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM, 9: ITU-R BT.2020, 10: =
SMPTE ST 428-1, 22: JEDEC P22 phosphors)
            
            
              Maximum brightness of a single =
pixel (Maximum Content Light Level) in candelas per square meter =
(cd/m=C2=B2).
            
            
              Maximum brightness of a single =
full frame (Maximum Frame-Average Light Level) in candelas per square =
meter (cd/m=C2=B2).
            
            
              SMPTE 2086 mastering =
data.
              
                Red X chromaticity coordinate =
as defined by CIE 1931.
              
              
                Red Y chromaticity coordinate =
as defined by CIE 1931.
              
              
                Green X chromaticity =
coordinate as defined by CIE 1931.
              
              
                Green Y chromaticity =
coordinate as defined by CIE 1931.
              
              
                Blue X chromaticity =
coordinate as defined by CIE 1931.
              
              
                Blue Y chromaticity =
coordinate as defined by CIE 1931.
              
              
                White X chromaticity =
coordinate as defined by CIE 1931.
              
              
                White Y chromaticity =
coordinate as defined by CIE 1931.
              
              
                Maximum luminance. Shall be =
represented in candelas per square meter (cd/m=C2=B2).
              
              
                Mininum luminance. Shall be =
represented in candelas per square meter (cd/m=C2=B2).
              
            
          
        
        
          Audio settings.
          
            Sampling frequency in =
Hz.
          
          
            Real output sampling frequency in =
Hz (used for SBR techniques).
          
          
            Numbers of channels in the =
track.
          
          
            Table of horizontal angles for =
each successive channel, see appendix.
          
          
            Bits per sample, mostly used for =
PCM.
          
        
        
          Operation that needs to be applied =
on tracks to create this virtual track. For more details look at the Specification Notes on the subject.
          
            Contains the list of all video =
plane tracks that need to be combined to create this 3D =
track
            
              Contains a video plane track =
that need to be combined to create this 3D track
              
                The trackUID number of the =
track representing the plane.
              
              
                The kind of plane this track =
corresponds to (0: left eye, 1: right eye, 2: =
background).
              
            
          
          
            Contains the list of all tracks =
whose Blocks need to be combined to create this virtual =
track
            
              The trackUID number of a track =
whose blocks are used to create this virtual track.
            
          
        
        
          DivX trick track extenstions
        
        
          DivX trick track extenstions
        
        
          DivX trick track extenstions
        
        
          DivX trick track extenstions
        
        
          DivX trick track extenstions
        
        
          Settings for several content =
encoding mechanisms like compression or encryption.
          
            Settings for one content encoding =
like compression or encryption.
            
              Tells when this modification =
was used during encoding/muxing starting with 0 and counting upwards. =
The decoder/demuxer has to start with the highest order number it finds =
and work its way down. This value has to be unique over all =
ContentEncodingOrder Elements in the Segment.
            
            
              A bit field that describes =
which Elements have been modified in this way. Values (big endian) can =
be OR'ed. Possible values:
 1 - all frame contents,
 2 - the =
track's private data,
 4 - the next ContentEncoding (next =
ContentEncodingOrder. Either the data inside ContentCompression and/or =
ContentEncryption)
            
            
              A value describing what kind of =
transformation has been done. Possible values:
 0 - =
compression,
 1 - encryption
            
            
              Settings describing the =
compression used. Must be present if the value of ContentEncodingType is =
0 and absent otherwise. Each block must be decompressable even if no =
previous block is available in order not to prevent =
seeking.
              
                The compression algorithm =
used. Algorithms that have been specified so far are:
 0 - =
zlib,
 1 - bzlib,
 2 - lzo1x
 3 - =
Header Stripping
              
              
                Settings that might be needed =
by the decompressor. For Header Stripping (ContentCompAlgo=3D3), the =
bytes that were removed from the beggining of each frames of the =
track.
              
            
            
              Settings describing the =
encryption used. Must be present if the value of ContentEncodingType is =
1 and absent otherwise.
              
                The encryption algorithm =
used. The value '0' means that the contents have not been encrypted but =
only signed. Predefined values:
 1 - DES, 2 - 3DES, 3 - Twofish, 4 - =
Blowfish, 5 - AES
              
              
                For public key algorithms =
this is the ID of the public key the the data was encrypted =
with.
              
              
                A cryptographic signature of =
the contents.
              
              
                This is the ID of the private =
key the data was signed with.
              
              
                The algorithm used for the =
signature. A value of '0' means that the contents have not been signed =
but only encrypted. Predefined values:
 1 - RSA
              
              
                The hash algorithm used for =
the signature. A value of '0' means that the contents have not been =
signed but only encrypted. Predefined values:
 1 - SHA1-160
 2 - =
MD5
              
            
          
        
      
    
    
      A Top-Level Element to speed seeking =
access. All entries are local to the Segment. Should be mandatory for =
non "live" =
streams.
      
        Contains all information relative to =
a seek point in the Segment.
        
          Absolute timestamp according to the =
Segment time base.
        
        
          Contain positions for different =
tracks corresponding to the timestamp.
          
            The track for which a position is =
given.
          
          
            The position of the Cluster containing the required =
Block.
          
          
            The relative position of the =
referenced block inside the cluster with 0 being the first possible =
position for an Element inside that cluster.
          
          
            The duration of the block =
according to the Segment time base. If missing the track's =
DefaultDuration does not apply and no duration information is available =
in terms of the cues.
          
          
            Number of the Block in the =
specified Cluster.
          
          
            The position of the Codec State corresponding to this Cue Element. =
0 means that the data is taken from the initial Track =
Entry.
          
          
            The Clusters containing the =
required referenced Blocks.
            
              Timestamp of the referenced =
Block.
            
            
              The Position of the Cluster containing the referenced =
Block.
            
            
              Number of the referenced Block =
of Track X in the specified Cluster.
            
            
              The position of the Codec State corresponding to this referenced =
Element. 0 means that the data is taken from the initial Track =
Entry.
            
          
        
      
    
    
      Contain attached files.
      
        An attached file.
        
          A human-friendly name for the =
attached file.
        
        
          Filename of the attached =
file.
        
        
          MIME type of the =
file.
        
        
          The data of the =
file.
        
        
          Unique ID representing the file, as =
random as possible.
        
        
          A binary value that a track/codec =
can refer to when the attachment is needed.
        
        
          DivX font extension
        
        
          DivX font extension
        
      
    
    
      A system to define basic menus and =
partition data. For more detailed information, look at the Chapt=
ers Explanation.
      
        Contains all information about a =
Segment edition.
        
          A unique ID to identify the =
edition. It's useful for tagging an edition.
        
        
          If an edition is hidden (1), it =
should not be available to the user interface (but still to Control =
Tracks; see flag notes). (1 bit)
        
        
          If a flag is set (1) the edition =
should be used as the default one. (1 bit)
        
        
          Specify if the chapters can be =
defined multiple times and the order to play them is enforced. (1 =
bit)
        
        
          Contains the atom information to =
use as the chapter atom (apply to all tracks).
          
            A unique ID to identify the =
Chapter.
          
          
            A unique string ID to identify =
the Chapter. Use for WebVTT =
cue identifier storage.
          
          
            Timestamp of the start of Chapter =
(not scaled).
          
          
            Timestamp of the end of Chapter =
(timestamp excluded, not scaled).
          
          
            If a chapter is hidden (1), it =
should not be available to the user interface (but still to Control =
Tracks; see flag notes). (1 bit)
          
          
            Specify wether the chapter is =
enabled. It can be enabled/disabled by a Control Track. When disabled, =
the movie should skip all the content between the TimeStart and TimeEnd =
of this chapter (see flag notes). (1 bit)
          
          
            A Segment to play in place of =
this chapter. Edition ChapterSegmentEditionUID should be used for this =
Segment, otherwise no edition is used.
          
          
            The EditionUID to play from the =
Segment linked in ChapterSegmentUID.
          
          
            Specify the physical equivalent =
of this ChapterAtom like "DVD" (60) or "SIDE" (50), see compl=
ete list of values.
          
          
            List of tracks on which the =
chapter applies. If this Element is not present, all tracks =
apply
            
              UID of the Track to apply this =
chapter too. In the absense of a control track, choosing this chapter =
will select the listed Tracks and deselect unlisted tracks. Absense of =
this Element indicates that the Chapter should be applied to any =
currently used Tracks.
            
          
          
            Contains all possible strings to =
use for the chapter display.
            
              Contains the string to use as =
the chapter atom.
            
            
              The languages corresponding to =
the string, in the biblio=
graphic ISO-639-2 form.
            
            
              The countries corresponding to =
the string, same 2 octets as in Internet =
domains.
            
          
          
            Contains all the commands =
associated to the Atom.
            
              Contains the type of the codec =
used for the processing. A value of 0 means native Matroska processing =
(to be defined), a value of 1 means the D=
VD command set is used. More codec IDs can be added =
later.
            
            
              Some optional data attached to =
the ChapProcessCodecID information. F=
or ChapProcessCodecID =3D 1, it is the "DVD level" =
equivalent.
            
            
              Contains all the commands =
associated to the Atom.
              
                Defines when the process =
command should be handled (0: during the whole chapter, 1: before =
starting playback, 2: after playback of the chapter).
              
              
                Contains the command =
information. The data should be interpreted depending on the =
ChapProcessCodecID value. F=
or ChapProcessCodecID =3D 1, the data correspond to the binary DVD =
cell pre/post commands.
              
            
          
        
      
    
    
      Element containing Elements specific to =
Tracks/Chapters. A list of valid tags can be found here.<=
/a>
      
        Element containing Elements specific =
to Tracks/Chapters.
        
          Contain all UIDs where the =
specified meta data apply. It is empty to describe everything in the =
Segment.
          
            A number to indicate the logical =
level of the target (see TargetType).
          
          
            An informational =
string that can be used to display the logical level of the target like =
"ALBUM", "TRACK", "MOVIE", "CHAPTER", etc (see TargetType).
          
          
            A unique ID to identify the =
Track(s) the tags belong to. If the value is 0 at this level, the tags =
apply to all tracks in the Segment.
          
          
            A unique ID to identify the =
EditionEntry(s) the tags belong to. If the value is 0 at this level, the =
tags apply to all editions in the Segment.
          
          
            A unique ID to identify the =
Chapter(s) the tags belong to. If the value is 0 at this level, the tags =
apply to all chapters in the Segment.
          
          
            A unique ID to identify the =
Attachment(s) the tags belong to. If the value is 0 at this level, the =
tags apply to all the attachments in the Segment.
          
        
        
          Contains general information about =
the target.
          
            The name of the Tag that is going =
to be stored.
          
          
            Specifies the language of the tag =
specified, in the Matr=
oska languages form.
          
          
            Indication to know if this is the =
default/original language to use for the given tag. (1 =
bit)
          
          
            The value of the =
Tag.
          
          
            The values of the Tag if it is =
binary. Note that this cannot be used in the same SimpleTag as =
TagString.
          
        
      
    
  


Best Regards,
Dave Rice


From nobody Thu May 26 04:46:03 2016
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 6FE2212D60C for ; Thu, 26 May 2016 04:45:42 -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 wLkwgdv5Rvtx for ; Thu, 26 May 2016 04:45:40 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 8CB2912DA8B for ; Thu, 26 May 2016 04:45:38 -0700 (PDT)
Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:37469 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b5tjL-001e2l-FN; Thu, 26 May 2016 07:45:38 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dave Rice 
In-Reply-To: <04409161-02A4-471F-9EFE-9DC612D1361B@dericed.com>
Date: Thu, 26 May 2016 07:45:33 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <0082910D-11B9-41A8-BB89-83BD03BAAD77@dericed.com>
References: <1687ED1D-AF44-4BC5-B1E5-89F2CD7440E7@dericed.com> <13C43671-E7FC-4011-B759-0E4F0E003D98@dericed.com>  <20160524071803.hcwlq4yu2s2djcxk@bunkus.org> <04409161-02A4-471F-9EFE-9DC612D1361B@dericed.com>
To: Moritz Bunkus 
X-Mailer: Apple Mail (2.3124)
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: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] Matroska Ordering Guidelines
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 11:45:42 -0000
X-List-Received-Date: Thu, 26 May 2016 11:45:42 -0000

> On May 24, 2016, at 10:01 AM, Dave Rice  wrote:
>=20
> Hi,
>=20
>> On May 24, 2016, at 3:18 AM, Moritz Bunkus  wrote:
>>=20
>> Hey,
>>=20
>>> - "The Matroska specification recommends that `CRC-32` Elements =
SHOULD
>>> NOT be used as an immediate Child Element of the `Segment`
>>> Element=E2=80=9D. The EBML spec permits CRC-32 within Level 0 =
Elements and
>>> I=E2=80=99ve seen files before with CRC-32 as a Child Element of the =
EBML
>>> Header.
>>=20
>> I'd like to keep the wording "SHOULD NOT =E2=80=A6 as a child of =E2=80=
=A6 segment" for
>> several reasons:
>=20
> Sorry to not clarify this well. The quote "The Matroska specification =
recommends that `CRC-32` Elements SHOULD
> NOT be used as an immediate Child Element of the `Segment` Element=E2=80=
=9D is a proposal of mine. The current Matroska specification seems to =
permit a CRC-32 Element as an immediate Child Element of Segment.
>=20
>> - If such an element is present updating any part of the file =
(changing
>> header values, adding attachments, removing chapters=E2=80=A6) =
requires
>> re-calculating the CRC-32 element.
>> - Verifying the element requires reading the whole file which =
requires a
>> lot of time and resources.
>=20
> Agreed.
>=20
>> - It doesn't provide a lot of value. If it is invalid all you can say =
is
>> that the whole, arbitrarily large file is damaged somewhere. With
>> libEBML you cannot even verify the CRC-32 properly because it =
requires
>> the whole element to be present in memory at the moment=E2=80=A6
>=20
> Agreed, but what if a non-Master-element was defined at Level 1 as an =
immediate child of Segment. Using a CRC-32 as a child of Segment would =
be the only way to represent the fixity of a non-Master-element at Level =
1.
>=20
>>> The `Info` Element doesn=E2=80=99t have it=E2=80=99s own ordering =
suggestions but the
>>> `Chapters` Element section infers it, so I added an `Info` ordering
>>> section based on what is inferred.
>>=20
>> Sounds fine.
>>=20
>>> I=E2=80=99m confused about the mandates of referencing `Clusters` in
>>> `SeekHead`. Is it required that ALL Cluster are referenced by the
>>> `SeekHead` Element(s)?
>>=20
>> No, we never mandated that. It doesn't provide much value over having
>> `Cues` elements anyway. I prefer guidelines to reflect what works =
well
>> in practice, and in practice you don't need `Clusters` to be =
referenced
>> by `SeekHead` elements.
>=20
> Right, bad presumption of mine that SeekHead(s) should document all =
Top Level Elements. The current SeekHead definition does not mandate =
that all Top-Level Elements are referenced, but says "Contains the =
position of other Top-Level Elements." Steve confirmed that it is not a =
mandate to document all Top Level Elements here: =
https://mailarchive.ietf.org/arch/msg/cellar/UZMYejpNV7roYBsrXDzQKDfJSd0. =
I'll remove the mandate, rebase, and resubmit.
>=20
>>> Or is only the first Cluster a mandate and the rest of the Clusters
>>> suggested? If two `SeekHead` Elements are used, is the first
>>> `SeekHead` allowed to reference all `Cluster` Element?
>>=20
>> Additionally I don't see any benefit of restricting which `SeekHead` =
can
>> contain the clusters seeing how little benefit referencing the =
clusters
>> provides.
>>=20
>> In fact I don't like imposing real restrictions on where to reference
>> elements from. If a player can read `SeekHead` elements then it =
should
>> not matter which `SeekHead` references which element =E2=80=93 the =
player should
>> process them all.
>=20
> This is a mandate from the original documentation at =
https://matroska.org/technical/order/index.html: "The second Meta Seek =
is placed at the end and contains a lengthy list of all Clusters (and =
not the other level 1 elements)." Is the parenthetical part at the end =
indeed a mandate about the second SeekHead?
>=20
>> Now from a perspective of being able to edit the file after it's been
>> created putting most content into a `SeekHead` at the end of the file =
is
>> more sensible as an editor has much more options to deal with such a
>> structure than if they're all part of the first `SeekHead` at the =
front
>> of the file.
>>=20
>>> The EBML specification gives a distinction between Level 1 Elements
>>> and Top-Level Elements in that Top-Level Elements are Elements that
>>> may only occur at Level 1. Thus CRC-32 and Void (as global elements)
>>> are not considered Top-Level Elements. If Void and CRC-32 are used =
at
>>> Level 1, is it clear that these Elements do not have to be =
referenced
>>> in the SeekHead Element(s)?
>>=20
>> Huh=E2=80=A6 Interesting question. As they're not required for =
playback I don't
>> consider them to be candidates for mandatory referencing; though it =
is
>> obvious that knowing their location is beneficial for certain kinds =
of
>> applications (CRC-32: structure verification & editing; Voids: =
editing).
>=20
> OK, without a mandate to reference all Top-Level Elements this =
question is less significant, but I could adjust this to say that the =
SeekHead should only reference Level 1 Elements, so that Void Elements =
may be listed in SeekHead.
>=20
>>> I=E2=80=99d like to verify that it is a requirement that the second
>>> `SeekHead`, if used, only contain reference to `Cluster` Elements. =
For
>>> instance if the first `SeekHead` is not followed by some padding, =
then
>>> this requirement makes it difficult to edit a file (to add an
>>> attachment, tags, or chapters) without re-writing most of it.
>>=20
>> I completely agree. This wording is one I've always disagreed
>> with. Steve & I where always opposites regarding the use of more than
>> one `SeekHead`. As I've stated above I strongly prefer to allow two
>> `SeekHeads` with almost arbitrary placement (the first one must be
>> located before the first cluster and it must reference the second =
one)
>> and, more important, arbitrary content.
>=20
> I agree that two SeekHeads is sensible. Once the Matroska specdata.xml =
is updated as an EBML Schema we can use maxOccurs=3D"2" for SeekHead as =
it seems that no one wants a third SeekHead. Going back to a quote from =
the original specification: "The second Meta Seek is placed at the end =
and contains a lengthy list of all Clusters (and not the other level 1 =
elements)." Are we agreed to remove this mandate that the second =
SeekHead not contain any non-Cluster Elements?
>=20
>> In writing mkvpropedit and the GUI's header editor it became =
painfully
>> obvious that editing existing files is simply not possible without
>> allowing a second `SeekHead` and using it for all types of 1
>> elements. If we disallow it then that would pretty much end all uses =
of
>> in-place editing of existing files without remuxing, something the =
users
>> would definitely not appreciate. Files that strictly follow the
>> guidelines are of course still editable, but my past experience is =
that
>> a very big percentage do not follow those guidelines and would not =
allow
>> editing (e.g. because there's no space after the first `SeekHead`).
>=20
> It seems though that there are two bad options permitted when editing =
a file with one SeekHead that do not use a second SeekHead.
>=20
> 1. Void the SeekHead and add a new SeekHead at the end. This doesn't =
follow the recommendation of the Matroska specification but does not =
violate any mandate. Putting SeekHead before Clusters is a SHOULD and =
not a MUST.
>=20
> 2. Just Void the SeekHead and have no SeekHead at all. It presence is =
not a mandate.
>=20
>>> We should recommend a certain amount of padding to follow the first
>>> SeekHead. Any recommendations?
>>=20
>> If we disregard the clusters: maybe 100 bytes or something like that?
>> One `SeekHead` entry is ~18 bytes in size, and leaving 100 bytes =
would
>> be plenty (adding attachments, chapters, tags are probably the most
>> interesting and most common use cases; the extra bytes would be a
>> reserve for future additions).
>=20
> Seems sensible, I'll add it as a suggestion.
>=20
>>> The Tags ordering section suggests that if a Tags Element is at the
>>> beginning of the file and needs to be edited/expanded, then the Tags
>>> Element can be Voided, and a new one written at the end. But the =
Tags
>>> Element is allowed to occur multiple times. If someone is just added =
a
>>> new tag, could the new Tags Element just be written at the end of =
the
>>> Segment and the first Tags element left as is?
>>=20
>> No. You'll have to relocate the whole element and add the new element =
to
>> the freshly moved `Tags` element.
>=20
> The "Tags" element is set to multiple. If not this case, when is it =
recommended to use more than one "Tags" Element?

Answering myself here, but perhaps Tags has multiple=3D=E2=80=9C1=E2=80=9D=
 to allow it to be repeated in entirety at differing points in the =
Segment, such as:

	
	
	


where the two  elements MUST be identical in storage and =
semantics. If this is so, then Tags should be defined as =
maxOccurs=3D=E2=80=9Cidentical=E2=80=9D in the EBML Schema.

Steve, Moritz, was this is the intent of repeating Tags?

>> Got to stop here as I have to go.
>=20
> [...]
>=20
> Same here. Bye,
> Dave Rice
>=20
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar


From nobody Thu May 26 04:57:49 2016
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 0F3FB12DE46 for ; Thu, 26 May 2016 04:57:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.427
X-Spam-Level: 
X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_HELO_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 VQscKPXQMvwl for ; Thu, 26 May 2016 04:57:47 -0700 (PDT)
Received: from liselle.bunkus.org (liselle.bunkus.org [IPv6:2a01:4f8:151:7310::105:1]) (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 E879412D1CE for ; Thu, 26 May 2016 04:57:46 -0700 (PDT)
Received: by liselle.bunkus.org (Postfix, from userid 1002) id BC89F3257C50; Thu, 26 May 2016 13:57:44 +0200 (CEST)
Received: from sweet-chili.local (unknown [10.55.1.18]) by liselle.bunkus.org (Postfix) with ESMTPS id 8778B3257C49 for ; Thu, 26 May 2016 13:57:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2016040101; t=1464263863; bh=9OhkNKtDLNibVzNIhoKqkijsw+zZL9MlAAROpZzpFXQ=; h=Date:From:To:Subject:References:In-Reply-To; b=F116pFODgYz1wYFNuu1tQ4k59erjhYtLMz2IMytAqhk5HeTJcRWTBKW/bQQ6G7aUu tEcOkZ6r90VhB5gQHH5bM+rwSEXZVvAaG1+UJCfw0XuYAVHfnat6UnIY8ti4NLnU5C eC8zbbxA1R7kai2pDr4OlsKVXX44t6WVJgMcf3P2hnhn0Ob6zabNKYfuixwnW0X1r/ uVQmFuDbb4JaQC17RU7xMFKcmIb6DJDEWCDe6jVrNw2wGKa/UADurHv0EmYxYFiGtt cKJ2+a8qymAAqf9q4T9b215Q7dDTBIIdj2O3I15EL5YGh0B6WfiiLjHPZAzoYQmB6T yIA9i2ETw2gdjDr+/khM/TFtJ/hUxeYLyQbj80iaRl7PsBA8BeOLhzOLlGYU5Y0moY LdU/ETZ28YTfAFmcePHXHclpGHplRSZOvNW68Bdxth0V1HXHiDPloOIFdwBd254rPe b9gEq5Ks1yyP8zjbKF/0WgItvctoIPiFcFhVnyuoqb3DfCuK9h4jejL2Ec6bw6rg8H q+8aVUF9VU/JWVgXfzLfYcOEsFFv4l5QSARA41YHX7BJSwg+c6/qNBkC/ORkol70dn M9YmlowPGSD61AtCcARIjLdfEem+zhkFw1/QlUWgKBHhEKuf29N2ANc8R2D1Z5M7pQ cpVLfFkaKNfSRlQFo2WqtlHo=
Received: by sweet-chili.local (Postfix, from userid 1000) id D9C3F667AAB; Thu, 26 May 2016 13:57:42 +0200 (CEST)
Date: Thu, 26 May 2016 13:57:42 +0200
From: Moritz Bunkus 
To: cellar@ietf.org
Message-ID: <20160526115742.nytc3jcedcgnz5ya@bunkus.org>
References: <1687ED1D-AF44-4BC5-B1E5-89F2CD7440E7@dericed.com> <13C43671-E7FC-4011-B759-0E4F0E003D98@dericed.com>  <20160524071803.hcwlq4yu2s2djcxk@bunkus.org> <04409161-02A4-471F-9EFE-9DC612D1361B@dericed.com> <0082910D-11B9-41A8-BB89-83BD03BAAD77@dericed.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <0082910D-11B9-41A8-BB89-83BD03BAAD77@dericed.com>
User-Agent: Mutt/1.6.1-neo ()
X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4
X-Virus-Scanned: clamav-milter 0.98.7 at liselle
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [Cellar] Matroska Ordering Guidelines
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 11:57:48 -0000

Hey,

> where the two  elements MUST be identical in storage and
> semantics. If this is so, then Tags should be defined as
> maxOccurs=“identical” in the EBML Schema.
>
> Steve, Moritz, was this is the intent of repeating Tags?

I honestly don't know/don't remember. Personally I'd prefer Tags,
Chapters, Attachments to be optional and unique (minOccurs="0"
maxOccurs="1") in order to avoid any ambiguity and to simplify software
dealing with those elements.

The intention with allowing "Tracks" multiple times was to improve
resilience by storing multiple identical copies
(maxOccurs="identical"). However, this does complicate things for
editing software. For example, neither mkvpropedit not MKVToolNix GUI's
header editor deal with such files properly and only change the first
"Tracks" element they find.

Kind regards,
mosu


From nobody Thu May 26 05:42:42 2016
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 EF14112DE97 for ; Thu, 26 May 2016 05:42:40 -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 1cba0NUEHA8X for ; Thu, 26 May 2016 05:42:39 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 ADF4412DE95 for ; Thu, 26 May 2016 05:42:39 -0700 (PDT)
Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:41858 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b5ucX-0034kN-8F for cellar@ietf.org; Thu, 26 May 2016 08:42:39 -0400
From: Dave Rice 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: 
Date: Thu, 26 May 2016 08:42:17 -0400
To: cellar@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
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: [Cellar] New Constraints in Matroska's EBML Schema
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 12:42:41 -0000

Compared to specdata.xml the EBML Schema permits some constraints that =
weren=E2=80=99t defined before. Before updating the Matroksa EBML Schema =
(currently here: =
https://github.com/Matroska-Org/matroska-specification/pull/20/files) =
I=E2=80=99d like to see if we have consensus on these new constraints.

I propose adding unknownsizeallowed=3D1 to Segment. Are there any other =
Elements which should permit an unknown size.

I propose changing SeekHead from maxOccurs=3D=E2=80=9Cunbounded=E2=80=9D =
to maxOccurs=3D=E2=80=9C2=E2=80=9D. It seems no one wants a third =
SeekHead.

For all Top Level Elements actually I think the use of =
maxOccurs=3D=E2=80=9Cidentical=E2=80=9D or maxOccurs=3D=E2=80=9Cunbounded=E2=
=80=9D should be reviewed.

Dave Rice=


From nobody Thu May 26 10:08:53 2016
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 C663012D7BE for ; Thu, 26 May 2016 10:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.126
X-Spam-Level: 
X-Spam-Status: No, score=-4.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 pBqEZ0T6cXli for ; Thu, 26 May 2016 10:08:49 -0700 (PDT)
Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (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 AFE1A12D7BA for ; Thu, 26 May 2016 10:08:49 -0700 (PDT)
Received: by mail-ig0-x236.google.com with SMTP id ww4so94141521igb.1 for ; Thu, 26 May 2016 10:08:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=AJJL4+k1tJ76wZjrLSApbQEZOdqxhhOkkMDFCWxmR88=; b=pQDH36qVJFcx3E1OTATJVT+d/+WtSmTuhtNpdWUw8rjawPimTxbZmUosMp/jZD2/B+ fSG8f50tfB1oyIVAEYAZJQc6Jtnky3Q1EMEoj7pe6Y6GykF1+yCqwqjHvsfzi7OZXfZj CIV18juxlmWDDv/292qxlr62cfA6cm2B8x3qSy2sqdl20aRjpFzRimTwhQpA1s1Pf3Iv 4u2GMmL0Z+NXk5EY1qMAU53Apg6lpJqrEQMVqk1YXLFU2DWReCWLCQ55NewDsyKcvUkn NtrWolNElX+Kw4kzt4bYzrwNPXVEVUvwt6UHScLFgkhhmOzylM4oXZg71eZ8W98CslhS Hbxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=AJJL4+k1tJ76wZjrLSApbQEZOdqxhhOkkMDFCWxmR88=; b=dZpjShqSpWLfZfoNZBIJWakX5vzvPrdrAq+H0I2wTcySOuWIlvhuWllvL/DNw9t90i /RGn73iTTf5rAH7g9Ndp3oQg+4MkPI/g3obxryKzqsjJpOmQXFWrLVua9gZR9V31JRGv N2ieh2kHDH301d9NsbYg4VWdI7MPEn7mzSeX2CVm7hwdDyVWkSg1bDJ9LNMILmX+qu62 qB4UGBWfVtmpRDi14Q1sjpQrgzjJqFnvB6KEqaBIRDInGae7qHfjtEBau1umiljhw8VI MGb9uVjkjJQcarCQVs8kKAKwY2/flFGUft0arQ6jZJMptQY0RrE07O6lQw2AGf597sQX nTNA==
X-Gm-Message-State: ALyK8tKIfZpkzBQnNJHKXA3cxzgZ9cNLpena9Dxo4kTY0svfU2GX0rhIHvmm99lQQCr+TBcMCjLU3blaaZvKGM36
X-Received: by 10.50.140.193 with SMTP id ri1mr4240313igb.60.1464282527272; Thu, 26 May 2016 10:08:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.15.22 with HTTP; Thu, 26 May 2016 10:08:27 -0700 (PDT)
In-Reply-To: 
References: <1687ED1D-AF44-4BC5-B1E5-89F2CD7440E7@dericed.com> <13C43671-E7FC-4011-B759-0E4F0E003D98@dericed.com> 
From: Michael Bradshaw 
Date: Thu, 26 May 2016 10:08:27 -0700
Message-ID: 
To: cellar@ietf.org
Content-Type: multipart/alternative; boundary=001a1132fe08e423100533c1d756
Archived-At: 
Subject: Re: [Cellar] Matroska Ordering Guidelines
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 26 May 2016 17:08:52 -0000

--001a1132fe08e423100533c1d756
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, May 23, 2016 at 8:07 PM, Dave Rice  wrote:
>
> I started a rewrite of the Matroska Ordering Guideilnes in order to
> correct and clarify the recommendations and mandates of the section. I=E2=
=80=99ll
> include the updated text below and it is also reviewable as a pull reques=
t
> at https://github.com/Matroska-Org/matroska-specification/pull/16.
> Because this is a rewrite, it is difficult to diff, but please review wha=
t
> parts are deleted. This link is probably the most readable diff:
> https://github.com/Matroska-Org/matroska-specification/pull/16/commits/9f=
d95b3a0ad75ee49ac56b9f09efbebb7c08f1e3.
> Overall I=E2=80=99ve intended to keep the same meaning but form it more c=
learly,
> but this needs a review.
>
> In addition to a rewrite I added a few more recommendations or mandates
> which include:
>

Overall I think it's an improvement. However, I still think calling them
"guidelines" but then using language like MUST is kind of confusing. If the
MUST mandates are truly requirements, then I suggest moving them into a
separate document that has an appropriate title.

Also, the structure of the spec(s) is kind of confusing because there are
multiple documents and it's not immediately clear what's intended to be
informative and what's intended to be authoritative. I think it would be
nice if all authoritative documents were compiled into a single document
(just with multiple sections/annexes), however if there are going to be
multiple RFCs then a single document makes less sense and I would suggest
each document clearly reference its dependencies (with language that makes
it clear what's a requirement and what's a guideline/purely informative).

--001a1132fe08e423100533c1d756
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


On M=
on, May 23, 2016 at 8:07 PM, Dave Rice <dave@dericed.com> wrote:
I started a rewrite of the =
Matroska Ordering Guideilnes in order to correct and clarify the recommenda=
tions and mandates of the section. I=E2=80=99ll include the updated text be=
low and it is also reviewable as a pull request at https://github.com/Matro=
ska-Org/matroska-specification/pull/16. Because this is a rewrite, it i=
s difficult to diff, but please review what parts are deleted. This link is=
 probably the most readable diff: https://github.com/Matroska-Org/matroska-specification/pull/16/comm=
its/9fd95b3a0ad75ee49ac56b9f09efbebb7c08f1e3. Overall I=E2=80=99ve inte=
nded to keep the same meaning but form it more clearly, but this needs a re=
view.

In addition to a rewrite I added a few more =
recommendations or mandates which include:

Overall I think it's an improvement. However, I still=
 think calling them "guidelines" but then using language like MUS=
T is kind of confusing. If the MUST mandates are truly requirements, then I=
 suggest moving them into a separate document that has an appropriate title=
.

Also, the structure of the spec(s) is kind of co=
nfusing because there are multiple documents and it's not immediately c=
lear what's intended to be informative and what's intended to be au=
thoritative. I think it would be nice if all authoritative documents were c=
ompiled into a single document (just with multiple sections/annexes), howev=
er if there are going to be multiple RFCs then a single document makes less=
 sense and I would suggest each document clearly reference its dependencies=
 (with language that makes it clear what's a requirement and what's=
 a guideline/purely informative).


--001a1132fe08e423100533c1d756--


From nobody Fri May 27 06:47:28 2016
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 69DAE12D52B for ; Fri, 27 May 2016 06:47:26 -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 HmVx09afhOP2 for ; Fri, 27 May 2016 06:47:24 -0700 (PDT)
Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (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 BA51612D508 for ; Fri, 27 May 2016 06:47:24 -0700 (PDT)
Received: from eris.local (dynamic-adsl-84-220-81-12.clienti.tiscali.it [84.220.81.12]) (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 82875340B29 for ; Fri, 27 May 2016 13:47:20 +0000 (UTC)
To: cellar@ietf.org
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net> <20160526030329.GA4558@nb4>
From: Luca Barbato 
Message-ID: <3b722ae9-7d85-977e-a085-9943b4809d3f@libav.org>
Date: Fri, 27 May 2016 15:47:16 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2
MIME-Version: 1.0
In-Reply-To: <20160526030329.GA4558@nb4>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1 0/2] Clarification about versions and slice structure
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 27 May 2016 13:47:26 -0000

On 26/05/16 05:03, Michael Niedermayer wrote:
> does "version >=3"  really refer less to version 2 than version >=2 ?
> i think in cases like above its better to choose the point so that
> its most correct

If version 2 is non-defined in the specification would be better not
even hint that it could be decoded somehow in the specification or even
in the implementation advices section.

It can get quite confusing, probably would be safer even remove it from
the code so nobody would look at it and maybe overlook the fact it is
experimental and not to be used...

lu


From nobody Fri May 27 09:47:18 2016
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 D56A412D73F for ; Fri, 27 May 2016 09:47:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 VY4KOua5Kcb8 for ; Fri, 27 May 2016 09:47:15 -0700 (PDT)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [IPv6:2001:4b98:c:538::197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E889012D726 for ; Fri, 27 May 2016 09:47:14 -0700 (PDT)
Received: from mfilter44-d.gandi.net (mfilter44-d.gandi.net [217.70.178.175]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id 3AB6841C087 for ; Fri, 27 May 2016 18:47:13 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter44-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter44-d.gandi.net (mfilter44-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id PWayGHNRIpeS for ; Fri, 27 May 2016 18:47:11 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 94C7841C09B for ; Fri, 27 May 2016 18:47:11 +0200 (CEST)
Date: Fri, 27 May 2016 18:44:50 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160527164450.GC4558@nb4>
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net> <20160526030329.GA4558@nb4> 
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yLVHuoLXiP9kZBkt"
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1 0/2] Clarification about versions and slice structure
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 27 May 2016 16:47:17 -0000

--yLVHuoLXiP9kZBkt
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 26, 2016 at 09:20:43AM +0200, Jerome Martinez wrote:
> Le 26/05/2016 =E0 05:03, Michael Niedermayer a =E9crit :
> >On Wed, May 25, 2016 at 10:40:43PM +0200, Jerome Martinez wrote:
> >>This patch is for some formatting, because it is becoming slightly
> >>incoherent after some additions:
> >>- version value of 2 is set as reserved but this value is seen in
> >>different places, I removed any reference to this value.
> >does "version >=3D3"  really refer less to version 2 than version >=3D2 ?
> >i think in cases like above its better to choose the point so that
> >its most correct
>=20
> This is on purpose : "version 2" is not defined (version field with
> value 2 is set as reserved), so it is difficult (it makes the spec
> less clear, it is not coherent) to refer to this undefined version.
> The goal of this patch is to have coherency: we have the sentence

the patch also does this:
(this does not look coherent to me if removing version 2 is teh goal)

-|=A0=A0=A0if( version \> 1 ) {                                     |     |
+|=A0=A0=A0if( version \>=3D 2 ) {                                    |    =
 |
 |=A0=A0=A0=A0=A0=A0=A0num\_h\_slices - 1                                  =
 | ur  |
 |=A0=A0=A0=A0=A0=A0=A0num\_v\_slices - 1                                  =
 | ur  |
 |=A0=A0=A0=A0=A0=A0=A0quant\_table\_count                                 =
 | ur  |
 |=A0=A0=A0}                                                        |     |
 |=A0=A0=A0for( i =3D 0; i \< quant\_table\_count; i++ )              |    =
 |
 |=A0=A0=A0=A0=A0=A0=A0QuantizationTable( i )                              =
 |     |
-|=A0=A0=A0if( version \> 1 ) {                                     |     |
+|=A0=A0=A0if( version \>=3D 2 ) {                                    |    =
 |




> "Version 2 was never enabled in the encoder thus version 2 files
> SHOULD NOT exist, and this document does not describe them to keep
> the text simpler", so any reference to version with a value 2 is
> removed.
>=20
> As 2 does not exist, >=3D3 refers to the exact same versions of FFV1
> as >=3D2 or >2 without referencing a version of FFV1 which does not
> exist.

It was not enabled by default, and probably hard to create them
by mistake but it was possible to generate such files though with
the right command line parameters

i have a mixed feeling about adjusting the version thresholds to
be less correct for version 2


[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange

--yLVHuoLXiP9kZBkt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAldIeYIACgkQYR7HhwQLD6thmwCcCxBIP+z6XqaB8opK3WX4fUoD
cCQAnj0cUF8nHFfid/Fa/VCnO+9GGEuf
=D/X/
-----END PGP SIGNATURE-----

--yLVHuoLXiP9kZBkt--


From nobody Fri May 27 10:21:57 2016
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 226B312DA12 for ; Fri, 27 May 2016 10:21:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QmLg9Tmeo8xY for ; Fri, 27 May 2016 10:21:52 -0700 (PDT)
Received: from 9.mo179.mail-out.ovh.net (9.mo179.mail-out.ovh.net [46.105.76.148]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62FA212D0DF for ; Fri, 27 May 2016 10:21:42 -0700 (PDT)
Received: from player715.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id AAAC8FF8A67 for ; Fri, 27 May 2016 19:21:40 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB411F.dip0.t-ipconnect.de [93.219.65.31]) (Authenticated sender: jerome@francoallemand.eu) by player715.ha.ovh.net (Postfix) with ESMTPSA id 64FC21C0085 for ; Fri, 27 May 2016 19:21:40 +0200 (CEST)
To: cellar@ietf.org
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net> <20160526030329.GA4558@nb4>  <20160527164450.GC4558@nb4>
From: Jerome Martinez 
Message-ID: <03b2df9b-7b33-24ff-6a9e-d2dda5161074@mediaarea.net>
Date: Fri, 27 May 2016 19:21:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160527164450.GC4558@nb4>
Content-Type: multipart/mixed; boundary="------------AF03512D3A4A074C01C9D5DB"
X-Ovh-Tracer-Id: 9377620325627728017
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrgeekgddvvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1 0/2] Clarification about versions and slice structure
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 27 May 2016 17:21:55 -0000

This is a multi-part message in MIME format.
--------------AF03512D3A4A074C01C9D5DB
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit

Le 27/05/2016  18:44, Michael Niedermayer a crit :
> the patch also does this:
> (this does not look coherent to me if removing version 2 is teh goal)
>
> -|   if( version \> 1 ) {                                     |     |
> +|   if( version \>= 2 ) {                                    |     |
>   |       num\_h\_slices - 1                                   | ur  |
>   |       num\_v\_slices - 1                                   | ur  |
>   |       quant\_table\_count                                  | ur  |
>   |   }                                                        |     |
>   |   for( i = 0; i \< quant\_table\_count; i++ )              |     |
>   |       QuantizationTable( i )                               |     |
> -|   if( version \> 1 ) {                                     |     |
> +|   if( version \>= 2 ) {                                    |     |

Was not my goal.
Updated patch attached.


>
>
>
>
>> "Version 2 was never enabled in the encoder thus version 2 files
>> SHOULD NOT exist, and this document does not describe them to keep
>> the text simpler", so any reference to version with a value 2 is
>> removed.
>>
>> As 2 does not exist, >=3 refers to the exact same versions of FFV1
>> as >=2 or >2 without referencing a version of FFV1 which does not
>> exist.
> It was not enabled by default, and probably hard to create them
> by mistake but it was possible to generate such files though with
> the right command line parameters

I understand that such file can be created, but they are explicitly non 
standard (experimental) streams.
We decided that we standardize FFV1 version 0, 1, 3, so we should not 
consider that we take care of version 2 files in the wild.
That does not prevent a decoder to support such stream if the developer 
wants to support it, just that we don't standardize it.

>
> i have a mixed feeling about adjusting the version thresholds to
> be less correct for version 2

As it is currently defined, we will not be able to decode version 2 
because we don't handle all exceptions about it, so it is "less correct" 
for only an unsupported version, from my point of view it is weird.

Additionally, In the patch, I do:
-|    if( i \|\| version \> 2 ) |       |
+|    if( version \>= 3 ) |       |

(I remove the "i" part because "i" is always 0 with versions 0 and 1. I 
will also be able to have simplifications in other parts of the spec 
without this "i" here)
and it is weird to keep a (relatively) more complex specification for a 
version we don't support completely (not decodable with this spec), in 
addition to a reference to a version we say that we don't support.

Jrme

--------------AF03512D3A4A074C01C9D5DB
Content-Type: text/plain; charset=UTF-8;
 name="0001-More-explicit-version-tests.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment;
 filename="0001-More-explicit-version-tests.patch"

>From a007a06a6b3f4fbda6b08d9393e927899509235d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Fri, 27 May 2016 19:04:10 +0200
Subject: [PATCH 1/2] More explicit version tests

Use everywhere the version number when a feature begins or stop
Avoid usage of the reserved version value 2
Remove tests specific to reserved version value 2
---
 ffv1.md | 24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/ffv1.md b/ffv1.md
index 11d0faa..cadb3e5 100644
--- a/ffv1.md
+++ b/ffv1.md
@@ -472,7 +472,7 @@ Default values at the decoder initialization phase:
 
 ## Configuration Record
 
-In the case of a bitstream with version >= 2, a configuration record is stored in the underlying container, at the track header level.
+In the case of a bitstream with version >= 3, a configuration record is stored in the underlying container, at the track header level.
 It contains the parameters used for all frames.
 The size of the configuration record, NumBytes, is supplied by the underlying container.
 
@@ -533,7 +533,7 @@ See [NUT](#references) for more information about elements.
 |                                                                    |
 |------------------------------------------------------------|:------|
 |Slice( i ) {                                                | type  |
-|    if( version \> 2 )                                      |       |
+|    if( version \>= 3 )                                     |       |
 |        SliceHeader( i )                                    |       |
 |    if( colorspace\_type == 0) {                            |       |
 |        for( p = 0; p \< primary\_color\_count; p++ ) {     |       |
@@ -546,7 +546,7 @@ See [NUT](#references) for more information about elements.
 |    if ( coder\_type == 0 )                                 |       |
 |        while ( !byte\_aligned() )                          |       |
 |            padding                                         |  u(1) |
-|    if( i \|\| version \> 2 )                               |       |
+|    if( version \>= 3 )                                     |       |
 |        slice\_size                                         | u(24) |
 |    if( ec ) {                                              |       |
 |        error\_status                                       |  u(8) |
@@ -589,7 +589,7 @@ The CRC generator polynom used is the standard IEEE CRC polynom (0x104C11DB7) wi
 |    picture\_structure                                      | ur |
 |    sar\_num                                                | ur |
 |    sar\_den                                                | ur |
-|    if( version \> 3 ) {                                    |    |
+|    if( version \>= 4 ) {                                   |    |
 |        reset\_contexts                                     | br |
 |        slice\_coding\_mode                                 | ur |
 |    }                                                       |    |
@@ -607,7 +607,7 @@ Inferred to be 1 if not present.
 **slice_height** indicates the height on the slice raster formed by num_v_slices.
 Inferred to be 1 if not present.
 
-**quant\_table\_index\_count** is defined as 1 + ( ( chroma_planes || version \< 4 ) ? 1 : 0 ) + ( alpha_plane ? 1 : 0 ).
+**quant\_table\_index\_count** is defined as 1 + ( ( chroma_planes || version \<= 3 ) ? 1 : 0 ) + ( alpha_plane ? 1 : 0 ).
 
 **quant\_table\_index** indicates the index to select the quantization table set and the initial states for the slice.
 Inferred to be 0 if not present.
@@ -649,27 +649,27 @@ Inferred to be 0 if not present.
 |------------------------------------------------------------|----:|
 | Parameters( ) {                                            | type|
 |   version                                                  | ur  |
-|   if( version \> 2 )                                       |     |
+|   if( version \>= 3 )                                      |     |
 |       micro\_version                                       | ur  |
 |   coder\_type                                              | ur  |
 |   if( coder\_type \> 1 )                                   |     |
 |       for( i = 1; i \< 256; i++ )                          |     |
 |           state\_transition\_delta[ i ]                    | sr  |
 |   colorspace\_type                                         | ur  |
-|   if( version \> 0 )                                       |     |
+|   if( version \>= 1 )                                      |     |
 |       bits\_per\_raw\_sample                               | ur  |
 |   chroma\_planes                                           | br  |
 |   log2( h\_chroma\_subsample )                             | ur  |
 |   log2( v\_chroma\_subsample )                             | ur  |
 |   alpha\_plane                                             | br  |
-|   if( version \> 1 ) {                                     |     |
+|   if( version \>= 3 ) {                                    |     |
 |       num\_h\_slices - 1                                   | ur  |
 |       num\_v\_slices - 1                                   | ur  |
 |       quant\_table\_count                                  | ur  |
 |   }                                                        |     |
 |   for( i = 0; i \< quant\_table\_count; i++ )              |     |
 |       QuantizationTable( i )                               |     |
-|   if( version \> 1 ) {                                     |     |
+|   if( version \>= 3 ) {                                    |     |
 |       for( i = 0; i \< quant\_table\_count; i++ ) {        |     |
 |           states\_coded                                    | br  |
 |           if( states\_coded )                              |     |
@@ -684,8 +684,8 @@ Inferred to be 0 if not present.
 
 **version** specifies the version of the bitstream.
 Each version is incompatible with others versions: decoders SHOULD reject a file due to unknown version.
-Decoders SHOULD reject a file with version < 2 && ConfigurationRecordIsPresent == 1.
-Decoders SHOULD reject a file with version >= 2 && ConfigurationRecordIsPresent == 0.
+Decoders SHOULD reject a file with version =< 1 && ConfigurationRecordIsPresent == 1.
+Decoders SHOULD reject a file with version >= 3 && ConfigurationRecordIsPresent == 0.
 
 |value   | version                 |
 |:-------|:------------------------|
@@ -857,7 +857,7 @@ MAX\_CONTEXT\_INPUTS is 5.
 
 ### Restrictions
 
-To ensure that fast multithreaded decoding is possible, starting version 2 and if frame\_width * frame\_height is more than 101376, slice\_width * slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4.
+To ensure that fast multithreaded decoding is possible, starting version 3 and if frame\_width * frame\_height is more than 101376, slice\_width * slice\_height MUST be less or equal to num\_h\_slices * num\_v\_slices / 4.
 Note: 101376 is the frame size in pixels of a 352x288 frame also known as CIF ("Common Intermediate Format") frame size format.
 
 For each frame, each position in the slice raster MUST be filled by one and only one slice of the frame (no missing slice position, no slice overlapping).
-- 
2.7.0.windows.1


--------------AF03512D3A4A074C01C9D5DB--


From nobody Fri May 27 10:41:58 2016
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 2CB9C12B071 for ; Fri, 27 May 2016 10:41:56 -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 gEkFdDe-CR6u for ; Fri, 27 May 2016 10:41:55 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 EB94D12D16D for ; Fri, 27 May 2016 10:41:53 -0700 (PDT)
Received: from [146.96.19.240] (port=12637 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b6Llf-000g26-I5; Fri, 27 May 2016 13:41:52 -0400
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dave Rice 
In-Reply-To: <03b2df9b-7b33-24ff-6a9e-d2dda5161074@mediaarea.net>
Date: Fri, 27 May 2016 13:41:49 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FF060B7-CC40-4EDD-A9F4-EB1E4511DBD5@dericed.com>
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net> <20160526030329.GA4558@nb4>  <20160527164450.GC4558@nb4> <03b2df9b-7b33-24ff-6a9e-d2dda5161074@mediaarea.net>
To: Jerome Martinez 
X-Mailer: Apple Mail (2.3112)
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: 
Cc: cellar@ietf.org
Subject: Re: [Cellar] [PATCH FFV1 0/2] Clarification about versions and slice structure
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 27 May 2016 17:41:56 -0000

> On May 27, 2016, at 1:21 PM, Jerome Martinez  =
wrote:
>=20
> Le 27/05/2016 =E0 18:44, Michael Niedermayer a =E9crit :
>> the patch also does this:
>> (this does not look coherent to me if removing version 2 is teh goal)
>>=20
>> -|   if( version \> 1 ) {                                     |     |
>> +|   if( version \>=3D 2 ) {                                    |     =
|
>>  |       num\_h\_slices - 1                                   | ur  |
>>  |       num\_v\_slices - 1                                   | ur  |
>>  |       quant\_table\_count                                  | ur  |
>>  |   }                                                        |     |
>>  |   for( i =3D 0; i \< quant\_table\_count; i++ )              |     =
|
>>  |       QuantizationTable( i )                               |     |
>> -|   if( version \> 1 ) {                                     |     |
>> +|   if( version \>=3D 2 ) {                                    |     =
|
>=20
> Was not my goal.
> Updated patch attached.
>=20
>=20
>>=20
>>=20
>>=20
>>=20
>>> "Version 2 was never enabled in the encoder thus version 2 files
>>> SHOULD NOT exist, and this document does not describe them to keep
>>> the text simpler", so any reference to version with a value 2 is
>>> removed.
>>>=20
>>> As 2 does not exist, >=3D3 refers to the exact same versions of FFV1
>>> as >=3D2 or >2 without referencing a version of FFV1 which does not
>>> exist.
>> It was not enabled by default, and probably hard to create them
>> by mistake but it was possible to generate such files though with
>> the right command line parameters
>=20
> I understand that such file can be created, but they are explicitly =
non standard (experimental) streams.
> We decided that we standardize FFV1 version 0, 1, 3, so we should not =
consider that we take care of version 2 files in the wild.
> That does not prevent a decoder to support such stream if the =
developer wants to support it, just that we don't standardize it.

+1

>> i have a mixed feeling about adjusting the version thresholds to
>> be less correct for version 2
>=20
> As it is currently defined, we will not be able to decode version 2 =
because we don't handle all exceptions about it, so it is "less correct" =
for only an unsupported version, from my point of view it is weird.
>=20
> Additionally, In the patch, I do:
> -|    if( i \|\| version \> 2 ) |       |
> +|    if( version \>=3D 3 ) |       |
>=20
> (I remove the "i" part because "i" is always 0 with versions 0 and 1. =
I will also be able to have simplifications in other parts of the spec =
without this "i" here)
> and it is weird to keep a (relatively) more complex specification for =
a version we don't support completely (not decodable with this spec), in =
addition to a reference to a version we say that we don't support.

I agree. Also I find it contradictory for the spec to claim both that =
'2' is reserved as a version value and to then go on to define many =
aspects relative to version 2. If version 2 is defined in the =
specification, then '2' should not be reserved; however, I prefer =
Jerome's approach to consider version 2 as out of scope of the =
specification and to remove its mention to only a note to explain why =
'2' is reversed.
Dave Rice


From nobody Sat May 28 08:13:12 2016
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 73A6312B02D for ; Sat, 28 May 2016 08:13:10 -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 dt8ZR2b1izla for ; Sat, 28 May 2016 08:13:08 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 5B9C912B00F for ; Sat, 28 May 2016 08:13:08 -0700 (PDT)
Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:47734 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b6fvF-001XVk-Ka; Sat, 28 May 2016 11:13:07 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_DEA37B0B-18E9-4E55-AC40-7F22461AA4FD"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Dave Rice 
In-Reply-To: 
Date: Sat, 28 May 2016 11:13:03 -0400
Message-Id: 
References: <1687ED1D-AF44-4BC5-B1E5-89F2CD7440E7@dericed.com> <13C43671-E7FC-4011-B759-0E4F0E003D98@dericed.com>  
To: Michael Bradshaw 
X-Mailer: Apple Mail (2.3124)
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: 
Cc: cellar@ietf.org, Ashley Blewer 
Subject: Re: [Cellar] Matroska Ordering Guidelines
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 28 May 2016 15:13:11 -0000

--Apple-Mail=_DEA37B0B-18E9-4E55-AC40-7F22461AA4FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8


> On May 26, 2016, at 1:08 PM, Michael Bradshaw  =
wrote:
>=20
> On Mon, May 23, 2016 at 8:07 PM, Dave Rice > wrote:
> I started a rewrite of the Matroska Ordering Guideilnes in order to =
correct and clarify the recommendations and mandates of the section. =
I=E2=80=99ll include the updated text below and it is also reviewable as =
a pull request at =
https://github.com/Matroska-Org/matroska-specification/pull/16 =
. =
Because this is a rewrite, it is difficult to diff, but please review =
what parts are deleted. This link is probably the most readable diff: =
https://github.com/Matroska-Org/matroska-specification/pull/16/commits/9fd=
95b3a0ad75ee49ac56b9f09efbebb7c08f1e3 =
. Overall I=E2=80=99ve intended =
to keep the same meaning but form it more clearly, but this needs a =
review.
>=20
> In addition to a rewrite I added a few more recommendations or =
mandates which include:
>=20
> Overall I think it's an improvement. However, I still think calling =
them "guidelines" but then using language like MUST is kind of =
confusing. If the MUST mandates are truly requirements, then I suggest =
moving them into a separate document that has an appropriate title.

I could renaming it to "Ordering Requirements", though I think including =
both mandates and recommendations on ordering in the same section is =
okay, or possibly having one subsection on mandates and one subsequent =
subsection on recommendations.

> Also, the structure of the spec(s) is kind of confusing because there =
are multiple documents and it's not immediately clear what's intended to =
be informative and what's intended to be authoritative. I think it would =
be nice if all authoritative documents were compiled into a single =
document (just with multiple sections/annexes), however if there are =
going to be multiple RFCs then a single document makes less sense and I =
would suggest each document clearly reference its dependencies (with =
language that makes it clear what's a requirement and what's a =
guideline/purely informative).

We could have a makefile to concatenates markdown to make a single file. =
With this approach the individual pages could be processed separately if =
we=E2=80=99d like single-pages presentations as the current html is on =
matroska.org. The FFV1 spec uses a makefile [1] with markdown as well =
but then a makefile to create specific outputs.

At any rate, Ashley has been working on the markdown to rfc process and =
the results of that may impact the strategy for makefiles or many-docs =
vs single-doc.


Best Regards,
Dave Rice

[1] https://github.com/FFmpeg/FFV1/blob/master/Makefile=

--Apple-Mail=_DEA37B0B-18E9-4E55-AC40-7F22461AA4FD
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


On May 26, 2016, at 1:08 PM, Michael Bradshaw <mjbshaw@google.com> =
wrote:

On Mon, May 23, 2016 at 8:07 PM, Dave Rice <dave@dericed.com> wrote:
I started a rewrite of the =
Matroska Ordering Guideilnes in order to correct and clarify the =
recommendations and mandates of the section. I=E2=80=99ll include the =
updated text below and it is also reviewable as a pull request at https://github.com/Matroska-Org/matroska-specification/pull/16<=
/a>. Because this is a rewrite, it is difficult to diff, but please =
review what parts are deleted. This link is probably the most readable =
diff: https://github.com/Matroska-Org/matroska-specification/pull/16/=
commits/9fd95b3a0ad75ee49ac56b9f09efbebb7c08f1e3. Overall I=E2=80=99ve=
 intended to keep the same meaning but form it more clearly, but this =
needs a review.

In addition to a rewrite I added a few more recommendations =
or mandates which include:

Overall I think it's an =
improvement. However, I still think calling them "guidelines" but then =
using language like MUST is kind of confusing. If the MUST mandates are =
truly requirements, then I suggest moving them into a separate document =
that has an appropriate =
title.

I could renaming it to "Ordering Requirements", =
though I think including both mandates and recommendations on ordering =
in the same section is okay, or possibly having one subsection on =
mandates and one subsequent subsection on recommendations.

Also, the structure of the spec(s) =
is kind of confusing because there are multiple documents and it's not =
immediately clear what's intended to be informative and what's intended =
to be authoritative. I think it would be nice if all authoritative =
documents were compiled into a single document (just with multiple =
sections/annexes), however if there are going to be multiple RFCs then a =
single document makes less sense and I would suggest each document =
clearly reference its dependencies (with language that makes it clear =
what's a requirement and what's a guideline/purely =
informative).

We could have a makefile to concatenates markdown =
to make a single file. With this approach the individual pages could be =
processed separately if we=E2=80=99d like single-pages presentations as =
the current html is on matroska.org. The FFV1 spec uses a makefile [1] with =
markdown as well but then a makefile to create specific outputs.

At any rate, Ashley has =
been working on the markdown to rfc process and the results of that may =
impact the strategy for makefiles or many-docs vs single-doc.


Best Regards,
Dave =
Rice

[1] https://github.com/FFmpeg/FFV1/blob/master/Makefile
=

--Apple-Mail=_DEA37B0B-18E9-4E55-AC40-7F22461AA4FD--


From nobody Sat May 28 08:35:15 2016
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 3B30912B02C for ; Sat, 28 May 2016 08:35:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 ePv1Sgr1i0F1 for ; Sat, 28 May 2016 08:35:12 -0700 (PDT)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2006612B027 for ; Sat, 28 May 2016 08:35:11 -0700 (PDT)
Received: from mfilter48-d.gandi.net (mfilter48-d.gandi.net [217.70.178.179]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id 5ECE8A80D1 for ; Sat, 28 May 2016 17:35:10 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter48-d.gandi.net
Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter48-d.gandi.net (mfilter48-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id T7eSk7b96aN1 for ; Sat, 28 May 2016 17:35:08 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id BCFEEA80C6 for ; Sat, 28 May 2016 17:35:08 +0200 (CEST)
Date: Sat, 28 May 2016 17:32:47 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160528153247.GE4558@nb4>
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net> <20160526030329.GA4558@nb4>  <20160527164450.GC4558@nb4> <03b2df9b-7b33-24ff-6a9e-d2dda5161074@mediaarea.net> <5FF060B7-CC40-4EDD-A9F4-EB1E4511DBD5@dericed.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BZaMRJmqxGScZ8Mx"
Content-Disposition: inline
In-Reply-To: <5FF060B7-CC40-4EDD-A9F4-EB1E4511DBD5@dericed.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1 0/2] Clarification about versions and slice structure
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 28 May 2016 15:35:14 -0000

--BZaMRJmqxGScZ8Mx
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 27, 2016 at 01:41:49PM -0400, Dave Rice wrote:
>=20
> > On May 27, 2016, at 1:21 PM, Jerome Martinez  wro=
te:
> >=20
> > Le 27/05/2016 =E0 18:44, Michael Niedermayer a =E9crit :
> >> the patch also does this:
> >> (this does not look coherent to me if removing version 2 is teh goal)
> >>=20
> >> -|   if( version \> 1 ) {                                     |     |
> >> +|   if( version \>=3D 2 ) {                                    |     |
> >>  |       num\_h\_slices - 1                                   | ur  |
> >>  |       num\_v\_slices - 1                                   | ur  |
> >>  |       quant\_table\_count                                  | ur  |
> >>  |   }                                                        |     |
> >>  |   for( i =3D 0; i \< quant\_table\_count; i++ )              |     |
> >>  |       QuantizationTable( i )                               |     |
> >> -|   if( version \> 1 ) {                                     |     |
> >> +|   if( version \>=3D 2 ) {                                    |     |
> >=20
> > Was not my goal.
> > Updated patch attached.
> >=20
> >=20
> >>=20
> >>=20
> >>=20
> >>=20
> >>> "Version 2 was never enabled in the encoder thus version 2 files
> >>> SHOULD NOT exist, and this document does not describe them to keep
> >>> the text simpler", so any reference to version with a value 2 is
> >>> removed.
> >>>=20
> >>> As 2 does not exist, >=3D3 refers to the exact same versions of FFV1
> >>> as >=3D2 or >2 without referencing a version of FFV1 which does not
> >>> exist.
> >> It was not enabled by default, and probably hard to create them
> >> by mistake but it was possible to generate such files though with
> >> the right command line parameters
> >=20
> > I understand that such file can be created, but they are explicitly non=
 standard (experimental) streams.
> > We decided that we standardize FFV1 version 0, 1, 3, so we should not c=
onsider that we take care of version 2 files in the wild.
> > That does not prevent a decoder to support such stream if the developer=
 wants to support it, just that we don't standardize it.
>=20
> +1
>=20
> >> i have a mixed feeling about adjusting the version thresholds to
> >> be less correct for version 2
> >=20
> > As it is currently defined, we will not be able to decode version 2 bec=
ause we don't handle all exceptions about it, so it is "less correct" for o=
nly an unsupported version, from my point of view it is weird.
> >=20
> > Additionally, In the patch, I do:
> > -|    if( i \|\| version \> 2 ) |       |
> > +|    if( version \>=3D 3 ) |       |
> >=20
> > (I remove the "i" part because "i" is always 0 with versions 0 and 1. I=
 will also be able to have simplifications in other parts of the spec witho=
ut this "i" here)
> > and it is weird to keep a (relatively) more complex specification for a=
 version we don't support completely (not decodable with this spec), in add=
ition to a reference to a version we say that we don't support.
>=20
> I agree. Also I find it contradictory for the spec to claim both that '2'=
 is reserved as a version value and to then go on to define many aspects re=
lative to version 2. If version 2 is defined in the specification, then '2'=
 should not be reserved; however, I prefer Jerome's approach to consider ve=
rsion 2 as out of scope of the specification and to remove its mention to o=
nly a note to explain why '2' is reversed.

patch applied


> Dave Rice
>=20
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
>=20

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Avoid a single point of failure, be that a person or equipment.

--BZaMRJmqxGScZ8Mx
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAldJuh8ACgkQYR7HhwQLD6segQCZASr2E+OA6P8mJTd/qsMGRnIl
bcwAn3fP6Od2oqLPlbN+Hoe7bYj4dZnq
=f2iu
-----END PGP SIGNATURE-----

--BZaMRJmqxGScZ8Mx--


From nobody Sat May 28 09:24:48 2016
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 E565112B02D for ; Sat, 28 May 2016 09:24:46 -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, RCVD_IN_MSPIKE_H2=-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 ddAoEidSavp0 for ; Sat, 28 May 2016 09:24:45 -0700 (PDT)
Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B95F12B011 for ; Sat, 28 May 2016 09:24:45 -0700 (PDT)
Received: from mfilter19-d.gandi.net (mfilter19-d.gandi.net [217.70.178.147]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id CD21C41C0A3 for ; Sat, 28 May 2016 18:24:43 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter19-d.gandi.net
Received: from relay5-d.mail.gandi.net ([IPv6:::ffff:217.70.183.197]) by mfilter19-d.gandi.net (mfilter19-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id qvmENc2A9tNl for ; Sat, 28 May 2016 18:24:42 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 3E82741C099 for ; Sat, 28 May 2016 18:24:41 +0200 (CEST)
Date: Sat, 28 May 2016 18:22:20 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160528162220.GB25385@nb4>
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net> <4b37aacc-10b9-3b04-d63b-79c8ba65a76f@mediaarea.net> <6c290042-7082-73df-96a3-543fd515d3c4@libav.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="H1spWtNR+x+ondvy"
Content-Disposition: inline
In-Reply-To: <6c290042-7082-73df-96a3-543fd515d3c4@libav.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1 2/2] Slice structure clarification
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 28 May 2016 16:24:47 -0000

--H1spWtNR+x+ondvy
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, May 25, 2016 at 11:18:56PM +0200, Luca Barbato wrote:
> On 25/05/16 23:01, Jerome Martinez wrote:
> >  |    if ( coder\_type =3D=3D 0 )                                 |    =
   |
> >  |        while ( !byte\_aligned() )                          |       |
> >  |            padding                                         |  u(1) |
>=20
> Might go to the Slice Content section as well
>=20
> so the Slice Content could specify the coder-specific details inside ther=
e.
>=20

> About that, Michael, is it specified somewhere why the state 129 is used
> to reset both coders and why 0 is put at the start in one case while in
> the other it is used to pad and terminate?

Does the way the coder is implemented result in a diferent bytestream
than what the specification allows ?
I thought Jerome had writen his own implementation based on the spec
and it worked, but i too was a bit unsure about the range coder
termination matching exactly between spec and implementation.

[...]
--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
            conveniently.
New school: Use the highest level language in which the latest supercomputer
            can solve the problem without the user falling asleep waiting.

--H1spWtNR+x+ondvy
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAldJxbwACgkQYR7HhwQLD6vKIACgmqGrm4mmY7XyFadLYNSlQbic
YW0AnjLurVfuq2ocltih9c+ANTKYetIN
=acsJ
-----END PGP SIGNATURE-----

--H1spWtNR+x+ondvy--


From nobody Sat May 28 10:01:32 2016
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 CCF9B12D0B3 for ; Sat, 28 May 2016 10:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 mmZ7oj-HmwpE for ; Sat, 28 May 2016 10:01:28 -0700 (PDT)
Received: from 12.mo4.mail-out.ovh.net (12.mo4.mail-out.ovh.net [178.33.104.253]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7181012D09C for ; Sat, 28 May 2016 10:01:27 -0700 (PDT)
Received: from player135.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo4.mail-out.ovh.net (Postfix) with ESMTP id 33ECFFFC27F for ; Sat, 28 May 2016 19:01:26 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB44F2.dip0.t-ipconnect.de [93.219.68.242]) (Authenticated sender: jerome@francoallemand.eu) by player135.ha.ovh.net (Postfix) with ESMTPSA id D96414C0085 for ; Sat, 28 May 2016 19:01:25 +0200 (CEST)
To: cellar@ietf.org
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net> <4b37aacc-10b9-3b04-d63b-79c8ba65a76f@mediaarea.net> <6c290042-7082-73df-96a3-543fd515d3c4@libav.org> <20160528162220.GB25385@nb4>
From: Jerome Martinez 
Message-ID: <3846340f-7ea8-29b8-20d1-47e094a4d36c@mediaarea.net>
Date: Sat, 28 May 2016 19:01:14 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <20160528162220.GB25385@nb4>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-Ovh-Tracer-Id: 14908322142803595409
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrhedtgddutdeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1 2/2] Slice structure clarification
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 28 May 2016 17:01:31 -0000

Le 28/05/2016  18:22, Michael Niedermayer a crit :
> On Wed, May 25, 2016 at 11:18:56PM +0200, Luca Barbato wrote:
>
>> About that, Michael, is it specified somewhere why the state 129 is used
>> to reset both coders and why 0 is put at the start in one case while in
>> the other it is used to pad and terminate?
> Does the way the coder is implemented result in a diferent bytestream
> than what the specification allows ?
> I thought Jerome had writen his own implementation based on the spec
> and it worked, but i too was a bit unsure about the range coder
> termination matching exactly between spec and implementation.

Not on the spec as it is currently.
This is actually the reason we want to improve the spec, because for the 
moment it is not possible to implement a decoder only based on the spec. 
this state 129 was something we had to peek in the FFmpeg source code if 
I remind well (I am not the one who wrote this part of our decoder, I'll 
ask for confirmation; maybe we missed it in the current spec?), beside 
several other small things (I already patched the spec for some of them 
e.g. the padding bits for Golomb Rice coder was not in the spec and it 
was making the decoder fail, for the last thing I patched, and other 
patches are in the queue e.g. slice_count is in the spec but is never 
defined so it is not usable). This state 129 is something I would like 
to have more clear in the spec, and unfortunately my knowledge of Range 
Coder is not enough for proposing good sentences about it (I know it is 
required, I don't know the reason and how to well write it in the spec), 
so this part is postponed for the moment.

BTW Michael, a small ping about the Patch 2/2 to comment or accept.


From nobody Sat May 28 11:10:56 2016
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 4BA7812D0A7 for ; Sat, 28 May 2016 11:10:55 -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 ANTmWZKkxCHa for ; Sat, 28 May 2016 11:10:54 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 F2AEE12D09B for ; Sat, 28 May 2016 11:10:53 -0700 (PDT)
Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:33665 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b6ihI-001NKz-L6 for cellar@ietf.org; Sat, 28 May 2016 14:10:53 -0400
From: Dave Rice 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Message-Id: <798B10B6-D518-494B-8DC1-78DCFD1E4514@dericed.com>
Date: Sat, 28 May 2016 14:10:51 -0400
To: cellar@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
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: [Cellar] TimeSlice and LaceNumber, deprecated in an unknown version
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 28 May 2016 18:10:55 -0000

Hi all,

=46rom specdata.xml is:

Contains extra time information =
about the data contained in the Block. While there are a few files in =
the wild with this Element, it is no longer in use and has been =
deprecated. Being able to interpret this Element is not required for =
playback.

The =
reverse number of the frame in the lace (0 is the last frame, 1 is the =
next to last, etc). While there are a few files in the wild with this =
Element, it is no longer in use and has been deprecated. Being able to =
interpret this Element is not required for playback.

These elements are noted as deprecated, but there is no declared maxver. =
Anyone remember when these were deprecated or what the maxver should be?
Dave Rice=


From nobody Sat May 28 11:14:49 2016
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 5FA8612D0AC for ; Sat, 28 May 2016 11:14:47 -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 EwETkDANnkqr for ; Sat, 28 May 2016 11:14:45 -0700 (PDT)
Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (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 C819312D09B for ; Sat, 28 May 2016 11:14:45 -0700 (PDT)
Received: from cpe-184-152-63-84.nyc.res.rr.com ([184.152.63.84]:35678 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1b6il2-001P55-K6 for cellar@ietf.org; Sat, 28 May 2016 14:14:45 -0400
From: Dave Rice 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-Id: <6C1ED9B4-83FE-4D0E-B5FA-EEE53197794E@dericed.com>
Date: Sat, 28 May 2016 14:14:42 -0400
To: cellar@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
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: [Cellar] resolving maxver / minver incoherancy with OldStereoMode
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 28 May 2016 18:14:47 -0000

Hi all,
The well named =E2=80=9COldStereoMode=E2=80=9D element is described in =
specdata.xml like this:

DEPRECATED, DO NOT =
USE. Bogus StereoMode value used in old versions of libmatroska. (0: =
mono, 1: right eye, 2: left eye, 3: both eyes).

The minver is not declared and the EBML spec [1] implies an undeclared =
minver is =E2=80=9C1=E2=80=9D, but maxver equals 0. Is it sensible for =
minver > maxver?

Best Regards,
Dave Rice

[1] =
https://github.com/Matroska-Org/ebml-specification/blob/master/specificati=
on.markdown#ebml-schema-element-attributes=


From nobody Sat May 28 13:56:48 2016
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 ADDF712D0B5 for ; Sat, 28 May 2016 13:56:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 25IwAHZ8fafI for ; Sat, 28 May 2016 13:56:45 -0700 (PDT)
Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [IPv6:2001:4b98:c:538::196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B793812B01D for ; Sat, 28 May 2016 13:56:45 -0700 (PDT)
Received: from mfilter13-d.gandi.net (mfilter13-d.gandi.net [217.70.178.141]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 0BC161720A4 for ; Sat, 28 May 2016 22:56:44 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mfilter13-d.gandi.net
Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter13-d.gandi.net (mfilter13-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id bSMS6AhSLOHM for ; Sat, 28 May 2016 22:56:42 +0200 (CEST)
X-Originating-IP: 213.47.41.20
Received: from localhost (chello213047041020.graz.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 790D41720A1 for ; Sat, 28 May 2016 22:56:41 +0200 (CEST)
Date: Sat, 28 May 2016 22:54:20 +0200
From: Michael Niedermayer 
To: cellar@ietf.org
Message-ID: <20160528205420.GC25385@nb4>
References: <6729c50f-8cac-4168-8e89-12ccef9fd47b@mediaarea.net> <4b37aacc-10b9-3b04-d63b-79c8ba65a76f@mediaarea.net> <6c290042-7082-73df-96a3-543fd515d3c4@libav.org> <20160528162220.GB25385@nb4> <3846340f-7ea8-29b8-20d1-47e094a4d36c@mediaarea.net>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/Uq4LBwYP4y1W6pO"
Content-Disposition: inline
In-Reply-To: <3846340f-7ea8-29b8-20d1-47e094a4d36c@mediaarea.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: 
Subject: Re: [Cellar] [PATCH FFV1 2/2] Slice structure clarification
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 28 May 2016 20:56:48 -0000

--/Uq4LBwYP4y1W6pO
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, May 28, 2016 at 07:01:14PM +0200, Jerome Martinez wrote:
[...]
> BTW Michael, a small ping about the Patch 2/2 to comment or accept.

applied

thanks


[...]

--=20
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus

--/Uq4LBwYP4y1W6pO
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAldKBXwACgkQYR7HhwQLD6vHtQCdGNIGSz8RDc5izhKj1oGXF/fp
oLYAoIgmGskI02EVP0bGm3erEk+us9nF
=nQgy
-----END PGP SIGNATURE-----

--/Uq4LBwYP4y1W6pO--


From nobody Tue May 31 12:17:48 2016
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 7D9F912D0B3 for ; Tue, 31 May 2016 12:17:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level: 
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 kvHdOQJm_6ig for ; Tue, 31 May 2016 12:17:44 -0700 (PDT)
Received: from 19.mo4.mail-out.ovh.net (19.mo4.mail-out.ovh.net [87.98.179.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A57F612D63C for ; Tue, 31 May 2016 12:17:43 -0700 (PDT)
Received: from player135.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo4.mail-out.ovh.net (Postfix) with ESMTP id 7C6031004802 for ; Tue, 31 May 2016 21:17:41 +0200 (CEST)
Received: from [192.168.2.101] (p5DDB44F2.dip0.t-ipconnect.de [93.219.68.242]) (Authenticated sender: jerome@francoallemand.eu) by player135.ha.ovh.net (Postfix) with ESMTPSA id 354694C0095 for ; Tue, 31 May 2016 21:17:41 +0200 (CEST)
From: Jerome Martinez 
To: cellar@ietf.org
Message-ID: 
Date: Tue, 31 May 2016 21:17:36 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="------------3719E3FDF46C055D99E4F899"
X-Ovh-Tracer-Id: 16380999222797930641
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekledrheehgddufeefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc
Archived-At: 
Subject: [Cellar] [PATCH FFV1] Remove slice_count reference
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.17
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, 31 May 2016 19:17:47 -0000

This is a multi-part message in MIME format.
--------------3719E3FDF46C055D99E4F899
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

slice_count is used but not defined.
It is actually not in the bistream, so we remove it from the spec.

I also remove "i" from "Slice ( i )" because the current usage is not 
coherent: either we use "i" everywhere (slice_y [ i ], picture_structure 
[ i ], slice_crc_parity [ i ]...) or nowhere, and avoiding it simplifies 
the spec without having misunderstanding (we explicitly say that slices 
are independent).


--------------3719E3FDF46C055D99E4F899
Content-Type: text/plain; charset=UTF-8;
 name="0001-Remove-slice_count-reference.patch"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="0001-Remove-slice_count-reference.patch"

RnJvbSA4OTUwODAzMzkwNmM5ZDkzZGY5ZDc5NzI2MmQ1YmZiYmNlNjlhNGMyIE1vbiBTZXAg
MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Sj1DMz1BOXI9QzM9QjRtZT0yME1h
cnRpbmV6Pz0gPGplcm9tZUBtZWRpYWFyZWEubmV0PgpEYXRlOiBUdWUsIDMxIE1heSAyMDE2
IDIwOjM1OjMxICswMjAwClN1YmplY3Q6IFtQQVRDSF0gUmVtb3ZlIHNsaWNlX2NvdW50IHJl
ZmVyZW5jZQoKc2xpY2VfY291bnQgaXMgdXNlZCBidXQgbm90IGRlZmluZWQuCkl0IGlzIGFj
dHVhbGx5IG5vdCBpbiB0aGUgYmlzdHJlYW0sIHNvIHdlIHJlbW92ZSBpdCBmcm9tIHRoZSBz
cGVjLgoKImkiIGluIFNsaWNlICggaSApIGlzIGFsc28gcmVtb3ZlZCBpbiBvcmRlciB0byBo
YXZlIGNvaGVyZW5jeQppbiB0aGUgc3BlYy4KLS0tCiBmZnYxLm1kIHwgMTggKysrKysrKysr
LS0tLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgOSBpbnNlcnRpb25zKCspLCA5IGRlbGV0aW9u
cygtKQoKZGlmZiAtLWdpdCBhL2ZmdjEubWQgYi9mZnYxLm1kCmluZGV4IDg0ZDk2YjQuLmE1
MDNkNmMgMTAwNjQ0Ci0tLSBhL2ZmdjEubWQKKysrIGIvZmZ2MS5tZApAQCAtNTE4LDIzICs1
MTgsMjUgQEAgU2VlIFtOVVRdKCNyZWZlcmVuY2VzKSBmb3IgbW9yZSBpbmZvcm1hdGlvbiBh
Ym91dCBlbGVtZW50cy4KIAogIyMgRnJhbWUKIAorQSBmcmFtZSBjb25zaXN0cyBvZiB0aGUg
a2V5ZnJhbWUgZmllbGQsIHBhcmFtZXRlcnMgKGlmIHZlcnNpb24gPD0xKSwgYW5kIGEgc2Vx
dWVuY2Ugb2YgaW5kZXBlbmRlbnQgc2xpY2VzLgorCiB8ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiB8LS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfC0tLTp8CiB8RnJhbWUoICkg
eyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfHR5cGV8CiB8wqDC
oMKgwqBrZXlmcmFtZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
IGJyfAogfMKgwqDCoMKgaWYoIGtleWZyYW1lICYmICFDb25maWd1cmF0aW9uUmVjb3JkSXNQ
cmVzZW50ICl8ICAgIHwKIHzCoMKgwqDCoMKgwqDCoMKgwqBQYXJhbWV0ZXJzKCApICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8ICAgIHwKLXzCoMKgwqDCoGZvciggaSA9IDA7IGkg
XDwgc2xpY2VcX2NvdW50OyBpKysgKSAgICAgICAgICAgfCAgICB8Ci18wqDCoMKgwqDCoMKg
wqDCoFNsaWNlKCBpICkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgIHwK
K3zCoMKgwqDCoHdoaWxlICggcmVtYWluaW5nXF9iaXRzXF9pblxfYml0c3RyZWFtKCkgKSAg
ICAgfCAgICB8Cit8wqDCoMKgwqDCoMKgwqDCoFNsaWNlKCApICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICB8ICAgIHwKIHx9ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICB8ICAgIHwKIAogIyMgU2xpY2UKIAogfCAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfAogfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLXw6LS0tLS0tfAotfFNsaWNlKCBpICkgeyAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgdHlwZSAgfAorfFNsaWNlKCAp
IHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
dHlwZSAgfAogfMKgwqDCoMKgaWYoIHZlcnNpb24gXD49IDMgKSAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKLXzCoMKgwqDCoMKgwqDCoMKgU2xpY2VI
ZWFkZXIoIGkgKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAg
fAorfMKgwqDCoMKgwqDCoMKgwqBTbGljZUhlYWRlciggKSAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgfCAgICAgICB8CiB8wqDCoMKgwqBTbGljZUNvbnRlbnQoICkg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgICAgfAogfMKg
wqDCoMKgaWYgKCBjb2RlclxfdHlwZSA9PSAwICkgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICB8ICAgICAgIHwKIHwgICAgICAgIHdoaWxlICggIWJ5dGVcX2FsaWduZWQoKSAp
ICAgICAgICAgICAgICAgICAgICAgICAgICB8ICAgICAgIHwKQEAgLTU1MCwxMyArNTUyLDEz
IEBAIE1VU1QgYmUgMC4KIAogfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIHwgICAgfAogfC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwtLS06fAotfCBTbGlj
ZUhlYWRlciggaSApIHsgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IHx0eXBlfAorfCBTbGljZUhlYWRlciggKSB7ICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHx0eXBlfAogfCDCoMKgwqBzbGljZVxfeCAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgdXIgfAogfCDCoMKgwqBzbGlj
ZVxfeSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwg
dXIgfAogfCDCoMKgwqBzbGljZVxfd2lkdGggLSAxICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIHwgdXIgfAogfCDCoMKgwqBzbGljZVxfaGVpZ2h0IC0gMSAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgdXIgfAotfCDCoMKgwqBmb3Io
IGogPSAwOyBqIFw8IHF1YW50XF90YWJsZVxfaW5kZXhcX2NvdW50OyBqKysgKSAgICAgIHwg
ICAgfAotfCDCoMKgwqDCoMKgwqDCoHF1YW50XF90YWJsZVxfaW5kZXggWyBpIF1bIGogXSAg
ICAgICAgICAgICAgICAgICAgICB8IHVyIHwKK3wgwqDCoMKgZm9yKCBpID0gMDsgaSBcPCBx
dWFudFxfdGFibGVcX2luZGV4XF9jb3VudDsgaSsrICkgICAgICB8ICAgIHwKK3wgwqDCoMKg
wqDCoMKgwqBxdWFudFxfdGFibGVcX2luZGV4IFsgaSBdICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfCB1ciB8CiB8IMKgwqDCoHBpY3R1cmVcX3N0cnVjdHVyZSAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgfCB1ciB8CiB8IMKgwqDCoHNhclxfbnVtICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB1ciB8CiB8IMKg
wqDCoHNhclxfZGVuICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgfCB1ciB8CkBAIC04MDgsOCArODEwLDYgQEAgSW5mZXJyZWQgdG8gYmUgMCBpZiBu
b3QgcHJlc2VudC4KIHByZWQgPSBqID8gaW5pdGlhbFxfc3RhdGVzWyBpIF1baiAtIDFdWyBr
IF0gOiAxMjgKIGluaXRpYWxcX3N0YXRlWyBpIF1bIGogXVsgayBdID0gKCBwcmVkICsgaW5p
dGlhbFxfc3RhdGVcX2RlbHRhWyBpIF1bIGogXVsgayBdICkgJiAyNTUKIAotKipzbGljZVxf
Y291bnQqKiBpbmRpY2F0ZXMgdGhlIG51bWJlciBvZiBzbGljZXMgaW4gdGhlIGN1cnJlbnQg
ZnJhbWUsIHNsaWNlXF9jb3VudCBpcyAxIGlmIGl0IGlzIG5vdCBleHBsaWNpdGx5IGNvZGVk
LgotCiAqKmVjKiogaW5kaWNhdGVzIHRoZSBlcnJvciBkZXRlY3Rpb24vY29ycmVjdGlvbiB0
eXBlLgogCiB8dmFsdWUgfCBlcnJvciBkZXRlY3Rpb24vY29ycmVjdGlvbiB0eXBlICAgICAg
ICAgIHwKLS0gCjIuNy4wLndpbmRvd3MuMQoK
--------------3719E3FDF46C055D99E4F899--