From nobody Tue Dec 1 13:04:02 2020 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 9502B3A110A; Tue, 1 Dec 2020 13:04:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <160685664056.28095.17327665471283573198@ietfa.amsl.com> Date: Tue, 01 Dec 2020 13:04:00 -0800 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-19.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 01 Dec 2020 21:04:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : FFV1 Video Coding Format Version 0, 1, and 3 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-19.txt Pages : 57 Date : 2020-12-01 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-cellar-ffv1-19.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 1 13:04:11 2020 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 CBD313A1181; Tue, 1 Dec 2020 13:04:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <160685664079.28112.16082606103790371622@ietfa.amsl.com> Date: Tue, 01 Dec 2020 13:04:00 -0800 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-v4-16.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 01 Dec 2020 21:04:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : FFV1 Video Coding Format Version 4 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-v4-16.txt Pages : 57 Date : 2020-12-01 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1-v4/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-cellar-ffv1-v4-16.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-v4-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Dec 1 13:16:59 2020 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 032963A1181; Tue, 1 Dec 2020 13:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EbtzJSSatujP; Tue, 1 Dec 2020 13:16:56 -0800 (PST) Received: from server172-4.web-hosting.com (server172-4.web-hosting.com [68.65.122.112]) (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 6B7223A116B; Tue, 1 Dec 2020 13:16:53 -0800 (PST) Received: from pool-100-37-115-144.nycmny.fios.verizon.net ([100.37.115.144]:55414 helo=[192.168.1.152]) by server172.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kkD0x-0014ek-Be; Tue, 01 Dec 2020 16:16:52 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Dave Rice In-Reply-To: Date: Tue, 1 Dec 2020 16:16:45 -0500 Cc: "draft-ietf-cellar-ffv1.chairs@ietf.org" , "draft-ietf-cellar-ffv1@ietf.org" , Codec Encoding for LossLess Archiving and Realtime transmission , Barry Leiba Content-Transfer-Encoding: quoted-printable Message-Id: References: <160208949226.20172.3161875416157552929@ietfa.amsl.com> To: Spencer Dawkins at IETF , Roman Danyliw X-Mailer: Apple Mail (2.3608.120.23.2.4) X-OutGoing-Spam-Status: No, score=-0.2 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] New Version Notification - draft-ietf-cellar-ffv1-18.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 01 Dec 2020 21:16:58 -0000 Hi Roman, Spencer, > On Oct 30, 2020, at 1:41 PM, Dave Rice wrote: >=20 > Thank you Roman, >=20 >> On Oct 21, 2020, at 2:03 PM, Spencer Dawkins at IETF = wrote: >>=20 >> Hi, Roman, >>=20 >> On Wed, Oct 21, 2020 at 12:38 PM Roman Danyliw wrote: >> Hi! >> (I can't find your response email to my ballot in my mail client = despite it being in the archive, so apologizes for making the new = thread). >>=20 >> Thanks for the -18 which cleared most of the COMMENTs. I updated my = ballot. >>=20 >> In the spirit of clearing what I consider a straightforward DISCUSS, = might I suggest: >>=20 >> OLD >>=20 >> Implementations of the FFV1 codec need to take appropriate security >> considerations into account, as outlined in [RFC4732]. It is >> extremely important for the decoder to be robust against malicious >> payloads. Malicious payloads MUST NOT cause the decoder to = overrun >> its allocated memory or to take an excessive amount of resources = to >> decode. The same applies to the encoder, ...=20 >>=20 >> NEW >>=20 >> Implementations of the FFV1 codec need to take appropriate security = considerations into account. Those related to denial of service are = outlined in Section 2.1 of [RFC4732]. It is extremely important for the = decoder to be robust against malicious payloads. Malicious payloads = MUST NOT cause the decoder to overrun its allocated memory or to take an = excessive amount of resources to decode. An overrun in allocated = memory could lead to arbitrary code execution by an attacker. The same = applies to the encoder, ... >=20 > The recommendation looks appropriate to me and more clear. I moved it = to a pull request at https://github.com/FFmpeg/FFV1/pull/253 for the = consideration of the other authors. Please note that we just updated the draft to include the recommended = changes for security considerations on denial of service, which can be = reviewed in version 19 of = https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/. Here=E2=80=99s = a link to the diff of version 18 and 19: = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-cellar-ffv1-18&url2=3Ddraft= -ietf-cellar-ffv1-19&difftype=3D--html. Kind Regards, Dave Rice From nobody Tue Dec 1 13:17:34 2020 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 797653A1134; Tue, 1 Dec 2020 13:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECQiD4EN1zkl; Tue, 1 Dec 2020 13:17:27 -0800 (PST) Received: from server172-4.web-hosting.com (server172-4.web-hosting.com [68.65.122.112]) (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 429903A1132; Tue, 1 Dec 2020 13:17:27 -0800 (PST) Received: from pool-100-37-115-144.nycmny.fios.verizon.net ([100.37.115.144]:55414 helo=[192.168.1.152]) by server172.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kkD1T-0014ek-QZ; Tue, 01 Dec 2020 16:17:26 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Dave Rice In-Reply-To: <92029D16-621F-4AE0-BC3F-03C08AB21ADE@dericed.com> Date: Tue, 1 Dec 2020 16:17:18 -0500 Cc: The IESG , Michael Richardson , draft-ietf-cellar-ffv1@ietf.org, cellar@ietf.org, cellar-chairs@ietf.org, pb@das-werkstatt.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <160049032442.20595.4616862102756589735@ietfa.amsl.com> <92029D16-621F-4AE0-BC3F-03C08AB21ADE@dericed.com> To: Barry Leiba X-Mailer: Apple Mail (2.3608.120.23.2.4) X-OutGoing-Spam-Status: No, score=0.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] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 01 Dec 2020 21:17:30 -0000 Hi Barry, > On Oct 30, 2020, at 2:29 PM, Dave Rice wrote: >=20 > Hi all, >=20 > I=E2=80=99m writing this as an update to what aspects of this DISCUSS = are resolved and what may remain. I added a summary at the end, but the = tl;dr is that in my opinion all discuss and comment points are resolved = in our git repository but Section 3.8.1.1 could use a new look in light = of the discuss comments against it. >=20 >> On Sep 19, 2020, at 12:38 AM, Barry Leiba via Datatracker = wrote: >>=20 >> Barry Leiba has entered the following ballot position for >> draft-ietf-cellar-ffv1-17: Discuss >>=20 >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut = this >> introductory paragraph, however.) >>=20 >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> There are a number of things I=E2=80=99d like to discuss, because I = find them not >> understandable. Perhaps it=E2=80=99s simply because I=E2=80=99m not = a codec expert, but, while >> I understand that this is written for readers who will actually be = implementing >> he FFV1 codec, some of them will also not be =E2=80=9Cexperts=E2=80=9D.= That said, I=E2=80=99m sure >> some of this is just a case of =E2=80=9Cgive Barry some clue and = it=E2=80=99s fine.=E2=80=9D >>=20 >> =E2=80=94 Section 2.1 =E2=80=94 >> You use the term =E2=80=9Csymbol=E2=80=9D here and later, without = defining it, and I don=E2=80=99t know >> what it is. A byte? A character? A string of bits? What length? >=20 > Symbol is defined in = https://github.com/FFmpeg/FFV1/commit/baa92e69bbdb5cece9f99556267906beffcd= 0fd2 as: >=20 > `Symbol`: A value stored in the bitstream, which is defined and = decoded through one of the methods described in = [@tablePseudoCodeSymbols]. >=20 >> =E2=80=94 Section 3.8.1.1 =E2=80=94 >> I=E2=80=99m not sure how to interpret the stuff in this section. = First, I don=E2=80=99t know >> why there are seven =E2=80=9Cfigures=E2=80=9D, with no captions nor = other explanation. Second, >> I=E2=80=99m having trouble making sense out of things like this: >>=20 >> S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND >> l_(i) =3D L_(i) AND >> t_(i) =3D R_(i) - r_(i) <=3D=3D >> b_(i) =3D 0 <=3D=3D> >> L_(i) < R_(i) - r_(i) >>=20 >> Can you explain how this is meant to be read? Maybe it=E2=80=99s = just me, and maybe >> after you explain it I=E2=80=99ll whack myself on the head and say, = =E2=80=9CDoh!=E2=80=9D >=20 > Reading this would take correlation to Section 2.2.5 (Mathematical = Functions) for definitions of <=3D=3D and <=3D=3D> and the form of a_(b) = and a_(b,c). >=20 > To read this out-loud would be like: >=20 > The i-th value of b equaling zero implies that the i-th value of L is = less than the result of i-th value of R minus the i-th value of r. The = reserve implication is also true. These implications both imply that the = =E2=80=98i+1,C_(i)' value of S equals the =E2=80=98S_(i, C_(i))=E2=80=99 = of zero_state as well as the i-th value of l equaling the i-th value of = L as well as the i-th value of t equaling the i-th value of R minus the = i-th value or r. >=20 >> Third, you say, =E2=80=9CS_(0, i) is the i-th initial state,=E2=80=9D = but you haven=E2=80=99t >> previously introduced the term =E2=80=9Cstate=E2=80=9D, and I don=E2=80= =99t know what it means. >=20 > Section 3.8 includes an informational reference to range coding. An = understanding on how range coding works could make this section more = clear. >=20 > More captions were added to these figures in = https://github.com/FFmpeg/FFV1/commit/32cb9ea3e697036e81722f1ceced47f74b70= 549f and = https://github.com/FFmpeg/FFV1/commit/ae3de36f528dbcef3fe5fdcc5b63bd5b06ae= fca0. >=20 >> =E2=80=94 Section 3.8.1.2 =E2=80=94 >>=20 >> "get_rac" returns a boolean, computed from the bytestream as >> described in Section 3.8.1.1. >>=20 >> I see nothing in Section 3.8.1.1 that describes get_rac. >=20 > We=E2=80=99ve added a definition = https://github.com/FFmpeg/FFV1/commit/199ce1b95eb426e807ddbfd5d8338243d845= 8db1 and cross-references in = https://github.com/FFmpeg/FFV1/commit/ae3de36f528dbcef3fe5fdcc5b63bd5b06ae= fca0. >=20 >> =E2=80=94 Section 3.8.1.3 =E2=80=94 >>=20 >> At keyframes all Range coder state variables are set to their = initial >> state. >>=20 >> What does =E2=80=9Cat keyframes=E2=80=9D mean? >=20 > It was presumed that =E2=80=98at keyframe=E2=80=99 meant a frame where = the keyframe value was set to 1. This is clarified in = https://github.com/FFmpeg/FFV1/commit/4b4d6f3c180fa2c4debefcc73793fc65ddd8= 52c0. >=20 >> =E2=80=94 Section 3.8.1.5 =E2=80=94 >> This is just a list of numbers with no explanation. It needs text = explaining >> what it means. >=20 > An introduction to this table is added at = https://github.com/FFmpeg/FFV1/commit/69dda1b8a4f02bcce47b860df83a2f26afdc= a909 >=20 > The introduction is: > In this mode a State Transition Table is used, indicating in which = state the decoder will move to, based on the current state and the value = extracted from [@figureGetRacPseudoCode]. >=20 >> =E2=80=94 Section 3.8.2.2 =E2=80=94 >>=20 >> The level is identical to the predicted one. >> The run and the first different level are coded. >>=20 >> What does =E2=80=9Clevel=E2=80=9D mean? It=E2=80=99s not defined = anywhere. >=20 > This was rewording to use the term =E2=80=9Csample difference=E2=80=9D = rather than level at = https://github.com/FFmpeg/FFV1/commit/d6fbc97aa32699d5bafba9760e4f5093fcaa= 6120 and to cross-reference to the section that defines sample = difference. >=20 >> =E2=80=94 Section 4.3.1 =E2=80=94 >>=20 >> "reserved_for_future_use" has semantics that are reserved for future >> use. >>=20 >> Yes, that seems rather obvious, though it=E2=80=99s oddly worded. = But then you say >> what to do with =E2=80=9Cthis value=E2=80=9D, and nowhere do you say = what the value is. How >> does one know? >=20 > This was clarified in = https://github.com/FFmpeg/FFV1/commit/e7f6b342ae5e1c326357479bbbfb2934fe6d= 83f1. >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> Some editorial comments that I ask you to please consider: >>=20 >> General: It=E2=80=99s jarring to see the defined terms, such as = =E2=80=9CSample=E2=80=9D and =E2=80=9CPixel=E2=80=9D in >> quotes every time they=E2=80=99re used. More common practice is to = quote them when >> they=E2=80=99re first defined, and then to just use the = capitalization to show that >> they=E2=80=99re defined terms. I find that the quotes affect the = readability and make >> it somewhat more of a challenge to read. >=20 > We agreed. These excessive quotes were removed in = https://github.com/FFmpeg/FFV1/commit/f0eb24b7820889fbd93b68d1e707d4380a90= ded1. >=20 >> =E2=80=94 Section 2.1 =E2=80=94 >>=20 >> "Plane": A discrete component of a static image comprised of >>=20 >> Total, total nit, and pet peeve: =E2=80=9Ccomposed of=E2=80=9D or = =E2=80=9Ccomprising=E2=80=9D, but not >> =E2=80=9Ccomprised of=E2=80=9D. >=20 > Fixed as suggested in = https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea597918b5633d11= 88ea. >=20 >> =E2=80=94 Section 2.2.2 =E2=80=94 >> You=E2=80=99re missing =E2=80=9Ca % b=E2=80=9D, which is referenced = in Section 2.2.6. >=20 > Nice catch. We removed this in = https://github.com/FFmpeg/FFV1/commit/34ec93cdacef056c6cb53ca3120d5a021acf= b911 as it is unused in the document. >=20 >> =E2=80=94 Section 2.2.4 =E2=80=94 >>=20 >> "a > b" means a is greater than b. >> "a >=3D b" means a is greater than or equal to b. >> "a < b" means a is less than b. >> "a <=3D b" means a is less than or equal b. >> "a =3D=3D b" means a is equal to b. >> "a !=3D b" means a is not equal to b. >>=20 >> I don=E2=80=99t think anyone will misunderstand this, so it=E2=80=99s = a very small thing, but=E2=80=A6 >> might this be better said as, =E2=80=98 "a > b" is true when a is = greater than b. =E2=80=98 >> (and similarly for the rest)? >=20 > Reworded as suggested in = https://github.com/FFmpeg/FFV1/commit/6ef98dc138d34966cc686f64d1f4224202e6= b263. >=20 >> =E2=80=94 Section 2.2.5 =E2=80=94 >>=20 >> "min(a,b)" means the smallest of two values a and b. >> "max(a,b)" means the largest of two values a and b. >>=20 >> Nit: =E2=80=9Csmaller=E2=80=9D and =E2=80=9Clarger=E2=80=9D, for only = two. >=20 > Fixed as suggested in = https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea597918b5633d11= 88ea. >=20 >> =E2=80=94 Section 2.2.7 =E2=80=94 >>=20 >> "a...b" means any value starting from a to b, inclusive. >>=20 >> =E2=80=9Cstarting=E2=80=9D? I would leave that word out. >=20 > Fixed as suggested in = https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea597918b5633d11= 88ea. >=20 >> =E2=80=94 Section 2.2.9.1 =E2=80=94 >>=20 >> "remaining_bits_in_bitstream( )" means the count of remaining bits >>=20 >> Section 2.2.9.3 uses remaining_bits_in_bitstream( NumBytes ), as do = Sections >> 4.4 and 4.5. This should too, yes? >=20 > Yes. Fixed in = https://github.com/FFmpeg/FFV1/commit/5685a9e8c35ce5ca8420b97cbb336aad8fa5= ad0c and = https://github.com/FFmpeg/FFV1/commit/5056a894d16c517a63aaa4925f8ca1a91803= f205. >=20 >> =E2=80=94 Section 3.2 =E2=80=94 >>=20 >> Figure 3: A depiction of how relatively positions Samples are >> references within this document. >>=20 >> I think you mean =E2=80=9Cpositioned=E2=80=9D and =E2=80=9Creferenced=E2= =80=9D, yes? >=20 > Yes. Fixed in = https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea597918b5633d11= 88ea. >=20 >> =E2=80=94 Section 3.3 =E2=80=94 >>=20 >> Background: a two's complement signed 16-bit signed integer was used >>=20 >> I=E2=80=99d remove the first =E2=80=9Csigned=E2=80=9D. >=20 > Fixed in = https://github.com/FFmpeg/FFV1/commit/55c200e145ed9067459d31910d3eda592109= 7098. >=20 >> =E2=80=94 Section 3.8.2 =E2=80=94 >>=20 >> The end of the bitstream of the "Frame" is filled with 0-bits until >> that the bitstream contains a multiple of 8 bits. >>=20 >> Is =E2=80=9Cthat=E2=80=9D just an extra word that needs to be struck, = or is something else >> wrong here? And is this meant to be what we usually call = =E2=80=9Cpadding=E2=80=9D? >=20 > Fixed in = https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea597918b5633d11= 88ea. >=20 >> =E2=80=94 Section 4 =E2=80=94 >>=20 >> Within the following sub-sections, pseudo-code is used to explain = the >> structure of each FFV1 bitstream component, as described in >> Section 2.2.1. >>=20 >> I read this as saying that Section 2.2.1 describes the structure of = each FFV1 >> bitstream component, until I went back there and looked. I suggest = reordering >> the sentence to help the reader a bit: >>=20 >> NEW >> Within the following sub-sections, pseudo-code is used, as described >> in Section 2.2.1, to explain the structure of each FFV1 bitstream >> component. >> END >=20 > The suggested was taken and used in = https://github.com/FFmpeg/FFV1/commit/ab5a5c944d518ad72a982118b3c90b99a78d= 5d7c. >=20 >> =E2=80=94 Section 4.5 =E2=80=94 >>=20 >> Encoders SHOULD NOT fill these bits. >> Decoders SHOULD ignore these bits. >>=20 >> Before this you describe two kinds of bits, and it=E2=80=99s not = clear whether these >> are talking about both kinds, or just the latter. I think changing = =E2=80=9Cthese=E2=80=9D to >> =E2=80=9Creserved=E2=80=9D is better. >=20 > Adjusted in = https://github.com/FFmpeg/FFV1/commit/12bfc977f5f868404b69f434501f011a850e= e9c0. >=20 >> =E2=80=94 Section 6 =E2=80=94 >>=20 >> A frequent security problem in image >> and video codecs is also to not check for integer overflows, for >> example to allocate "frame_pixel_width * frame_pixel_height" in >> "Pixel" count computations without considering that the >> multiplication result may have overflowed the arithmetic types = range. >>=20 >> This is somewhat complex and awkward (arguably a comma splice), and I = suggest >> splitting the sentence thus: >>=20 >> NEW >> A frequent security problem in image >> and video codecs is failure to check for integer overflows. An >> example is allocating "frame_pixel_width * frame_pixel_height" in >> "Pixel" count computations without considering that the >> multiplication result may have overflowed the arithmetic types = range. >> END >=20 > Fixed in = https://github.com/FFmpeg/FFV1/commit/741f67b405b2bfbe683a2a3d9dc83468bca9= 60cf. >=20 >> I might also make the =E2=80=9Cmust=E2=80=9D in the last sentence of = that paragraph be =E2=80=9CMUST=E2=80=9D. >=20 > Fixed in = https://github.com/FFmpeg/FFV1/commit/50d9e14ad889cc833d65a905a01637ea8b52= 6a45. >=20 > summary: >=20 > In my opinion, all discuss and comments listed in this review have = been resolved with the exception of the status of comments on Section = 3.8.1.1 being less clear. I=E2=80=99m pasting in the current state of = Section 3.8.1.1 for consideration: >=20 >> 3.8.1.1. Range Binary Values >>=20 >> To encode binary digits efficiently a Range coder is used. C_(i) = is >> the i-th Context. B_(i) is the i-th byte of the bytestream. b_(i) = is >> the i-th Range coded binary value, S_(0, i) is the i-th initial >> state. The length of the bytestream encoding n binary symbols is >> j_(n) bytes. >>=20 >> r_(i) =3D floor( ( R_(i) * S_(i, C_(i)) ) / 2 ^ 8 ) >>=20 >> Figure 11: A formula of the read of a binary value in Range >> Binary mode. >>=20 >> S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND >> l_(i) =3D L_(i) AND >> t_(i) =3D R_(i) - r_(i) <=3D=3D >> b_(i) =3D 0 <=3D=3D> >> L_(i) < R_(i) - r_(i) >>=20 >> S_(i + 1, C_(i)) =3D one_state_(S_(i, C_(i))) AND >> l_(i) =3D L_(i) - R_(i) + r_(i) AND >> t_(i) =3D r_(i) <=3D=3D >> b_(i) =3D 1 <=3D=3D> >> L_(i) >=3D R_(i) - r_(i) >>=20 >> Figure 12 >>=20 >> S_(i + 1, k) =3D S_(i, k) <=3D=3D C_(i) !=3D k >>=20 >> Figure 13: The "i+1,k"-th State is equal to the "i,k"-th State if >> the value of "k" is unequal to the i-th value of Context. >>=20 >> R_(i + 1) =3D 2 ^ 8 * t_(i) AND >> L_(i + 1) =3D 2 ^ 8 * l_(i) + B_(j_(i)) AND >> j_(i + 1) =3D j_(i) + 1 <=3D=3D >> t_(i) < 2 ^ 8 >>=20 >> R_(i + 1) =3D t_(i) AND >> L_(i + 1) =3D l_(i) AND >> j_(i + 1) =3D j_(i) <=3D=3D >> t_(i) >=3D 2 ^ 8 >>=20 >> Figure 14: The "i+1"-th values for "Range", "Low", and the length >> of the bytestream encoding are conditionally set depending on the >> "i-th" value of "t". >>=20 >> R_(0) =3D 65280 >>=20 >> Figure 15: The initial value for "Range". >>=20 >> L_(0) =3D 2 ^ 8 * B_(0) + B_(1) >>=20 >> Figure 16: The initial value for "Low" is set according to the >> first two bytes of the bytestream. >>=20 >> j_(0) =3D 2 >>=20 >> Figure 17: The initial value for "j", the length of the >> bytestream encoding. >>=20 >> range =3D 0xFF00; >> end =3D 0; >> low =3D get_bits(16); >> if (low >=3D range) { >> low =3D range; >> end =3D 1; >> } >>=20 >> Figure 18: A pseudo-code description of the initial states in >> Range Binary mode. >>=20 >> refill() { >> if (range < 256) { >> range =3D range * 256; >> low =3D low * 256; >> if (!end) { >> c.low +=3D get_bits(8); >> if (remaining_bits_in_bitstream( NumBytes ) =3D=3D 0) { >> end =3D 1; >> } >> } >> } >> } >>=20 >> Figure 19: A pseudo-code description of refilling the Range >> Binary Value coder buffer. >>=20 >> get_rac(state) { >> rangeoff =3D (range * state) / 256; >> range -=3D rangeoff; >> if (low < range) { >> state =3D zero_state[state]; >> refill(); >> return 0; >> } else { >> low -=3D range; >> state =3D one_state[state]; >> range =3D rangeoff; >> refill(); >> return 1; >> } >> } >>=20 >> Figure 20: A pseudo-code description of the read of a binary >> value in Range Binary mode. Please note that we just updated the draft to include the recommended = changes, which can be reviewed in version 19 of = https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/. Here=E2=80=99s = a link to the diff of version 18 and 19: = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-cellar-ffv1-18&url2=3Ddraft= -ietf-cellar-ffv1-19&difftype=3D--html. To repeat a comment above: In my opinion, all discuss and comments = listed in this review have been resolved with the exception of the = status of comments on Section 3.8.1.1 being less clear but since a lot = of work has been done here, we could use a new review of this section = within the new version. Kind Regards, Dave Rice From nobody Tue Dec 1 14:02:00 2020 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 48E1B3A1506; Tue, 1 Dec 2020 14:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.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 QC6faFv81aDm; Tue, 1 Dec 2020 14:01:56 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 389E03A1505; Tue, 1 Dec 2020 14:01:55 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0B1M16mq016541; Tue, 1 Dec 2020 17:01:06 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 0B1M16mq016541 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1606860066; bh=yrgFyKSrnT2i8YWJ8YZGpQ6EfJq5hEhQSsediPMRfC8=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=P6kckDd5QAPauDtAlQKI5w+FmCLYl2Khn3vzbqT2LWU1ONFK+NWajsygyyYRM/8gi OVxIAOarozslc7wqGcLX/KPmj/Dl0CCKriHeXf61yIyp0h9jpEi8XzfgudytE+Yxgv dREy6nudvcki49jvvPsvNTjop4suAtKlPqsSSvEA= Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 0B1M14qP017066; Tue, 1 Dec 2020 17:01:04 -0500 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 1 Dec 2020 17:01:04 -0500 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Tue, 1 Dec 2020 17:01:04 -0500 From: Roman Danyliw To: Dave Rice , Spencer Dawkins at IETF CC: "draft-ietf-cellar-ffv1.chairs@ietf.org" , "draft-ietf-cellar-ffv1@ietf.org" , "Codec Encoding for LossLess Archiving and Realtime transmission" , Barry Leiba Thread-Topic: [Cellar] New Version Notification - draft-ietf-cellar-ffv1-18.txt Thread-Index: AQHWruuzAiXNhGI6XEOa/iU25Oq7SKnjRIWA//+4RUA= Date: Tue, 1 Dec 2020 22:01:03 +0000 Message-ID: <308c772b2e324fe88836caa91c78c8fb@cert.org> References: <160208949226.20172.3161875416157552929@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Cellar] New Version Notification - draft-ietf-cellar-ffv1-18.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 01 Dec 2020 22:01:58 -0000 SGkgRGF2ZSENCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERhdmUg UmljZSA8ZGF2ZUBkZXJpY2VkLmNvbT4NCj4gU2VudDogVHVlc2RheSwgRGVjZW1iZXIgMSwgMjAy MCA0OjE3IFBNDQo+IFRvOiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURiA8c3BlbmNlcmRhd2tpbnMu aWV0ZkBnbWFpbC5jb20+OyBSb21hbg0KPiBEYW55bGl3IDxyZGRAY2VydC5vcmc+DQo+IENjOiBk cmFmdC1pZXRmLWNlbGxhci1mZnYxLmNoYWlyc0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi1jZWxsYXIt ZmZ2MUBpZXRmLm9yZzsgQ29kZWMNCj4gRW5jb2RpbmcgZm9yIExvc3NMZXNzIEFyY2hpdmluZyBh bmQgUmVhbHRpbWUgdHJhbnNtaXNzaW9uIDxjZWxsYXJAaWV0Zi5vcmc+Ow0KPiBCYXJyeSBMZWli YSA8YmFycnlsZWliYUBjb21wdXRlci5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbQ2VsbGFyXSBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gLSBkcmFmdC1pZXRmLWNlbGxhci1mZnYxLTE4LnR4dA0KPiAN Cj4gSGkgUm9tYW4sIFNwZW5jZXIsDQo+IA0KPiA+IE9uIE9jdCAzMCwgMjAyMCwgYXQgMTo0MSBQ TSwgRGF2ZSBSaWNlIDxkYXZlQGRlcmljZWQuY29tPiB3cm90ZToNCj4gPg0KPiA+IFRoYW5rIHlv dSBSb21hbiwNCj4gPg0KPiA+PiBPbiBPY3QgMjEsIDIwMjAsIGF0IDI6MDMgUE0sIFNwZW5jZXIg RGF3a2lucyBhdCBJRVRGDQo+IDxzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6 DQo+ID4+DQo+ID4+IEhpLCBSb21hbiwNCj4gPj4NCj4gPj4gT24gV2VkLCBPY3QgMjEsIDIwMjAg YXQgMTI6MzggUE0gUm9tYW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPiB3cm90ZToNCj4gPj4gSGkh DQo+ID4+IChJIGNhbid0IGZpbmQgeW91ciByZXNwb25zZSBlbWFpbCB0byBteSBiYWxsb3QgaW4g bXkgbWFpbCBjbGllbnQgZGVzcGl0ZSBpdA0KPiBiZWluZyBpbiB0aGUgYXJjaGl2ZSwgc28gYXBv bG9naXplcyBmb3IgbWFraW5nIHRoZSBuZXcgdGhyZWFkKS4NCj4gPj4NCj4gPj4gVGhhbmtzIGZv ciB0aGUgLTE4IHdoaWNoIGNsZWFyZWQgbW9zdCBvZiB0aGUgQ09NTUVOVHMuICBJIHVwZGF0ZWQg bXkNCj4gYmFsbG90Lg0KPiA+Pg0KPiA+PiBJbiB0aGUgc3Bpcml0IG9mIGNsZWFyaW5nIHdoYXQg SSBjb25zaWRlciBhIHN0cmFpZ2h0Zm9yd2FyZCBESVNDVVNTLCBtaWdodCBJDQo+IHN1Z2dlc3Q6 DQo+ID4+DQo+ID4+IE9MRA0KPiA+Pg0KPiA+PiAgIEltcGxlbWVudGF0aW9ucyBvZiB0aGUgRkZW MSBjb2RlYyBuZWVkIHRvIHRha2UgYXBwcm9wcmlhdGUgc2VjdXJpdHkNCj4gPj4gICAgY29uc2lk ZXJhdGlvbnMgaW50byBhY2NvdW50LCBhcyBvdXRsaW5lZCBpbiBbUkZDNDczMl0uICBJdCBpcw0K PiA+PiAgICBleHRyZW1lbHkgaW1wb3J0YW50IGZvciB0aGUgZGVjb2RlciB0byBiZSByb2J1c3Qg YWdhaW5zdCBtYWxpY2lvdXMNCj4gPj4gICAgcGF5bG9hZHMuICBNYWxpY2lvdXMgcGF5bG9hZHMg TVVTVCBOT1QgY2F1c2UgdGhlIGRlY29kZXIgdG8gb3ZlcnJ1bg0KPiA+PiAgICBpdHMgYWxsb2Nh dGVkIG1lbW9yeSBvciB0byB0YWtlIGFuIGV4Y2Vzc2l2ZSBhbW91bnQgb2YgcmVzb3VyY2VzIHRv DQo+ID4+ICAgIGRlY29kZS4gIFRoZSBzYW1lIGFwcGxpZXMgdG8gdGhlIGVuY29kZXIsIC4uLg0K PiA+Pg0KPiA+PiBORVcNCj4gPj4NCj4gPj4gSW1wbGVtZW50YXRpb25zIG9mIHRoZSBGRlYxIGNv ZGVjIG5lZWQgdG8gdGFrZSBhcHByb3ByaWF0ZSBzZWN1cml0eQ0KPiBjb25zaWRlcmF0aW9ucyBp bnRvIGFjY291bnQuICBUaG9zZSByZWxhdGVkIHRvIGRlbmlhbCBvZiBzZXJ2aWNlIGFyZSBvdXRs aW5lZCBpbg0KPiBTZWN0aW9uIDIuMSBvZiBbUkZDNDczMl0uICBJdCBpcyBleHRyZW1lbHkgaW1w b3J0YW50IGZvciB0aGUgZGVjb2RlciB0byBiZQ0KPiByb2J1c3QgYWdhaW5zdCBtYWxpY2lvdXMg cGF5bG9hZHMuICBNYWxpY2lvdXMgcGF5bG9hZHMgTVVTVCBOT1QgY2F1c2UgdGhlDQo+IGRlY29k ZXIgdG8gb3ZlcnJ1biBpdHMgYWxsb2NhdGVkIG1lbW9yeSBvciB0byB0YWtlIGFuIGV4Y2Vzc2l2 ZSBhbW91bnQgb2YNCj4gcmVzb3VyY2VzIHRvIGRlY29kZS4gICAgQW4gb3ZlcnJ1biBpbiBhbGxv Y2F0ZWQgbWVtb3J5IGNvdWxkIGxlYWQgdG8gYXJiaXRyYXJ5DQo+IGNvZGUgZXhlY3V0aW9uIGJ5 IGFuIGF0dGFja2VyLiAgVGhlIHNhbWUgYXBwbGllcyB0byB0aGUgZW5jb2RlciwgLi4uDQo+ID4N Cj4gPiBUaGUgcmVjb21tZW5kYXRpb24gbG9va3MgYXBwcm9wcmlhdGUgdG8gbWUgYW5kIG1vcmUg Y2xlYXIuIEkgbW92ZWQgaXQgdG8gYQ0KPiBwdWxsIHJlcXVlc3QgYXQgaHR0cHM6Ly9naXRodWIu Y29tL0ZGbXBlZy9GRlYxL3B1bGwvMjUzIGZvciB0aGUgY29uc2lkZXJhdGlvbg0KPiBvZiB0aGUg b3RoZXIgYXV0aG9ycy4NCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgd2UganVzdCB1cGRhdGVkIHRo ZSBkcmFmdCB0byBpbmNsdWRlIHRoZSByZWNvbW1lbmRlZA0KPiBjaGFuZ2VzIGZvciBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBvbiBkZW5pYWwgb2Ygc2VydmljZSwgd2hpY2ggY2FuIGJlIHJldmll d2VkDQo+IGluIHZlcnNpb24gMTkgb2YgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1jZWxsYXItZmZ2MS8uIEhlcmXigJlzIGENCj4gbGluayB0byB0aGUgZGlmZiBv ZiB2ZXJzaW9uIDE4IGFuZCAxOTogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwxPWRy YWZ0LQ0KPiBpZXRmLWNlbGxhci1mZnYxLTE4JnVybDI9ZHJhZnQtaWV0Zi1jZWxsYXItZmZ2MS0x OSZkaWZmdHlwZT0tLWh0bWwuDQoNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZSBhbmQgcHVzaGluZyB0 aGlzIHRleHQgaW50byAtMTkuICBJIGp1c3QgY2xlYXJlZCBteSBkaXNjdXNzaW9uIHBvc2l0aW9u Lg0KDQpSZWdhcmRzLA0KUm9tYW4NCg== From nobody Tue Dec 1 15:41:32 2020 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 94DC13A0B23; Tue, 1 Dec 2020 15:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 D7a99Po-EoN6; Tue, 1 Dec 2020 15:41:28 -0800 (PST) Received: from mail-yb1-xb2b.google.com (mail-yb1-xb2b.google.com [IPv6:2607:f8b0:4864:20::b2b]) (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 ACC5A3A0489; Tue, 1 Dec 2020 15:41:28 -0800 (PST) Received: by mail-yb1-xb2b.google.com with SMTP id l14so3533978ybq.3; Tue, 01 Dec 2020 15:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2PID2Ura0aGBNNJxmIEADCB4jV6suG+ZiH+5AQ9xQEg=; b=ocZTj8QocWLl5sp6RsiXb2L5mgcE1C3owB49kWXsasBTNCFUKuQJ48HghDqrtXZxlZ /iN8n694T7Pd4v6hmMoA0qyhS9E0KsMrLbh6W6o+QZgss6C3XK4coNQP2A/Xyha6OIfT 2EKrul6mLHFmGAHHl47eB1jzHTMsAr22YXq2YVqNmChS6KV0DhMM3sDvjn5yz9HCX6Ec 7P7/KlsBa8/4F0dI5d28NGmiP1zf4EOq1b+xP7adGwZZr5d8XRwofEWbx+minbcC372p pReofYFxcq5DE7/N0NU0VTTx92cgkthjtmiv8btm8AhppojbRifsYfokeAnp868ZyPeE jUlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2PID2Ura0aGBNNJxmIEADCB4jV6suG+ZiH+5AQ9xQEg=; b=JqY70nbCnO6c9Vl8DJQi6j1aiq6p3FUGf7U4SQ2Oe+bW6q/kkfT/1eI7DtGzhMOCFF SJA7C9t1CYpyb2ejyCeXxGMv1blExSavLUd/OQvcn+LW04W5GsQ4P1QJJO5/TJ9tm0zi qEl7JStL4+PteLMI9plLIz3XzF0HQW5V35YN3vwBPJC1lkMBlL2EjhanfbJhqf7QUz8p aloqUjiwShry58N/PW99KyD+TtIPqz4UjK5AlZvSY6tcgqrmJKXUYd5qMrE8FAvpY5ZG f8Z6yhZsVFP0GP8FS3VaA4X2etl01XgNfgxjoqKjWaP2hdAgZO0J2FENjIPD/08Vb8Q9 TvRg== X-Gm-Message-State: AOAM533rhsXUcp/CO/0VeUhrvh1YEUoY8r052MQZGIgK6yNYxxm7vJFD nykm0cXPao+6rcfqspPUx9WN43wKWeOPBaaoNWg= X-Google-Smtp-Source: ABdhPJwEQyV5HJvlxt9j+TAJTvP4kXwpYhBAESWAu4gkF7ZWtz5l1x931XGBSmcTsdunvn9CDSTibrs0sQAWlsHeHO8= X-Received: by 2002:a25:ae53:: with SMTP id g19mr6920144ybe.288.1606866087919; Tue, 01 Dec 2020 15:41:27 -0800 (PST) MIME-Version: 1.0 References: <160208949226.20172.3161875416157552929@ietfa.amsl.com> <308c772b2e324fe88836caa91c78c8fb@cert.org> In-Reply-To: <308c772b2e324fe88836caa91c78c8fb@cert.org> From: Spencer Dawkins at IETF Date: Tue, 1 Dec 2020 17:41:01 -0600 Message-ID: To: Roman Danyliw Cc: Dave Rice , "draft-ietf-cellar-ffv1.chairs@ietf.org" , "draft-ietf-cellar-ffv1@ietf.org" , Codec Encoding for LossLess Archiving and Realtime transmission , Barry Leiba Content-Type: multipart/alternative; boundary="0000000000005f42e305b56faac4" Archived-At: Subject: Re: [Cellar] New Version Notification - draft-ietf-cellar-ffv1-18.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 01 Dec 2020 23:41:31 -0000 --0000000000005f42e305b56faac4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Roman and Dave! Best, Spencer On Tue, Dec 1, 2020 at 4:01 PM Roman Danyliw wrote: > Hi Dave! > > > > -----Original Message----- > > From: Dave Rice > > Sent: Tuesday, December 1, 2020 4:17 PM > > To: Spencer Dawkins at IETF ; Roman > > Danyliw > > Cc: draft-ietf-cellar-ffv1.chairs@ietf.org; > draft-ietf-cellar-ffv1@ietf.org; Codec > > Encoding for LossLess Archiving and Realtime transmission < > cellar@ietf.org>; > > Barry Leiba > > Subject: Re: [Cellar] New Version Notification - > draft-ietf-cellar-ffv1-18.txt > > > > Hi Roman, Spencer, > > > > > On Oct 30, 2020, at 1:41 PM, Dave Rice wrote: > > > > > > Thank you Roman, > > > > > >> On Oct 21, 2020, at 2:03 PM, Spencer Dawkins at IETF > > wrote: > > >> > > >> Hi, Roman, > > >> > > >> On Wed, Oct 21, 2020 at 12:38 PM Roman Danyliw wrote: > > >> Hi! > > >> (I can't find your response email to my ballot in my mail client > despite it > > being in the archive, so apologizes for making the new thread). > > >> > > >> Thanks for the -18 which cleared most of the COMMENTs. I updated my > > ballot. > > >> > > >> In the spirit of clearing what I consider a straightforward DISCUSS, > might I > > suggest: > > >> > > >> OLD > > >> > > >> Implementations of the FFV1 codec need to take appropriate securit= y > > >> considerations into account, as outlined in [RFC4732]. It is > > >> extremely important for the decoder to be robust against maliciou= s > > >> payloads. Malicious payloads MUST NOT cause the decoder to overr= un > > >> its allocated memory or to take an excessive amount of resources = to > > >> decode. The same applies to the encoder, ... > > >> > > >> NEW > > >> > > >> Implementations of the FFV1 codec need to take appropriate security > > considerations into account. Those related to denial of service are > outlined in > > Section 2.1 of [RFC4732]. It is extremely important for the decoder to > be > > robust against malicious payloads. Malicious payloads MUST NOT cause t= he > > decoder to overrun its allocated memory or to take an excessive amount = of > > resources to decode. An overrun in allocated memory could lead to > arbitrary > > code execution by an attacker. The same applies to the encoder, ... > > > > > > The recommendation looks appropriate to me and more clear. I moved it > to a > > pull request at https://github.com/FFmpeg/FFV1/pull/253 for the > consideration > > of the other authors. > > > > Please note that we just updated the draft to include the recommended > > changes for security considerations on denial of service, which can be > reviewed > > in version 19 of > https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/. Here=E2=80=99s = a > > link to the diff of version 18 and 19: > https://www.ietf.org/rfcdiff?url1=3Ddraft- > > ietf-cellar-ffv1-18&url2=3Ddraft-ietf-cellar-ffv1-19&difftype=3D--html. > > Thanks for the update and pushing this text into -19. I just cleared my > discussion position. > > Regards, > Roman > --0000000000005f42e305b56faac4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Roman and Dave!

Best,

Spencer

On Tue, Dec 1, 2020 at 4:01 PM Roman Danyliw = <rdd@cert.org> wrote:
Hi Dave!


> -----Original Message-----
> From: Dave Rice <dave@dericed.com>
> Sent: Tuesday, December 1, 2020 4:17 PM
> To: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>; Roman > Danyliw <rdd@cert= .org>
> Cc: draft-ietf-cellar-ffv1.chairs@ietf.org; draft-ietf-cellar-ffv1@ie= tf.org; Codec
> Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>;
> Barry Leiba <barryleiba@computer.org>
> Subject: Re: [Cellar] New Version Notification - draft-ietf-cellar-ffv= 1-18.txt
>
> Hi Roman, Spencer,
>
> > On Oct 30, 2020, at 1:41 PM, Dave Rice <dave@dericed.com> wrote:
> >
> > Thank you Roman,
> >
> >> On Oct 21, 2020, at 2:03 PM, Spencer Dawkins at IETF
> <spencerdawkins.ietf@gmail.com> wrote:
> >>
> >> Hi, Roman,
> >>
> >> On Wed, Oct 21, 2020 at 12:38 PM Roman Danyliw <rdd@cert.org> wrote:
> >> Hi!
> >> (I can't find your response email to my ballot in my mail= client despite it
> being in the archive, so apologizes for making the new thread).
> >>
> >> Thanks for the -18 which cleared most of the COMMENTs.=C2=A0 = I updated my
> ballot.
> >>
> >> In the spirit of clearing what I consider a straightforward D= ISCUSS, might I
> suggest:
> >>
> >> OLD
> >>
> >>=C2=A0 =C2=A0Implementations of the FFV1 codec need to take ap= propriate security
> >>=C2=A0 =C2=A0 considerations into account, as outlined in [RFC= 4732].=C2=A0 It is
> >>=C2=A0 =C2=A0 extremely important for the decoder to be robust= against malicious
> >>=C2=A0 =C2=A0 payloads.=C2=A0 Malicious payloads MUST NOT caus= e the decoder to overrun
> >>=C2=A0 =C2=A0 its allocated memory or to take an excessive amo= unt of resources to
> >>=C2=A0 =C2=A0 decode.=C2=A0 The same applies to the encoder, .= ..
> >>
> >> NEW
> >>
> >> Implementations of the FFV1 codec need to take appropriate se= curity
> considerations into account.=C2=A0 Those related to denial of service = are outlined in
> Section 2.1 of [RFC4732].=C2=A0 It is extremely important for the deco= der to be
> robust against malicious payloads.=C2=A0 Malicious payloads MUST NOT c= ause the
> decoder to overrun its allocated memory or to take an excessive amount= of
> resources to decode.=C2=A0 =C2=A0 An overrun in allocated memory could= lead to arbitrary
> code execution by an attacker.=C2=A0 The same applies to the encoder, = ...
> >
> > The recommendation looks appropriate to me and more clear. I move= d it to a
> pull request at https://github.com/FFmpeg/FFV1/pull/253<= /a> for the consideration
> of the other authors.
>
> Please note that we just updated the draft to include the recommended<= br> > changes for security considerations on denial of service, which can be= reviewed
> in version 19 of https://datatracker.ie= tf.org/doc/draft-ietf-cellar-ffv1/. Here=E2=80=99s a
> link to the diff of version 18 and 19: https://www.ie= tf.org/rfcdiff?url1=3Ddraft-
> ietf-cellar-ffv1-18&url2=3Ddraft-ietf-cellar-ffv1-19&difftype= =3D--html.

Thanks for the update and pushing this text into -19.=C2=A0 I just cleared = my discussion position.

Regards,
Roman
--0000000000005f42e305b56faac4-- From nobody Wed Dec 2 09:30:23 2020 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 EC69D3A1462; Wed, 2 Dec 2020 09:30:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aeo8m_ejOcDC; Wed, 2 Dec 2020 09:30:16 -0800 (PST) Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) (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 9ADFB3A1474; Wed, 2 Dec 2020 09:30:13 -0800 (PST) Received: by mail-vk1-f170.google.com with SMTP id u16so579908vkb.1; Wed, 02 Dec 2020 09:30:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=YD/VfJ1APr7hFGfTGsCiYRFviDEfNdlPG2URklBpuuE=; b=k2odYhPLD0ET9neSqglTUjPzu4ni8ylYuwBALOcJi/S8B7OBwrKKxr+WZfpxBT5zkL IBRlFISvxr5+xHH1lfBe2L1uAEqzt4LVfG5FlPoucEOR3e342U4txvh+oRmSIsanEj6z ImVvLLAMLilhhuVLy7jsj1YntdHrpgtsR3o94eFBApMbbd4GukZBiV8iYNX1eMy/gv/H DXnon7AFT0k7gjpeLJRcqNzpkE4pzS4XYWPqv45ViRcZdCfXrjBEvlAxcxKi308Gm26W h/WiVifk0Sjbt2BrJVbgfBV0k+sRDbXWt4icLpNV5o4LgQnypvt3pQREliDeYTikz3uR VZhA== X-Gm-Message-State: AOAM532ZD6T2zBQ8IzfmzP0N67XtxbSuLvkU6CkIZP0yp8Cz/PgXZWo1 ga9W3f2a/jWgQngAQQ4pfTF+WuWKXxWqyxqnjSQYeb3QZnY= X-Google-Smtp-Source: ABdhPJz3rftzc6fugHUxaD0AZr9TnxagPqtu4XAK1SZRvZA6zVZTx+clvZHlB9qZc15pid9am0nwlMQXYGfKTv+lcSE= X-Received: by 2002:a1f:9ed4:: with SMTP id h203mr2593851vke.1.1606930212231; Wed, 02 Dec 2020 09:30:12 -0800 (PST) MIME-Version: 1.0 References: <160049032442.20595.4616862102756589735@ietfa.amsl.com> <92029D16-621F-4AE0-BC3F-03C08AB21ADE@dericed.com> In-Reply-To: From: Barry Leiba Date: Wed, 2 Dec 2020 12:30:00 -0500 Message-ID: To: Dave Rice Cc: The IESG , Michael Richardson , draft-ietf-cellar-ffv1@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission , cellar-chairs@ietf.org, pb@das-werkstatt.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 02 Dec 2020 17:30:19 -0000 Thank you, Dave. I have checked everything other than the 3.8.1.x subsections, and you've covered all my comments perfectly. I really appreciate the clarifications, and thanks for addressing my nit-level things as well. I'm reviewing 3.8.1.x now, but I wanted to give an intermediate status quic= kly. Barry On Tue, Dec 1, 2020 at 4:17 PM Dave Rice wrote: > > Hi Barry, > > > On Oct 30, 2020, at 2:29 PM, Dave Rice wrote: > > > > Hi all, > > > > I=E2=80=99m writing this as an update to what aspects of this DISCUSS a= re resolved and what may remain. I added a summary at the end, but the tl;d= r is that in my opinion all discuss and comment points are resolved in our = git repository but Section 3.8.1.1 could use a new look in light of the dis= cuss comments against it. > > > >> On Sep 19, 2020, at 12:38 AM, Barry Leiba via Datatracker wrote: > >> > >> Barry Leiba has entered the following ballot position for > >> draft-ietf-cellar-ffv1-17: Discuss > >> > >> When responding, please keep the subject line intact and reply to all > >> email addresses included in the To and CC lines. (Feel free to cut thi= s > >> introductory paragraph, however.) > >> > >> > >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.h= tml > >> for more information about IESG DISCUSS and COMMENT positions. > >> > >> > >> The document, along with other ballot positions, can be found here: > >> https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ > >> > >> > >> > >> ---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> There are a number of things I=E2=80=99d like to discuss, because I fi= nd them not > >> understandable. Perhaps it=E2=80=99s simply because I=E2=80=99m not a= codec expert, but, while > >> I understand that this is written for readers who will actually be imp= lementing > >> he FFV1 codec, some of them will also not be =E2=80=9Cexperts=E2=80=9D= . That said, I=E2=80=99m sure > >> some of this is just a case of =E2=80=9Cgive Barry some clue and it=E2= =80=99s fine.=E2=80=9D > >> > >> =E2=80=94 Section 2.1 =E2=80=94 > >> You use the term =E2=80=9Csymbol=E2=80=9D here and later, without defi= ning it, and I don=E2=80=99t know > >> what it is. A byte? A character? A string of bits? What length? > > > > Symbol is defined in https://github.com/FFmpeg/FFV1/commit/baa92e69bbdb= 5cece9f99556267906beffcd0fd2 as: > > > > `Symbol`: A value stored in the bitstream, which is defined and d= ecoded through one of the methods described in [@tablePseudoCodeSymbols]. > > > >> =E2=80=94 Section 3.8.1.1 =E2=80=94 > >> I=E2=80=99m not sure how to interpret the stuff in this section. Firs= t, I don=E2=80=99t know > >> why there are seven =E2=80=9Cfigures=E2=80=9D, with no captions nor ot= her explanation. Second, > >> I=E2=80=99m having trouble making sense out of things like this: > >> > >> S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND > >> l_(i) =3D L_(i) AND > >> t_(i) =3D R_(i) - r_(i) <=3D=3D > >> b_(i) =3D 0 <=3D=3D> > >> L_(i) < R_(i) - r_(i) > >> > >> Can you explain how this is meant to be read? Maybe it=E2=80=99s just= me, and maybe > >> after you explain it I=E2=80=99ll whack myself on the head and say, = =E2=80=9CDoh!=E2=80=9D > > > > Reading this would take correlation to Section 2.2.5 (Mathematical Func= tions) for definitions of <=3D=3D and <=3D=3D> and the form of a_(b) and a_= (b,c). > > > > To read this out-loud would be like: > > > > The i-th value of b equaling zero implies that the i-th value of L is l= ess than the result of i-th value of R minus the i-th value of r. The reser= ve implication is also true. These implications both imply that the =E2=80= =98i+1,C_(i)' value of S equals the =E2=80=98S_(i, C_(i))=E2=80=99 of zero_= state as well as the i-th value of l equaling the i-th value of L as well a= s the i-th value of t equaling the i-th value of R minus the i-th value or = r. > > > >> Third, you say, =E2=80=9CS_(0, i) is the i-th initial state,=E2=80=9D = but you haven=E2=80=99t > >> previously introduced the term =E2=80=9Cstate=E2=80=9D, and I don=E2= =80=99t know what it means. > > > > Section 3.8 includes an informational reference to range coding. An und= erstanding on how range coding works could make this section more clear. > > > > More captions were added to these figures in https://github.com/FFmpeg/= FFV1/commit/32cb9ea3e697036e81722f1ceced47f74b70549f and https://github.com= /FFmpeg/FFV1/commit/ae3de36f528dbcef3fe5fdcc5b63bd5b06aefca0. > > > >> =E2=80=94 Section 3.8.1.2 =E2=80=94 > >> > >> "get_rac" returns a boolean, computed from the bytestream as > >> described in Section 3.8.1.1. > >> > >> I see nothing in Section 3.8.1.1 that describes get_rac. > > > > We=E2=80=99ve added a definition https://github.com/FFmpeg/FFV1/commit/= 199ce1b95eb426e807ddbfd5d8338243d8458db1 and cross-references in https://gi= thub.com/FFmpeg/FFV1/commit/ae3de36f528dbcef3fe5fdcc5b63bd5b06aefca0. > > > >> =E2=80=94 Section 3.8.1.3 =E2=80=94 > >> > >> At keyframes all Range coder state variables are set to their initial > >> state. > >> > >> What does =E2=80=9Cat keyframes=E2=80=9D mean? > > > > It was presumed that =E2=80=98at keyframe=E2=80=99 meant a frame where = the keyframe value was set to 1. This is clarified in https://github.com/FF= mpeg/FFV1/commit/4b4d6f3c180fa2c4debefcc73793fc65ddd852c0. > > > >> =E2=80=94 Section 3.8.1.5 =E2=80=94 > >> This is just a list of numbers with no explanation. It needs text exp= laining > >> what it means. > > > > An introduction to this table is added at https://github.com/FFmpeg/FFV= 1/commit/69dda1b8a4f02bcce47b860df83a2f26afdca909 > > > > The introduction is: > > In this mode a State Transition Table is used, indicating in which stat= e the decoder will move to, based on the current state and the value extrac= ted from [@figureGetRacPseudoCode]. > > > >> =E2=80=94 Section 3.8.2.2 =E2=80=94 > >> > >> The level is identical to the predicted one. > >> The run and the first different level are coded. > >> > >> What does =E2=80=9Clevel=E2=80=9D mean? It=E2=80=99s not defined anyw= here. > > > > This was rewording to use the term =E2=80=9Csample difference=E2=80=9D = rather than level at https://github.com/FFmpeg/FFV1/commit/d6fbc97aa32699d5= bafba9760e4f5093fcaa6120 and to cross-reference to the section that defines= sample difference. > > > >> =E2=80=94 Section 4.3.1 =E2=80=94 > >> > >> "reserved_for_future_use" has semantics that are reserved for future > >> use. > >> > >> Yes, that seems rather obvious, though it=E2=80=99s oddly worded. But= then you say > >> what to do with =E2=80=9Cthis value=E2=80=9D, and nowhere do you say w= hat the value is. How > >> does one know? > > > > This was clarified in https://github.com/FFmpeg/FFV1/commit/e7f6b342ae5= e1c326357479bbbfb2934fe6d83f1. > > > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> Some editorial comments that I ask you to please consider: > >> > >> General: It=E2=80=99s jarring to see the defined terms, such as =E2=80= =9CSample=E2=80=9D and =E2=80=9CPixel=E2=80=9D in > >> quotes every time they=E2=80=99re used. More common practice is to qu= ote them when > >> they=E2=80=99re first defined, and then to just use the capitalization= to show that > >> they=E2=80=99re defined terms. I find that the quotes affect the read= ability and make > >> it somewhat more of a challenge to read. > > > > We agreed. These excessive quotes were removed in https://github.com/FF= mpeg/FFV1/commit/f0eb24b7820889fbd93b68d1e707d4380a90ded1. > > > >> =E2=80=94 Section 2.1 =E2=80=94 > >> > >> "Plane": A discrete component of a static image comprised of > >> > >> Total, total nit, and pet peeve: =E2=80=9Ccomposed of=E2=80=9D or =E2= =80=9Ccomprising=E2=80=9D, but not > >> =E2=80=9Ccomprised of=E2=80=9D. > > > > Fixed as suggested in https://github.com/FFmpeg/FFV1/commit/fe219d9b2af= ff5583b40ea597918b5633d1188ea. > > > >> =E2=80=94 Section 2.2.2 =E2=80=94 > >> You=E2=80=99re missing =E2=80=9Ca % b=E2=80=9D, which is referenced in= Section 2.2.6. > > > > Nice catch. We removed this in https://github.com/FFmpeg/FFV1/commit/34= ec93cdacef056c6cb53ca3120d5a021acfb911 as it is unused in the document. > > > >> =E2=80=94 Section 2.2.4 =E2=80=94 > >> > >> "a > b" means a is greater than b. > >> "a >=3D b" means a is greater than or equal to b. > >> "a < b" means a is less than b. > >> "a <=3D b" means a is less than or equal b. > >> "a =3D=3D b" means a is equal to b. > >> "a !=3D b" means a is not equal to b. > >> > >> I don=E2=80=99t think anyone will misunderstand this, so it=E2=80=99s = a very small thing, but=E2=80=A6 > >> might this be better said as, =E2=80=98 "a > b" is true when a is grea= ter than b. =E2=80=98 > >> (and similarly for the rest)? > > > > Reworded as suggested in https://github.com/FFmpeg/FFV1/commit/6ef98dc1= 38d34966cc686f64d1f4224202e6b263. > > > >> =E2=80=94 Section 2.2.5 =E2=80=94 > >> > >> "min(a,b)" means the smallest of two values a and b. > >> "max(a,b)" means the largest of two values a and b. > >> > >> Nit: =E2=80=9Csmaller=E2=80=9D and =E2=80=9Clarger=E2=80=9D, for only = two. > > > > Fixed as suggested in https://github.com/FFmpeg/FFV1/commit/fe219d9b2af= ff5583b40ea597918b5633d1188ea. > > > >> =E2=80=94 Section 2.2.7 =E2=80=94 > >> > >> "a...b" means any value starting from a to b, inclusive. > >> > >> =E2=80=9Cstarting=E2=80=9D? I would leave that word out. > > > > Fixed as suggested in https://github.com/FFmpeg/FFV1/commit/fe219d9b2af= ff5583b40ea597918b5633d1188ea. > > > >> =E2=80=94 Section 2.2.9.1 =E2=80=94 > >> > >> "remaining_bits_in_bitstream( )" means the count of remaining bits > >> > >> Section 2.2.9.3 uses remaining_bits_in_bitstream( NumBytes ), as do Se= ctions > >> 4.4 and 4.5. This should too, yes? > > > > Yes. Fixed in https://github.com/FFmpeg/FFV1/commit/5685a9e8c35ce5ca842= 0b97cbb336aad8fa5ad0c and https://github.com/FFmpeg/FFV1/commit/5056a894d16= c517a63aaa4925f8ca1a91803f205. > > > >> =E2=80=94 Section 3.2 =E2=80=94 > >> > >> Figure 3: A depiction of how relatively positions Samples are > >> references within this document. > >> > >> I think you mean =E2=80=9Cpositioned=E2=80=9D and =E2=80=9Creferenced= =E2=80=9D, yes? > > > > Yes. Fixed in https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b4= 0ea597918b5633d1188ea. > > > >> =E2=80=94 Section 3.3 =E2=80=94 > >> > >> Background: a two's complement signed 16-bit signed integer was used > >> > >> I=E2=80=99d remove the first =E2=80=9Csigned=E2=80=9D. > > > > Fixed in https://github.com/FFmpeg/FFV1/commit/55c200e145ed9067459d3191= 0d3eda5921097098. > > > >> =E2=80=94 Section 3.8.2 =E2=80=94 > >> > >> The end of the bitstream of the "Frame" is filled with 0-bits until > >> that the bitstream contains a multiple of 8 bits. > >> > >> Is =E2=80=9Cthat=E2=80=9D just an extra word that needs to be struck, = or is something else > >> wrong here? And is this meant to be what we usually call =E2=80=9Cpad= ding=E2=80=9D? > > > > Fixed in https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea59= 7918b5633d1188ea. > > > >> =E2=80=94 Section 4 =E2=80=94 > >> > >> Within the following sub-sections, pseudo-code is used to explain the > >> structure of each FFV1 bitstream component, as described in > >> Section 2.2.1. > >> > >> I read this as saying that Section 2.2.1 describes the structure of ea= ch FFV1 > >> bitstream component, until I went back there and looked. I suggest re= ordering > >> the sentence to help the reader a bit: > >> > >> NEW > >> Within the following sub-sections, pseudo-code is used, as described > >> in Section 2.2.1, to explain the structure of each FFV1 bitstream > >> component. > >> END > > > > The suggested was taken and used in https://github.com/FFmpeg/FFV1/comm= it/ab5a5c944d518ad72a982118b3c90b99a78d5d7c. > > > >> =E2=80=94 Section 4.5 =E2=80=94 > >> > >> Encoders SHOULD NOT fill these bits. > >> Decoders SHOULD ignore these bits. > >> > >> Before this you describe two kinds of bits, and it=E2=80=99s not clear= whether these > >> are talking about both kinds, or just the latter. I think changing = =E2=80=9Cthese=E2=80=9D to > >> =E2=80=9Creserved=E2=80=9D is better. > > > > Adjusted in https://github.com/FFmpeg/FFV1/commit/12bfc977f5f868404b69f= 434501f011a850ee9c0. > > > >> =E2=80=94 Section 6 =E2=80=94 > >> > >> A frequent security problem in image > >> and video codecs is also to not check for integer overflows, for > >> example to allocate "frame_pixel_width * frame_pixel_height" in > >> "Pixel" count computations without considering that the > >> multiplication result may have overflowed the arithmetic types range. > >> > >> This is somewhat complex and awkward (arguably a comma splice), and I = suggest > >> splitting the sentence thus: > >> > >> NEW > >> A frequent security problem in image > >> and video codecs is failure to check for integer overflows. An > >> example is allocating "frame_pixel_width * frame_pixel_height" in > >> "Pixel" count computations without considering that the > >> multiplication result may have overflowed the arithmetic types range. > >> END > > > > Fixed in https://github.com/FFmpeg/FFV1/commit/741f67b405b2bfbe683a2a3d= 9dc83468bca960cf. > > > >> I might also make the =E2=80=9Cmust=E2=80=9D in the last sentence of t= hat paragraph be =E2=80=9CMUST=E2=80=9D. > > > > Fixed in https://github.com/FFmpeg/FFV1/commit/50d9e14ad889cc833d65a905= a01637ea8b526a45. > > > > summary: > > > > In my opinion, all discuss and comments listed in this review have been= resolved with the exception of the status of comments on Section 3.8.1.1 b= eing less clear. I=E2=80=99m pasting in the current state of Section 3.8.1.= 1 for consideration: > > > >> 3.8.1.1. Range Binary Values > >> > >> To encode binary digits efficiently a Range coder is used. C_(i) is > >> the i-th Context. B_(i) is the i-th byte of the bytestream. b_(i) i= s > >> the i-th Range coded binary value, S_(0, i) is the i-th initial > >> state. The length of the bytestream encoding n binary symbols is > >> j_(n) bytes. > >> > >> r_(i) =3D floor( ( R_(i) * S_(i, C_(i)) ) / 2 ^ 8 ) > >> > >> Figure 11: A formula of the read of a binary value in Range > >> Binary mode. > >> > >> S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND > >> l_(i) =3D L_(i) AND > >> t_(i) =3D R_(i) - r_(i) <=3D=3D > >> b_(i) =3D 0 <=3D=3D> > >> L_(i) < R_(i) - r_(i) > >> > >> S_(i + 1, C_(i)) =3D one_state_(S_(i, C_(i))) AND > >> l_(i) =3D L_(i) - R_(i) + r_(i) AND > >> t_(i) =3D r_(i) <=3D=3D > >> b_(i) =3D 1 <=3D=3D> > >> L_(i) >=3D R_(i) - r_(i) > >> > >> Figure 12 > >> > >> S_(i + 1, k) =3D S_(i, k) <=3D=3D C_(i) !=3D k > >> > >> Figure 13: The "i+1,k"-th State is equal to the "i,k"-th State if > >> the value of "k" is unequal to the i-th value of Context. > >> > >> R_(i + 1) =3D 2 ^ 8 * t_(i) AND > >> L_(i + 1) =3D 2 ^ 8 * l_(i) + B_(j_(i)) AND > >> j_(i + 1) =3D j_(i) + 1 <=3D=3D > >> t_(i) < 2 ^ 8 > >> > >> R_(i + 1) =3D t_(i) AND > >> L_(i + 1) =3D l_(i) AND > >> j_(i + 1) =3D j_(i) <=3D=3D > >> t_(i) >=3D 2 ^ 8 > >> > >> Figure 14: The "i+1"-th values for "Range", "Low", and the length > >> of the bytestream encoding are conditionally set depending on the > >> "i-th" value of "t". > >> > >> R_(0) =3D 65280 > >> > >> Figure 15: The initial value for "Range". > >> > >> L_(0) =3D 2 ^ 8 * B_(0) + B_(1) > >> > >> Figure 16: The initial value for "Low" is set according to the > >> first two bytes of the bytestream. > >> > >> j_(0) =3D 2 > >> > >> Figure 17: The initial value for "j", the length of the > >> bytestream encoding. > >> > >> range =3D 0xFF00; > >> end =3D 0; > >> low =3D get_bits(16); > >> if (low >=3D range) { > >> low =3D range; > >> end =3D 1; > >> } > >> > >> Figure 18: A pseudo-code description of the initial states in > >> Range Binary mode. > >> > >> refill() { > >> if (range < 256) { > >> range =3D range * 256; > >> low =3D low * 256; > >> if (!end) { > >> c.low +=3D get_bits(8); > >> if (remaining_bits_in_bitstream( NumBytes ) =3D=3D 0) { > >> end =3D 1; > >> } > >> } > >> } > >> } > >> > >> Figure 19: A pseudo-code description of refilling the Range > >> Binary Value coder buffer. > >> > >> get_rac(state) { > >> rangeoff =3D (range * state) / 256; > >> range -=3D rangeoff; > >> if (low < range) { > >> state =3D zero_state[state]; > >> refill(); > >> return 0; > >> } else { > >> low -=3D range; > >> state =3D one_state[state]; > >> range =3D rangeoff; > >> refill(); > >> return 1; > >> } > >> } > >> > >> Figure 20: A pseudo-code description of the read of a binary > >> value in Range Binary mode. > > Please note that we just updated the draft to include the recommended cha= nges, which can be reviewed in version 19 of https://datatracker.ietf.org/d= oc/draft-ietf-cellar-ffv1/. Here=E2=80=99s a link to the diff of version 18= and 19: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-cellar-ffv1-18&url2= =3Ddraft-ietf-cellar-ffv1-19&difftype=3D--html. > > To repeat a comment above: In my opinion, all discuss and comments listed= in this review have been resolved with the exception of the status of comm= ents on Section 3.8.1.1 being less clear but since a lot of work has been d= one here, we could use a new review of this section within the new version. > > Kind Regards, > Dave Rice > From nobody Wed Dec 2 13:11:36 2020 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 181973A153A; Wed, 2 Dec 2020 13:11:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160694349397.19222.15324351855081692353@ietfa.amsl.com> Date: Wed, 02 Dec 2020 13:11:34 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2021-01-26 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 02 Dec 2020 21:11:34 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2021-01-26 from 21:00 to 22:00 Europe/Amsterdam (20:00 to 21:00 UTC). Agenda: Agenda will be provided on the CELLAR mailing list (cellar@ietf.org) Information about remote participation: Web Conference is at https://whereby.com/cellar-interim (You can try this at any time) THERE IS NO TELEPHONE DIALIN. From nobody Wed Dec 2 13:11:55 2020 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 F00723A159C; Wed, 2 Dec 2020 13:11:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160694350295.14395.1098372400289623603@ietfa.amsl.com> Date: Wed, 02 Dec 2020 13:11:42 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2021-02-23 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 02 Dec 2020 21:11:51 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2021-02-23 from 21:00 to 22:00 Europe/Amsterdam (20:00 to 21:00 UTC). Agenda: Agenda will be provided on the CELLAR mailing list (cellar@ietf.org) Information about remote participation: Web Conference is at https://whereby.com/cellar-interim (You can try this at any time) THERE IS NO TELEPHONE DIALIN. From nobody Wed Dec 2 13:12:02 2020 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 32B7E3A15AC; Wed, 2 Dec 2020 13:11:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160694351317.26179.8529981778158454335@ietfa.amsl.com> Date: Wed, 02 Dec 2020 13:11:53 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2021-03-23 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 02 Dec 2020 21:12:00 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2021-03-23 from 21:00 to 22:00 Europe/Amsterdam (20:00 to 21:00 UTC). Agenda: Agenda will be provided on the CELLAR mailing list (cellar@ietf.org) Information about remote participation: Web Conference is at https://whereby.com/cellar-interim (You can try this at any time) THERE IS NO TELEPHONE DIALIN. From nobody Wed Dec 2 13:12:13 2020 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 1BAAF3A15AC; Wed, 2 Dec 2020 13:12:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160694352108.13983.724155402706382774@ietfa.amsl.com> Date: Wed, 02 Dec 2020 13:12:01 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2021-04-27 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 02 Dec 2020 21:12:07 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2021-04-27 from 21:00 to 22:00 Europe/Amsterdam (19:00 to 20:00 UTC). Agenda: Agenda will be provided on the CELLAR mailing list (cellar@ietf.org) Information about remote participation: Web Conference is at https://whereby.com/cellar-interim (You can try this at any time) THERE IS NO TELEPHONE DIALIN. From nobody Wed Dec 2 13:12:17 2020 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 B8B513A1639; Wed, 2 Dec 2020 13:12:11 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160694353173.11687.3001897158879461659@ietfa.amsl.com> Date: Wed, 02 Dec 2020 13:12:11 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2021-05-25 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 02 Dec 2020 21:12:16 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2021-05-25 from 21:00 to 22:00 Europe/Amsterdam (19:00 to 20:00 UTC). Agenda: Agenda will be provided on the CELLAR mailing list (cellar@ietf.org) Information about remote participation: Web Conference is at https://whereby.com/cellar-interim (You can try this at any time) THERE IS NO TELEPHONE DIALIN. From nobody Wed Dec 2 13:12:25 2020 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 8E8663A16AC; Wed, 2 Dec 2020 13:12:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160694354056.11687.14526354471539579865@ietfa.amsl.com> Date: Wed, 02 Dec 2020 13:12:20 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2021-06-22 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 02 Dec 2020 21:12:25 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2021-06-22 from 21:00 to 22:00 Europe/Amsterdam (19:00 to 20:00 UTC). Agenda: Agenda will be provided on the CELLAR mailing list (cellar@ietf.org) Information about remote participation: Web Conference is at https://whereby.com/cellar-interim (You can try this at any time) THERE IS NO TELEPHONE DIALIN. From nobody Wed Dec 2 13:13:45 2020 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 EF7CE3A16C8; Wed, 2 Dec 2020 13:13:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160694361594.27941.7103931148969244257@ietfa.amsl.com> Date: Wed, 02 Dec 2020 13:13:35 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2021-08-24 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 02 Dec 2020 21:13:43 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2021-08-24 from 21:00 to 22:00 Europe/Amsterdam (19:00 to 20:00 UTC). Agenda: Agenda will be provided on the CELLAR mailing list (cellar@ietf.org) Information about remote participation: Web Conference is at https://whereby.com/cellar-interim (You can try this at any time) THERE IS NO TELEPHONE DIALIN. From nobody Wed Dec 2 13:14:00 2020 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 704653A15F7; Wed, 2 Dec 2020 13:13:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160694362542.27941.12210340154389602800@ietfa.amsl.com> Date: Wed, 02 Dec 2020 13:13:45 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2021-09-28 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 02 Dec 2020 21:13:53 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2021-09-28 from 21:00 to 22:00 Europe/Amsterdam (19:00 to 20:00 UTC). Agenda: Agenda will be provided on the CELLAR mailing list (cellar@ietf.org) Information about remote participation: Web Conference is at https://whereby.com/cellar-interim (You can try this at any time) THERE IS NO TELEPHONE DIALIN. From nobody Wed Dec 2 13:14:07 2020 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 DA71C3A1663; Wed, 2 Dec 2020 13:13:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160694363286.18670.5609885959942407448@ietfa.amsl.com> Date: Wed, 02 Dec 2020 13:13:52 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2021-10-26 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 02 Dec 2020 21:14:01 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2021-10-26 from 21:00 to 22:00 Europe/Amsterdam (19:00 to 20:00 UTC). Agenda: Agenda will be provided on the CELLAR mailing list (cellar@ietf.org) Information about remote participation: Web Conference is at https://whereby.com/cellar-interim (You can try this at any time) THERE IS NO TELEPHONE DIALIN. From nobody Wed Dec 2 13:14:11 2020 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 9B1D43A1804; Wed, 2 Dec 2020 13:14:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160694364061.22344.4052236300182038129@ietfa.amsl.com> Date: Wed, 02 Dec 2020 13:14:00 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2021-11-23 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 02 Dec 2020 21:14:08 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG will hold a virtual interim meeting on 2021-11-23 from 21:00 to 22:00 Europe/Amsterdam (20:00 to 21:00 UTC). Agenda: Agenda will be provided on the CELLAR mailing list (cellar@ietf.org) Information about remote participation: Web Conference is at https://whereby.com/cellar-interim (You can try this at any time) THERE IS NO TELEPHONE DIALIN. From nobody Wed Dec 2 14:43:45 2020 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 4CE423A159F; Wed, 2 Dec 2020 14:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Vi6EjCOhlD4; Wed, 2 Dec 2020 14:43:37 -0800 (PST) Received: from mail-vk1-f175.google.com (mail-vk1-f175.google.com [209.85.221.175]) (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 1AD773A1657; Wed, 2 Dec 2020 14:43:28 -0800 (PST) Received: by mail-vk1-f175.google.com with SMTP id j142so785907vkj.9; Wed, 02 Dec 2020 14:43:28 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=AKGXiuIj9uUjRDLMmcYE/KvzCaZAKw3zisqNhA3ZBB4=; b=VppmcB/+IQup8Dm2dWOzyjxcnwfQE09n4HDl9PzDnPRuqR5912fROj7tHD6zPJT5WX SvaclMgPWpnMc6V7iXME4Z3vGZxCszloNUZzx+djnoA11+ssCH/O/AlPj5HtyNxndKm9 +209sS4hU8Kwj3wGZBziDUns5XRR+34s0vePEeeo/I22KpYAFb/67QYAQpwCLx7QIJxZ SiLZWodzopP07R2jJQnHlssye9YH3WLOjiXFZMH91v7nv/kqvmNhEDgIpOSsE0nKL8ZR gw+Ut37KdU6Nl5WdGMszBJJAi0MKGXRVsmy7wT6eAtONb2K/7Vx6wGRgRRVapa7QchBK c1jw== X-Gm-Message-State: AOAM531sR9qRNRKJTw7RS9WECnPXXa87GNpTQBVpUPFL20AKxCNrsIQe bwu782isvEJ7zbczOSeWfUAB85nmlUN0f7w5V2YZVckD90fegA== X-Google-Smtp-Source: ABdhPJxSmfLGW/DUHRb5xL5ChIa4BMiiwBa+9EADecCH2dFm4XhDT0dz//jnRaGCjNOnSR6batKZdppEXgibo6yp1G8= X-Received: by 2002:a1f:5587:: with SMTP id j129mr321381vkb.0.1606949006734; Wed, 02 Dec 2020 14:43:26 -0800 (PST) MIME-Version: 1.0 References: <160049032442.20595.4616862102756589735@ietfa.amsl.com> <92029D16-621F-4AE0-BC3F-03C08AB21ADE@dericed.com> In-Reply-To: From: Barry Leiba Date: Wed, 2 Dec 2020 17:43:15 -0500 Message-ID: To: Dave Rice Cc: The IESG , Michael Richardson , draft-ietf-cellar-ffv1@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission , cellar-chairs@ietf.org, pb@das-werkstatt.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 02 Dec 2020 22:43:41 -0000 OK, Dave, here's where I am with 3.8.1.x: =E2=80=94 Section 3.8.1 =E2=80=94 CABAC was replaced by a Range coder based on an algorithm defined by G. Nigel N. Martin in 1979 [range-coding]. Keep in mind as you read my comments below that I=E2=80=99m not versed in t= his field at all, I am not familiar with Range coding, and can=E2=80=99t easily look up the reference. Ha=E2=80=A6 but after typing that, I just did: I fo= und it here: http://sachingarg.com/compression/entropy_coding/range_coder.pdf Maybe it would help to add that URI to the reference? Anyway, again, this isn=E2=80=99t my area, so it=E2=80=99s valid to say, for any of this b= elow, that someone actually implementing this would already understand these things. =E2=80=94 Section 3.8.1.1 =E2=80=94 To encode binary digits efficiently a Range coder is used. C_(i) is the i-th Context. B_(i) is the i-th byte of the bytestream. b_(i) is the i-th Range coded binary value, S_(0, i) is the i-th initial state. The length of the bytestream encoding n binary symbols is j_(n) bytes. Two things here: Editorial: I think it would be easier to read this as an item list (what do you think?): NEW To encode binary digits efficiently a Range coder is used. - C_(i) is the i-th Context - B_(i) is the i-th byte of the bytestream - b_(i) is the i-th Range coded binary value - S_(0, i) is the i-th initial state - j_(n) is the length of the bytestream encoding n binary symbols END Substantive: It would also help to add to that list L_(i), l_(i), R_(i), r_(i), and t_(i), so things are complete. Maybe also S_(x, i), where x is not 0. S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND l_(i) =3D L_(i) AND t_(i) =3D R_(i) - r_(i) <=3D=3D b_(i) =3D 0 <=3D=3D> L_(i) < R_(i) - r_(i) I still don=E2=80=99t understand how to read this. Perhaps explain verball= y what it=E2=80=99s supposed to mean, and I can help figure out some words to add that will help others? I don=E2=80=99t know what the =E2=80=9CAND=E2= =80=9D and =E2=80=9C<=3D=3D=E2=80=9C and =E2=80=9C<=3D=3D>=E2=80=9D on the right are trying to tell me (I get what = =E2=80=9CA <=3D=3D B=E2=80=9D means, but I don=E2=80=99t know how to interpret =E2=80=9C<=3D=3D=E2=80=9C at the = end of the line, for example). Do others who haven=E2=80=99t worked on this understand it? It=E2=80=99s q= uite possible that it=E2=80=99s just me, in which case I=E2=80=99ll happily step= aside. But I=E2=80=99m also happy to try to make it more understandable. S_(i + 1, k) =3D S_(i, k) <=3D=3D C_(i) !=3D k Figure 13: The "i+1,k"-th State is equal to the "i,k"-th State if the value of "k" is unequal to the i-th value of Context. The caption on this does help, so now I see what it=E2=80=99s getting at! = But I would *never* understand it without the caption. (1) The right-to-left conditional is odd to me. (2) I=E2=80=99m not used to that s= ort of conditional being used as an =E2=80=9Cif-then=E2=80=9D statement. I=E2= =80=99m curious why you didn=E2=80=99t write this whole section in pseudo-code, and perhaps it= =E2=80=99s another artifact of my wading into a field that=E2=80=99s foreign to me. H= ad Figure 13 been written like this, I would understand it perfectly: if ( C_(i) !=3D k ) then { S_(i + 1, k) =3D S_(i, k) } So, maybe tell me in pseudo-code what the example I quote further above is? R_(i + 1) =3D 2 ^ 8 * t_(i) AND L_(i + 1) =3D 2 ^ 8 * l_(i) + B_(j_(i)) AND j_(i + 1) =3D j_(i) + 1 <=3D=3D t_(i) < 2 ^ 8 R_(i + 1) =3D t_(i) AND L_(i + 1) =3D l_(i) AND j_(i + 1) =3D j_(i) <=3D=3D t_(i) >=3D 2 ^ 8 Is that trying to say this?: if ( t_(i) < 2 ^ 8 ) then { j_(i + 1) =3D j_(i) + 1; L_(i + 1) =3D 2 ^ 8 * l_(i) + B_(j_(i)); R_(i + 1) =3D 2 ^ 8 * t_(i); } else { j_(i + 1) =3D j_(i); L_(i + 1) =3D l_(i); R_(i + 1) =3D t_(i); } =E2=80=94 Section 3.8.1.2 =E2=80=94 "get_rac" returns a boolean, computed from the bytestream as described in Figure 11 as a formula and in Figure 20 as pseudo-code. Thanks for fixing this, and for the pseudo-code in Figure 20. I don=E2=80= =99t see a clear connection between the formula in Figure 11 and get_rac, so it still might be good to clarify that part. But this is no longer at DISCUSS level, so handle this as you think best. Barry On Wed, Dec 2, 2020 at 12:30 PM Barry Leiba wrote= : > > Thank you, Dave. I have checked everything other than the 3.8.1.x > subsections, and you've covered all my comments perfectly. I really > appreciate the clarifications, and thanks for addressing my nit-level > things as well. > > I'm reviewing 3.8.1.x now, but I wanted to give an intermediate status qu= ickly. > > Barry > > On Tue, Dec 1, 2020 at 4:17 PM Dave Rice wrote: > > > > Hi Barry, > > > > > On Oct 30, 2020, at 2:29 PM, Dave Rice wrote: > > > > > > Hi all, > > > > > > I=E2=80=99m writing this as an update to what aspects of this DISCUSS= are resolved and what may remain. I added a summary at the end, but the tl= ;dr is that in my opinion all discuss and comment points are resolved in ou= r git repository but Section 3.8.1.1 could use a new look in light of the d= iscuss comments against it. > > > > > >> On Sep 19, 2020, at 12:38 AM, Barry Leiba via Datatracker wrote: > > >> > > >> Barry Leiba has entered the following ballot position for > > >> draft-ietf-cellar-ffv1-17: Discuss > > >> > > >> When responding, please keep the subject line intact and reply to al= l > > >> email addresses included in the To and CC lines. (Feel free to cut t= his > > >> introductory paragraph, however.) > > >> > > >> > > >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria= .html > > >> for more information about IESG DISCUSS and COMMENT positions. > > >> > > >> > > >> The document, along with other ballot positions, can be found here: > > >> https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ > > >> > > >> > > >> > > >> --------------------------------------------------------------------= -- > > >> DISCUSS: > > >> --------------------------------------------------------------------= -- > > >> > > >> There are a number of things I=E2=80=99d like to discuss, because I = find them not > > >> understandable. Perhaps it=E2=80=99s simply because I=E2=80=99m not= a codec expert, but, while > > >> I understand that this is written for readers who will actually be i= mplementing > > >> he FFV1 codec, some of them will also not be =E2=80=9Cexperts=E2=80= =9D. That said, I=E2=80=99m sure > > >> some of this is just a case of =E2=80=9Cgive Barry some clue and it= =E2=80=99s fine.=E2=80=9D > > >> > > >> =E2=80=94 Section 2.1 =E2=80=94 > > >> You use the term =E2=80=9Csymbol=E2=80=9D here and later, without de= fining it, and I don=E2=80=99t know > > >> what it is. A byte? A character? A string of bits? What length? > > > > > > Symbol is defined in https://github.com/FFmpeg/FFV1/commit/baa92e69bb= db5cece9f99556267906beffcd0fd2 as: > > > > > > `Symbol`: A value stored in the bitstream, which is defined and= decoded through one of the methods described in [@tablePseudoCodeSymbols]. > > > > > >> =E2=80=94 Section 3.8.1.1 =E2=80=94 > > >> I=E2=80=99m not sure how to interpret the stuff in this section. Fi= rst, I don=E2=80=99t know > > >> why there are seven =E2=80=9Cfigures=E2=80=9D, with no captions nor = other explanation. Second, > > >> I=E2=80=99m having trouble making sense out of things like this: > > >> > > >> S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND > > >> l_(i) =3D L_(i) AND > > >> t_(i) =3D R_(i) - r_(i) <=3D=3D > > >> b_(i) =3D 0 <=3D=3D> > > >> L_(i) < R_(i) - r_(i) > > >> > > >> Can you explain how this is meant to be read? Maybe it=E2=80=99s ju= st me, and maybe > > >> after you explain it I=E2=80=99ll whack myself on the head and say, = =E2=80=9CDoh!=E2=80=9D > > > > > > Reading this would take correlation to Section 2.2.5 (Mathematical Fu= nctions) for definitions of <=3D=3D and <=3D=3D> and the form of a_(b) and = a_(b,c). > > > > > > To read this out-loud would be like: > > > > > > The i-th value of b equaling zero implies that the i-th value of L is= less than the result of i-th value of R minus the i-th value of r. The res= erve implication is also true. These implications both imply that the =E2= =80=98i+1,C_(i)' value of S equals the =E2=80=98S_(i, C_(i))=E2=80=99 of ze= ro_state as well as the i-th value of l equaling the i-th value of L as wel= l as the i-th value of t equaling the i-th value of R minus the i-th value = or r. > > > > > >> Third, you say, =E2=80=9CS_(0, i) is the i-th initial state,=E2=80= =9D but you haven=E2=80=99t > > >> previously introduced the term =E2=80=9Cstate=E2=80=9D, and I don=E2= =80=99t know what it means. > > > > > > Section 3.8 includes an informational reference to range coding. An u= nderstanding on how range coding works could make this section more clear. > > > > > > More captions were added to these figures in https://github.com/FFmpe= g/FFV1/commit/32cb9ea3e697036e81722f1ceced47f74b70549f and https://github.c= om/FFmpeg/FFV1/commit/ae3de36f528dbcef3fe5fdcc5b63bd5b06aefca0. > > > > > >> =E2=80=94 Section 3.8.1.2 =E2=80=94 > > >> > > >> "get_rac" returns a boolean, computed from the bytestream as > > >> described in Section 3.8.1.1. > > >> > > >> I see nothing in Section 3.8.1.1 that describes get_rac. > > > > > > We=E2=80=99ve added a definition https://github.com/FFmpeg/FFV1/commi= t/199ce1b95eb426e807ddbfd5d8338243d8458db1 and cross-references in https://= github.com/FFmpeg/FFV1/commit/ae3de36f528dbcef3fe5fdcc5b63bd5b06aefca0. > > > > > >> =E2=80=94 Section 3.8.1.3 =E2=80=94 > > >> > > >> At keyframes all Range coder state variables are set to their initi= al > > >> state. > > >> > > >> What does =E2=80=9Cat keyframes=E2=80=9D mean? > > > > > > It was presumed that =E2=80=98at keyframe=E2=80=99 meant a frame wher= e the keyframe value was set to 1. This is clarified in https://github.com/= FFmpeg/FFV1/commit/4b4d6f3c180fa2c4debefcc73793fc65ddd852c0. > > > > > >> =E2=80=94 Section 3.8.1.5 =E2=80=94 > > >> This is just a list of numbers with no explanation. It needs text e= xplaining > > >> what it means. > > > > > > An introduction to this table is added at https://github.com/FFmpeg/F= FV1/commit/69dda1b8a4f02bcce47b860df83a2f26afdca909 > > > > > > The introduction is: > > > In this mode a State Transition Table is used, indicating in which st= ate the decoder will move to, based on the current state and the value extr= acted from [@figureGetRacPseudoCode]. > > > > > >> =E2=80=94 Section 3.8.2.2 =E2=80=94 > > >> > > >> The level is identical to the predicted one. > > >> The run and the first different level are coded. > > >> > > >> What does =E2=80=9Clevel=E2=80=9D mean? It=E2=80=99s not defined an= ywhere. > > > > > > This was rewording to use the term =E2=80=9Csample difference=E2=80= =9D rather than level at https://github.com/FFmpeg/FFV1/commit/d6fbc97aa326= 99d5bafba9760e4f5093fcaa6120 and to cross-reference to the section that def= ines sample difference. > > > > > >> =E2=80=94 Section 4.3.1 =E2=80=94 > > >> > > >> "reserved_for_future_use" has semantics that are reserved for futur= e > > >> use. > > >> > > >> Yes, that seems rather obvious, though it=E2=80=99s oddly worded. B= ut then you say > > >> what to do with =E2=80=9Cthis value=E2=80=9D, and nowhere do you say= what the value is. How > > >> does one know? > > > > > > This was clarified in https://github.com/FFmpeg/FFV1/commit/e7f6b342a= e5e1c326357479bbbfb2934fe6d83f1. > > > > > >> --------------------------------------------------------------------= -- > > >> COMMENT: > > >> --------------------------------------------------------------------= -- > > >> > > >> Some editorial comments that I ask you to please consider: > > >> > > >> General: It=E2=80=99s jarring to see the defined terms, such as =E2= =80=9CSample=E2=80=9D and =E2=80=9CPixel=E2=80=9D in > > >> quotes every time they=E2=80=99re used. More common practice is to = quote them when > > >> they=E2=80=99re first defined, and then to just use the capitalizati= on to show that > > >> they=E2=80=99re defined terms. I find that the quotes affect the re= adability and make > > >> it somewhat more of a challenge to read. > > > > > > We agreed. These excessive quotes were removed in https://github.com/= FFmpeg/FFV1/commit/f0eb24b7820889fbd93b68d1e707d4380a90ded1. > > > > > >> =E2=80=94 Section 2.1 =E2=80=94 > > >> > > >> "Plane": A discrete component of a static image comprised of > > >> > > >> Total, total nit, and pet peeve: =E2=80=9Ccomposed of=E2=80=9D or = =E2=80=9Ccomprising=E2=80=9D, but not > > >> =E2=80=9Ccomprised of=E2=80=9D. > > > > > > Fixed as suggested in https://github.com/FFmpeg/FFV1/commit/fe219d9b2= afff5583b40ea597918b5633d1188ea. > > > > > >> =E2=80=94 Section 2.2.2 =E2=80=94 > > >> You=E2=80=99re missing =E2=80=9Ca % b=E2=80=9D, which is referenced = in Section 2.2.6. > > > > > > Nice catch. We removed this in https://github.com/FFmpeg/FFV1/commit/= 34ec93cdacef056c6cb53ca3120d5a021acfb911 as it is unused in the document. > > > > > >> =E2=80=94 Section 2.2.4 =E2=80=94 > > >> > > >> "a > b" means a is greater than b. > > >> "a >=3D b" means a is greater than or equal to b. > > >> "a < b" means a is less than b. > > >> "a <=3D b" means a is less than or equal b. > > >> "a =3D=3D b" means a is equal to b. > > >> "a !=3D b" means a is not equal to b. > > >> > > >> I don=E2=80=99t think anyone will misunderstand this, so it=E2=80=99= s a very small thing, but=E2=80=A6 > > >> might this be better said as, =E2=80=98 "a > b" is true when a is gr= eater than b. =E2=80=98 > > >> (and similarly for the rest)? > > > > > > Reworded as suggested in https://github.com/FFmpeg/FFV1/commit/6ef98d= c138d34966cc686f64d1f4224202e6b263. > > > > > >> =E2=80=94 Section 2.2.5 =E2=80=94 > > >> > > >> "min(a,b)" means the smallest of two values a and b. > > >> "max(a,b)" means the largest of two values a and b. > > >> > > >> Nit: =E2=80=9Csmaller=E2=80=9D and =E2=80=9Clarger=E2=80=9D, for onl= y two. > > > > > > Fixed as suggested in https://github.com/FFmpeg/FFV1/commit/fe219d9b2= afff5583b40ea597918b5633d1188ea. > > > > > >> =E2=80=94 Section 2.2.7 =E2=80=94 > > >> > > >> "a...b" means any value starting from a to b, inclusive. > > >> > > >> =E2=80=9Cstarting=E2=80=9D? I would leave that word out. > > > > > > Fixed as suggested in https://github.com/FFmpeg/FFV1/commit/fe219d9b2= afff5583b40ea597918b5633d1188ea. > > > > > >> =E2=80=94 Section 2.2.9.1 =E2=80=94 > > >> > > >> "remaining_bits_in_bitstream( )" means the count of remaining bits > > >> > > >> Section 2.2.9.3 uses remaining_bits_in_bitstream( NumBytes ), as do = Sections > > >> 4.4 and 4.5. This should too, yes? > > > > > > Yes. Fixed in https://github.com/FFmpeg/FFV1/commit/5685a9e8c35ce5ca8= 420b97cbb336aad8fa5ad0c and https://github.com/FFmpeg/FFV1/commit/5056a894d= 16c517a63aaa4925f8ca1a91803f205. > > > > > >> =E2=80=94 Section 3.2 =E2=80=94 > > >> > > >> Figure 3: A depiction of how relatively positions Samples are > > >> references within this document. > > >> > > >> I think you mean =E2=80=9Cpositioned=E2=80=9D and =E2=80=9Creference= d=E2=80=9D, yes? > > > > > > Yes. Fixed in https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583= b40ea597918b5633d1188ea. > > > > > >> =E2=80=94 Section 3.3 =E2=80=94 > > >> > > >> Background: a two's complement signed 16-bit signed integer was use= d > > >> > > >> I=E2=80=99d remove the first =E2=80=9Csigned=E2=80=9D. > > > > > > Fixed in https://github.com/FFmpeg/FFV1/commit/55c200e145ed9067459d31= 910d3eda5921097098. > > > > > >> =E2=80=94 Section 3.8.2 =E2=80=94 > > >> > > >> The end of the bitstream of the "Frame" is filled with 0-bits until > > >> that the bitstream contains a multiple of 8 bits. > > >> > > >> Is =E2=80=9Cthat=E2=80=9D just an extra word that needs to be struck= , or is something else > > >> wrong here? And is this meant to be what we usually call =E2=80=9Cp= adding=E2=80=9D? > > > > > > Fixed in https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea= 597918b5633d1188ea. > > > > > >> =E2=80=94 Section 4 =E2=80=94 > > >> > > >> Within the following sub-sections, pseudo-code is used to explain t= he > > >> structure of each FFV1 bitstream component, as described in > > >> Section 2.2.1. > > >> > > >> I read this as saying that Section 2.2.1 describes the structure of = each FFV1 > > >> bitstream component, until I went back there and looked. I suggest = reordering > > >> the sentence to help the reader a bit: > > >> > > >> NEW > > >> Within the following sub-sections, pseudo-code is used, as describe= d > > >> in Section 2.2.1, to explain the structure of each FFV1 bitstream > > >> component. > > >> END > > > > > > The suggested was taken and used in https://github.com/FFmpeg/FFV1/co= mmit/ab5a5c944d518ad72a982118b3c90b99a78d5d7c. > > > > > >> =E2=80=94 Section 4.5 =E2=80=94 > > >> > > >> Encoders SHOULD NOT fill these bits. > > >> Decoders SHOULD ignore these bits. > > >> > > >> Before this you describe two kinds of bits, and it=E2=80=99s not cle= ar whether these > > >> are talking about both kinds, or just the latter. I think changing = =E2=80=9Cthese=E2=80=9D to > > >> =E2=80=9Creserved=E2=80=9D is better. > > > > > > Adjusted in https://github.com/FFmpeg/FFV1/commit/12bfc977f5f868404b6= 9f434501f011a850ee9c0. > > > > > >> =E2=80=94 Section 6 =E2=80=94 > > >> > > >> A frequent security problem in image > > >> and video codecs is also to not check for integer overflows, for > > >> example to allocate "frame_pixel_width * frame_pixel_height" in > > >> "Pixel" count computations without considering that the > > >> multiplication result may have overflowed the arithmetic types rang= e. > > >> > > >> This is somewhat complex and awkward (arguably a comma splice), and = I suggest > > >> splitting the sentence thus: > > >> > > >> NEW > > >> A frequent security problem in image > > >> and video codecs is failure to check for integer overflows. An > > >> example is allocating "frame_pixel_width * frame_pixel_height" in > > >> "Pixel" count computations without considering that the > > >> multiplication result may have overflowed the arithmetic types rang= e. > > >> END > > > > > > Fixed in https://github.com/FFmpeg/FFV1/commit/741f67b405b2bfbe683a2a= 3d9dc83468bca960cf. > > > > > >> I might also make the =E2=80=9Cmust=E2=80=9D in the last sentence of= that paragraph be =E2=80=9CMUST=E2=80=9D. > > > > > > Fixed in https://github.com/FFmpeg/FFV1/commit/50d9e14ad889cc833d65a9= 05a01637ea8b526a45. > > > > > > summary: > > > > > > In my opinion, all discuss and comments listed in this review have be= en resolved with the exception of the status of comments on Section 3.8.1.1= being less clear. I=E2=80=99m pasting in the current state of Section 3.8.= 1.1 for consideration: > > > > > >> 3.8.1.1. Range Binary Values > > >> > > >> To encode binary digits efficiently a Range coder is used. C_(i) = is > > >> the i-th Context. B_(i) is the i-th byte of the bytestream. b_(i)= is > > >> the i-th Range coded binary value, S_(0, i) is the i-th initial > > >> state. The length of the bytestream encoding n binary symbols is > > >> j_(n) bytes. > > >> > > >> r_(i) =3D floor( ( R_(i) * S_(i, C_(i)) ) / 2 ^ 8 ) > > >> > > >> Figure 11: A formula of the read of a binary value in Range > > >> Binary mode. > > >> > > >> S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND > > >> l_(i) =3D L_(i) AND > > >> t_(i) =3D R_(i) - r_(i) <=3D=3D > > >> b_(i) =3D 0 <=3D=3D> > > >> L_(i) < R_(i) - r_(i) > > >> > > >> S_(i + 1, C_(i)) =3D one_state_(S_(i, C_(i))) AND > > >> l_(i) =3D L_(i) - R_(i) + r_(i) AND > > >> t_(i) =3D r_(i) <=3D=3D > > >> b_(i) =3D 1 <=3D=3D> > > >> L_(i) >=3D R_(i) - r_(i) > > >> > > >> Figure 12 > > >> > > >> S_(i + 1, k) =3D S_(i, k) <=3D=3D C_(i) !=3D k > > >> > > >> Figure 13: The "i+1,k"-th State is equal to the "i,k"-th State i= f > > >> the value of "k" is unequal to the i-th value of Context. > > >> > > >> R_(i + 1) =3D 2 ^ 8 * t_(i) AND > > >> L_(i + 1) =3D 2 ^ 8 * l_(i) + B_(j_(i)) AND > > >> j_(i + 1) =3D j_(i) + 1 <=3D=3D > > >> t_(i) < 2 ^ 8 > > >> > > >> R_(i + 1) =3D t_(i) AND > > >> L_(i + 1) =3D l_(i) AND > > >> j_(i + 1) =3D j_(i) <=3D=3D > > >> t_(i) >=3D 2 ^ 8 > > >> > > >> Figure 14: The "i+1"-th values for "Range", "Low", and the lengt= h > > >> of the bytestream encoding are conditionally set depending on th= e > > >> "i-th" value of "t". > > >> > > >> R_(0) =3D 65280 > > >> > > >> Figure 15: The initial value for "Range". > > >> > > >> L_(0) =3D 2 ^ 8 * B_(0) + B_(1) > > >> > > >> Figure 16: The initial value for "Low" is set according to the > > >> first two bytes of the bytestream. > > >> > > >> j_(0) =3D 2 > > >> > > >> Figure 17: The initial value for "j", the length of the > > >> bytestream encoding. > > >> > > >> range =3D 0xFF00; > > >> end =3D 0; > > >> low =3D get_bits(16); > > >> if (low >=3D range) { > > >> low =3D range; > > >> end =3D 1; > > >> } > > >> > > >> Figure 18: A pseudo-code description of the initial states in > > >> Range Binary mode. > > >> > > >> refill() { > > >> if (range < 256) { > > >> range =3D range * 256; > > >> low =3D low * 256; > > >> if (!end) { > > >> c.low +=3D get_bits(8); > > >> if (remaining_bits_in_bitstream( NumBytes ) =3D=3D 0) = { > > >> end =3D 1; > > >> } > > >> } > > >> } > > >> } > > >> > > >> Figure 19: A pseudo-code description of refilling the Range > > >> Binary Value coder buffer. > > >> > > >> get_rac(state) { > > >> rangeoff =3D (range * state) / 256; > > >> range -=3D rangeoff; > > >> if (low < range) { > > >> state =3D zero_state[state]; > > >> refill(); > > >> return 0; > > >> } else { > > >> low -=3D range; > > >> state =3D one_state[state]; > > >> range =3D rangeoff; > > >> refill(); > > >> return 1; > > >> } > > >> } > > >> > > >> Figure 20: A pseudo-code description of the read of a binary > > >> value in Range Binary mode. > > > > Please note that we just updated the draft to include the recommended c= hanges, which can be reviewed in version 19 of https://datatracker.ietf.org= /doc/draft-ietf-cellar-ffv1/. Here=E2=80=99s a link to the diff of version = 18 and 19: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-cellar-ffv1-18&ur= l2=3Ddraft-ietf-cellar-ffv1-19&difftype=3D--html. > > > > To repeat a comment above: In my opinion, all discuss and comments list= ed in this review have been resolved with the exception of the status of co= mments on Section 3.8.1.1 being less clear but since a lot of work has been= done here, we could use a new review of this section within the new versio= n. > > > > Kind Regards, > > Dave Rice > > From nobody Thu Dec 3 15:47:04 2020 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 8D1923A08B0; Thu, 3 Dec 2020 15:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xRubm8j9ZB81; Thu, 3 Dec 2020 15:47:00 -0800 (PST) Received: from server172-4.web-hosting.com (server172-4.web-hosting.com [68.65.122.112]) (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 6DD493A07AE; Thu, 3 Dec 2020 15:46:58 -0800 (PST) Received: from pool-100-37-115-144.nycmny.fios.verizon.net ([100.37.115.144]:60156 helo=[192.168.1.152]) by server172.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kkyJG-003LEd-En; Thu, 03 Dec 2020 18:46:57 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Dave Rice In-Reply-To: Date: Thu, 3 Dec 2020 18:46:48 -0500 Cc: cellar-chairs@ietf.org, derek.buitenhuis@gmail.com, Michael Richardson , pb@das-werkstatt.com, draft-ietf-cellar-ffv1@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission , The IESG Content-Transfer-Encoding: quoted-printable Message-Id: <3BDF43E9-1245-40D0-B589-7ABFC14C8823@dericed.com> References: <160049032442.20595.4616862102756589735@ietfa.amsl.com> <92029D16-621F-4AE0-BC3F-03C08AB21ADE@dericed.com> To: Barry Leiba X-Mailer: Apple Mail (2.3608.120.23.2.4) X-OutGoing-Spam-Status: No, score=0.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] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 03 Dec 2020 23:47:04 -0000 Hi Barry, Thanks so much for your comments. > On Dec 2, 2020, at 5:43 PM, Barry Leiba = wrote: >=20 > OK, Dave, here's where I am with 3.8.1.x: >=20 > =E2=80=94 Section 3.8.1 =E2=80=94 >=20 > CABAC was replaced by a Range coder based on an algorithm defined by > G. Nigel N. Martin in 1979 [range-coding]. >=20 > Keep in mind as you read my comments below that I=E2=80=99m not versed = in this > field at all, I am not familiar with Range coding, and can=E2=80=99t = easily > look up the reference. Ha=E2=80=A6 but after typing that, I just did: = I found > it here: > http://sachingarg.com/compression/entropy_coding/range_coder.pdf >=20 > Maybe it would help to add that URI to the reference? Anyway, again, > this isn=E2=80=99t my area, so it=E2=80=99s valid to say, for any of = this below, that > someone actually implementing this would already understand these > things. We had some discussion on this at = https://github.com/FFmpeg/FFV1/pull/219 and considered adding a = reference to http://www.compressconsult.com/rangecoder/#literature or = https://web.archive.org/web/*/http://www.compressconsult.com/rangecoder/#l= iterature. A reason against is that these are unofficial sources of this = knowledge and thus perhaps not ideal to use for the citation. I did just check to see if other RFCs cite this and found that RFC6716 = cites = http://en.wikipedia.org/w/index.php?title=3DRange_encoding&oldid=3D5095827= 57 as an informative reference. For IETF is there a preference for which of these citations if any to = use? > =E2=80=94 Section 3.8.1.1 =E2=80=94 >=20 > To encode binary digits efficiently a Range coder is used. C_(i) is > the i-th Context. B_(i) is the i-th byte of the bytestream. b_(i) = is > the i-th Range coded binary value, S_(0, i) is the i-th initial > state. The length of the bytestream encoding n binary symbols is > j_(n) bytes. >=20 > Two things here: >=20 > Editorial: I think it would be easier to read this as an item list > (what do you think?): >=20 > NEW > To encode binary digits efficiently a Range coder is used. > - C_(i) is the i-th Context > - B_(i) is the i-th byte of the bytestream > - b_(i) is the i-th Range coded binary value > - S_(0, i) is the i-th initial state > - j_(n) is the length of the bytestream encoding n binary symbols > END Locally, I=E2=80=99ve tested converting this into a definition list per = https://tools.ietf.org/html/rfc7991#section-2.20, which rendered in the = text output as: C_(i) the i-th Context. B_(i) the i-th byte of the bytestream. b_(i) the i-th Range coded binary value. S_(0, i) the i-th initial State. j_(n) the length of the bytestream encoding n binary symbols. > Substantive: It would also help to add to that list L_(i), l_(i), > R_(i), r_(i), and t_(i), so things are complete. Maybe also S_(x, i), > where x is not 0. Nudging Michael Niedermayer and Derek Buitenhuis on this for help. Some = guess work but if I understand correctly. L_(i) is the Low value of the Range l_(i) is a temporary storage variable used in assigning values to L_(i) R_(i) is the Range value r_(i) is a temporary storage variable used in assigning values to R_(i) t_(i) is a temporary storage variable used in assigning values to R_(i) S_(x, i) is the =E2=80=98x, 1=E2=80=99-th State. > S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND > l_(i) =3D L_(i) AND > t_(i) =3D R_(i) - r_(i) <=3D=3D > b_(i) =3D 0 <=3D=3D> > L_(i) < R_(i) - r_(i) >=20 > I still don=E2=80=99t understand how to read this. I should note that these equation appear a bit differently in the HTML = version of the draft where they are depicted in SVG images of LaTeX = equations. In the SVG, the equation all exists on one line; however, in = the plain text output it doesn=E2=80=99t fit in the line width so we = wrap the output a bit for cosmetics. If more clear we could re-arrange = the line breaks, such as: ( S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND l_(i) =3D L_(i) AND t_(i) =3D R_(i) - r_(i) ) <=3D=3D ( b_(i) =3D 0 ) <=3D=3D> ( L_(i) < R_(i) - r_(i) ) > Perhaps explain verbally > what it=E2=80=99s supposed to mean, and I can help figure out some = words to > add that will help others? b_(i) =3D 0 and L_(i) < R_(i) - r_(i) would imply each other as well as = implies the other group of three assignments. > I don=E2=80=99t know what the =E2=80=9CAND=E2=80=9D and =E2=80=9C<=3D=3D= =E2=80=9C and > =E2=80=9C<=3D=3D>=E2=80=9D on the right are trying to tell me (I get = what =E2=80=9CA <=3D=3D B=E2=80=9D means, > but I don=E2=80=99t know how to interpret =E2=80=9C<=3D=3D=E2=80=9C at = the end of the line, for > example). It is only a line break, if not for the line width limitation this would = be: S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND l_(i) =3D L_(i) AND = t_(i) =3D R_(i) - r_(i) <=3D=3D b_(i) =3D 0 <=3D=3D> L_(i) < R_(i) - = r_(i) which is closer to how it looks in the SVG HTML version. > Do others who haven=E2=80=99t worked on this understand it? It=E2=80=99= s quite > possible that it=E2=80=99s just me, in which case I=E2=80=99ll happily = step aside. > But I=E2=80=99m also happy to try to make it more understandable. Yes, please more understandability. :) > S_(i + 1, k) =3D S_(i, k) <=3D=3D C_(i) !=3D k >=20 > Figure 13: The "i+1,k"-th State is equal to the "i,k"-th State if > the value of "k" is unequal to the i-th value of Context. >=20 > The caption on this does help, so now I see what it=E2=80=99s getting = at! But > I would *never* understand it without the caption. (1) The > right-to-left conditional is odd to me. (2) I=E2=80=99m not used to = that sort > of conditional being used as an =E2=80=9Cif-then=E2=80=9D statement. = I=E2=80=99m curious why > you didn=E2=80=99t write this whole section in pseudo-code, and = perhaps it=E2=80=99s > another artifact of my wading into a field that=E2=80=99s foreign to = me. Had > Figure 13 been written like this, I would understand it perfectly: >=20 > if ( C_(i) !=3D k ) then { S_(i + 1, k) =3D S_(i, k) } Yes, in pseudo-code that is the same. Michael Niedermayer, any objection to converting some of the math to = pseudocode? > So, maybe tell me in pseudo-code what the example I quote further = above is? >=20 > R_(i + 1) =3D 2 ^ 8 * t_(i) AND > L_(i + 1) =3D 2 ^ 8 * l_(i) + B_(j_(i)) AND > j_(i + 1) =3D j_(i) + 1 <=3D=3D > t_(i) < 2 ^ 8 >=20 > R_(i + 1) =3D t_(i) AND > L_(i + 1) =3D l_(i) AND > j_(i + 1) =3D j_(i) <=3D=3D > t_(i) >=3D 2 ^ 8 >=20 > Is that trying to say this?: >=20 > if ( t_(i) < 2 ^ 8 ) then { > j_(i + 1) =3D j_(i) + 1; > L_(i + 1) =3D 2 ^ 8 * l_(i) + B_(j_(i)); > R_(i + 1) =3D 2 ^ 8 * t_(i); > } else { > j_(i + 1) =3D j_(i); > L_(i + 1) =3D l_(i); > R_(i + 1) =3D t_(i); > } Looks right to me. Though I=E2=80=99m not sure how to do this with: S_(i + 1, C_(i)) =3D one_state_(S_(i, C_(i))) AND l_(i) =3D L_(i) - R_(i) + r_(i) AND t_(i) =3D r_(i) <=3D=3D b_(i) =3D 1 <=3D=3D> L_(i) >=3D R_(i) - r_(i) As if would be like: if ( L_(i) >=3D R_(i) - r_(i) ) then { b_(i) =3D 1; t_(i) =3D r_(i); l_(i) =3D L_(i) - R_(i) + r_(i); S_(i + 1, C_(i)) =3D one_state_(S_(i, C_(i))); } else if ( b_(i) =3D 1 ) then { L_(i) >=3D R_(i) - r_(i) t_(i) =3D r_(i); l_(i) =3D L_(i) - R_(i) + r_(i); S_(i + 1, C_(i)) =3D one_state_(S_(i, C_(i))); } Or is there a pseudo-code equivalent of <=3D=3D> that I=E2=80=99m not = thinking of? > =E2=80=94 Section 3.8.1.2 =E2=80=94 >=20 > "get_rac" returns a boolean, computed from the bytestream as > described in Figure 11 as a formula and in Figure 20 as pseudo-code. >=20 > Thanks for fixing this, and for the pseudo-code in Figure 20. I = don=E2=80=99t > see a clear connection between the formula in Figure 11 and get_rac, > so it still might be good to clarify that part. But this is no longer > at DISCUSS level, so handle this as you think best. IIRC, the equation of Figure 11 is the same as the psuedo-code in Figure = 20 is the process of the get_rac function. Nudging, Michael Niedermayer and Jerome Martinez for comment or = verification. Dave Rice > Barry >=20 > On Wed, Dec 2, 2020 at 12:30 PM Barry Leiba = wrote: >>=20 >> Thank you, Dave. I have checked everything other than the 3.8.1.x >> subsections, and you've covered all my comments perfectly. I really >> appreciate the clarifications, and thanks for addressing my nit-level >> things as well. >>=20 >> I'm reviewing 3.8.1.x now, but I wanted to give an intermediate = status quickly. >>=20 >> Barry >>=20 >> On Tue, Dec 1, 2020 at 4:17 PM Dave Rice wrote: >>>=20 >>> Hi Barry, >>>=20 >>>> On Oct 30, 2020, at 2:29 PM, Dave Rice wrote: >>>>=20 >>>> Hi all, >>>>=20 >>>> I=E2=80=99m writing this as an update to what aspects of this = DISCUSS are resolved and what may remain. I added a summary at the end, = but the tl;dr is that in my opinion all discuss and comment points are = resolved in our git repository but Section 3.8.1.1 could use a new look = in light of the discuss comments against it. >>>>=20 >>>>> On Sep 19, 2020, at 12:38 AM, Barry Leiba via Datatracker = wrote: >>>>>=20 >>>>> Barry Leiba has entered the following ballot position for >>>>> draft-ietf-cellar-ffv1-17: Discuss >>>>>=20 >>>>> When responding, please keep the subject line intact and reply to = all >>>>> email addresses included in the To and CC lines. (Feel free to cut = this >>>>> introductory paragraph, however.) >>>>>=20 >>>>>=20 >>>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>>> for more information about IESG DISCUSS and COMMENT positions. >>>>>=20 >>>>>=20 >>>>> The document, along with other ballot positions, can be found = here: >>>>> https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ >>>>>=20 >>>>>=20 >>>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> DISCUSS: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> There are a number of things I=E2=80=99d like to discuss, because = I find them not >>>>> understandable. Perhaps it=E2=80=99s simply because I=E2=80=99m = not a codec expert, but, while >>>>> I understand that this is written for readers who will actually be = implementing >>>>> he FFV1 codec, some of them will also not be =E2=80=9Cexperts=E2=80=9D= . That said, I=E2=80=99m sure >>>>> some of this is just a case of =E2=80=9Cgive Barry some clue and = it=E2=80=99s fine.=E2=80=9D >>>>>=20 >>>>> =E2=80=94 Section 2.1 =E2=80=94 >>>>> You use the term =E2=80=9Csymbol=E2=80=9D here and later, without = defining it, and I don=E2=80=99t know >>>>> what it is. A byte? A character? A string of bits? What = length? >>>>=20 >>>> Symbol is defined in = https://github.com/FFmpeg/FFV1/commit/baa92e69bbdb5cece9f99556267906beffcd= 0fd2 as: >>>>=20 >>>> `Symbol`: A value stored in the bitstream, which is defined = and decoded through one of the methods described in = [@tablePseudoCodeSymbols]. >>>>=20 >>>>> =E2=80=94 Section 3.8.1.1 =E2=80=94 >>>>> I=E2=80=99m not sure how to interpret the stuff in this section. = First, I don=E2=80=99t know >>>>> why there are seven =E2=80=9Cfigures=E2=80=9D, with no captions = nor other explanation. Second, >>>>> I=E2=80=99m having trouble making sense out of things like this: >>>>>=20 >>>>> S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND >>>>> l_(i) =3D L_(i) AND >>>>> t_(i) =3D R_(i) - r_(i) <=3D=3D >>>>> b_(i) =3D 0 <=3D=3D> >>>>> L_(i) < R_(i) - r_(i) >>>>>=20 >>>>> Can you explain how this is meant to be read? Maybe it=E2=80=99s = just me, and maybe >>>>> after you explain it I=E2=80=99ll whack myself on the head and = say, =E2=80=9CDoh!=E2=80=9D >>>>=20 >>>> Reading this would take correlation to Section 2.2.5 (Mathematical = Functions) for definitions of <=3D=3D and <=3D=3D> and the form of a_(b) = and a_(b,c). >>>>=20 >>>> To read this out-loud would be like: >>>>=20 >>>> The i-th value of b equaling zero implies that the i-th value of L = is less than the result of i-th value of R minus the i-th value of r. = The reserve implication is also true. These implications both imply that = the =E2=80=98i+1,C_(i)' value of S equals the =E2=80=98S_(i, C_(i))=E2=80=99= of zero_state as well as the i-th value of l equaling the i-th value of = L as well as the i-th value of t equaling the i-th value of R minus the = i-th value or r. >>>>=20 >>>>> Third, you say, =E2=80=9CS_(0, i) is the i-th initial state,=E2=80=9D= but you haven=E2=80=99t >>>>> previously introduced the term =E2=80=9Cstate=E2=80=9D, and I = don=E2=80=99t know what it means. >>>>=20 >>>> Section 3.8 includes an informational reference to range coding. An = understanding on how range coding works could make this section more = clear. >>>>=20 >>>> More captions were added to these figures in = https://github.com/FFmpeg/FFV1/commit/32cb9ea3e697036e81722f1ceced47f74b70= 549f and = https://github.com/FFmpeg/FFV1/commit/ae3de36f528dbcef3fe5fdcc5b63bd5b06ae= fca0. >>>>=20 >>>>> =E2=80=94 Section 3.8.1.2 =E2=80=94 >>>>>=20 >>>>> "get_rac" returns a boolean, computed from the bytestream as >>>>> described in Section 3.8.1.1. >>>>>=20 >>>>> I see nothing in Section 3.8.1.1 that describes get_rac. >>>>=20 >>>> We=E2=80=99ve added a definition = https://github.com/FFmpeg/FFV1/commit/199ce1b95eb426e807ddbfd5d8338243d845= 8db1 and cross-references in = https://github.com/FFmpeg/FFV1/commit/ae3de36f528dbcef3fe5fdcc5b63bd5b06ae= fca0. >>>>=20 >>>>> =E2=80=94 Section 3.8.1.3 =E2=80=94 >>>>>=20 >>>>> At keyframes all Range coder state variables are set to their = initial >>>>> state. >>>>>=20 >>>>> What does =E2=80=9Cat keyframes=E2=80=9D mean? >>>>=20 >>>> It was presumed that =E2=80=98at keyframe=E2=80=99 meant a frame = where the keyframe value was set to 1. This is clarified in = https://github.com/FFmpeg/FFV1/commit/4b4d6f3c180fa2c4debefcc73793fc65ddd8= 52c0. >>>>=20 >>>>> =E2=80=94 Section 3.8.1.5 =E2=80=94 >>>>> This is just a list of numbers with no explanation. It needs text = explaining >>>>> what it means. >>>>=20 >>>> An introduction to this table is added at = https://github.com/FFmpeg/FFV1/commit/69dda1b8a4f02bcce47b860df83a2f26afdc= a909 >>>>=20 >>>> The introduction is: >>>> In this mode a State Transition Table is used, indicating in which = state the decoder will move to, based on the current state and the value = extracted from [@figureGetRacPseudoCode]. >>>>=20 >>>>> =E2=80=94 Section 3.8.2.2 =E2=80=94 >>>>>=20 >>>>> The level is identical to the predicted one. >>>>> The run and the first different level are coded. >>>>>=20 >>>>> What does =E2=80=9Clevel=E2=80=9D mean? It=E2=80=99s not defined = anywhere. >>>>=20 >>>> This was rewording to use the term =E2=80=9Csample difference=E2=80=9D= rather than level at = https://github.com/FFmpeg/FFV1/commit/d6fbc97aa32699d5bafba9760e4f5093fcaa= 6120 and to cross-reference to the section that defines sample = difference. >>>>=20 >>>>> =E2=80=94 Section 4.3.1 =E2=80=94 >>>>>=20 >>>>> "reserved_for_future_use" has semantics that are reserved for = future >>>>> use. >>>>>=20 >>>>> Yes, that seems rather obvious, though it=E2=80=99s oddly worded. = But then you say >>>>> what to do with =E2=80=9Cthis value=E2=80=9D, and nowhere do you = say what the value is. How >>>>> does one know? >>>>=20 >>>> This was clarified in = https://github.com/FFmpeg/FFV1/commit/e7f6b342ae5e1c326357479bbbfb2934fe6d= 83f1. >>>>=20 >>>>> = ---------------------------------------------------------------------- >>>>> COMMENT: >>>>> = ---------------------------------------------------------------------- >>>>>=20 >>>>> Some editorial comments that I ask you to please consider: >>>>>=20 >>>>> General: It=E2=80=99s jarring to see the defined terms, such as = =E2=80=9CSample=E2=80=9D and =E2=80=9CPixel=E2=80=9D in >>>>> quotes every time they=E2=80=99re used. More common practice is = to quote them when >>>>> they=E2=80=99re first defined, and then to just use the = capitalization to show that >>>>> they=E2=80=99re defined terms. I find that the quotes affect the = readability and make >>>>> it somewhat more of a challenge to read. >>>>=20 >>>> We agreed. These excessive quotes were removed in = https://github.com/FFmpeg/FFV1/commit/f0eb24b7820889fbd93b68d1e707d4380a90= ded1. >>>>=20 >>>>> =E2=80=94 Section 2.1 =E2=80=94 >>>>>=20 >>>>> "Plane": A discrete component of a static image comprised of >>>>>=20 >>>>> Total, total nit, and pet peeve: =E2=80=9Ccomposed of=E2=80=9D or = =E2=80=9Ccomprising=E2=80=9D, but not >>>>> =E2=80=9Ccomprised of=E2=80=9D. >>>>=20 >>>> Fixed as suggested in = https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea597918b5633d11= 88ea. >>>>=20 >>>>> =E2=80=94 Section 2.2.2 =E2=80=94 >>>>> You=E2=80=99re missing =E2=80=9Ca % b=E2=80=9D, which is = referenced in Section 2.2.6. >>>>=20 >>>> Nice catch. We removed this in = https://github.com/FFmpeg/FFV1/commit/34ec93cdacef056c6cb53ca3120d5a021acf= b911 as it is unused in the document. >>>>=20 >>>>> =E2=80=94 Section 2.2.4 =E2=80=94 >>>>>=20 >>>>> "a > b" means a is greater than b. >>>>> "a >=3D b" means a is greater than or equal to b. >>>>> "a < b" means a is less than b. >>>>> "a <=3D b" means a is less than or equal b. >>>>> "a =3D=3D b" means a is equal to b. >>>>> "a !=3D b" means a is not equal to b. >>>>>=20 >>>>> I don=E2=80=99t think anyone will misunderstand this, so it=E2=80=99= s a very small thing, but=E2=80=A6 >>>>> might this be better said as, =E2=80=98 "a > b" is true when a is = greater than b. =E2=80=98 >>>>> (and similarly for the rest)? >>>>=20 >>>> Reworded as suggested in = https://github.com/FFmpeg/FFV1/commit/6ef98dc138d34966cc686f64d1f4224202e6= b263. >>>>=20 >>>>> =E2=80=94 Section 2.2.5 =E2=80=94 >>>>>=20 >>>>> "min(a,b)" means the smallest of two values a and b. >>>>> "max(a,b)" means the largest of two values a and b. >>>>>=20 >>>>> Nit: =E2=80=9Csmaller=E2=80=9D and =E2=80=9Clarger=E2=80=9D, for = only two. >>>>=20 >>>> Fixed as suggested in = https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea597918b5633d11= 88ea. >>>>=20 >>>>> =E2=80=94 Section 2.2.7 =E2=80=94 >>>>>=20 >>>>> "a...b" means any value starting from a to b, inclusive. >>>>>=20 >>>>> =E2=80=9Cstarting=E2=80=9D? I would leave that word out. >>>>=20 >>>> Fixed as suggested in = https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea597918b5633d11= 88ea. >>>>=20 >>>>> =E2=80=94 Section 2.2.9.1 =E2=80=94 >>>>>=20 >>>>> "remaining_bits_in_bitstream( )" means the count of remaining bits >>>>>=20 >>>>> Section 2.2.9.3 uses remaining_bits_in_bitstream( NumBytes ), as = do Sections >>>>> 4.4 and 4.5. This should too, yes? >>>>=20 >>>> Yes. Fixed in = https://github.com/FFmpeg/FFV1/commit/5685a9e8c35ce5ca8420b97cbb336aad8fa5= ad0c and = https://github.com/FFmpeg/FFV1/commit/5056a894d16c517a63aaa4925f8ca1a91803= f205. >>>>=20 >>>>> =E2=80=94 Section 3.2 =E2=80=94 >>>>>=20 >>>>> Figure 3: A depiction of how relatively positions Samples are >>>>> references within this document. >>>>>=20 >>>>> I think you mean =E2=80=9Cpositioned=E2=80=9D and = =E2=80=9Creferenced=E2=80=9D, yes? >>>>=20 >>>> Yes. Fixed in = https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea597918b5633d11= 88ea. >>>>=20 >>>>> =E2=80=94 Section 3.3 =E2=80=94 >>>>>=20 >>>>> Background: a two's complement signed 16-bit signed integer was = used >>>>>=20 >>>>> I=E2=80=99d remove the first =E2=80=9Csigned=E2=80=9D. >>>>=20 >>>> Fixed in = https://github.com/FFmpeg/FFV1/commit/55c200e145ed9067459d31910d3eda592109= 7098. >>>>=20 >>>>> =E2=80=94 Section 3.8.2 =E2=80=94 >>>>>=20 >>>>> The end of the bitstream of the "Frame" is filled with 0-bits = until >>>>> that the bitstream contains a multiple of 8 bits. >>>>>=20 >>>>> Is =E2=80=9Cthat=E2=80=9D just an extra word that needs to be = struck, or is something else >>>>> wrong here? And is this meant to be what we usually call = =E2=80=9Cpadding=E2=80=9D? >>>>=20 >>>> Fixed in = https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea597918b5633d11= 88ea. >>>>=20 >>>>> =E2=80=94 Section 4 =E2=80=94 >>>>>=20 >>>>> Within the following sub-sections, pseudo-code is used to explain = the >>>>> structure of each FFV1 bitstream component, as described in >>>>> Section 2.2.1. >>>>>=20 >>>>> I read this as saying that Section 2.2.1 describes the structure = of each FFV1 >>>>> bitstream component, until I went back there and looked. I = suggest reordering >>>>> the sentence to help the reader a bit: >>>>>=20 >>>>> NEW >>>>> Within the following sub-sections, pseudo-code is used, as = described >>>>> in Section 2.2.1, to explain the structure of each FFV1 bitstream >>>>> component. >>>>> END >>>>=20 >>>> The suggested was taken and used in = https://github.com/FFmpeg/FFV1/commit/ab5a5c944d518ad72a982118b3c90b99a78d= 5d7c. >>>>=20 >>>>> =E2=80=94 Section 4.5 =E2=80=94 >>>>>=20 >>>>> Encoders SHOULD NOT fill these bits. >>>>> Decoders SHOULD ignore these bits. >>>>>=20 >>>>> Before this you describe two kinds of bits, and it=E2=80=99s not = clear whether these >>>>> are talking about both kinds, or just the latter. I think = changing =E2=80=9Cthese=E2=80=9D to >>>>> =E2=80=9Creserved=E2=80=9D is better. >>>>=20 >>>> Adjusted in = https://github.com/FFmpeg/FFV1/commit/12bfc977f5f868404b69f434501f011a850e= e9c0. >>>>=20 >>>>> =E2=80=94 Section 6 =E2=80=94 >>>>>=20 >>>>> A frequent security problem in image >>>>> and video codecs is also to not check for integer overflows, for >>>>> example to allocate "frame_pixel_width * frame_pixel_height" in >>>>> "Pixel" count computations without considering that the >>>>> multiplication result may have overflowed the arithmetic types = range. >>>>>=20 >>>>> This is somewhat complex and awkward (arguably a comma splice), = and I suggest >>>>> splitting the sentence thus: >>>>>=20 >>>>> NEW >>>>> A frequent security problem in image >>>>> and video codecs is failure to check for integer overflows. An >>>>> example is allocating "frame_pixel_width * frame_pixel_height" in >>>>> "Pixel" count computations without considering that the >>>>> multiplication result may have overflowed the arithmetic types = range. >>>>> END >>>>=20 >>>> Fixed in = https://github.com/FFmpeg/FFV1/commit/741f67b405b2bfbe683a2a3d9dc83468bca9= 60cf. >>>>=20 >>>>> I might also make the =E2=80=9Cmust=E2=80=9D in the last sentence = of that paragraph be =E2=80=9CMUST=E2=80=9D. >>>>=20 >>>> Fixed in = https://github.com/FFmpeg/FFV1/commit/50d9e14ad889cc833d65a905a01637ea8b52= 6a45. >>>>=20 >>>> summary: >>>>=20 >>>> In my opinion, all discuss and comments listed in this review have = been resolved with the exception of the status of comments on Section = 3.8.1.1 being less clear. I=E2=80=99m pasting in the current state of = Section 3.8.1.1 for consideration: >>>>=20 >>>>> 3.8.1.1. Range Binary Values >>>>>=20 >>>>> To encode binary digits efficiently a Range coder is used. C_(i) = is >>>>> the i-th Context. B_(i) is the i-th byte of the bytestream. = b_(i) is >>>>> the i-th Range coded binary value, S_(0, i) is the i-th initial >>>>> state. The length of the bytestream encoding n binary symbols is >>>>> j_(n) bytes. >>>>>=20 >>>>> r_(i) =3D floor( ( R_(i) * S_(i, C_(i)) ) / 2 ^ 8 ) >>>>>=20 >>>>> Figure 11: A formula of the read of a binary value in Range >>>>> Binary mode. >>>>>=20 >>>>> S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND >>>>> l_(i) =3D L_(i) AND >>>>> t_(i) =3D R_(i) - r_(i) <=3D=3D >>>>> b_(i) =3D 0 <=3D=3D> >>>>> L_(i) < R_(i) - r_(i) >>>>>=20 >>>>> S_(i + 1, C_(i)) =3D one_state_(S_(i, C_(i))) AND >>>>> l_(i) =3D L_(i) - R_(i) + r_(i) AND >>>>> t_(i) =3D r_(i) <=3D=3D >>>>> b_(i) =3D 1 <=3D=3D> >>>>> L_(i) >=3D R_(i) - r_(i) >>>>>=20 >>>>> Figure 12 >>>>>=20 >>>>> S_(i + 1, k) =3D S_(i, k) <=3D=3D C_(i) !=3D k >>>>>=20 >>>>> Figure 13: The "i+1,k"-th State is equal to the "i,k"-th State = if >>>>> the value of "k" is unequal to the i-th value of Context. >>>>>=20 >>>>> R_(i + 1) =3D 2 ^ 8 * t_(i) AND >>>>> L_(i + 1) =3D 2 ^ 8 * l_(i) + B_(j_(i)) AND >>>>> j_(i + 1) =3D j_(i) + 1 <=3D=3D >>>>> t_(i) < 2 ^ 8 >>>>>=20 >>>>> R_(i + 1) =3D t_(i) AND >>>>> L_(i + 1) =3D l_(i) AND >>>>> j_(i + 1) =3D j_(i) <=3D=3D >>>>> t_(i) >=3D 2 ^ 8 >>>>>=20 >>>>> Figure 14: The "i+1"-th values for "Range", "Low", and the = length >>>>> of the bytestream encoding are conditionally set depending on = the >>>>> "i-th" value of "t". >>>>>=20 >>>>> R_(0) =3D 65280 >>>>>=20 >>>>> Figure 15: The initial value for "Range". >>>>>=20 >>>>> L_(0) =3D 2 ^ 8 * B_(0) + B_(1) >>>>>=20 >>>>> Figure 16: The initial value for "Low" is set according to = the >>>>> first two bytes of the bytestream. >>>>>=20 >>>>> j_(0) =3D 2 >>>>>=20 >>>>> Figure 17: The initial value for "j", the length of the >>>>> bytestream encoding. >>>>>=20 >>>>> range =3D 0xFF00; >>>>> end =3D 0; >>>>> low =3D get_bits(16); >>>>> if (low >=3D range) { >>>>> low =3D range; >>>>> end =3D 1; >>>>> } >>>>>=20 >>>>> Figure 18: A pseudo-code description of the initial states in >>>>> Range Binary mode. >>>>>=20 >>>>> refill() { >>>>> if (range < 256) { >>>>> range =3D range * 256; >>>>> low =3D low * 256; >>>>> if (!end) { >>>>> c.low +=3D get_bits(8); >>>>> if (remaining_bits_in_bitstream( NumBytes ) =3D=3D 0) = { >>>>> end =3D 1; >>>>> } >>>>> } >>>>> } >>>>> } >>>>>=20 >>>>> Figure 19: A pseudo-code description of refilling the Range >>>>> Binary Value coder buffer. >>>>>=20 >>>>> get_rac(state) { >>>>> rangeoff =3D (range * state) / 256; >>>>> range -=3D rangeoff; >>>>> if (low < range) { >>>>> state =3D zero_state[state]; >>>>> refill(); >>>>> return 0; >>>>> } else { >>>>> low -=3D range; >>>>> state =3D one_state[state]; >>>>> range =3D rangeoff; >>>>> refill(); >>>>> return 1; >>>>> } >>>>> } >>>>>=20 >>>>> Figure 20: A pseudo-code description of the read of a binary >>>>> value in Range Binary mode. >>>=20 >>> Please note that we just updated the draft to include the = recommended changes, which can be reviewed in version 19 of = https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/. Here=E2=80=99s = a link to the diff of version 18 and 19: = https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-cellar-ffv1-18&url2=3Ddraft= -ietf-cellar-ffv1-19&difftype=3D--html. >>>=20 >>> To repeat a comment above: In my opinion, all discuss and comments = listed in this review have been resolved with the exception of the = status of comments on Section 3.8.1.1 being less clear but since a lot = of work has been done here, we could use a new review of this section = within the new version. >>>=20 >>> Kind Regards, >>> Dave Rice >>>=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Fri Dec 4 10:34:05 2020 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 5CFFE3A0F46; Fri, 4 Dec 2020 10:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvoFjZ9HsNmN; Fri, 4 Dec 2020 10:33:55 -0800 (PST) Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2615B3A0E8B; Fri, 4 Dec 2020 10:33:48 -0800 (PST) X-Originating-IP: 213.47.68.29 Received: from localhost (213-47-68-29.cable.dynamic.surfer.at [213.47.68.29]) (Authenticated sender: michael@niedermayer.cc) by relay7-d.mail.gandi.net (Postfix) with ESMTPSA id 6C7A320006; Fri, 4 Dec 2020 18:33:43 +0000 (UTC) Date: Fri, 4 Dec 2020 19:33:42 +0100 From: Michael Niedermayer To: Dave Rice Cc: Barry Leiba , cellar-chairs@ietf.org, derek.buitenhuis@gmail.com, Michael Richardson , pb@das-werkstatt.com, draft-ietf-cellar-ffv1@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission , The IESG Message-ID: <20201204183342.GO2389354@pb2> References: <160049032442.20595.4616862102756589735@ietfa.amsl.com> <92029D16-621F-4AE0-BC3F-03C08AB21ADE@dericed.com> <3BDF43E9-1245-40D0-B589-7ABFC14C8823@dericed.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IUSVF+LtaR4kWxuH" Content-Disposition: inline In-Reply-To: <3BDF43E9-1245-40D0-B589-7ABFC14C8823@dericed.com> Archived-At: Subject: Re: [Cellar] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 04 Dec 2020 18:34:04 -0000 --IUSVF+LtaR4kWxuH Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 03, 2020 at 06:46:48PM -0500, Dave Rice wrote: > Hi Barry, > Thanks so much for your comments. >=20 > > On Dec 2, 2020, at 5:43 PM, Barry Leiba wrote: > >=20 > > OK, Dave, here's where I am with 3.8.1.x: > >=20 > > =E2=80=94 Section 3.8.1 =E2=80=94 > >=20 > > CABAC was replaced by a Range coder based on an algorithm defined by > > G. Nigel N. Martin in 1979 [range-coding]. > >=20 > > Keep in mind as you read my comments below that I=E2=80=99m not versed = in this > > field at all, I am not familiar with Range coding, and can=E2=80=99t ea= sily > > look up the reference. Ha=E2=80=A6 but after typing that, I just did: = I found > > it here: > > http://sachingarg.com/compression/entropy_coding/range_coder.pdf > >=20 > > Maybe it would help to add that URI to the reference? Anyway, again, > > this isn=E2=80=99t my area, so it=E2=80=99s valid to say, for any of th= is below, that > > someone actually implementing this would already understand these > > things. >=20 > We had some discussion on this at https://github.com/FFmpeg/FFV1/pull/219= and considered adding a reference to http://www.compressconsult.com/range= coder/#literature or https://web.archive.org/web/*/http://www.compressconsu= lt.com/rangecoder/#literature. A reason against is that these are unofficia= l sources of this knowledge and thus perhaps not ideal to use for the citat= ion. >=20 > I did just check to see if other RFCs cite this and found that RFC6716 ci= tes http://en.wikipedia.org/w/index.php?title=3DRange_encoding&oldid=3D5095= 82757 as an informative reference. >=20 > For IETF is there a preference for which of these citations if any to use? >=20 > > =E2=80=94 Section 3.8.1.1 =E2=80=94 > >=20 > > To encode binary digits efficiently a Range coder is used. C_(i) is > > the i-th Context. B_(i) is the i-th byte of the bytestream. b_(i) is > > the i-th Range coded binary value, S_(0, i) is the i-th initial > > state. The length of the bytestream encoding n binary symbols is > > j_(n) bytes. > >=20 > > Two things here: > >=20 > > Editorial: I think it would be easier to read this as an item list > > (what do you think?): > >=20 > > NEW > > To encode binary digits efficiently a Range coder is used. > > - C_(i) is the i-th Context > > - B_(i) is the i-th byte of the bytestream > > - b_(i) is the i-th Range coded binary value > > - S_(0, i) is the i-th initial state > > - j_(n) is the length of the bytestream encoding n binary symbols > > END >=20 > Locally, I=E2=80=99ve tested converting this into a definition list per h= ttps://tools.ietf.org/html/rfc7991#section-2.20, which rendered in the text= output as: >=20 > C_(i) the i-th Context. > B_(i) the i-th byte of the bytestream. > b_(i) the i-th Range coded binary value. > S_(0, i) the i-th initial State. > j_(n) the length of the bytestream encoding n binary symbols. >=20 > > Substantive: It would also help to add to that list L_(i), l_(i), > > R_(i), r_(i), and t_(i), so things are complete. Maybe also S_(x, i), > > where x is not 0. >=20 > Nudging Michael Niedermayer and Derek Buitenhuis on this for help. Some g= uess work but if I understand correctly. >=20 > L_(i) is the Low value of the Range > l_(i) is a temporary storage variable used in assigning values to L_(i) > R_(i) is the Range value > r_(i) is a temporary storage variable used in assigning values to R_(i) > t_(i) is a temporary storage variable used in assigning values to R_(i) > S_(x, i) is the =E2=80=98x, 1=E2=80=99-th State. >=20 > > S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND > > l_(i) =3D L_(i) AND > > t_(i) =3D R_(i) - r_(i) <=3D=3D > > b_(i) =3D 0 <=3D=3D> > > L_(i) < R_(i) - r_(i) > >=20 > > I still don=E2=80=99t understand how to read this. >=20 > I should note that these equation appear a bit differently in the HTML ve= rsion of the draft where they are depicted in SVG images of LaTeX equations= =2E In the SVG, the equation all exists on one line; however, in the plain = text output it doesn=E2=80=99t fit in the line width so we wrap the output = a bit for cosmetics. If more clear we could re-arrange the line breaks, suc= h as: >=20 > ( > S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND > l_(i) =3D L_(i) AND > t_(i) =3D R_(i) - r_(i) > ) <=3D=3D ( b_(i) =3D 0 ) <=3D=3D> ( L_(i) < R_(i) - r_(i) ) >=20 > > Perhaps explain verbally > > what it=E2=80=99s supposed to mean, and I can help figure out some word= s to > > add that will help others? >=20 > b_(i) =3D 0 and L_(i) < R_(i) - r_(i) would imply each other as well as = implies the other group of three assignments. >=20 > > I don=E2=80=99t know what the =E2=80=9CAND=E2=80=9D and =E2=80=9C<=3D= =3D=E2=80=9C and > > =E2=80=9C<=3D=3D>=E2=80=9D on the right are trying to tell me (I get wh= at =E2=80=9CA <=3D=3D B=E2=80=9D means, > > but I don=E2=80=99t know how to interpret =E2=80=9C<=3D=3D=E2=80=9C at = the end of the line, for > > example). >=20 > It is only a line break, if not for the line width limitation this would = be: >=20 > S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND l_(i) =3D L_(i) AND = t_(i) =3D R_(i) - r_(i) <=3D=3D b_(i) =3D 0 <=3D=3D> L_(i) < R_(i) - r_(= i) >=20 > which is closer to how it looks in the SVG HTML version. >=20 > > Do others who haven=E2=80=99t worked on this understand it? It=E2=80= =99s quite > > possible that it=E2=80=99s just me, in which case I=E2=80=99ll happily = step aside. > > But I=E2=80=99m also happy to try to make it more understandable. >=20 > Yes, please more understandability. :) >=20 > > S_(i + 1, k) =3D S_(i, k) <=3D=3D C_(i) !=3D k > >=20 > > Figure 13: The "i+1,k"-th State is equal to the "i,k"-th State if > > the value of "k" is unequal to the i-th value of Context. > >=20 > > The caption on this does help, so now I see what it=E2=80=99s getting a= t! But > > I would *never* understand it without the caption. (1) The > > right-to-left conditional is odd to me. (2) I=E2=80=99m not used to th= at sort > > of conditional being used as an =E2=80=9Cif-then=E2=80=9D statement. I= =E2=80=99m curious why > > you didn=E2=80=99t write this whole section in pseudo-code, and perhaps= it=E2=80=99s > > another artifact of my wading into a field that=E2=80=99s foreign to me= =2E Had > > Figure 13 been written like this, I would understand it perfectly: > >=20 > > if ( C_(i) !=3D k ) then { S_(i + 1, k) =3D S_(i, k) } >=20 > Yes, in pseudo-code that is the same. > Michael Niedermayer, any objection to converting some of the math to pseu= docode? Iam perfectly fine with changing the notation so it is easier to understand. One disadavantage of pure pseudocode could be that it may be hard to descri= be encoding in such a way that it describes not one bitstream but a set of bitstreams which are guranteed to be decoded correctly. That is if the encoder side is described by pseudocode. If the approuch of trying to describe the bitstream by the non pseudocode notation is disliked. Then maybe the decoder side can be described by normative pseudocode and the encoder side by informative pseudocode so that the encoder side would be "one possible" solution but not the only one.=20 We could of course also describe both by strict normative pseudocode but that would be different from what the original intend was None of this is specific to the quoted line of code above of course I had not imagined that the notation would lead to so much confusion, its definitly important that the text can be understood and implemented by the average target audience, if the notation causes problems here it certainly should be improved ... Thanks [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answe= r. --IUSVF+LtaR4kWxuH Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iF0EABEIAB0WIQSf8hKLFH72cwut8TNhHseHBAsPqwUCX8qA/wAKCRBhHseHBAsP qyfEAKCbFWomTrHa2dcHxLpmiiJlWsWIzACeLq84UNCbOudPEsJ1oJhmcTEhnvk= =UKqF -----END PGP SIGNATURE----- --IUSVF+LtaR4kWxuH-- From nobody Fri Dec 4 10:53:28 2020 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 0E8623A0EB9 for ; Fri, 4 Dec 2020 10:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.461 X-Spam-Level: X-Spam-Status: No, score=-1.461 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FAKE_REPLY_B=0.658, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=reto.ch 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 aheZUs6JR7xP for ; Fri, 4 Dec 2020 10:53:25 -0800 (PST) Received: from smtp-8fac.mail.infomaniak.ch (smtp-8fac.mail.infomaniak.ch [83.166.143.172]) (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 EB57D3A0EB4 for ; Fri, 4 Dec 2020 10:53:24 -0800 (PST) Received: from smtp-3-0000.mail.infomaniak.ch (unknown [10.4.36.107]) by smtp-3-3000.mail.infomaniak.ch (Postfix) with ESMTPS id 4Cnhg52sMqzlhdFq for ; Fri, 4 Dec 2020 19:53:21 +0100 (CET) Received: from Castor (unknown [8.41.5.27]) by smtp-3-0000.mail.infomaniak.ch (Postfix) with ESMTPA id 4Cnhg500Kqzlh8TM for ; Fri, 4 Dec 2020 19:53:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=reto.ch; s=20191114; t=1607108001; bh=zwnYkVcavLjTGW/jY1cszBc8qCDTmQ+z9l3m9Qxy7sA=; h=Date:From:Subject:To:From; b=sB4XIDazNpWwzke5be1/ApBVgTIqizswwd0I+BvLAvZgp04556CaNHxBiS03J2uiT acCdCSy+/vRVVX8ZEGmg23Rw/Qv4IJ3MYIql6ZRc1wXVzUX7JUPZvE6DMkLk6ajHQn MIc+4cb6d/Oc86A8Kx8VjU/dP7wP9kfOr78iiEWc= Date: Fri, 4 Dec 2020 19:53:21 +0100 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) Archived-At: Subject: Re: [Cellar] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 04 Dec 2020 18:53:27 -0000 Michael Niedermayer wrote: >One disadavantage of pure pseudocode could be that it may be >hard to describe encoding in such a way that it describes not >one bitstream but a set of bitstreams which are guranteed to be >decoded correctly. Of course, I agree with Michael, as this is also one of my concerns. Best regards, Reto From nobody Sat Dec 5 23:40:58 2020 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 607583A0E7D for ; Sat, 5 Dec 2020 23:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=a3iYWzG2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jVY3QrFX 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 oaOWgGqLzewQ for ; Sat, 5 Dec 2020 23:40:54 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDB33A0E6B for ; Sat, 5 Dec 2020 23:40:54 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 93B625C0131 for ; Sun, 6 Dec 2020 02:35:07 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 06 Dec 2020 02:35:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=OcEXPGeKNUpqkVyeEF2iuh9ZmaiWjEOLH7fuy0v+bIc=; b=a3iYWzG2 aZY6yg1g08brKhFgntL63BUAUFVme5Rg9MtE/OY7H7OIG8/TnNErLVnSDXJWcunh N63KXojn0ZZZ8dTO7sR8C9vLyNsejGg1ztG/Y/TwmnPt1ndWP9PIEhWlVXtCYBaV fWJCWT5rJ9l5x/WOQCMP0LDt30gSq2T51M4eQbyhIjF8oo1lPjG4rfjbSV1sb7dw 1r6EM4CvujhOtmsyUC+GCUU8ANEflJPqTj4YJ3h/aAuzaMZFISnAmOdbHzPJqhq1 muSel3gldtK38PNGq2PJVzLzgo0CxgEEp4V6T4jjg5SDhDafB2sR9E+jPjH6rN38 zsFsp6pxlV+QvQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=OcEXPGeKNUpqkVyeEF2iuh9ZmaiWj EOLH7fuy0v+bIc=; b=jVY3QrFXkxCW4iAj1Wjqie8ovBckdPCnnecfUVjposGoZ XQw4bTYU2OtYWyu+O10XALH2UhW4zcUiFvfILsyQXrPc98p7Nih3alRfTX2h4o/5 HmbbMAQDk0KFak9c5u94Wt++KlyKJZ/agDa8tYJeu7VrmsRjwYG7r7Y43BIsICdY R3iJHd6lQXcVsJn0MlnTE+RyZJVnR/Pc4cimgkEgRlBIrJfbxs4iavPLw1M83etL aNa8ycZaJvbRm1/fzva3IAffnvPX8OTdKzNm3u6JZEBzif6t9JVvnuEBDATfmQj9 Mmzpe/IFwiqq0N3VeAIbEFWQta0GT7UT90d2zY+tQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudejuddguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrieehrddvfedtrd dukeenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az60-565.internal.cloudapp.net (unknown [40.65.230.18]) by mail.messagingengine.com (Postfix) with ESMTPA id 6AEFF24005C for ; Sun, 6 Dec 2020 02:35:07 -0500 (EST) Content-Type: multipart/alternative; boundary="===============6308612389116622521==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20201206073507.6AEFF24005C@mailuser.nyi.internal> Date: Sun, 6 Dec 2020 02:35:07 -0500 (EST) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 06 Dec 2020 07:40:56 -0000 --===============6308612389116622521== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Errors while compiling the digest: - Repo ietf-cellar-wg/chair-notes/events yields 404 error Events without label "editorial" Issues ------ * FFmpeg/FFV1 (+0/-0/=F0=9F=92=AC1) 1 issues received 1 new comments: - #231 section 3.8.1.1 should have pseudocode (1 by dericed) https://github.com/FFmpeg/FFV1/issues/231=20 Pull requests ------------- * FFmpeg/FFV1 (+2/-1/=F0=9F=92=AC1) 2 pull requests submitted: - fix typo (by dericed) https://github.com/FFmpeg/FFV1/pull/256=20 - move range coder variables to a definition list (by dericed) https://github.com/FFmpeg/FFV1/pull/255=20 1 pull requests received 1 new comments: - #255 move range coder variables to a definition list (1 by dericed) https://github.com/FFmpeg/FFV1/pull/255=20 1 pull requests merged: - rewrite of security considerations on denial of service https://github.com/FFmpeg/FFV1/pull/253=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-cellar-wg/ebml-specification * https://github.com/ietf-cellar-wg/matroska-specification * https://github.com/FFmpeg/FFV1 * https://github.com/ietf-cellar-wg/Cellar-FLAC * https://github.com/ietf-cellar-wg/chair-notes --===============6308612389116622521== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday December 06, 2020

Errors while compiling the digest:
  • Repo ietf-cellar-wg/chair-notes/events yields 404 error

Events without label "editorial"

Issues

FFmpeg/FFV1 (+0/-0/=F0=9F=92=AC1)

1 issues received 1 new comments:

Pull requests

FFmpeg/FFV1 (+2/-1/=F0=9F=92=AC1)

2 pull requests submitted:

1 pull requests received 1 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============6308612389116622521==-- From nobody Sun Dec 6 17:48:30 2020 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 D369B3A0E53; Sun, 6 Dec 2020 17:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdS7bBGgwwPE; Sun, 6 Dec 2020 17:48:25 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8295A3A0E52; Sun, 6 Dec 2020 17:48:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 59B923899E; Sun, 6 Dec 2020 20:50:27 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bcmrnW5JZq-D; Sun, 6 Dec 2020 20:50:26 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 12EDA3899D; Sun, 6 Dec 2020 20:50:26 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id AB7684F5; Sun, 6 Dec 2020 20:48:20 -0500 (EST) From: Michael Richardson To: cellar@ietf.org, Michael Niedermayer cc: Dave Rice , Barry Leiba , derek.buitenhuis@gmail.com, pb@das-werkstatt.com, draft-ietf-cellar-ffv1@ietf.org In-Reply-To: <20201204183342.GO2389354@pb2> References: <160049032442.20595.4616862102756589735@ietfa.amsl.com> <92029D16-621F-4AE0-BC3F-03C08AB21ADE@dericed.com> <3BDF43E9-1245-40D0-B589-7ABFC14C8823@dericed.com> <20201204183342.GO2389354@pb2> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 07 Dec 2020 01:48:28 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Michael Niedermayer wrote: >> Yes, in pseudo-code that is the same. >> Michael Niedermayer, any objection to converting some of the math to= pseudocode? > Iam perfectly fine with changing the notation so it is easier to unde= rstand. > One disadavantage of pure pseudocode could be that it may be hard to = describe > encoding in such a way that it describes not one bitstream but a set = of > bitstreams which are guranteed to be decoded correctly. > That is if the encoder side is described by pseudocode. > If the approuch of trying to describe the bitstream by the non pseudo= code > notation is disliked. Then maybe the decoder side can be described by > normative pseudocode and the encoder side by informative pseudocode > so that the encoder side would be "one possible" solution but not the= only > one. This sounds good to me. I think that you want the decoder to be normative, because we must always produce only bitstreams that can be decoded. > I had not imagined that the notation would lead to so much confusion, > its definitly important that the text can be understood and implement= ed > by the average target audience, if the notation causes problems here = it > certainly should be improved ... It is unfortunately the case that we must often write specifications for the general audience. That's the plight of the expert: to explain themselves to non-experts :-) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/NieQACgkQgItw+93Q 3WVFGwf8C/XXGop397sUuzqh/fEb89jekqL/dx6ryk/WPJChYmv+LzMiKdWBbJ4U O+SpNRzydNep2oYenn57aUBKGXRH+Znu/WAo6i79DjERH9QtKPyVJiO6MATjudw5 T6DhmI5968JCX+L8EUXRBmy8g5PSCtdL0+NvIUOXVJdaV2xsVi4zlaH6gyGnrf7A TTXWgc+nukskUM9qKZVphIlIj2R5SJEQnjffe/AHfaeq1r5+3++L7oJxUhvnuOG3 /byij8MHULRSxvg0dtXtWEIeVCefe6nLBw8bBq+sVcuct0TRgFU8fKL/vwhQ3E9h k5SMcDI4tKrdIjcdOZtweOI1eMJSvg== =jlbM -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 7 14:45:47 2020 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 310A23A0BFC for ; Mon, 7 Dec 2020 14:44:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU879AtL28w1 for ; Mon, 7 Dec 2020 14:44:52 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AFD73A0C01 for ; Mon, 7 Dec 2020 14:44:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 1301F389AE for ; Mon, 7 Dec 2020 17:47:00 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9aKRIFAa3bNr for ; Mon, 7 Dec 2020 17:46:56 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 71BD9389AD for ; Mon, 7 Dec 2020 17:46:56 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CB52648F for ; Mon, 7 Dec 2020 17:44:47 -0500 (EST) From: Michael Richardson To: cellar@ietf.org X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] Request to Charter a New Working Group: WebRTC Ingest Signaling over HTTPS (wish) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 07 Dec 2020 22:44:54 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain This may be of interest to some CELLAR participants. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=152 Content-Description: forwarded message Replied: Mon, 07 Dec 2020 17:44:14 -0500 Replied: "iesg@ietf.org, wish@ietf.org " Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3:216:3eff:fe7c:d1f3] by localhost with IMAP (fetchmail-6.4.0.beta4) for (single-drop); Mon, 07 Dec 2020 17:07:36 -0500 (EST) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus 2.5.10-Debian-2.5.10-3+deb9u2) with LMTPA; Mon, 07 Dec 2020 13:16:49 -0500 X-Sieve: CMU Sieve 2.4 Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id E5E73389A6 for ; Mon, 7 Dec 2020 13:16:48 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id uwD6_wdtJ5u9 for ; Mon, 7 Dec 2020 13:16:44 -0500 (EST) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPS id 848F5389A0 for ; Mon, 7 Dec 2020 13:16:44 -0500 (EST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3C13A165E for ; Mon, 7 Dec 2020 10:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1607364875; bh=hDT/GCD2VgYHbHiTKDwAjWF1fYWuFdEnvoxVbYyPGtg=; h=From:To:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To:Cc; b=SZ3zz4TrgernV1p2gVan3DgHJQuEZNgbVbVhiRBBYLH/CK5wVphw5kjRmG9O8BZsO oqBsciuuT73ZyZn1lyKNodM1JBCvD6kDUvb+KD8X+8TbuysGJ1jzxRmD6PiAGB8IKS NfL1pY4kD8/COrt1vP1Q3mFGHlTlhubGht2kuS5w= X-Mailbox-Line: From ietf-announce-bounces@ietf.org Mon Dec 7 10:14:30 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83BDE3A1640; Mon, 7 Dec 2020 10:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1607364870; bh=hDT/GCD2VgYHbHiTKDwAjWF1fYWuFdEnvoxVbYyPGtg=; h=From:To:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To:Cc; b=nzN9GfkpB7CX9BCSuVN1u7gVnotHGSpQ3vs2ckUcLkx+dYcKMZ6RRzQ7EfYb7/5Ai O7H3XsB4tehpXLvOp3QtIqbRiRSx9FJ/ovLl6pUZ7dShcS0llJ+Pbq7YBre6MJVQb4 YZ7TqDPWIfxui1HSNQXCRP/BQ7BxMs+sEnaesU1k= X-Original-To: ietf-announce@ietf.org Delivered-To: ietf-announce@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A09D3A1640; Mon, 7 Dec 2020 10:14:29 -0800 (PST) MIME-Version: 1.0 From: IESG Secretary To: "IETF Announcement List" Subject: Request to Charter a New Working Group: WebRTC Ingest Signaling over HTTPS (wish) X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160736486948.13061.223896594760983263@ietfa.amsl.com> Date: Mon, 07 Dec 2020 10:14:29 -0800 Archived-At: X-BeenThere: ietf-announce@ietf.org X-Mailman-Version: 2.1.29 List-Id: "IETF announcement list. No discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: iesg@ietf.org Cc: wish@ietf.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ietf-announce-bounces@ietf.org Sender: "IETF-Announce" The IESG has received a request to charter a new working group, "WebRTC Ingest Signaling over HTTPS (wish)." The proposed charter, which is a work in progress, can be found here: The charter will be discussed on the wish@ietf.org mailing list, which can be subscribed to here: _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl/OsF8ACgkQgItw+93Q 3WWyAQgAmjqHtoAUpNzkj1NsciZSyVZlpIXtK5Wmr2/8zoHDRqbT8FWdCszimYJl kAGkKs9lCSQ3sxcQYnNEbdz8LHclS3Mn7GEsNaoKfLAreZJcvCycWoQwOodKz9Pr Jhzww89Mc8bn/vQQj/ix/rIObepgvVsMkf7WeUv7G+5CllNVkjg0Me99ntuf1CNK jb+xbVX0kIUVgHe8x/5H5bSAg+bhBWrqwrWJaFlt8MTWRJnpJ3HS/sSzGhEg/whs 59u1u/Dk8/yD6VNEX0MogsLHVrC47nazEMzSpRlPPAmtH1VMkLCUvtMMQcCIWDlt umzY+B43D1lAqGa1mPRxZFd/SurO+w== =c1VO -----END PGP SIGNATURE----- --==-=-=-- From nobody Sat Dec 12 23:56:02 2020 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 8AFA73A15B5 for ; Sat, 12 Dec 2020 23:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ZcxND0kA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=j9M9teqK 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 6oL40naWE_Sm for ; Sat, 12 Dec 2020 23:55:55 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDEF93A15B0 for ; Sat, 12 Dec 2020 23:55:54 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 16F3D5C00A9 for ; Sun, 13 Dec 2020 02:38:37 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 13 Dec 2020 02:38:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=mrNkCWx7uxky5FN9Jfd2K8VbD1nlr88QLzKtow264h4=; b=ZcxND0kA Fnq3pXo0DIS6s/1i1kHpQQ9qgpXpE2iNz15qHWW2C4IkbBulzfZmk5estiPXIV5V Zq/VsYl3PPbTrCvO/p/TAQ61wQlA+PGrkdDsSNyLWWkd7foBEM7+3I2LKM9O5b/u 35HwDNMis3ynWbR6X/R106w/k5inlAWQRXHC28XYIhyTucIno3t6GCNz68AIrIR/ 45gYp6kHGtsICLTksWMLYyBb+zd2KmF3tDUy4GnuZ09NZA6meBduuzd3rrduGO4t uTTWVGoC72a4ae+jhECz/LYv4g0+AAedtjDe5hZ+XA/Kwweby79BnK00uHyyIspJ 0PSEz8Ljo6IdGg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=mrNkCWx7uxky5FN9Jfd2K8VbD1nlr 88QLzKtow264h4=; b=j9M9teqKAOm1vsJl5kkfQDk9h3IfcfL9miUKiHexevsfy cOF2X7iV/3gQ7aAKyI594/K8KS2oV54XK/8bd9I0KNciLXkUYTHdjQtEHvnoQ1k8 zBoRqErJJc1cFGTa9vmaFVIWEonqJ5089MshcfEZtSfge4RF9zsreCdxIlmlwZuj X7B3lN+k+uAcPP8yJHjqZVnHs5HwgM2PQhvracfItzhSI4qsyJI4umDx4Luig8Zq mpj+11YR9uQbk1ZR73NiH28bqu09i32lMR+BTs/+bnKyG9XzSCCH3ZoCngo/7pjs Kw26RIgEoRqeYROU337BmyGlRwu1LYvQ5d4iLXZQw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudekhedgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppedufedrjeejrdekuddrud eileenucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az184-911.internal.cloudapp.net (unknown [13.77.81.169]) by mail.messagingengine.com (Postfix) with ESMTPA id E275E240057 for ; Sun, 13 Dec 2020 02:38:36 -0500 (EST) Content-Type: multipart/alternative; boundary="===============3773837366753152987==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20201213073836.E275E240057@mailuser.nyi.internal> Date: Sun, 13 Dec 2020 02:38:36 -0500 (EST) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 13 Dec 2020 07:55:57 -0000 --===============3773837366753152987== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Errors while compiling the digest: - Repo ietf-cellar-wg/chair-notes/events yields 404 error Events without label "editorial" Pull requests ------------- * FFmpeg/FFV1 (+0/-1/=F0=9F=92=AC0) 1 pull requests merged: - move range coder variables to a definition list https://github.com/FFmpeg/FFV1/pull/255=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-cellar-wg/ebml-specification * https://github.com/ietf-cellar-wg/matroska-specification * https://github.com/FFmpeg/FFV1 * https://github.com/ietf-cellar-wg/Cellar-FLAC * https://github.com/ietf-cellar-wg/chair-notes --===============3773837366753152987== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday December 13, 2020

Errors while compiling the digest:
  • Repo ietf-cellar-wg/chair-notes/events yields 404 error

Events without label "editorial"

Pull requests

FFmpeg/FFV1 (+0/-1/=F0=9F=92=AC0)

1 pull requests merged:

Repositories tracked by this digest:

--===============3773837366753152987==-- From nobody Sun Dec 20 00:16:01 2020 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 692553A0E5F for ; Sun, 20 Dec 2020 00:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=M/VkJ7Yx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=l6SeB5Ij 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 OAftsJoVdNE5 for ; Sun, 20 Dec 2020 00:15:56 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C51F3A0E5D for ; Sun, 20 Dec 2020 00:15:56 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4DC4F5C0098 for ; Sun, 20 Dec 2020 02:40:35 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 20 Dec 2020 02:40:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=KI6bBystaBK3hPlOix/wAt4NyIszz4FX5ZWtnoJSs4c=; b=M/VkJ7Yx WgPOeSJ7MxXEBy53TWQGWj/h9a6RMEW/y06n91ZyX1BF6t4f6AXZtndKCyDPom2j aF0UpW7lBUDksOJPaaAq5amPhXiz552nEnC0Y3xs10z1FVZDj01ABYDBZU3K3gYy pALlw8GxeJ2pr+AOn40XxtWAwZltZH+oL7KyKThRQ/VEGkCFV++RNv2k16Ktuo2u aBLGM2b6x0mW1m9g5eXKC29S2RhkKFEdgBDC8wWBoyk04uNpLuREIF5+r+XuygXJ /AbVImddzWniYztfG3lQnexxPtLTlc1pudQI3WIvw1JJaeS4PLHOwJ4SSX8RWJFF bep9B6cuvvt29w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=KI6bBystaBK3hPlOix/wAt4NyIszz 4FX5ZWtnoJSs4c=; b=l6SeB5IjVQJpxCx5pd7LG0Iu+a2+Wad5SCi4QoiPu7f34 Zb5sr98Mw9/pKhFsICIVYS9RJm2WNq5AlN9MMJw5F0l1CYrJ9PgqjoYxeiATSVoV IP9Oe+2EVP4F6tFpmN7jOzPSV0kqdVfFJHOxoGdAKLsW5fuIx53AD/JoRRh758I7 p6AogAQ9ubiHTuU9Z2FRariUvodgOYe5V+FXg704pQpbfrmUBgAX9Bd+ce1DtyQc KIZSsf3zzavi0k34t3pZl/c6knoPIGf1tHxQOpY8tmXUOshahQPUuIFwhKZNGUau yVayLZuogyqU2zXhry1KatB7RjhR3NmGIH4WrZmuA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudelledgudduudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtje enucfhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicu uehothcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeekfedvudetjedvfeekheeiveeugfefhfetteevgeffkefffeetffdvleehudei teenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppeegtddrjedtrdejuddrud dtleenucevlhhushhtvghrufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az59-708.internal.cloudapp.net (unknown [40.70.71.109]) by mail.messagingengine.com (Postfix) with ESMTPA id 260431080057 for ; Sun, 20 Dec 2020 02:40:35 -0500 (EST) Content-Type: multipart/alternative; boundary="===============0551260794552511232==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20201220074035.260431080057@mailuser.nyi.internal> Date: Sun, 20 Dec 2020 02:40:35 -0500 (EST) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 20 Dec 2020 08:15:58 -0000 --===============0551260794552511232== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Errors while compiling the digest: - Repo ietf-cellar-wg/chair-notes/events yields 404 error Events without label "editorial" Issues ------ * FFmpeg/FFV1 (+0/-0/=F0=9F=92=AC2) 1 issues received 2 new comments: - #231 section 3.8.1.1 should have pseudocode (2 by dericed, dwbuiten) https://github.com/FFmpeg/FFV1/issues/231=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/ietf-cellar-wg/ebml-specification * https://github.com/ietf-cellar-wg/matroska-specification * https://github.com/FFmpeg/FFV1 * https://github.com/ietf-cellar-wg/Cellar-FLAC * https://github.com/ietf-cellar-wg/chair-notes --===============0551260794552511232== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday December 20, 2020

Errors while compiling the digest:
  • Repo ietf-cellar-wg/chair-notes/events yields 404 error

Events without label "editorial"

Issues

FFmpeg/FFV1 (+0/-0/=F0=9F=92=AC2)

1 issues received 2 new comments:

Repositories tracked by this digest:

--===============0551260794552511232==-- From guest271314@gmail.com Sun Dec 27 07:33:50 2020 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 A2BF83A07E8 for ; Sun, 27 Dec 2020 07:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.853 X-Spam-Level: X-Spam-Status: No, score=0.853 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MhyfLAOJ0HqN for ; Sun, 27 Dec 2020 07:33:49 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 EFB6B3A07C8 for ; Sun, 27 Dec 2020 07:33:48 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id j26so5507111qtq.8 for ; Sun, 27 Dec 2020 07:33:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5nsn2LOi4W2RR9qBJCL5l+JVkpJkHIFagzX1jeVnht0=; b=QovpHmVrj1IxFoRd0+0NrTcY/EKHZdDh7tRQcWa71A8zdL2RE8CjLBnnM+XEHBV4Mw mhYWV7kaFqxe7uaZ3nqXxRuhGr+3vkKVd5ULDWEvrxSWvqd0NPzl8pgwBamPzvEylaOg Ui9spiNd/mlJow3blCNby0BterLNmc/MH629HHZiLGreMkhNpywQ3Dxjq+97o8JBL7lH ol/qv0Mf7R6WpFNTsNVUsrV9O4ouFZ4aXfBbnPZhUK1KL+dVSHbK6sm0idBKiRR3J/6X mGtjm9ZFD6WOy2XaXFyMEGvbxbcWJJUefMDmpH3UWvXVNqexEBgYnhPZ35UxXHs8w2sv tZrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5nsn2LOi4W2RR9qBJCL5l+JVkpJkHIFagzX1jeVnht0=; b=cGWAt6UN5kKDWGubBNR54cL5IOG3X1eLOp3GudxupnfEve56jkKBjsxU4fecSv+gIa /Hg+isVPf4k3/l2Nz8wOdlQ5A65zZ8FN8GYEoEshyWOT6qV7kZ1UYQeS9BZ8K9qd/ZhU FTZkO1gAafkC1EmGspuASBh4Mf3EdRa+j+JoT69UsD/7zZYIEmRwhEnjVUwEuoppHs4m mI14CFkpJy0O5j1agmztKSkk/Yu6+JiZBIW/PVtW0wT0MdVSVkBafazn83lK3TWHvHdK k1Hx025NJhRFrb1elzm/YmvPLifA/Tf3XfXXS6iRH79+g7JoPwrVtlCYl8SGTeVsPxRt F1GA== X-Gm-Message-State: AOAM531q8VLJmnnHNpxk+Oyw2YW3NbLUB/9URqkJBU8uFL65ocC1zy/b e1hACdQ/PiqTQsUnc9h4GZqfvDdMrlhKX275Si3iEsXi9NyOeA== X-Google-Smtp-Source: ABdhPJzknfVipYujmoRrD4a06TQPIXXgvau3xsdg17bgU0sCBN7tMN+Ye64R+vkRvN690oeiwWPV+sliqbw9D9CqczM= X-Received: by 2002:ac8:7c8e:: with SMTP id y14mr38727327qtv.161.1609083227831; Sun, 27 Dec 2020 07:33:47 -0800 (PST) MIME-Version: 1.0 From: guest271314 Date: Sun, 27 Dec 2020 07:33:36 -0800 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary="0000000000003581bc05b773e2c6" Archived-At: Subject: [Cellar] Update specification language: CodecPrivate element MUST be set for H264 in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 27 Dec 2020 15:37:33 -0000 --0000000000003581bc05b773e2c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Evidently CodecPrivate element being required/mandatory for H264 in Matroska container is not clear nor conspicuous enough in the standard/specification. Cure that by conspicuously and unambiguously including wording in the standard/specification that " CodecPrivate element MUST be set for H264 in Matroska". References: https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2986#note_474111881 > Yes, both require & expect it to be present as there's important data stored there. One could go and assume certain defaults, and that might actually work for certain files, but not in general. This isn't a bug, nor a missing feature. https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2986#note_474135850 > Whether or not certain header elements (not just CodecPrivate) must be set depends on the video codec. VP8 & VP9 don't require one, for example, whereas AVC/h.264 & HEVC/h.265 do. https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2986#note_474137735 > We don't use RFC-style verbiage everywhere yet. The terms "CodecPrivate contains=E2=80=A6" pretty much states that the element is required for deco= ding. Issue 1161944: CodecPrivate element is required for H264 in Matroska - Chrome MediaRecorder does not set the element https://bugs.chromium.org/p/chromium/issues/detail?id=3D1161944 --0000000000003581bc05b773e2c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Evidently CodecPrivate element being required/mandato= ry for H264 in Matroska container is not clear nor conspicuous enough in th= e standard/specification.

Cure that by conspicuous= ly and unambiguously including wording in the standard/specification that &= quot;=C2=A0CodecPrivate element MUST be set for H264 in Matroska".

References:

https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2986#note_474111881> Yes, both require & expect = it to be present as there's important data stored there. One could go a= nd assume certain defaults, and that might actually work for certain files,= but not in general. This isn't a bug, nor a missing feature.
https://gitlab.com/mbunkus/mkvtoolnix/-/issues/2986#note= _474135850

> Whether or not = certain header elements (not just CodecPrivate) must be set depends on the = video codec. VP8 & VP9 don't require one, for example, whereas AVC/= h.264 & HEVC/h.265 do.

https://gitlab.com/m= bunkus/mkvtoolnix/-/issues/2986#note_474137735

> We don't use RFC-style verbiage everywhere yet. Th= e terms "CodecPrivate contains=E2=80=A6" pretty much states that = the element is required for decoding.

Issue 1161944: CodecPrivate element i= s required for H264 in Matroska - Chrome MediaRecorder does not set the ele= ment=C2=A0https://bugs.chromium.org/p/chromium/issue= s/detail?id=3D1161944
--0000000000003581bc05b773e2c6-- From nobody Sun Dec 27 08:15:53 2020 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 91CAB3A0BF7 for ; Sun, 27 Dec 2020 08:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 kGU9_tflOB6t for ; Sun, 27 Dec 2020 08:15:49 -0800 (PST) Received: from 1.mo68.mail-out.ovh.net (1.mo68.mail-out.ovh.net [46.105.41.146]) (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 57BA33A0BF6 for ; Sun, 27 Dec 2020 08:15:49 -0800 (PST) Received: from player728.ha.ovh.net (unknown [10.108.54.230]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 66DA118265B for ; Sun, 27 Dec 2020 17:15:47 +0100 (CET) Received: from mediaarea.net (p548f9a4c.dip0.t-ipconnect.de [84.143.154.76]) (Authenticated sender: jerome@mediaarea.net) by player728.ha.ovh.net (Postfix) with ESMTPSA id B352B196F3D15; Sun, 27 Dec 2020 16:15:44 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-95G0012a085e33-2c0a-4149-95c3-9247e2eaf299, BBADD9AAB17F2EC7E8DDA773C58BBF48E3EE42CD) smtp.auth=jerome@mediaarea.net X-OVh-ClientIp: 84.143.154.76 To: cellar@ietf.org, guest271314 References: From: Jerome Martinez Message-ID: <0baf7cee-e8f1-7b3f-7312-5ef45342c07e@mediaarea.net> Date: Sun, 27 Dec 2020 17:15:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 12912664560437694513 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrvddujedgkeelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpeekhfdvgfeuhffggefhfffhtdehfffhudeuveejtdfgjefgleelueejheetfffgjeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecukfhppedtrddtrddtrddtpdekgedrudegfedrudehgedrjeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrjedvkedrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvthdprhgtphhtthhopegtvghllhgrrhesihgvthhfrdhorhhg Archived-At: Subject: Re: [Cellar] Update specification language: CodecPrivate element MUST be set for H264 in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 27 Dec 2020 16:15:52 -0000 On 27/12/2020 16:33, guest271314 wrote: > Cure that by conspicuously and unambiguously including wording in the > standard/specification that " CodecPrivate element MUST be set for > H264 in Matroska". CodecPrivate in Matroska general specification is not mandatory, as this status depends on the coding format (mandatory for H.264, not mandatory for MPEG-2 etc). >From https://github.com/ietf-wg-cellar/matroska-specification/blob/master/codec_specs.md#v_mpeg4isoavc "The Private Data contains a AVCDecoderConfigurationRecord structure, [...]" This is not the IETF "MUST" but seems clear (affirmative sentence) that CodecPrivate is mandatory in the case of the H.264 mapping. Do you mean that we should be even more clear in 2 places? - in CodecPrivate definition, something like CodecPrivate is mandatory if specified as such ("MUST") in the corresponding codec mapping specification. - in H.264 codec mapping definition, something like The CodecPrivate block MUST contain a AVCDecoderConfigurationRecord structure [...] Jérôme From nobody Sun Dec 27 08:35:11 2020 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 B1C873A0C25 for ; Sun, 27 Dec 2020 08:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.365 X-Spam-Level: X-Spam-Status: No, score=-0.365 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FROM_SUSPICIOUS_NTLD=0.499, PDS_OTHER_BAD_TLD=1.236, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bunkus.online 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 a8mdDd2GMWXM for ; Sun, 27 Dec 2020 08:35:08 -0800 (PST) Received: from liselle.bunkus.org (liselle.bunkus.org [144.76.140.85]) (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 1AFAB3A0C16 for ; Sun, 27 Dec 2020 08:35:07 -0800 (PST) Received: from sweet-chili.int.bunkus.org (sweet-chili.int.bunkus.org [192.168.191.4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by liselle.bunkus.org (Postfix) with ESMTPS id 77D6E91B9AE; Sun, 27 Dec 2020 17:35:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bunkus.online; s=dkim; t=1609086903; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=J9mVG02TPU4RNAm4ydeOmK0ZFXxrHxdKucTrzH537Uc=; b=EO2V7YjqA/1/Zt4fMPgeKmlzO+F6FSLMuF8a8oe1MeVWs+030DSb5nYsbpGVxilmb6+cRz HSxGzJQYVceimBJ1WjAuhRLTIfdr5J0YUnp1S7ttptVa2HWvTytK++Qntm+cKw8yBu81/0 C/PP3/XwlCHiNhN095X7hk8iEwAnU5A= Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.int.bunkus.org (Postfix) with ESMTP id 4403542CC856; Sun, 27 Dec 2020 17:35:03 +0100 (CET) References: <0baf7cee-e8f1-7b3f-7312-5ef45342c07e@mediaarea.net> User-agent: mu4e 1.4.13; emacs 27.1 From: Moritz Bunkus To: Jerome Martinez Cc: guest271314 , cellar@ietf.org In-reply-to: <0baf7cee-e8f1-7b3f-7312-5ef45342c07e@mediaarea.net> Message-ID: <87im8n5hs9.fsf@bunkus.online> Date: Sun, 27 Dec 2020 17:35:03 +0100 MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] Update specification language: CodecPrivate element MUST be set for H264 in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 27 Dec 2020 16:35:10 -0000 Hey, while it's true that _from the EBML PoV_ the CodecPrivate element isn't mandatory, it still must be present for certain codecs in order for them to be decodable. So yes, their request is that we say something like: "for Codec == V_ABC/DEF/GHI the CodecPrivate element MUST be present. It MUST contain data according to ReferenceToSomeOtherStandard." Not only that the content MUST contain data following certain format, but also that the element MUST be present. Kind regards, mosu From nobody Sun Dec 27 08:38:40 2020 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 DBA123A0C26 for ; Sun, 27 Dec 2020 08:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 MVc48abe8AUz for ; Sun, 27 Dec 2020 08:38:36 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 6921F3A09C1 for ; Sun, 27 Dec 2020 08:38:36 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id v126so7179281qkd.11 for ; Sun, 27 Dec 2020 08:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=gR00bo+2KRFZVl9ZLF3RsO+5vY/fKWc1w5RaHQgP3js=; b=cI3At+PGa4kovXmn0VnhsB1yOp8itPSvhI74ew7s3kmI3ZuMPIeU9inSnf6IzbSFD8 THW3zqMJgD80Sd+8COhTzJRyXByHp0TzWs8WC1ovzUlsaJg/i18usXA84a80CaxyL7vn 2LdeaqUMsrStWCrXBkE469Oz+dQsRTi4niE/9RYnU60OY2cNwDdA4eH7TwWEPCtNgI2x gi0MMds6R6cnsOkgHGV9V1wV9ZoWp/2CXWUPdL2cRJyph2F1MS9JoREo21/IGJlnvxG7 9ieW4fFKiRLXZRvfuU3Ofz5B5cJwrYuXCIXoSSzm7rjTGf6M8XKKue+fQoaE0ooAqv7H 8xUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=gR00bo+2KRFZVl9ZLF3RsO+5vY/fKWc1w5RaHQgP3js=; b=jguYV0McXhkcjVSp4J/BpujyncpEjhrjAkIILQm8WehYyGlTLARwGrCunLv9h4VUoV ZXDh3AwRWhz2vmOLRGQZ4UywctrAkwdqaGVUlKY/tBZje8bqtw6q1mgfW51o5K3qKdLA M+ZnjM+Edn/La/N5+1UtmVKwP7K/Kx3vsJGEud2nISMShQ6SZwo0NT3+f0JMFcuk6l3a bZaofshZSrRAHuPjO3JPl9ZkJhWYEn/UQLIyBKr0X2PlpGBw2kADmpKGheHi9a0yw3HZ sOMnvbrWgoFJmJxKiVBGxNYxCnKStKLFtHclZsukXdOzH0QpCbZYepROgh3vqGqZMHgm nDAg== X-Gm-Message-State: AOAM532zRiYt9UPaAJhJFe3ehKzik9B0ihjwK2ae5PMOIwEUn5QRT7Ts JY6uHEV2NihR/fzmGOTENDT5bb9bpYhFwWKLIKbk/Z+FpPQ= X-Google-Smtp-Source: ABdhPJw8uXeMN8XItNHb0jR1EkWhC/gRhipIfb5ZTJGQNSOu3vG35dR+10PrUpsx0k1Phc/hpdC6NB/fEvx2eeZFeFw= X-Received: by 2002:a05:620a:4047:: with SMTP id i7mr41026739qko.3.1609087115288; Sun, 27 Dec 2020 08:38:35 -0800 (PST) MIME-Version: 1.0 References: <0baf7cee-e8f1-7b3f-7312-5ef45342c07e@mediaarea.net> In-Reply-To: From: guest271314 Date: Sun, 27 Dec 2020 08:38:23 -0800 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary="000000000000eb652a05b774c979" Archived-At: Subject: [Cellar] Fwd: Update specification language: CodecPrivate element MUST be set for H264 in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 27 Dec 2020 16:38:38 -0000 --000000000000eb652a05b774c979 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---------- Forwarded message --------- From: guest271314 Date: Sun, Dec 27, 2020 at 8:36 AM Subject: Re: [Cellar] Update specification language: CodecPrivate element MUST be set for H264 in Matroska To: Jerome Martinez Alternatively, if your conclusion is that the specification/standard is clear right now, can you kindly inform the Chrome authors of the same, and their omission of the element is non-compliant with the specification/standard at https://bugs.chromium.org/p/chromium/issues/detail?id=3D601636#c_ts16090799= 78 so that there will be no quarter for confusion as to Chrome MediaRecorder implementation being non-conformant with the sections that you cited. Either way Chrome authors need to be aware of this issue from the canonical source. On Sun, Dec 27, 2020 at 8:15 AM Jerome Martinez wrote: > On 27/12/2020 16:33, guest271314 wrote: > > Cure that by conspicuously and unambiguously including wording in the > > standard/specification that " CodecPrivate element MUST be set for > > H264 in Matroska". > > CodecPrivate in Matroska general specification is not mandatory, as this > status depends on the coding format (mandatory for H.264, not mandatory > for MPEG-2 etc). > > From > > https://github.com/ietf-wg-cellar/matroska-specification/blob/master/code= c_specs.md#v_mpeg4isoavc > "The Private Data contains a AVCDecoderConfigurationRecord structure, > [...]" > This is not the IETF "MUST" but seems clear (affirmative sentence) that > CodecPrivate is mandatory in the case of the H.264 mapping. > > Do you mean that we should be even more clear in 2 places? > - in CodecPrivate definition, something like CodecPrivate is mandatory > if specified as such ("MUST") in the corresponding codec mapping > specification. > - in H.264 codec mapping definition, something like The CodecPrivate > block MUST contain a AVCDecoderConfigurationRecord structure [...] > > J=C3=A9r=C3=B4me > > --000000000000eb652a05b774c979 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


---------- Forwarded message ---------
From: guest271314 <guest271314@gmail.com>= ;
Date: Sun, Dec 27, 2020 at 8:36 AM
Subject: Re: [Cellar] Upd= ate specification language: CodecPrivate element MUST be set for H264 in Ma= troska
To: Jerome Martinez <j= erome@mediaarea.net>


Alternatively= , if your conclusion is that the specification/standard is clear right now,= can you kindly inform the Chrome authors of the same, and their omission o= f the element is non-compliant with the specification/standard at=C2=A0https://bugs.chromium.org/p/chromium/issues/de= tail?id=3D601636#c_ts1609079978 so that there will be no quarter for co= nfusion as to Chrome MediaRecorder implementation being non-conformant with= the sections that you cited.=C2=A0

Either way Chrome au= thors need to be aware of this issue from the canonical source.
=
On Sun= , Dec 27, 2020 at 8:15 AM Jerome Martinez <jerome@mediaarea.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">On 27/12/2020 16:33, guest= 271314 wrote:
> Cure that by conspicuously and unambiguously including wording in the =
> standard/specification that "=C2=A0CodecPrivate element MUST be s= et for
> H264 in Matroska".

CodecPrivate in Matroska general specification is not mandatory, as this status depends on the coding format (mandatory for H.264, not mandatory for MPEG-2 etc).

>From
htt= ps://github.com/ietf-wg-cellar/matroska-specification/blob/master/codec_spe= cs.md#v_mpeg4isoavc
"The Private Data contains a AVCDecoderConfigurationRecord structure, = [...]"
This is not the IETF "MUST" but seems clear (affirmative sentence= ) that
CodecPrivate is mandatory in the case of the H.264 mapping.

Do you mean that we should be even more clear in 2 places?
- in CodecPrivate definition, something like CodecPrivate is mandatory
if specified as such ("MUST") in the corresponding codec mapping =
specification.
- in H.264 codec mapping definition, something like The CodecPrivate
block MUST contain a AVCDecoderConfigurationRecord structure [...]

J=C3=A9r=C3=B4me

--000000000000eb652a05b774c979-- From nobody Sun Dec 27 08:47:32 2020 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 82F5D3A0C2F for ; Sun, 27 Dec 2020 08:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 h01Z9UwylOYD for ; Sun, 27 Dec 2020 08:47:28 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 B5BBE3A0C2E for ; Sun, 27 Dec 2020 08:47:28 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id h4so7254262qkk.4 for ; Sun, 27 Dec 2020 08:47:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=lnmQQA2+NbSJiniyBV4LSSMcbOin3azopIqRe0UISWY=; b=s5oo2XyE3M6ljMas7Yj/L1kJLDKlVvc0hKQ2PoFmZ5SHf5UNEE4KcQWjDwVii/vyt1 WSLoG2tcXpv5xHKs/43YOSlja2GKm3dMLNwuPtEpJoV+G0aIKQoXlWxjm81DDeDTp57G 5hksk2tr0zg1IYWIWqFcWziBEI3X3FBGCqzYZS7H0l8TTMXNQltUkbN2Liiyt1c/j/X3 ngJXkLQbAZiavK7BxKHEKJZwTTWee0LX2LF628Ux0NWDI5bampX2orBX3q6Ey0JwvVwV iONJX/u6/C+iEq4mfBdsdoFy00iu3cqLbLCeNOf7CgVYtqRw7uFXxH8/wABhC1Z8MZRH o1hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=lnmQQA2+NbSJiniyBV4LSSMcbOin3azopIqRe0UISWY=; b=SmaH40ILpzklGlHkHeybI/5aGbtbh8t8pWCGwtSsB0ekrZDSySZGf/vaSDhpFIePY8 VZtWb7szQ6EZF0Y8vIsY8+WvVe/R68y1Thd/vXHzugzonPv4xAQ6kE2nfUGpVcu5wKuV jJIYtD1ZjssqS39Y1W84e+VrVB/X/nAIIDN+RIPAn/xf0hcGcbz6/2u59Owee4rxGF/7 8wUPHGKqHk6NC9Vmcba9ucH10+BDCygJr5929tTK4LiCs4FUr7Sqwuncz09f5v2Pknqh wFrT+gDhO1ABSxzDwVtBWmj1O75u6yf+haLJthuTzq3qYxHZVnodRFlK9yCX/n34/7Ps ZUtw== X-Gm-Message-State: AOAM531ryjfzw6EtFIfVHHq0btTWpcSsrBFHRGhwxW91un2rVvgK+Y1w mEpGESfDm5nIdGocbpAkUkx9Lxc5Z+kDgRHk1eLbitJNAhk= X-Google-Smtp-Source: ABdhPJyIbth8ld2LdIXrIc1vZkFxYcQ4X3gqD1e8F3Vk9EXKI0R3dLZVVe+NhLPW4L3nvX4DUcrJse2qYdJbbRhNwoo= X-Received: by 2002:a37:9b8d:: with SMTP id d135mr39859503qke.338.1609087647580; Sun, 27 Dec 2020 08:47:27 -0800 (PST) MIME-Version: 1.0 References: <0baf7cee-e8f1-7b3f-7312-5ef45342c07e@mediaarea.net> In-Reply-To: From: guest271314 Date: Sun, 27 Dec 2020 08:47:16 -0800 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary="000000000000a586db05b774e947" Archived-At: Subject: [Cellar] Fwd: Update specification language: CodecPrivate element MUST be set for H264 in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 27 Dec 2020 16:47:31 -0000 --000000000000a586db05b774e947 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable ---------- Forwarded message --------- From: guest271314 Date: Sun, Dec 27, 2020 at 8:31 AM Subject: Re: [Cellar] Update specification language: CodecPrivate element MUST be set for H264 in Matroska To: Jerome Martinez Do you mean that we should be even more clear in 2 places? > - in CodecPrivate definition, something like CodecPrivate is mandatory > if specified as such ("MUST") in the corresponding codec mapping > specification. > - in H.264 codec mapping definition, something like The CodecPrivate > block MUST contain a AVCDecoderConfigurationRecord structure [...] Yes. That is what the request for updating the standard/specification states. Evidently that information (wording; language) was not clear enough for Chrome authors when they implemented H264 encoding in Matroska container for MediaRecorder. Since your organization is the authority in this matter it would be helpful to inform the Chrome authors of their omission of the CodecPrivate element - otherwise nothing will change and users in the field will still not be able to extract H264 tracks from the resulting Matroska file that Chrome MediaRecorder implementation produces when mimeType is set to 'video/x-matroska;codecs=3Dh264' or 'video/x-matroska;codecs=3Davc1'. On Sun, Dec 27, 2020 at 8:15 AM Jerome Martinez wrote: > On 27/12/2020 16:33, guest271314 wrote: > > Cure that by conspicuously and unambiguously including wording in the > > standard/specification that " CodecPrivate element MUST be set for > > H264 in Matroska". > > CodecPrivate in Matroska general specification is not mandatory, as this > status depends on the coding format (mandatory for H.264, not mandatory > for MPEG-2 etc). > > From > > https://github.com/ietf-wg-cellar/matroska-specification/blob/master/code= c_specs.md#v_mpeg4isoavc > "The Private Data contains a AVCDecoderConfigurationRecord structure, > [...]" > This is not the IETF "MUST" but seems clear (affirmative sentence) that > CodecPrivate is mandatory in the case of the H.264 mapping. > > Do you mean that we should be even more clear in 2 places? > - in CodecPrivate definition, something like CodecPrivate is mandatory > if specified as such ("MUST") in the corresponding codec mapping > specification. > - in H.264 codec mapping definition, something like The CodecPrivate > block MUST contain a AVCDecoderConfigurationRecord structure [...] > > J=C3=A9r=C3=B4me > > --000000000000a586db05b774e947 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


---------- Forwarded message ---------
From: guest271314 <guest271314@gmail.com>= ;
Date: Sun, Dec 27, 2020 at 8:31 AM
Subject: Re: [Cellar] Upd= ate specification language: CodecPrivate element MUST be set for H264 in Ma= troska
To: Jerome Martinez <j= erome@mediaarea.net>


Do you mean that we should be even mor= e clear in 2 places?
- in CodecPrivate definition, something like CodecP= rivate is mandatory
if specified as such ("MUST") in the corre= sponding codec mapping
specification.
- in H.264 codec mapping defini= tion, something like The CodecPrivate
block MUST contain a AVCDecoderCon= figurationRecord structure [...]

Yes. That is wh= at the request for updating the standard/specification states. Evidently th= at information (wording; language) was not clear enough for Chrome authors = when they implemented H264 encoding in Matroska container for MediaRecorder= .

Since your organization is the authority=C2=A0in this = matter it would be helpful to inform the Chrome authors of their omission o= f the CodecPrivate element - otherwise nothing will change and users in the= field will still not be able to extract H264 tracks from the resulting Mat= roska file that Chrome MediaRecorder implementation produces when mimeType = is set to 'video/x-matroska;codecs=3Dh264' or 'video/x-matroska= ;codecs=3Davc1'.

On Sun, Dec 27, 2020 at 8:15 AM Jerome Martinez &= lt;jerome@mediaar= ea.net> wrote:
On 27/12/2020 16:33, guest271314 wrote:
> Cure that by conspicuously and unambiguously including wording in the =
> standard/specification that "=C2=A0CodecPrivate element MUST be s= et for
> H264 in Matroska".

CodecPrivate in Matroska general specification is not mandatory, as this status depends on the coding format (mandatory for H.264, not mandatory for MPEG-2 etc).

>From
htt= ps://github.com/ietf-wg-cellar/matroska-specification/blob/master/codec_spe= cs.md#v_mpeg4isoavc
"The Private Data contains a AVCDecoderConfigurationRecord structure, = [...]"
This is not the IETF "MUST" but seems clear (affirmative sentence= ) that
CodecPrivate is mandatory in the case of the H.264 mapping.

Do you mean that we should be even more clear in 2 places?
- in CodecPrivate definition, something like CodecPrivate is mandatory
if specified as such ("MUST") in the corresponding codec mapping =
specification.
- in H.264 codec mapping definition, something like The CodecPrivate
block MUST contain a AVCDecoderConfigurationRecord structure [...]

J=C3=A9r=C3=B4me

--000000000000a586db05b774e947-- From nobody Sun Dec 27 11:21:43 2020 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 28B203A0C74 for ; Sun, 27 Dec 2020 11:21:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJx1lIagUFaq for ; Sun, 27 Dec 2020 11:21:40 -0800 (PST) Received: from 5.mo3.mail-out.ovh.net (5.mo3.mail-out.ovh.net [87.98.178.36]) (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 D1BE53A0C6A for ; Sun, 27 Dec 2020 11:21:39 -0800 (PST) Received: from player695.ha.ovh.net (unknown [10.108.42.168]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id 72071270023 for ; Sun, 27 Dec 2020 20:21:36 +0100 (CET) Received: from mediaarea.net (p548f9a4c.dip0.t-ipconnect.de [84.143.154.76]) (Authenticated sender: jerome@mediaarea.net) by player695.ha.ovh.net (Postfix) with ESMTPSA id E3BC919665F41; Sun, 27 Dec 2020 19:21:33 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-95G001b95a5b8e-2528-4833-ba9f-8042e05eb595, BBADD9AAB17F2EC7E8DDA773C58BBF48E3EE42CD) smtp.auth=jerome@mediaarea.net X-OVh-ClientIp: 84.143.154.76 To: cellar@ietf.org, guest271314 References: <0baf7cee-e8f1-7b3f-7312-5ef45342c07e@mediaarea.net> From: Jerome Martinez Message-ID: Date: Sun, 27 Dec 2020 20:21:33 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------230B6A162572BD2B0684B82A" Content-Language: en-US X-Ovh-Tracer-Id: 16050829074770890801 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrvddujedguddviecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurhepuffvfhfhkffffgggjggtsegrtderredtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpedtffelteeuvdehfeffgfeljedvlefhtdetleelvefgkefhveeufefgkefhgffftdenucffohhmrghinheptghhrhhomhhiuhhmrdhorhhgnecukfhppedtrddtrddtrddtpdekgedrudegfedrudehgedrjeeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrieelhedrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvthdprhgtphhtthhopegtvghllhgrrhesihgvthhfrdhorhhg Archived-At: Subject: Re: [Cellar] Fwd: Update specification language: CodecPrivate element MUST be set for H264 in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 27 Dec 2020 19:21:42 -0000 This is a multi-part message in MIME format. --------------230B6A162572BD2B0684B82A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 27/12/2020 17:38, guest271314 wrote: > > Alternatively, if your conclusion is that the specification/standard > is clear right now, can you kindly inform the Chrome authors of the > same, and their omission of the element is non-compliant with the > specification/standard [...] I am pretty sure that this is clear for them as the files can not be decoded correctly, just that what Google uses is more VP8/VP9/AV1/Opus, and these coding formats don't need CodecPrivate. And from https://bugs.chromium.org/p/chromium/issues/detail?id=601636#c2, it looks like they don't wait for a change in the spec. Anyway, better to be clear, I'll send a PR about that. Jérôme --------------230B6A162572BD2B0684B82A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 27/12/2020 17:38, guest271314 wrote:

Alternatively, if your conclusion is that the specification/standard is clear right now, can you kindly inform the Chrome authors of the same, and their omission of the element is non-compliant with the specification/standard [...]

I am pretty sure that this is clear for them as the files can not be decoded correctly, just that what Google uses is more VP8/VP9/AV1/Opus, and these coding formats don't need CodecPrivate.
And from https://bugs.chromium.org/p/chromium/issues/detail?id=601636#c2, it looks like they don't wait for a change in the spec.
Anyway, better to be clear, I'll send a PR about that.

Jérôme


--------------230B6A162572BD2B0684B82A-- From nobody Sun Dec 27 14:27:59 2020 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 CE2013A0CCD for ; Sun, 27 Dec 2020 14:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=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 vUF5uhOGnRfb for ; Sun, 27 Dec 2020 14:27:55 -0800 (PST) Received: from 18.mo6.mail-out.ovh.net (18.mo6.mail-out.ovh.net [46.105.73.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 ADCDC3A0CCC for ; Sun, 27 Dec 2020 14:27:55 -0800 (PST) Received: from player715.ha.ovh.net (unknown [10.108.57.95]) by mo6.mail-out.ovh.net (Postfix) with ESMTP id 8FB83235BE0 for ; Sun, 27 Dec 2020 23:27:52 +0100 (CET) Received: from mediaarea.net (p548f9a4c.dip0.t-ipconnect.de [84.143.154.76]) (Authenticated sender: jerome@mediaarea.net) by player715.ha.ovh.net (Postfix) with ESMTPSA id A0A94195718C9; Sun, 27 Dec 2020 22:27:49 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-95G00161cf9347-4502-4c16-90e3-bc54885144ab, BBADD9AAB17F2EC7E8DDA773C58BBF48E3EE42CD) smtp.auth=jerome@mediaarea.net X-OVh-ClientIp: 84.143.154.76 To: cellar@ietf.org, guest271314 References: From: Jerome Martinez Message-ID: <61a08722-61e1-2506-cf95-7a8f824e9d1e@mediaarea.net> Date: Sun, 27 Dec 2020 23:27:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Ovh-Tracer-Id: 749567864434397233 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrvddujedgudeigecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecunecujfgurhepuffvfhfhkffffgggjggtgfesthejredttdefjeenucfhrhhomheplfgvrhhomhgvucforghrthhinhgviicuoehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvtheqnecuggftrfgrthhtvghrnhepieeuveektdfhtdeguddvieefgfeugeehgfeiiefgtddvieegleeggeefueetleffnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkpheptddrtddrtddrtddpkeegrddugeefrdduheegrdejieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejudehrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh Archived-At: Subject: Re: [Cellar] Update specification language: CodecPrivate element MUST be set for H264 in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 27 Dec 2020 22:27:58 -0000 On 27/12/2020 16:33, guest271314 wrote: > Evidently CodecPrivate element being required/mandatory for H264 in > Matroska container is not clear nor conspicuous enough in the > standard/specification. Proposal of changes: https://github.com/ietf-wg-cellar/matroska-specification/pull/446