From nobody Thu Jan 2 05:55:46 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 C60B512008D for ; Thu, 2 Jan 2020 05:55:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWM7QXBy3I1e for ; Thu, 2 Jan 2020 05:55:42 -0800 (PST) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67C9512008F for ; Thu, 2 Jan 2020 05:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2019123101; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:Subject:To:From; bh=skfYWrfJcvdNHOUBT5/6xJL+KCwTZs8BDrHbySzH4vM=; b=B+Sl77vqJFxeECnzLLNrpfNmGNSn5zgmTtWeN+cFAhX7mUPVPda3S50RlA0g9cljelwAbSHO4chKgXW9gIYZEOCfNI9YdkfnzusotFar4pTNqPqQocWfK8KCN+5EvFgKReRWhs+t47cdbu7S4bEA0RdiL0obcIQBAb3p2UC4k0ZR5iih8CjP8p38+Lybv/VJlLAqQArt3h1IwgHohFloJkXS3Am3IG1PiiCFl5dP5SlwIE4EJ0YNg+ERkKS+5ikfUqRu+YzEUBeYMi+iBQFyefu6OiWiPnQemaVxLe6wuSOAnD7wmVwaZYy/16Z4ZsJKiUfsZX/5feuMN2V94Nzn2g==; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:37690) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1in0wj-0001RA-1c; Thu, 02 Jan 2020 14:55:29 +0100 Received: from sweet-chili.int.bunkus.org (unknown [10.55.5.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by liselle.bunkus.org (Postfix) with ESMTPS id 60672654000A; Thu, 2 Jan 2020 14:55:29 +0100 (CET) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.int.bunkus.org (Postfix) with ESMTP id D36411B43140; Thu, 2 Jan 2020 14:55:28 +0100 (CET) User-agent: mu4e 1.2.0; emacs 26.3 From: Moritz Bunkus To: help Questions , Cellar list Date: Thu, 02 Jan 2020 14:55:28 +0100 Message-ID: <878smqrmi7.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Cellar] MKVToolNix v42.0.0 released 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, 02 Jan 2020 13:55:45 -0000 Hey everyone, I sincerely hope y'all have had a good start into the new year and are sufficiently recovered from whatever you've done over the last couple of days. I've been busy fixing up release v42 of MKVToolNix. Yeah, I'm that boring :) In this release a lot of source code changed under the hood as I replaced two external libraries (Boost's "optional" and "regex" libraries) with ones from the C++ Standard Library. I tested extensively, but it's quite possible there are bugs lurking due to those changes. If you find one, please file a bug on Gitlab ( https://gitlab.com/mbunkus/mkvtoolnix/issues/ ) as usual. Thanks! Apart from that there were many, many changes; see below for the list. Dear package maintainers: apart from the aforementioned library changes (Boost's "optional" and "regex" are no longer used, they've been replaced with "std::optional" and "std::regex") four new translations of man pages have been added. The required compiler versions haven't changed, though: gcc =E2=89=A5 7 and clang =E2=89=A5 4 should work fine. Please adjust your= packaging instructions accordingly. And now for the usual boilerplate: Here are the usual links: =E2=80=A6to the source code: https://mkvtoolnix.download/source.html =E2=80=A6to the binaries: https://mkvtoolnix.download/downloads.html The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available of the course of the next couple of hours. Here are the NEWS since the previous release: ------------------------------------------------------------ # Version 42.0.0 "Overtime" 2020-01-02 ## New features and enhancements * mkvmerge: added an option for creating byte-identical files: `--deterministic `. Part of the implementation of #2698. * mkvmerge: Matroska reader: mkvmerge will remove the `icpf` atom headers if they're present in frames read from Matroska files. Implements #2692. * mkvmerge: MP4 reader: ALAC tracks: the number of channels, sampling frequency and bit depth are now taken from the bitstream in order to fix bogus values on the container level. Implements #2714. * mkvpropedit: when changing track UIDs the referring elements in existing chapters & tags will be updated automatically, too. Part of the implementation of #2700. * mkvinfo: when the option `-p`/`--hex-positions` is used, element positions will be output regardless of the verbosity level. Part of the implementat= ion of #2713. * mkvinfo: added the option `-P`/`--positions` for showing the position of each element in decimal regardless of the verbosity level used. Part of t= he implementation of #2713. * mkvinfo: added the option `-o`/`--continue` for continuing processing when the first cluster is encountered regardless of the verbosity level used. Part of the implementation of #2713. * mkvinfo: added the option `-a`/`--all` for outputting all sub-elements (e= ven cues & seek head entries) and not stopping at the first cluster regardless of the verbosity level used. Part of the implementation of #2713. * MKVToolNix GUI: multiplexer: added an option in the preferences for disabling adding cover images from Blu-ray discs. Implements #2693. * MKVToolNix GUI: multiplexer: added mkvmerge's new `--deterministic` option in the "additional command-line options" dialog. Part of the implementati= on of #2698. * MKVToolNix GUI: header editor:: when changing track UIDs the referring elements in existing chapters & tags will be updated automatically, too. Part of the implementation of #2700. ## Bug fixes * mkvmerge: HEVC ES parser: fixed a bug in the slice parser calculating the size of a field which in turn could have led to the slice's type being re= ad wrong. Patch by Torsten Hauska. Fixes #2710. * mkvmerge: Matroska reader: fixed a segmentation fault when trying to read= a file that uses header removal compression but no removed bytes are present in the track headers. Fixes #2687. * mkvmerge: MPEG elementary stream parser: fixed an invalid memory access a= nd use of uninitialized memory that could happen under certain circumstances. Fixes #2690. * mkvmerge: RealMedia reader: fixed a division by zero when all audio timestamps were zero. Fixes #2689. * mkvmerge: RealMedia reader: fixed an invalid memory access in the video frame assembly code triggered by invalid data in the file. Fixes #2691. ## Build system changes * `std::optional` (C++17 feature) is now used instead of `boost::optional`. * `std::regex` is now used instead of `boost::regex`. ## Other changes * New man page translations into French, Italian, Russian and Chinese Traditional have been added. ------------------------------------------------------------ Have fun :) mosu From nobody Thu Jan 2 15:26:24 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 40DF4120105; Thu, 2 Jan 2020 15:26:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 zSlKVk51tSZF; Thu, 2 Jan 2020 15:26:20 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6980B1200C3; Thu, 2 Jan 2020 15:26:17 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 002NQEYC019202 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 2 Jan 2020 17:26:15 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578007576; bh=RWpafsbT5pX4x5o/EfRLCwKC93OvU1BEkYleTYKjJA4=; h=To:From:Subject:Date; b=iYIo1PFCP8vGGEG9D2z7pfJe9dbHvyit2tlWzDBi/ZXT974BHr2tiTqMMB8CFWe6G 9y9G+v9TZdXAesTKbIEmkLf00SoMqqfxZU9UUt8Fvo7Dwq54tsg2LYFbXj3BfmIxJ9 oYdz0maamo5bqLrVEbUxMzZh1r/VUVUnV9Wgwdec= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: draft-ietf-cellar-ffv1.all@ietf.org, cellar@ietf.org From: Adam Roach Message-ID: Date: Thu, 2 Jan 2020 17:26:07 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Cellar] AD Review: draft-ietf-cellar-ffv1 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, 02 Jan 2020 23:26:23 -0000 This is my AD review for draft-ietf-cellar-ffv1, which I am processing at Alexey Melinikov's request. Thanks to everyone who has taken the time to document these formats for publication as an RFC. I have identified a couple of issues that will need to be addressed prior to IETF last call (which are clearly identified below), as well as a number of smaller issues that can be addressed as normal IETF last call comments. --------------------------------------------------------------------------- §1: >  The latest version of this document is available at >  https://raw.github.com/FFmpeg/FFV1/master/ffv1.md >  (https://raw.github.com/FFmpeg/FFV1/master/ffv1.md) Please add a note to the RFC editor to remove this paragraph prior to publication (or remove the paragraph in the draft at this time). --------------------------------------------------------------------------- §2: >  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >  document are to be interpreted as described in [RFC2119]. Please update this to match the updated boilerplate given in RFC 8174. --------------------------------------------------------------------------- §2.2.1: >  The pseudo-code used is based upon the C programming >  language [ISO.9899.1990] and uses its "if/else", "while" and "for" >  functions as well as functions defined within this document. It's a minor nit, but these are keywords, not functions. --------------------------------------------------------------------------- §2.2.2: >  Note: the operators and the order of precedence are the same as used >  in the C programming language [ISO.9899.1990]. Is there a reason to cite C90 here instead of any of the four newer versions? --------------------------------------------------------------------------- §2.2.2: >  Note: the operators and the order of precedence are the same as used >  in the C programming language [ISO.9899.1990]. ... >  "a ^ b" means a raised to the b-th power. One of these two statements is incorrect: the "^" operator in C is a bitwise XOR, not a power operator. C has no built-in exponentiation operator, and relies on a library-provided `pow(a,b)` function. Because this introduces an ambiguity into the specification, it will need to be corrected before entering IETF last call. --------------------------------------------------------------------------- §2.2.2: >  "a >> b" means arithmetic right shift of two's complement integer >  representation of a by b binary digits. This needs to indicate whether the resulting value is sign-extended or zero-padded. We can't rely on C's definition here, as right shifting a signed value is implementation-defined by the standard:     The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an     unsigned type or if E1 has a signed type and a nonnegative value, the     value of the result is the integral part of the quotient of E1 / 2E2. If     E1 has a signed type and a negative value, the resulting value is     implementation-defined. Because this introduces an ambiguity into the specification, it will need to be corrected before entering IETF last call. --------------------------------------------------------------------------- §2.2.5: >  a~b,c.  the 'b,c'-th value of a sequence of a Please explain this with more words. I can't figure out what it means. --------------------------------------------------------------------------- §2.2.8: >  relies on its "Container" to store the "NumBytes" values, see the >  section on the Mapping FFV1 into Containers (#mapping-ffv1-into- >  containers). Nit: "...values; see the section..." Also, please replace the MD-style anchor with a section number. --------------------------------------------------------------------------- §3: >  For each "Slice" (as described in the section on Slices (#slice)) of >  a "Frame", the "Planes", "Lines", and "Samples" are coded in an order >  determined by the "Color Space" (see the section on Color Space >  (#color-spaces)).  Each "Sample" is predicted by the median predictor >  as described in the section of the Median Predictor (#median- >  predictor) from other "Samples" within the same "Plane" and the >  difference is stored using the method described in Coding of the >  Sample Difference (#coding-of-the-sample-difference). Please replace the MD-style anchors with section numbers. --------------------------------------------------------------------------- §3.4: >  context = Q_{0}[l - tl] + >            Q_{1}[tl - t] + >            Q_{2}[t - tr] + >            Q_{3}[L - l]  + >            Q_{4}[T - t] This is the first time in the document we're encountering Q. Please add a forward reference to its definition. --------------------------------------------------------------------------- §3.7.2: >  As an example, a "Frame" that is two "Pixels" wide and two "Pixels" >  high, could be comprised of the following structure: Nit: "...could be composed of the following structure:" OR "...could comprise the following structure:" --------------------------------------------------------------------------- §3.8.1.1: >  S_{i+1,C_{i}} =  zero_state_{S_{i,C_{i}}} XOR >            l_i =  L_i                      XOR >            t_i =  R_i - r_i                <== >            b_i =  0                        <==> >            L_i <  R_i - r_i Substantial parts of this syntax are undefined at this point in the document. Presumably "XOR" means "exclusive or," although it is unclear whether this is intended to be a boolean or bitwise operation. The "<==" and "<==>" notation is also without explanation, and I can't even make an educated guess at their intended meaning. There is no explanation what it might mean to combine a series of assignment operations (and one comparison operation) with these XOR, <==, and <==> symbols. This needs to be clarified (for all of figures 7 through 9) before the document can go to IETF last call. --------------------------------------------------------------------------- §3.8.1.1.1: >  Above describes the range decoding, encoding is defined as any >  process which produces a decodable bytestream. Would it be reasonable to include a non-normative example of one such process? --------------------------------------------------------------------------- §3.8.1.2: >  exact contexts used are best described by the >  following code, followed by some comments. I can't find the referenced comments. --------------------------------------------------------------------------- §3.8.1.2: > pseudo-code                                                   | type > --------------------------------------------------------------|----- >  void put_symbol(RangeCoder *c, uint8_t *state, int v, int \   | >  is_signed) {                                                  | >      int i;                                                    | >      put_rac(c, state+0, !v);                                  | >      if (v) {                                                  | >          int a= abs(v);                                        | >          int e= log2(a);                                       | >                                                                | >          for (i = 0; i < e; i++) {                             | >              put_rac(c, state+1+min(i,9), 1); //1..10         | > }                                                     | >                                                                | >          put_rac(c, state+1+min(i,9), 0);                      | >          for (i = e-1; i >= 0; i--) {                          | >              put_rac(c, state+22+min(i,9), (a>>i)&1); //22..31 | > }                                                     | >                                                                | >          if (is_signed) {                                      | >              put_rac(c, state+11 + min(e, 10), v < 0); //11..21| > }                                                     | > }                                                         | > }                                                             | The "type" column here appears superfluous, and should either employed or removed. The behavior of the function "put_rac" isn't defined anywhere. While the purpose of its first two parameters can be deduced from context, the purpose of the third parameter is baffling. For avoidance of doubt, please add a description of what this function does, and what its parameters mean. --------------------------------------------------------------------------- §3.8.1.6: >  The alternative state transition table has been built using iterative >  minimization of frame sizes and generally performs better than the >  default.  To use it, the coder_type (see the section on coder_type >  (#codertype)) MUST be set to 2 and the difference to the default MUST >  be stored in the "Parameters", see the section on Parameters >  (#parameters).  The reference implementation of FFV1 in FFmpeg uses >  this table by default at the time of this writing when Range coding >  is used. Please replace the MD-style anchors with section numbers. --------------------------------------------------------------------------- §3.8.2.1: > pseudo-code                                                   | type > --------------------------------------------------------------|----- >  int get_ur_golomb(k) {                                        | >      for (prefix = 0; prefix < 12; prefix++) {                 | >          if (get_bits(1)) {                                    | >              return get_bits(k) + (prefix << k)                | > }                                                     | > }                                                         | >      return get_bits(bits) + 11                                | > }                                                             | >                                                                | >  int get_sr_golomb(k) {                                        | >      v = get_ur_golomb(k);                                     | >      if (v & 1) return - (v >> 1) - 1;                         | >      else       return   (v >> 1);                             | >  } The "type" column here appears superfluous, and should either employed or removed. Please clarify the meaning of "ur" and "sr" in the function names. --------------------------------------------------------------------------- §3.8.2.1.1: >                       +----------------+-------+ >                       | bits           | value | >                       +================+=======+ >                       | 1              | 0     | >                       +----------------+-------+ >                       | 01             | 1     | >                       +----------------+-------+ >                       | ...            | ...   | >                       +----------------+-------+ >                       | 0000 0000 0001 | 11    | >                       +----------------+-------+ >                       | 0000 0000 0000 | ESC   | >                       +----------------+-------+ This is pretty confusing, not least of all because the base of the number on the right is unclear (given that all the shown values contain 1's and 0's exclusively). I would suggest:                         +----------------+-------+                         | bits           | value |                         +================+=======+                         | 1              | 0     |                         +----------------+-------+                         | 01             | 1     |                         +----------------+-------+                         | ...            | ...   |                         +----------------+-------+                         | 00 0000 0001   | 9     |                         +----------------+-------+                         | 000 0000 0001  | 10    |                         +----------------+-------+                         | 0000 0000 0001 | 11    |                         +----------------+-------+                         | 0000 0000 0000 | ESC   |                         +----------------+-------+ --------------------------------------------------------------------------- §3.8.2.2.1: > pseudo-code                                                   | type > --------------------------------------------------------------|----- > log2_run[41]={                                                | >   0, 0, 0, 0, 1, 1, 1, 1,                                      | >   2, 2, 2, 2, 3, 3, 3, 3,                                      | >   4, 4, 5, 5, 6, 6, 7, 7,                                      | >   8, 9,10,11,12,13,14,15,                                      | > 16,17,18,19,20,21,22,23,                                      | > 24,                                                           | > };                                                            | >                                                                | >  if (run_count == 0 && run_mode == 1) {                        | >      if (get_bits(1)) {                                        | >          run_count = 1 << log2_run[run_index];                 | >          if (x + run_count <= w) {                             | > run_index++;                                      | > }                                                     | >      } else {                                                  | >          if (log2_run[run_index]) {                            | >              run_count = get_bits(log2_run[run_index]);        | >          } else {                                              | >              run_count = 0;                                    | > }                                                     | >          if (run_index) {                                      | > run_index--;                                      | > }                                                     | >          run_mode = 2;                                         | > }                                                         | > }                                                             | The "type" column here appears superfluous, and should either employed or removed. >  The log2_run function is also used within [ISO.14495-1.1999]. The reference to "log2_run" as a "function" is perplexing, as log2_run is defined as an array in the above pseudocode. --------------------------------------------------------------------------- §3.8.2.3: Some light documentation of the "state" structure would make this pseudocode much easier to follow. --------------------------------------------------------------------------- §4: >  Within the following sub-sections, pseudo-code is used to explain the >  structure of each FFV1 bitstream component, as described in the >  section on Pseudo-Code (#pseudocode). Please replace the MD-style anchor with a section number. > +--------+-------------------------------------------+ >         | Symbol | Definition | > +========+===========================================+ >         | u(n)   | unsigned big endian integer using n bits | > +--------+-------------------------------------------+ >         | sg     | Golomb Rice coded signed scalar symbol | >         |        | coded with the method described in Signed | >         |        | Golomb Rice Codes (#golomb-rice-mode) | > +--------+-------------------------------------------+ >         | br     | Range coded Boolean (1-bit) symbol with | >         |        | the method described in Range binary | >         |        | values (#range-binary-values) | > +--------+-------------------------------------------+ >         | ur     | Range coded unsigned scalar symbol coded | >         |        | with the method described in Range non | >         |        | binary values (#range-non-binary-values) | > +--------+-------------------------------------------+ >         | sr     | Range coded signed scalar symbol coded | >         |        | with the method described in Range non | >         |        | binary values (#range-non-binary-values) | > +--------+-------------------------------------------+ Please replace the several MD-style anchors with a section number. --------------------------------------------------------------------------- §4: >  The same context that is initialized to 128 is used for all fields in >  the header. This phrasing is confusing, as it reads like it's referring to some previously-mentioned context that is best identified as containing "128." After convincing myself that I didn't miss such a thing, I *think* you might mean:    All fields in the header use the same context, which is    initialized to 128. Although, even with that adjustment, I'm not sure which header you're talking about. The only header mentioned anywhere earlier in the document is the "Slice Header," and that seems unlikely to be what you're referring to. --------------------------------------------------------------------------- §4.1: >              state_transition_delta[ i ]                       | sr ... >          QuantizationTableSet( i )                             | This psuedo-code appears to use both "[]" and "()" as array operators.  I understand this is only pseudocode, but please try to remain consistent with the meaning of operators. Also, "QuantiztionTableSet" is missing a type designation. --------------------------------------------------------------------------- §4.1.16: > +-------+--------------------------------------------+ >         | value | error detection/correction type | > +=======+============================================+ >         | 0     | 32-bit CRC on the global header | > +-------+--------------------------------------------+ >         | 1     | 32-bit CRC per slice and the global header | > +-------+--------------------------------------------+ >         | Other | reserved for future use | > +-------+--------------------------------------------+ I'm still perplexed by the intended meaning of "header." --------------------------------------------------------------------------- §4.2.3.4: >  FFV1 SHOULD use "V_FFV1" as the Matroska "Codec ID". Normative requirements on external documents make those documents normative dependencies. Please move "[Matroska]" from the "Informative References" section to the "Normative References" section. --------------------------------------------------------------------------- §4.1.17: >             +-------+-------------------------------------+ >             | value | relationship                        | >             +=======+=====================================+ >             | 0     | Frames are independent or dependent | >             |       | (keyframes and non keyframes)       | >             +-------+-------------------------------------+ >             | 1     | Frames are independent (keyframes   | >             |       | only)                               | >             +-------+-------------------------------------+ >             | Other | reserved for future use             | >             +-------+-------------------------------------+ > >                                 Table 14 I'm having a hard time understanding "Other" in this table. Section 4.3 defines "keyframe" to be of "br" type. I'm confused about how a boolean variable can take on more than two values. --------------------------------------------------------------------------- §4.4: >  Background: due to some non conforming >  encoders, some bitstreams where found with 40 extra bits >  corresponding to "error_status" and "slice_crc_parity", a decoder >  conforming to the revised specification could not do the difference >  between a revised bitstream and a buggy bitstream. This is hard to parse. I suggest rephrasing like:    Background: Due to some non-conforming    encoders, some bitstreams were found with 40 extra bits    corresponding to "error_status" and "slice_crc_parity". As a    result, a decoder conforming to the revised specification could not    distinguish between a revised bitstream and a buggy bitstream. --------------------------------------------------------------------------- §4.6: > pseudo-code                                                   | type > --------------------------------------------------------------|----- >  SliceContent( ) {                                             | >      if (colorspace_type == 0) {                               | >          for (p = 0; p < primary_color_count; p++) {           | >              for (y = 0; y < plane_pixel_height[ p ]; y++) {   | >                  Line( p, y )                                  | > }                                                 | > }                                                     | >      } else if (colorspace_type == 1) {                        | >          for (y = 0; y < slice_pixel_height; y++) {            | >              for (p = 0; p < primary_color_count; p++) {       | >                  Line( p, y )                                  | > }                                                 | > }                                                     | > }                                                         | > }                                                             | Without a "type" indicated on the "Line( p, y )" lines, this encoding appears to be ambiguous. --------------------------------------------------------------------------- §4.7: > pseudo-code                                                   | type > --------------------------------------------------------------|----- >  Line( p, y ) {                                                | >      if (colorspace_type == 0) {                               | >          for (x = 0; x < plane_pixel_width[ p ]; x++) {        | >              sample_difference[ p ][ y ][ x ]                  | > }                                                     | >      } else if (colorspace_type == 1) {                        | >          for (x = 0; x < slice_pixel_width; x++) {             | >              sample_difference[ p ][ y ][ x ]                  | > }                                                     | > }                                                         | > }                                                             | Although redundant with the request above regarding section 4.6, please add "type" indicators for the "sample_difference[ p ][ y ][ x ]" lines. --------------------------------------------------------------------------- §4.7.4: >  "Sample" value is computed based on median predictor and context >  described in the section on Samples (#samples). Please replace the MD-style anchor with a section number. --------------------------------------------------------------------------- §4.9 >  The Quantization Table Sets are stored by storing the number of equal >  entries -1 of the first half of the table (represented as "len - 1" >  in the pseudo-code below) using the method described in Range Non >  Binary Values (#range-non-binary-values). Please replace the MD-style anchor with a section number. --------------------------------------------------------------------------- §6: While it does provide compression (my understanding is that a typical ratio is about 2:1), FFV1 still produces a very large bitstream, due to its lossless properties. This does present some security challenges that need to be cited. I would expect this document to include text that is roughly equivalent to the final three paragraphs of RFC 4175, Section 8. --------------------------------------------------------------------------- §7: Please replace the seven various MD-style anchors with section numbers. --------------------------------------------------------------------------- §7: >  This registration is done using the template defined in [RFC6838] and >  following [RFC4855]. To avoid the need to dereference the cited RFC, please also include the IANA table name ("Media Types") in this paragraph. --------------------------------------------------------------------------- §7: >  This >  media type is framed binary data Section 4.8 of [RFC6838]. I think this means to say something like:    This media type is framed binary data; see Section 4.8 of [RFC6838]. --------------------------------------------------------------------------- §7: >  Published specification: > >  [I-D.ietf-cellar-ffv1] and RFC XXXX. I can't figure out why two documents are mentioned here -- it would seem that both of these refer to the same document. --------------------------------------------------------------------------- > 9.  Appendixes > > 9.1.  Decoder implementation suggestions > > 9.1.1.  Multi-threading Support and Independence of Slices This seems like an unnecessarily deep nesting for its contents. Consider collapsing into a single section instead of three nested sections. --------------------------------------------------------------------------- Section 10 should contain instructions to the RFC editor to remove it prior to publication. Thanks! /a From nobody Sun Jan 5 00:58:52 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 45A291200B7 for ; Sun, 5 Jan 2020 00:58:45 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GLniYjyWCk9c for ; Sun, 5 Jan 2020 00:58:42 -0800 (PST) Received: from mail-pl1-x641.google.com (mail-pl1-x641.google.com [IPv6:2607:f8b0:4864:20::641]) (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 CD71C12001A for ; Sun, 5 Jan 2020 00:58:42 -0800 (PST) Received: by mail-pl1-x641.google.com with SMTP id c13so20669125pls.0 for ; Sun, 05 Jan 2020 00:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1qLoUNnnbmaug45wr47qnw9gOXUyu8LyCTvwxJOqkwU=; b=CC5n2alPn2mGMTM9Exn2zvGP3/LQugelNXaRa1ml3yaXkUY18tieHU1NZMYdedQX2z RyzeK40s5GDir8+wZB0Gs9xNpAIGO2uH4kM59jIEczYp3E9+BeRgyXZ62fqePdW2r+SH ofQJXkzWt2TfsfmCMMTeF4sCZygtagXUjFwbBsdh3KnA/SyU6CbuJHNXMYpHHXuoW/G3 4u0HNKNZIXmyVHuwY5PMa7jv5kf51XqZmQ7h0l08FQ/r8u7fl4FreWAJkhvfE6imq2p7 K9ELtY5XA5EKT1JdUk21aVRP+rsIggF7HPXUXe1IwbBGkSvwMh/k16lVU+/b7zRUBXN0 /UWg== 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=1qLoUNnnbmaug45wr47qnw9gOXUyu8LyCTvwxJOqkwU=; b=KJZhIuNEmjgxG7NK2V5soVcBG/tlVHgNdhf0ROkW7mLr+XUFAsBooxPhKW/64VpTc2 so3VboBW/mnD9EBlkGawHQpXgwhIVxW14CVekcOsGaNCXuj3seJTbW1uCfjCxbb+gfLp pWhliFBactR/BF3b6QUdnpqpEpSogvvRv26q1x+gWMY5ipLzkvAqwYLU3FrhibB0bMC+ 0tzyumXBp2L0k0cIYSPJ1IgfTPBK2ds5nKfix9H9tlNsqoBGJ0la7uwmo/OA7uCKZCO6 8NqZ0n/XIrOMHc153mOeMc20MPlSt2yagejOOd9RxIkzSAovl1MtzBOF7XHGVeufjxKV 3+PA== X-Gm-Message-State: APjAAAUa4Yk00tTj76XK6nPgpxLjBs+X9/Pzu+q6JprEPYerZJBzDFPs GQGOWnln1NQnWI01nRDkb846oHbU1Lxq4lM/9aurXQ== X-Google-Smtp-Source: APXvYqzrWiiRaHx4fjdITuq0fG6ULvDX4nHoKt1GPfHxZbGbIUIu8DxjhyS2Pyo1Oapi+DRh2QE2S7fzltzsygqNbcE= X-Received: by 2002:a17:90a:cf11:: with SMTP id h17mr37079369pju.103.1578214722265; Sun, 05 Jan 2020 00:58:42 -0800 (PST) MIME-Version: 1.0 References: <157676970970.27491.11040479061607849531.idtracker@ietfa.amsl.com> <20191224184147.GP35479@kduck.mit.edu> <3fb0107e-a5d3-5d3a-0d15-f556b97755ae@matroska.org> <20191230035023.GI35479@kduck.mit.edu> In-Reply-To: <20191230035023.GI35479@kduck.mit.edu> From: Steve Lhomme Date: Sun, 5 Jan 2020 09:58:30 +0100 Message-ID: To: Benjamin Kaduk Cc: The IESG , Steven Villereal , draft-ietf-cellar-ebml@ietf.org, cellar-chairs@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Benjamin Kaduk's Discuss on draft-ietf-cellar-ebml-15: (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: Sun, 05 Jan 2020 08:58:45 -0000 Le lun. 30 d=C3=A9c. 2019 =C3=A0 04:50, Benjamin Kaduk a = =C3=A9crit : > > On Fri, Dec 27, 2019 at 10:17:58AM +0100, Steve Lhomme wrote: > > On 2019-12-24 19:41, Benjamin Kaduk wrote: > > > On Tue, Dec 24, 2019 at 04:20:25PM +0100, Steve Lhomme wrote: > > > > >>> Section 12 > > >>> > > >>> If a Master Element contains a CRC-32 Element that doesn't vali= date, > > >>> then the EBML Reader MAY ignore all contained data except for > > >>> Descendant Elements that contain their own valid CRC-32 Element= . > > >>> > > >>> Ignoring only part of the known questionable content could have > > >>> significant security considerations, if (e.g.) security-relevant > > >>> restrictions are in the garbled part of the document but the sensit= ive > > >>> content has a (valid) redundant CRC. > > >> > > >> That's why it's a MAY. If a Matroska Segment has a CRC and each fram= e > > >> in it has a CRC. If the top CRC is invalid, we can still use some of > > >> the frames that have a valid CRC. It's not a requirement but a > > >> possibility. > > > > > > I agree that it's an implementation choice for whether or not to do t= his, > > > but please add some text in the Security Considerations that mentions= the > > > risk of handling incomplete-but-interdependent data when implementati= ons > > > choose to do this sort of thing. > > > > I think it really depends on the dependency of the data at the semantic > > level. For example and EBML Element may define the type of data found i= n > > another EBML Element. If the type is damaged the interpretation of the > > data can create many kind of issues. > > > > As for the CRC I think it's similar. It depends on what the CRC covers > > and the decision should probably be done at the semantic level, even > > with various options on how to handle the data. > > I entirely agree that it depneds on the semantics of the particular data = in > question. That said, even if it only would happen for a small fraction o= f > actual usage, typically we still see fit to document the existence of the > risk for the affected cases, in the security considerations. I created this Pull Request to address this https://github.com/cellar-wg/ebml-specification/pull/333 From nobody Mon Jan 6 09:51:27 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 5ABCA1208C4; Mon, 6 Jan 2020 09:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=fastmail.fm header.b=kjl7/fGV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=JnXmCwDu 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 qkTkD6wqclS7; Mon, 6 Jan 2020 09:51:23 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B971200B3; Mon, 6 Jan 2020 09:51:23 -0800 (PST) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DA82621F9F; Mon, 6 Jan 2020 12:51:21 -0500 (EST) Received: from imap1 ([10.202.2.51]) by compute7.internal (MEProxy); Mon, 06 Jan 2020 12:51:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= mime-version:message-id:in-reply-to:references:date:from:to:cc :subject:content-type:content-transfer-encoding; s=fm2; bh=1A2Rp Dhxx6SjqBq0SvDY0u9iEDiXfylGG6fO4EKf26Q=; b=kjl7/fGVlA9ZytPurDMJS 5P3yAAmD2HW2xODY8iVkX0ovffManKusqSKA1379DgO2RRmrmMcZuLeVnHk+mWb8 pFP3g2CNw3aqjJLc3o3JbcFqDKK1qz77VLCtNK0MhHTvSBhVDCYQMQ5m1V3JeMNK gbh/4X5FwyfaIO6aedYeF7lJ3Q4XCWGdJRXNC58FkxiApMKcMLThym0fFbJkJVnB A+QOn90m0vp1d6xMpNn/LysUb4YgFN1grErvZKErLsfQJA5YmYtxZgMchfRxNp5z 8QfG8kPQQ+zh6gOxIG1iQkP8SjCmZVsUMEamHHLDNbiZllk4Sjg9j2lCrLO62sKj Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=1A2RpDhxx6SjqBq0SvDY0u9iEDiXfylGG6fO4EKf2 6Q=; b=JnXmCwDuf05NBKBXuxlZ4MgASQAXf+fuHhiZEk5mamneHzVyJDv62LhTa 6k66RCR8Q9zhutLc6LnHJzfDPPacaexgNjPg6vd89+RxsyU/EouOVX7+8ZLvvtTF gL542W17eg4KQ8wajMZU37B6pdsoDlAEMc+lr14RHGpUvcBSU/A2DE9+8zpQ67+L K/n6jIQAVO0fpJ/TqRFhRCXE5/Q6Nwdc7tlSCO8sJzmn0X099tK8y7cQqsWqnqwt Son0wM3QCleTF1/4LzG3ch8Y5W1Rlm5D1x9xDYr2rNfHtnPeKVDnXsBDxa1t4Mjx BcLnC9hmhc4kNcMmAg4kjgPU/+R6A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdehtddguddtiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdet lhgvgigvhicuofgvlhhnihhkohhvfdcuoegrrghmvghlnhhikhhovhesfhgrshhtmhgrih hlrdhfmheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrrghmvghlnhhikhhovhesfhgr shhtmhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4D2D7C200A4; Mon, 6 Jan 2020 12:51:21 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-731-g1812a7f-fmstable-20200106v2 Mime-Version: 1.0 Message-Id: <63de67eb-c77e-45d7-a95e-4010bf1cece8@www.fastmail.com> In-Reply-To: References: <157673433343.4965.3950484582725131414.idtracker@ietfa.amsl.com> <4B8173E7-1A15-44E2-98C3-C8D08DAE3F1D@dericed.com> Date: Mon, 06 Jan 2020 17:51:00 +0000 From: "Alexey Melnikov" To: "Steve Lhomme" , "Barry Leiba" Cc: "Dave Rice" , "Steven Villereal" , cellar-chairs@ietf.org, draft-ietf-cellar-ebml@ietf.org, "The IESG" , "Codec Encoding for LossLess Archiving and Realtime transmission" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] =?utf-8?q?Barry_Leiba=27s_No_Objection_on_draft-ietf-ce?= =?utf-8?q?llar-ebml-15=3A_=28with_COMMENT=29?= 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, 06 Jan 2020 17:51:25 -0000 Hi, On Tue, Dec 24, 2019, at 9:49 AM, Steve Lhomme wrote: > Hi, >=20 > Le ven. 20 d=C3=A9c. 2019 =C3=A0 22:08, Dave Rice a= =C3=A9crit : > > > =E2=80=94 Section 17.1 =E2=80=94 > > > > > > Values from 1 to 126 are to > > > be allocated according to the "RFC Required" policy [RFC8126]. > > > > > > Why did you choose that policy? Are you aware that this allows re= gistrations > > > from non-IETF-stream RFCs? In particular, anyone can get an RFC p= ublished in > > > the Independent stream with a very light level of review. Did you= consider > > > IETF Review, which requires an RFC in the IETF stream (including I= nformational > > > and Experimental RFCs)? Or even Standards Action, which requires > > > standards-track RFCs? > > > >=20 > For Matroska that's probably not an issue. It's OK if it's extended > independently. >=20 > For the IDs in the EBML Header I don't have a strong opinion. If > someone defines extra data in the header that only them plan to use, > why not. If they make it public through the IETF it's already a better= > step. The problem is if there's a collision between 2 independent > extensions or a planned addition to the format and an extension. In > this case the first published should have priority. >=20 > There can be an issue if someone just comes and assign *all* the > remaining one-octet IDs in their EBML extension and there's nothing > left for the main EBML. Does the "light review" cover this kind of > problem ? Otherwise we probably need to raise the level of scrutiny. I missed this in my review and I am glad that Barry has noticed. In orde= r to avoid issues that you mentioned, I suggest you either use "IETF Rev= iew" or "Specification Required" (the latter would require a stable spec= ification, which might include a non IETF stream RFC, but also implies "= expert review" which can catch issues like this). And after thinking abo= ut this for 10 seconds longer, I think "Specification Required" would be= a better choice, as it means assigning a specific person (or group of p= eople) who would be contacted before a new value can be registered. Best Regards, Alexey From nobody Thu Jan 9 08:07:55 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 4BAA7120019; Thu, 9 Jan 2020 08:07:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWJgfjIuyuaL; Thu, 9 Jan 2020 08:07:51 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C54B6120800; Thu, 9 Jan 2020 08:02:40 -0800 (PST) Received: from [146.96.19.240] (port=8238 helo=[10.10.201.20]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ipaGW-000B0e-Hk; Thu, 09 Jan 2020 11:02:38 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Dave Rice In-Reply-To: Date: Thu, 9 Jan 2020 11:02:31 -0500 Cc: draft-ietf-cellar-ffv1.all@ietf.org, cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7DDCA42B-8BDA-4EBD-9C04-F0615265E021@dericed.com> References: To: Adam Roach X-Mailer: Apple Mail (2.3445.104.11) X-OutGoing-Spam-Status: No, score=-1.6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] AD Review: draft-ietf-cellar-ffv1 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, 09 Jan 2020 16:07:53 -0000 Hi Adam, Thanks for your review. I have addressed some of these in a pull request = at https://github.com/FFmpeg/FFV1/pull/185 and left questions or nudges = to other authors below. > On Jan 2, 2020, at 6:26 PM, Adam Roach wrote: >=20 > This is my AD review for draft-ietf-cellar-ffv1, which I am processing > at Alexey Melinikov's request. Thanks to everyone who has taken the = time > to document these formats for publication as an RFC. >=20 > I have identified a couple of issues that will need to be addressed = prior to > IETF last call (which are clearly identified below), as well as a = number of > smaller issues that can be addressed as normal IETF last call = comments. >=20 > = --------------------------------------------------------------------------= - >=20 > =C2=A71: >=20 > > The latest version of this document is available at > > https://raw.github.com/FFmpeg/FFV1/master/ffv1.md > > (https://raw.github.com/FFmpeg/FFV1/master/ffv1.md) >=20 > Please add a note to the RFC editor to remove this paragraph prior to > publication (or remove the paragraph in the draft at this time). In the pull request, I removed this line. > = --------------------------------------------------------------------------= - >=20 > =C2=A72: >=20 > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this > > document are to be interpreted as described in [RFC2119]. >=20 > Please update this to match the updated boilerplate given in RFC 8174. Updated in the pull request. > = --------------------------------------------------------------------------= - >=20 > =C2=A72.2.1: >=20 > > The pseudo-code used is based upon the C programming > > language [ISO.9899.1990] and uses its "if/else", "while" and "for" > > functions as well as functions defined within this document. >=20 > It's a minor nit, but these are keywords, not functions. Should both references to the term functions be keywords or just the = first? Note there are also two section headers that use the term = Functions. > = --------------------------------------------------------------------------= - >=20 > =C2=A72.2.2: >=20 > > Note: the operators and the order of precedence are the same as = used > > in the C programming language [ISO.9899.1990]. >=20 > Is there a reason to cite C90 here instead of any of the four newer = versions? Updated in the pull request. Updated to the 2018 version. > = --------------------------------------------------------------------------= - >=20 > =C2=A72.2.2: >=20 > > Note: the operators and the order of precedence are the same as = used > > in the C programming language [ISO.9899.1990]. > ... > > "a ^ b" means a raised to the b-th power. >=20 > One of these two statements is incorrect: the "^" operator in C is a = bitwise > XOR, not a power operator. C has no built-in exponentiation operator, = and > relies on a library-provided `pow(a,b)` function. >=20 > Because this introduces an ambiguity into the specification, it will = need > to be corrected before entering IETF last call. This impacts a lot of the math. Is there consensus to replace `a^b` with = `pow(a,b)` or should `a^b` be defined locally as an exception? > = --------------------------------------------------------------------------= - >=20 > =C2=A72.2.2: >=20 > > "a >> b" means arithmetic right shift of two's complement integer > > representation of a by b binary digits. >=20 > This needs to indicate whether the resulting value is sign-extended > or zero-padded. We can't rely on C's definition here, as right > shifting a signed value is implementation-defined by the standard: >=20 > The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 = has an > unsigned type or if E1 has a signed type and a nonnegative value, = the > value of the result is the integral part of the quotient of E1 / = 2E2. If > E1 has a signed type and a negative value, the resulting value is > implementation-defined. >=20 > Because this introduces an ambiguity into the specification, it will = need > to be corrected before entering IETF last call. I=E2=80=99m uncertain, nudging the other authors. > = --------------------------------------------------------------------------= - >=20 > =C2=A72.2.5: >=20 > > a~b,c. the 'b,c'-th value of a sequence of a >=20 > Please explain this with more words. I can't figure out what it means. Same. I=E2=80=99m uncertain, nudging the other authors. > = --------------------------------------------------------------------------= - >=20 > =C2=A72.2.8: >=20 > > relies on its "Container" to store the "NumBytes" values, see the > > section on the Mapping FFV1 into Containers (#mapping-ffv1-into- > > containers). >=20 > Nit: "...values; see the section..." >=20 > Also, please replace the MD-style anchor with a section number. Updated in the pull request. > = --------------------------------------------------------------------------= - >=20 > =C2=A73: >=20 > > For each "Slice" (as described in the section on Slices (#slice)) = of > > a "Frame", the "Planes", "Lines", and "Samples" are coded in an = order > > determined by the "Color Space" (see the section on Color Space > > (#color-spaces)). Each "Sample" is predicted by the median = predictor > > as described in the section of the Median Predictor (#median- > > predictor) from other "Samples" within the same "Plane" and the > > difference is stored using the method described in Coding of the > > Sample Difference (#coding-of-the-sample-difference). >=20 > Please replace the MD-style anchors with section numbers. Updated all such anchors in the pull request. > = --------------------------------------------------------------------------= - >=20 > =C2=A73.4: >=20 > > context =3D Q_{0}[l - tl] + > > Q_{1}[tl - t] + > > Q_{2}[t - tr] + > > Q_{3}[L - l] + > > Q_{4}[T - t] >=20 > This is the first time in the document we're encountering Q. Please = add a > forward reference to its definition. To do, as the language of the Quantization Table Sets section never says = that the table is referred to as Q. > = --------------------------------------------------------------------------= - >=20 > =C2=A73.7.2: >=20 > > As an example, a "Frame" that is two "Pixels" wide and two "Pixels" > > high, could be comprised of the following structure: >=20 > Nit: "...could be composed of the following structure:" OR "...could = comprise > the following structure:=E2=80=9D Updated to the latter suggestion in the pull request. > = --------------------------------------------------------------------------= - >=20 > =C2=A73.8.1.1: >=20 > > S_{i+1,C_{i}} =3D zero_state_{S_{i,C_{i}}} XOR > > l_i =3D L_i XOR > > t_i =3D R_i - r_i <=3D=3D > > b_i =3D 0 <=3D=3D> > > L_i < R_i - r_i >=20 > Substantial parts of this syntax are undefined at this point in the = document. >=20 > Presumably "XOR" means "exclusive or," although it is unclear whether = this is > intended to be a boolean or bitwise operation. >=20 > The "<=3D=3D" and "<=3D=3D>" notation is also without explanation, and = I can't even make > an educated guess at their intended meaning. >=20 > There is no explanation what it might mean to combine a series of = assignment > operations (and one comparison operation) with these XOR, <=3D=3D, and = <=3D=3D> symbols. >=20 > This needs to be clarified (for all of figures 7 through 9) before the > document can go to IETF last call. To do > = --------------------------------------------------------------------------= - >=20 > =C2=A73.8.1.1.1: >=20 > > Above describes the range decoding, encoding is defined as any > > process which produces a decodable bytestream. >=20 > Would it be reasonable to include a non-normative example of one such > process? To do > = --------------------------------------------------------------------------= - >=20 > =C2=A73.8.1.2: > > exact contexts used are best described by the > > following code, followed by some comments. >=20 > I can't find the referenced comments. To do > = --------------------------------------------------------------------------= - >=20 > =C2=A73.8.1.2: >=20 > > pseudo-code | type > > --------------------------------------------------------------|----- > > void put_symbol(RangeCoder *c, uint8_t *state, int v, int \ | > > is_signed) { | > > int i; | > > put_rac(c, state+0, !v); | > > if (v) { | > > int a=3D abs(v); | > > int e=3D log2(a); | > > | > > for (i =3D 0; i < e; i++) { | > > put_rac(c, state+1+min(i,9), 1); //1..10 | > > } | > > | > > put_rac(c, state+1+min(i,9), 0); | > > for (i =3D e-1; i >=3D 0; i--) { | > > put_rac(c, state+22+min(i,9), (a>>i)&1); //22..31 | > > } | > > | > > if (is_signed) { | > > put_rac(c, state+11 + min(e, 10), v < 0); //11..21| > > } | > > } | > > } | >=20 > The "type" column here appears superfluous, and should either employed = or > removed. To do > The behavior of the function "put_rac" isn't defined anywhere. While = the purpose > of its first two parameters can be deduced from context, the purpose = of the > third parameter is baffling. For avoidance of doubt, please add a = description of > what this function does, and what its parameters mean. To do > = --------------------------------------------------------------------------= - >=20 > =C2=A73.8.1.6: >=20 > > The alternative state transition table has been built using = iterative > > minimization of frame sizes and generally performs better than the > > default. To use it, the coder_type (see the section on coder_type > > (#codertype)) MUST be set to 2 and the difference to the default = MUST > > be stored in the "Parameters", see the section on Parameters > > (#parameters). The reference implementation of FFV1 in FFmpeg uses > > this table by default at the time of this writing when Range coding > > is used. >=20 > Please replace the MD-style anchors with section numbers. Updated all such anchors in the pull request. > = --------------------------------------------------------------------------= - >=20 > =C2=A73.8.2.1: >=20 > > pseudo-code | type > > --------------------------------------------------------------|----- > > int get_ur_golomb(k) { | > > for (prefix =3D 0; prefix < 12; prefix++) { | > > if (get_bits(1)) { | > > return get_bits(k) + (prefix << k) | > > } | > > } | > > return get_bits(bits) + 11 | > > } | > > | > > int get_sr_golomb(k) { | > > v =3D get_ur_golomb(k); | > > if (v & 1) return - (v >> 1) - 1; | > > else return (v >> 1); | > > } >=20 > The "type" column here appears superfluous, and should either employed = or > removed. To do. > Please clarify the meaning of "ur" and "sr" in the function names. To do, define function names with references to ur / sr definitions. > = --------------------------------------------------------------------------= - >=20 > =C2=A73.8.2.1.1: >=20 > > +----------------+-------+ > > | bits | value | > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D+ > > | 1 | 0 | > > +----------------+-------+ > > | 01 | 1 | > > +----------------+-------+ > > | ... | ... | > > +----------------+-------+ > > | 0000 0000 0001 | 11 | > > +----------------+-------+ > > | 0000 0000 0000 | ESC | > > +----------------+-------+ >=20 > This is pretty confusing, not least of all because the base of the = number on the > right is unclear (given that all the shown values contain 1's and 0's > exclusively). I would suggest: >=20 > +----------------+-------+ > | bits | value | > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= +=3D=3D=3D=3D=3D=3D=3D+ > | 1 | 0 | > +----------------+-------+ > | 01 | 1 | > +----------------+-------+ > | ... | ... | > +----------------+-------+ > | 00 0000 0001 | 9 | > +----------------+-------+ > | 000 0000 0001 | 10 | > +----------------+-------+ > | 0000 0000 0001 | 11 | > +----------------+-------+ > | 0000 0000 0000 | ESC | > +----------------+=E2=80=94=E2=80=94=E2=80=94+ To do > = --------------------------------------------------------------------------= - >=20 > =C2=A73.8.2.2.1: >=20 > > pseudo-code | type > > --------------------------------------------------------------|----- > > log2_run[41]=3D{ | > > 0, 0, 0, 0, 1, 1, 1, 1, | > > 2, 2, 2, 2, 3, 3, 3, 3, | > > 4, 4, 5, 5, 6, 6, 7, 7, | > > 8, 9,10,11,12,13,14,15, | > > 16,17,18,19,20,21,22,23, | > > 24, | > > }; | > > | > > if (run_count =3D=3D 0 && run_mode =3D=3D 1) { = | > > if (get_bits(1)) { | > > run_count =3D 1 << log2_run[run_index]; | > > if (x + run_count <=3D w) { | > > run_index++; | > > } | > > } else { | > > if (log2_run[run_index]) { | > > run_count =3D get_bits(log2_run[run_index]); | > > } else { | > > run_count =3D 0; | > > } | > > if (run_index) { | > > run_index--; | > > } | > > run_mode =3D 2; | > > } | > > } | >=20 >=20 > The "type" column here appears superfluous, and should either employed = or > removed. >=20 >=20 > > The log2_run function is also used within [ISO.14495-1.1999]. >=20 > The reference to "log2_run" as a "function" is perplexing, as log2_run = is defined > as an array in the above pseudocode. To do > = --------------------------------------------------------------------------= - >=20 > =C2=A73.8.2.3: >=20 > Some light documentation of the "state" structure would make this = pseudocode > much easier to follow. To do > = --------------------------------------------------------------------------= - >=20 > =C2=A74: >=20 > > Within the following sub-sections, pseudo-code is used to explain = the > > structure of each FFV1 bitstream component, as described in the > > section on Pseudo-Code (#pseudocode). >=20 > Please replace the MD-style anchor with a section number. >=20 > > +--------+-------------------------------------------+ > > | Symbol | Definition | > > +=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D+ > > | u(n) | unsigned big endian integer using n bits | > > +--------+-------------------------------------------+ > > | sg | Golomb Rice coded signed scalar symbol | > > | | coded with the method described in Signed | > > | | Golomb Rice Codes (#golomb-rice-mode) | > > +--------+-------------------------------------------+ > > | br | Range coded Boolean (1-bit) symbol with | > > | | the method described in Range binary | > > | | values (#range-binary-values) | > > +--------+-------------------------------------------+ > > | ur | Range coded unsigned scalar symbol coded | > > | | with the method described in Range non | > > | | binary values (#range-non-binary-values) | > > +--------+-------------------------------------------+ > > | sr | Range coded signed scalar symbol coded | > > | | with the method described in Range non | > > | | binary values (#range-non-binary-values) | > > +--------+-------------------------------------------+ >=20 > Please replace the several MD-style anchors with a section number. Updated all such anchors in the pull request. > = --------------------------------------------------------------------------= - >=20 > =C2=A74: >=20 > > The same context that is initialized to 128 is used for all fields = in > > the header. >=20 > This phrasing is confusing, as it reads like it's referring to some > previously-mentioned context that is best identified as containing = "128." After > convincing myself that I didn't miss such a thing, I *think* you might = mean: >=20 > All fields in the header use the same context, which is > initialized to 128. >=20 > Although, even with that adjustment, I'm not sure which header you're = talking > about. The only header mentioned anywhere earlier in the document is = the > "Slice Header," and that seems unlikely to be what you're referring = to. To do > = --------------------------------------------------------------------------= - >=20 > =C2=A74.1: >=20 > > state_transition_delta[ i ] | sr > ... > > QuantizationTableSet( i ) | >=20 > This psuedo-code appears to use both "[]" and "()" as array operators. = I > understand this is only pseudocode, but please try to remain = consistent with > the meaning of operators. >=20 > Also, "QuantiztionTableSet" is missing a type designation. To do > = --------------------------------------------------------------------------= - >=20 > =C2=A74.1.16: >=20 > > +-------+--------------------------------------------+ > > | value | error detection/correction type | > > +=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D+ > > | 0 | 32-bit CRC on the global header | > > +-------+--------------------------------------------+ > > | 1 | 32-bit CRC per slice and the global header | > > +-------+--------------------------------------------+ > > | Other | reserved for future use | > > +-------+--------------------------------------------+ >=20 > I'm still perplexed by the intended meaning of "header.=E2=80=9D To do > = --------------------------------------------------------------------------= - >=20 > =C2=A74.2.3.4: >=20 > > FFV1 SHOULD use "V_FFV1" as the Matroska "Codec ID". >=20 > Normative requirements on external documents make those documents = normative > dependencies. Please move "[Matroska]" from the "Informative = References" section > to the "Normative References" section. Updated in the pull request. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.1.17: >=20 > > +-------+-------------------------------------+ > > | value | relationship | > > +=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= + > > | 0 | Frames are independent or dependent | > > | | (keyframes and non keyframes) | > > +-------+-------------------------------------+ > > | 1 | Frames are independent (keyframes | > > | | only) | > > +-------+-------------------------------------+ > > | Other | reserved for future use | > > +-------+-------------------------------------+ > > > > Table 14 >=20 > I'm having a hard time understanding "Other" in this table. Section = 4.3 > defines "keyframe" to be of "br" type. I'm confused about how a = boolean > variable can take on more than two values. To do > = --------------------------------------------------------------------------= - >=20 > =C2=A74.4: >=20 > > Background: due to some non conforming > > encoders, some bitstreams where found with 40 extra bits > > corresponding to "error_status" and "slice_crc_parity", a decoder > > conforming to the revised specification could not do the difference > > between a revised bitstream and a buggy bitstream. >=20 > This is hard to parse. I suggest rephrasing like: >=20 > Background: Due to some non-conforming > encoders, some bitstreams were found with 40 extra bits > corresponding to "error_status" and "slice_crc_parity". As a > result, a decoder conforming to the revised specification could not > distinguish between a revised bitstream and a buggy bitstream. Updated to your recommendation in the pull request. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.6: >=20 > > pseudo-code | type > > --------------------------------------------------------------|----- > > SliceContent( ) { | > > if (colorspace_type =3D=3D 0) { | > > for (p =3D 0; p < primary_color_count; p++) { | > > for (y =3D 0; y < plane_pixel_height[ p ]; y++) { | > > Line( p, y ) | > > } | > > } | > > } else if (colorspace_type =3D=3D 1) { | > > for (y =3D 0; y < slice_pixel_height; y++) { | > > for (p =3D 0; p < primary_color_count; p++) { | > > Line( p, y ) | > > } | > > } | > > } | > > } | >=20 > Without a "type" indicated on the "Line( p, y )" lines, this encoding = appears > to be ambiguous. To do > = --------------------------------------------------------------------------= - >=20 > =C2=A74.7: >=20 > > pseudo-code | type > > --------------------------------------------------------------|----- > > Line( p, y ) { | > > if (colorspace_type =3D=3D 0) { | > > for (x =3D 0; x < plane_pixel_width[ p ]; x++) { | > > sample_difference[ p ][ y ][ x ] | > > } | > > } else if (colorspace_type =3D=3D 1) { | > > for (x =3D 0; x < slice_pixel_width; x++) { | > > sample_difference[ p ][ y ][ x ] | > > } | > > } | > > } | >=20 > Although redundant with the request above regarding section 4.6, = please > add "type" indicators for the "sample_difference[ p ][ y ][ x ]" = lines. To do > = --------------------------------------------------------------------------= - >=20 > =C2=A74.7.4: >=20 > > "Sample" value is computed based on median predictor and context > > described in the section on Samples (#samples). >=20 > Please replace the MD-style anchor with a section number. Updated all such anchors in the pull request. > = --------------------------------------------------------------------------= - >=20 > =C2=A74.9 >=20 > > The Quantization Table Sets are stored by storing the number of = equal > > entries -1 of the first half of the table (represented as "len - 1" > > in the pseudo-code below) using the method described in Range Non > > Binary Values (#range-non-binary-values). >=20 > Please replace the MD-style anchor with a section number. Updated all such anchors in the pull request. > = --------------------------------------------------------------------------= - >=20 > =C2=A76: >=20 > While it does provide compression (my understanding is that a typical > ratio is about 2:1), FFV1 still produces a very large bitstream, due = to > its lossless properties. This does present some security challenges = that > need to be cited. >=20 > I would expect this document to include text that is roughly = equivalent to the > final three paragraphs of RFC 4175, Section 8. To do > = --------------------------------------------------------------------------= - >=20 > =C2=A77: >=20 > Please replace the seven various MD-style anchors with section = numbers. Updated all such anchors in the pull request. > = --------------------------------------------------------------------------= - >=20 > =C2=A77: >=20 > > This registration is done using the template defined in [RFC6838] = and > > following [RFC4855]. >=20 > To avoid the need to dereference the cited RFC, please also include = the IANA > table name ("Media Types") in this paragraph. To do > = --------------------------------------------------------------------------= - >=20 > =C2=A77: >=20 > > This > > media type is framed binary data Section 4.8 of [RFC6838]. >=20 > I think this means to say something like: >=20 > This media type is framed binary data; see Section 4.8 of = [RFC6838]. To do > = --------------------------------------------------------------------------= - >=20 > =C2=A77: >=20 > > Published specification: > > > > [I-D.ietf-cellar-ffv1] and RFC XXXX. >=20 > I can't figure out why two documents are mentioned here -- it would = seem that > both of these refer to the same document. To do > = --------------------------------------------------------------------------= - >=20 > > 9. Appendixes > > > > 9.1. Decoder implementation suggestions > > > > 9.1.1. Multi-threading Support and Independence of Slices >=20 > This seems like an unnecessarily deep nesting for its contents. = Consider > collapsing into a single section instead of three nested sections. To do > = --------------------------------------------------------------------------= - >=20 > Section 10 should contain instructions to the RFC editor to remove it = prior to > publication. To do > Thanks! >=20 > /a >=20 From nobody Thu Jan 9 08:14:17 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 69E341208E9; Thu, 9 Jan 2020 08:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 vslyWHL6Qf3Y; Thu, 9 Jan 2020 08:14:05 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0071208D7; Thu, 9 Jan 2020 08:14:04 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 009GDGEj041607 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 9 Jan 2020 10:13:18 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578586399; bh=WnIyTUlnBWZl9PO0cC7+fDmQJLq/bx3ngnNVEtu+Wn8=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=QtKK3805G5+UhqAcR+5Cnx9o9KpIws7Mc/SwOTk0GX8XyWJNZRZGzPRvRAEvqDYec 9ukw2iGUl0m0NyvNm+xwjWahRa/fkC6WzXIEWmfEo6B+HVNC/zpliXmsE3N/bn2Frv 6DrWuytB+nz/MjNBVRy4ioQF7IWSlhMIp67jgrWg= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Dave Rice Cc: draft-ietf-cellar-ffv1.all@ietf.org, cellar@ietf.org References: <7DDCA42B-8BDA-4EBD-9C04-F0615265E021@dericed.com> From: Adam Roach Message-ID: <46918a0c-0e03-bb81-3ba1-5554a8ac2392@nostrum.com> Date: Thu, 9 Jan 2020 10:13:11 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <7DDCA42B-8BDA-4EBD-9C04-F0615265E021@dericed.com> Content-Type: multipart/alternative; boundary="------------2FFDE3CDA411DA8BC183C843" Content-Language: en-US Archived-At: Subject: Re: [Cellar] AD Review: draft-ietf-cellar-ffv1 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, 09 Jan 2020 16:14:16 -0000 This is a multi-part message in MIME format. --------------2FFDE3CDA411DA8BC183C843 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/9/20 10:02 AM, Dave Rice wrote: > Hi Adam, > Thanks for your review. I have addressed some of these in a pull request at https://github.com/FFmpeg/FFV1/pull/185 and left questions or nudges to other authors below. Thanks! It looks like one of the questions is for me; I've responded below. > >> --------------------------------------------------------------------------- >> >> §2.2.1: >> >>> The pseudo-code used is based upon the C programming >>> language [ISO.9899.1990] and uses its "if/else", "while" and "for" >>> functions as well as functions defined within this document. >> It's a minor nit, but these are keywords, not functions. > Should both references to the term functions be keywords or just the first? Note there are also two section headers that use the term Functions. Sorry for the ambiguity -- just the first one. That is: The pseudo-code used is based upon the C programming language [ISO.9899.2018] and uses its "if/else", "while", and "for" keywords as well as functions defined within this document. I don't think any of the section headers are incorrect. /a --------------2FFDE3CDA411DA8BC183C843 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 1/9/20 10:02 AM, Dave Rice wrote:
Hi Adam,
Thanks for your review. I have addressed some of these in a pull request at https://github.com/FFmpeg/FFV1/pull/185 and left questions or nudges to other authors below.


Thanks! It looks like one of the questions is for me; I've responded below.



---------------------------------------------------------------------------

§2.2.1:


 The pseudo-code used is based upon the C programming
 language [ISO.9899.1990] and uses its "if/else", "while" and "for"
 functions as well as functions defined within this document.

It's a minor nit, but these are keywords, not functions.

Should both references to the term functions be keywords or just the first? Note there are also two section headers that use the term Functions.


Sorry for the ambiguity -- just the first one. That is:


The pseudo-code used is based upon the C programming language [ISO.9899.2018] and uses its "if/else", "while", and "for" keywords as well as functions defined within this document.


I don't think any of the section headers are incorrect.

/a

--------------2FFDE3CDA411DA8BC183C843-- From nobody Thu Jan 9 08:16:03 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 F1B981200F9; Thu, 9 Jan 2020 08:16:01 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1lESA1W7kgn; Thu, 9 Jan 2020 08:16:00 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CF4C1200F1; Thu, 9 Jan 2020 08:16:00 -0800 (PST) Received: from [146.96.19.240] (port=43378 helo=[10.10.201.20]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ipaTT-000KgA-AK; Thu, 09 Jan 2020 11:16:00 -0500 From: Dave Rice Message-Id: <03092952-9E68-4A2B-A683-5A699A8F4E43@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6A6C7213-8EB6-473D-87D1-BC395B035453" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 9 Jan 2020 11:15:53 -0500 In-Reply-To: <46918a0c-0e03-bb81-3ba1-5554a8ac2392@nostrum.com> Cc: draft-ietf-cellar-ffv1.all@ietf.org, cellar@ietf.org To: Adam Roach References: <7DDCA42B-8BDA-4EBD-9C04-F0615265E021@dericed.com> <46918a0c-0e03-bb81-3ba1-5554a8ac2392@nostrum.com> X-Mailer: Apple Mail (2.3445.104.11) X-OutGoing-Spam-Status: No, score=0.3 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] AD Review: draft-ietf-cellar-ffv1 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, 09 Jan 2020 16:16:02 -0000 --Apple-Mail=_6A6C7213-8EB6-473D-87D1-BC395B035453 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 9, 2020, at 11:13 AM, Adam Roach wrote: >=20 > On 1/9/20 10:02 AM, Dave Rice wrote: >> Hi Adam, >> Thanks for your review. I have addressed some of these in a pull = request at https://github.com/FFmpeg/FFV1/pull/185 = and left questions or nudges = to other authors below. > Thanks! It looks like one of the questions is for me; I've responded = below. >=20 >>=20 >>> = --------------------------------------------------------------------------= - >>>=20 >>> =C2=A72.2.1: >>>=20 >>>> The pseudo-code used is based upon the C programming >>>> language [ISO.9899.1990] and uses its "if/else", "while" and "for" >>>> functions as well as functions defined within this document. >>> It's a minor nit, but these are keywords, not functions. >> Should both references to the term functions be keywords or just the = first? Note there are also two section headers that use the term = Functions. > Sorry for the ambiguity -- just the first one. That is:=20 >=20 > The pseudo-code used is based upon the C programming language = [ISO.9899.2018] and uses its "if/else", "while", and "for" keywords as = well as functions defined within this document. >=20 > I don't think any of the section headers are incorrect. >=20 > /a >=20 Thanks, I=E2=80=99ve updated the PR to include this. Dave= --Apple-Mail=_6A6C7213-8EB6-473D-87D1-BC395B035453 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = Jan 9, 2020, at 11:13 AM, Adam Roach <adam@nostrum.com> = wrote:

=20 =20
On 1/9/20 10:02 AM, Dave Rice = wrote:
Hi Adam,
Thanks for your review. I have addressed some of these in a pull request =
at https://github.com/FFmpeg=
/FFV1/pull/185 and left questions or nudges to other authors =
below.

Thanks! It looks like one of the = questions is for me; I've responded below.


----------------------------------------------------------------=
-----------

=C2=A72.2.1:


 The pseudo-code used =
is based upon the C programming
 language [ISO.9899.1990] and uses its "if/else", "while" and "for"
 functions as well as functions defined within this document.

It's a minor nit, but =
these are keywords, not functions.

Should both references to =
the term functions be keywords or just the first? Note there are also =
two section headers that use the term Functions.

Sorry for the ambiguity -- just the first = one. That is: 

The pseudo-code used is based = upon the C programming language [ISO.9899.2018] and uses its "if/else", "while", and "for" keywords as well as functions defined within this = document.

I don't think any of the section = headers are incorrect.

/a

Thanks, I=E2=80=99ve updated the PR to include = this.
Dave
= --Apple-Mail=_6A6C7213-8EB6-473D-87D1-BC395B035453-- From nobody Thu Jan 9 10:23: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 935BB120108; Thu, 9 Jan 2020 10:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 5dH8FEXx6I7M; Thu, 9 Jan 2020 10:23:41 -0800 (PST) Received: from relay12.mail.gandi.net (relay12.mail.gandi.net [217.70.178.232]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D91120104; Thu, 9 Jan 2020 10:23:40 -0800 (PST) Received: from localhost (213-47-68-29.cable.dynamic.surfer.at [213.47.68.29]) (Authenticated sender: michael@niedermayer.cc) by relay12.mail.gandi.net (Postfix) with ESMTPSA id E9870200003; Thu, 9 Jan 2020 18:23:36 +0000 (UTC) Date: Thu, 9 Jan 2020 19:23:35 +0100 From: Michael Niedermayer To: Dave Rice Cc: Adam Roach , draft-ietf-cellar-ffv1.all@ietf.org, cellar@ietf.org Message-ID: <20200109182335.GH1173@michaelspb> References: <7DDCA42B-8BDA-4EBD-9C04-F0615265E021@dericed.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GBDnBH7+ZvLx8QD4" Content-Disposition: inline In-Reply-To: <7DDCA42B-8BDA-4EBD-9C04-F0615265E021@dericed.com> Archived-At: Subject: Re: [Cellar] AD Review: draft-ietf-cellar-ffv1 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, 09 Jan 2020 18:23:44 -0000 --GBDnBH7+ZvLx8QD4 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi On Thu, Jan 09, 2020 at 11:02:31AM -0500, Dave Rice wrote: > Hi Adam, > Thanks for your review. I have addressed some of these in a pull request = at https://github.com/FFmpeg/FFV1/pull/185 and left questions or nudges to = other authors below. >=20 > > On Jan 2, 2020, at 6:26 PM, Adam Roach wrote: [...] > > -----------------------------------------------------------------------= ---- > >=20 > > =C2=A72.2.2: > >=20 > > > "a >> b" means arithmetic right shift of two's complement integer > > > representation of a by b binary digits. > >=20 > > This needs to indicate whether the resulting value is sign-extended > > or zero-padded. We can't rely on C's definition here, as right > > shifting a signed value is implementation-defined by the standard: > >=20 > > The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 = has an > > unsigned type or if E1 has a signed type and a nonnegative value, t= he > > value of the result is the integral part of the quotient of E1 / 2E= 2. If > > E1 has a signed type and a negative value, the resulting value is > > implementation-defined. > >=20 > > Because this introduces an ambiguity into the specification, it will ne= ed > > to be corrected before entering IETF last call. >=20 > I=E2=80=99m uncertain, nudging the other authors. The implementation definedness can be avoided by simply refering to an impl= ementation and not just "C90" or other. not sure "twos complement" is strictly enough = but it may be the cleanest way to specify it. >=20 > > -----------------------------------------------------------------------= ---- > >=20 > > =C2=A72.2.5: > >=20 > > > a~b,c. the 'b,c'-th value of a sequence of a > >=20 > > Please explain this with more words. I can't figure out what it means. >=20 > Same. I=E2=80=99m uncertain, nudging the other authors. maybe this notation can be avoidded and array indexes [] used, iam not sure this would work better in all cases though Thanks [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad --GBDnBH7+ZvLx8QD4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAl4Xb6cACgkQYR7HhwQLD6vwBgCfWE3lBE9WYEhkYzAI7WLq4PPK KqAAn1slRTMJWX6gksa3xOckm9dqzypV =0Zj+ -----END PGP SIGNATURE----- --GBDnBH7+ZvLx8QD4-- From nobody Thu Jan 9 13:15:25 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 6343212081B; Thu, 9 Jan 2020 13:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 5cbtRd06IzLX; Thu, 9 Jan 2020 13:15:22 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE60120810; Thu, 9 Jan 2020 13:15:22 -0800 (PST) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 009LEVhb092544 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 9 Jan 2020 15:14:34 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1578604475; bh=rbZvymW+pl7ew74FCdxNgDnFGxP9t3QHVKb6CcpULJ8=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=eB64K6Gb20Eau4OklqMc1lr+b2fIiIUkUxmG9yCcyICKAX24QRTLMGnlYkw/lkGg7 TyfVFHQjNa4VjS045eRHlxj7r2c2YS8lMce7kAtbyjP+VhYheqyVhOb+Dlqgew04+K 9iQYtL0BshLQ5s4URzDcBORH01bVPrqZPuvxi9gA= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Michael Niedermayer , Dave Rice Cc: cellar@ietf.org, draft-ietf-cellar-ffv1.all@ietf.org References: <7DDCA42B-8BDA-4EBD-9C04-F0615265E021@dericed.com> <20200109182335.GH1173@michaelspb> From: Adam Roach Message-ID: <95c9d576-3683-208f-4e0a-0fa0cba70c42@nostrum.com> Date: Thu, 9 Jan 2020 15:14:26 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <20200109182335.GH1173@michaelspb> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] AD Review: draft-ietf-cellar-ffv1 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, 09 Jan 2020 21:15:24 -0000 On 1/9/20 12:23 PM, Michael Niedermayer wrote: > The implementation definedness can be avoided by simply refering to an implementation > and not just "C90" or other. not sure "twos complement" is strictly enough but it > may be the cleanest way to specify it. I don't think "two's complement" clearly indicates sign extension versus zero padding. I think you need to clearly specify precisely what happens to new high-order bits during a right-shift. /a From nobody Thu Jan 9 15:29:31 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 CB09B120128; Thu, 9 Jan 2020 15:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=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 Usj4Puh_Kb_1; Thu, 9 Jan 2020 15:29:27 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4C9812003E; Thu, 9 Jan 2020 15:29:26 -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 relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 5DD9EE0004; Thu, 9 Jan 2020 23:29:24 +0000 (UTC) Date: Fri, 10 Jan 2020 00:29:23 +0100 From: Michael Niedermayer To: Adam Roach Cc: Dave Rice , draft-ietf-cellar-ffv1.all@ietf.org, cellar@ietf.org Message-ID: <20200109232923.GK1173@michaelspb> References: <7DDCA42B-8BDA-4EBD-9C04-F0615265E021@dericed.com> <20200109182335.GH1173@michaelspb> <95c9d576-3683-208f-4e0a-0fa0cba70c42@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aqWxf8ydqYKP8htK" Content-Disposition: inline In-Reply-To: <95c9d576-3683-208f-4e0a-0fa0cba70c42@nostrum.com> Archived-At: Subject: Re: [Cellar] AD Review: draft-ietf-cellar-ffv1 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, 09 Jan 2020 23:29:29 -0000 --aqWxf8ydqYKP8htK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 09, 2020 at 03:14:26PM -0600, Adam Roach wrote: > On 1/9/20 12:23 PM, Michael Niedermayer wrote: > >The implementation definedness can be avoided by simply refering to an i= mplementation > >and not just "C90" or other. not sure "twos complement" is strictly enou= gh but it > >may be the cleanest way to specify it. >=20 >=20 > I don't think "two's complement" clearly indicates sign extension versus > zero padding. I think you need to clearly specify precisely what happens = to > new high-order bits during a right-shift. thats what i meant by "strictly enough". here a gradient from clear to precisse to clarify more what i meant: A. >> is defined as on common mainstream two's complement architectures B. >> with signed values is defined with two's complement representation and sign extension C. a >> b with signed a is defined so that the two's complement representat= ion of a is shifted toward the less significant bit by b places. The newly introduced bits are identical to the previous sign bit of a. The bits shifted beyond the least significant bit are discarded. If b is negative the behavior is undefined. =20 when reading the text for A., i think its clear to everyone knowing ISO-C while C. is more precisse it requires more effort to understand that this is mostly what is done by ISO-C on mainstream architectures. I guess we probably should combine something like A and C so its both precisse and still can be immedeatly understood without the need to disentagle the definition Thanks =20 [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. --aqWxf8ydqYKP8htK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAl4Xt1MACgkQYR7HhwQLD6un9gCeLxytgNq43UTAO/eEIgMr5+a+ cvUAoI9OhiJJdOjqrhHRKbwtMjWnUjvf =G39k -----END PGP SIGNATURE----- --aqWxf8ydqYKP8htK-- From nobody Sat Jan 11 16:24: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 33E1112001A; Sat, 11 Jan 2020 16:24:09 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mcr+ietf@sandelman.ca, cellar@ietf.org, cellar-chairs@ietf.org, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157878864913.26118.4951743878844142439.idtracker@ietfa.amsl.com> Date: Sat, 11 Jan 2020 16:24:09 -0800 Archived-At: Subject: [Cellar] cellar - Not having a session at IETF 107 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: Sun, 12 Jan 2020 00:24:09 -0000 Michael Richardson, a chair of the cellar working group, indicated that the cellar working group does not plan to hold a session at IETF 107. This message was generated and sent by the IETF Meeting Session Request Tool. From nobody Wed Jan 15 05:43: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 D206C120071 for ; Wed, 15 Jan 2020 05:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 8FlvzxAsHUpR for ; Wed, 15 Jan 2020 05:43:06 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A330912003E for ; Wed, 15 Jan 2020 05:43:05 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id AF8663897C for ; Wed, 15 Jan 2020 08:35:13 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 496B0124A for ; Wed, 15 Jan 2020 08:35:40 -0500 (EST) From: Michael Richardson To: cellar@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Wed, 15 Jan 2020 08:35:40 -0500 Message-ID: <12399.1579095340@localhost> Archived-At: Subject: [Cellar] january meeting... 2020-01-21 or 2020-01-28! 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, 15 Jan 2020 13:43:13 -0000 1) Hi, I think that I have made a mistake in booking the virtual interim date. It's 2020-01-21 on the web site. My notes say: Fourth tuesday of the month. Starting January 28, 2020. and also say: NEXT meeting is 2020-01-22, which isn't even a Tuesday! I shall adjust the secretariat to fix the date to Jan.28, as I think was originally intended. 2) Please welcome Spencer Dawkins as a new CELLAR co-chair. From nobody Wed Jan 15 07:04: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 33207120089; Wed, 15 Jan 2020 07:03:19 -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: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157910059912.4684.8540403420205082026@ietfa.amsl.com> Date: Wed, 15 Jan 2020 07:03:19 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2020-01-28 CHANGED 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, 15 Jan 2020 15:03:19 -0000 MEETING DETAILS HAVE CHANGED. SEE LATEST DETAILS BELOW. The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2020-01-28 from 21:00 to 22:00 Europe/Amsterdam. Agenda: CELLAR -- DRAFT AGENDA for Virtual Interim Meeting January 28, 2020 19:00 UTC 21:00 Amsterdam 15:00 NYC 12:00 San Francisco INFO: https://datatracker.ietf.org/meeting/interim-2020-cellar-01/session/cellar https://datatracker.ietf.org/doc/agenda-interim-2020-cellar-01-cellar-01/ WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes 1. Note Well. https://www.ietf.org/about/note-well/ 2. Accept draft minutes from December 10 meeting (attached below) 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont=true 2b) APPEAR.IN is not called "whereby.com" https://whereby.com/cellar-interim 2c) Roll call 4. Welcome to Spencer Dawkins. 5. WG status update * EBML -- version 16 was posted 2019-12-22, on IESG telechat for 2019-12-16 https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/writeup/ https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ballot/ * FFV1 -- version 11 was posted 2019-10-23, waiting for AD writeup. REVIEW oF IESG DISCUSS COMMENTS from Adam Roach. Roman: "Section 1. Please add a reference for WebM" ACTION: MCR to followup with Robert Sparks on IANA issue. -> EBML is a "general purpose audio/video container" Steve to fix #304. 6. Work on Matroska issues. ---- PREVIOUS NOTES CELLAR -- DRAFT AGENDA for Virtual Interim Meeting December 10, 2019 19:00 UTC 21:00 Amsterdam 15:00 NYC 12:00 San Francisco REGRETS: 1) Reto Kromer PRESENT: 1) Michael Richardson 2) Benjamin Turkus 3) Dave Rice 4) Martin Below 5) Michael Niedermayer 6) Peter Bubestinger 7) Steve Lhomme 8) Jerome Martinez 9) Dante Bromkovsky INFO: https://datatracker.ietf.org/meeting/interim-2019-cellar-10/session/cellar https://datatracker.ietf.org/doc/agenda-interim-2019-cellar-10-sessa/ WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes 1. Note Well. https://www.ietf.org/about/note-well/ 2. Accept draft minutes from October 22 meeting (attached below) no objections or changes noted. 3. Logistics for Meeting. 2a) Etherpad for notes https://etherpad.ietf.org/p/notes-cellar-virtual?useMonospaceFont=true 2b) APPEAR.IN is not called "whereby.com" https://whereby.com/cellar-interim 2c) Roll call 4. Establish meeting schedule for 2020! Fourth tuesday of the month. Starting January 28, 2020. No meeting in July. September meeting might be 22nd, at conference "No Time to Wait". (web page for the last one: https://mediaarea.net/NoTimeToWait4 , in Amsterdam 2020 September) November meeting moved to Tuesday, December 1. 5. WG status update * EBML -- version 14 was posted 2019-12-02, on IESG telechat for 2019-12-05 --- deferred as document was too long for some IESG membes to get a handle on * FFV1 -- version 11 was posted 2019-10-23, waiting for AD writeup. Dave Rice reports that changes that occured today was as a result of a review; some figures and tables are now cross-referenced more clearly. The same was done to ffv1. Some help is needed to get appropriate captions on the tables. Robert Sparks asks that new versions not be updated until there are replies and instructions. ACTION: MCR to followup with Robert Sparks on IANA issue. -> EBML is a "general purpose audio/video container" Steve to fix #304. 6. Work on Matroska issues. Split the main Matroska document to take the Chapters in another document? Only elements required for proper playback should be in the main document. Document 166 pages today. Chapters is 6 pages, section 11. --- but the section is not finished. Core document 9.3.4 "Tracks" is pages 45->106. MCR: hears support for splitting the chapter off, but asks if there is really that much savings. Steve: we could make the document smaller by grouping things that have only one parent or one child, with some better transformation of the formatting. The chapters section is not finished, and there are lot of incomplete sections which will make the section significantly larger, and so splitting it off into another document may still be justified. It makes no sense to work on it now, but make the split off now. Steve will give it a try and see what the savings is, and if we have a lot references that break, but does not think that this is the case. Dave Rice is hesistant, not sure he sees enough of an advantage. Tags and Meta-data are developed asynchronously, but the chapters are not going to evolve in place. This issue will be deferred. Peter B: ffv1 support in davinci / black-magic. Would rather do this after the document is published. What is status? did Derek's feedback about the implementation in GO make it back into the document. DR: Yes, this went back into the document about three months ago. This resulted in a few issues being created, and the review was very helpful. Noting that there are three decoders: ffmpeg, Derek-GO, and Jerome's decoder 7. Any other business. 7.1 Side Data Format for MKV Benjamin: side data format for MKV! Dave Rice: it is merged into Matroska, can add side data to frames. Three competing things how to encode time code into the file. Related discussion at https://mailarchive.ietf.org/arch/browse/cellar/?q=matroska%20and%20side%20data%20vs%20timecode. 1) use side data. A debated proposal is at https://github.com/cellar-wg/matroska-specification/pull/348. (needsd to mentioned in main document) A sample of matroska with side data timecode is at https://github.com/Matroska-Org/matroska-test-files/pull/5. 2) meta-data tag or segment info(needs to be in main document) 3) seperate track (codec-like document) NEXT meeting is 2020-01-22, Information about remote participation: https://whereby.com/cellar-interim From nobody Wed Jan 15 15:12:18 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 A397E120639 for ; Wed, 15 Jan 2020 15:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o17xiCLqUtBg for ; Wed, 15 Jan 2020 15:12:15 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 4BDDD120113 for ; Wed, 15 Jan 2020 15:12:15 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id i23so14049560lfo.7 for ; Wed, 15 Jan 2020 15:12:15 -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=lMaJCQ+/F8e9myZ6iJKCdOsOJPG2jrEcCCGcCEtuiSE=; b=RCorfve4UCuPcsdoemGMWTz4On3JQUm3uKXgZny4K4/+sQVxaDVAABw3VbrgdlbKUj sP+ggq9k/nI+gEw1jgH9v3Ck9t8VEu13CGQ7Z9BW0OLF8BbCBkt2v9bBaYkxeL4d2mF2 h5mIX6ooFlw36KP7CVDYLtTm8Zb/AVmQsAx6ucmXdOHzYLUNeP2dFWL7r5TPLvMMgrG+ QfRQCJpaxhZ80pLVIw8PsuMIRxd/b5jXwTtN98yoX5tI9JNlcgP0kixY2K0ixX1JQSG/ oDtCUUkWxR8uOlt3OqUriufR4B4bKF+Jp2PjM5bqmCb16w7GxAHghW9yFO3MGpgHzpfo rs2Q== 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=lMaJCQ+/F8e9myZ6iJKCdOsOJPG2jrEcCCGcCEtuiSE=; b=STf5QmIb4du4M2WBFzuXtIxMbwonePMhM483yr/PgAiN4JHd2x8OcloVhca8tat8yU 0GVJVuaS8ddTAYBDo3YwEL5z8MJVoIOnBKLsSrjo+jbILi9nLPrn9dWLzCtyrlLRXJca 5vIDXFYcweG1qtIv0t2UO9EO5c9jdFUWAZUL5j8b13BKAcuMntO+qxhBidjOAZ3ZkxYA 9WZ/kuT49fkg85+xyCk2t4BaJEo/pz+jmrkj2aoAXGOGwE6tdGfjAuBMr5Y83UtmwqCt iZKDlmy7SI+jB1cZFMYO5xErmR3TuGwC3f+wysTlhZ9fa0sifT6R6qcIZPUhznguy6LU SoEA== X-Gm-Message-State: APjAAAXUEmnWHdePuYTiVv+8WISeWYC5YtCcR/CoXkWMWNVS27+5w3Cw K71XLWq76PY7A2H4E+aQLPvkmv471k/HTzo5bCvAq9YU X-Google-Smtp-Source: APXvYqySqnFqcesVNHoORo8+1V1iP8dKP4dHrbb+b7h9zK7VnHAr6HKc1eKRLXldVAmCGcsHSeONDwDt710d2uXGh6s= X-Received: by 2002:a19:4bcf:: with SMTP id y198mr698258lfa.204.1579129933302; Wed, 15 Jan 2020 15:12:13 -0800 (PST) MIME-Version: 1.0 References: <12399.1579095340@localhost> In-Reply-To: <12399.1579095340@localhost> From: Spencer Dawkins at IETF Date: Thu, 16 Jan 2020 08:11:46 +0900 Message-ID: To: Michael Richardson Cc: cellar@ietf.org Content-Type: multipart/alternative; boundary="000000000000ba8f7b059c35d668" Archived-At: Subject: Re: [Cellar] january meeting... 2020-01-21 or 2020-01-28! 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, 15 Jan 2020 23:12:16 -0000 --000000000000ba8f7b059c35d668 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 15, 2020 at 10:43 PM Michael Richardson wrote: > 2) Please welcome Spencer Dawkins as a new CELLAR co-chair. > Thank you, Michael. I look forward to helping, and will be on the 1-28 call. Best, Spencer --000000000000ba8f7b059c35d668 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jan 15, 2020 at 10:43 PM Michael = Richardson <mcr@sandelman.ca>= wrote:
2) Please welc= ome Spencer Dawkins as a new CELLAR co-chair.

Thank you, Michael. I look forward to helping, and will be on the 1-= 28 call.=C2=A0

Best,

Spen= cer=C2=A0
--000000000000ba8f7b059c35d668-- From nobody Sat Jan 18 14:08:54 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 CAC13120043; Sat, 18 Jan 2020 14:08:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Adam Roach via Datatracker To: "The IESG" Cc: draft-ietf-cellar-ebml@ietf.org, Steven Villereal , cellar-chairs@ietf.org, villereal@gmail.com, cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Adam Roach Message-ID: <157938532476.31674.3895174405780154769.idtracker@ietfa.amsl.com> Date: Sat, 18 Jan 2020 14:08:44 -0800 Archived-At: Subject: [Cellar] Adam Roach's No Objection on draft-ietf-cellar-ebml-16: (with COMMENT) 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: Sat, 18 Jan 2020 22:08:45 -0000 Adam Roach has entered the following ballot position for draft-ietf-cellar-ebml-16: No Objection 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.) 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-ebml/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my discuss and comments! From nobody Sat Jan 18 23:41:14 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 88F2012004C for ; Sat, 18 Jan 2020 23:41:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=q6XcDHp5; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KgvdH/VR 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 j2O0_QjuHehD for ; Sat, 18 Jan 2020 23:41:11 -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 2B491120041 for ; Sat, 18 Jan 2020 23:41:11 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 06EF020222 for ; Sun, 19 Jan 2020 02:32:26 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 19 Jan 2020 02:32:26 -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=Kup/9zpZbwILndLcabHStiIPO2aHS9wuU6mqyRkNeF8=; b=q6XcDHp5 hJrgdOIRm/KOfAC/u3Jgo8pbCd4psW64iDkj5OoHCgnu9jhsSpbvune/vbTrv5YR ZGqOeRcsIx4XnulpoigRhFioNlqXv1Ypspx/VjwIynMUz7r78sieTRTb1q//Fy0N C1is+ZNYhG+WqpvV/60WmN/g4nQzAEP7hNuMFyK68gDeDS+9/PGP26gS9CnamuvI qmSbo+fPm2DETMRHkZjkbrgEcUknRnrQhfL+xIjvOwxS3Lca59Po/lVOYvuaTySY t13eYGkCr3VNgewMrwFcT+icgiCIDo8U76ze9U2m4QqJOX8lPklYTeDtGttSxpuS /CC5KSi/8RQ0vQ== 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=Kup/9zpZbwILndLcabHStiIPO2aHS 9wuU6mqyRkNeF8=; b=KgvdH/VRlMsR2fKthpdJs1yz9a31OQnPwoUjzrOqcKyNW Svmj5q38BpydgmmOgHXMLAzvzFo0OX41p0VMfEegQlBDUkXzytCkmf5PagZpAZnq 7vjSrT+bL+2Ccf4avln/GD83n8t2D/UMmBAdnWuDYBsuHPqKtv1S/vMODEV57zVS RUDSnt3//79GguUNPFDoN8UTVFJ1Acpx713mr9lTgg4tebYMUI+k1suy74eJRWJ9 wK7pVaMq6AMZ7nEoEUNfIXqfmEh2ETSOqJpqnbksGee52GITKFLHdkmjXH9/K6yQ r4wAQIFiYKX7gctqqmcnqca0Dcajs/U3kI17GRKyA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedruddvgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecukfhppeegtddruddvuddrudefrddvudenucfrrghrrghmpehm rghilhhfrhhomhepughopghnohhtpghrvghplhihsehmnhhothdrnhgvthenucevlhhush htvghrufhiiigvpedv X-ME-Proxy: Received: from [10.1.0.4] (unknown [40.121.13.21]) by mail.messagingengine.com (Postfix) with ESMTPA id C919030607CD for ; Sun, 19 Jan 2020 02:32:25 -0500 (EST) Content-Type: multipart/alternative; boundary="===============6951574002571647323==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200119073225.C919030607CD@mailuser.nyi.internal> Date: Sun, 19 Jan 2020 02:32:25 -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, 19 Jan 2020 07:41:12 -0000 --===============6951574002571647323== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Pull requests ------------- * cellar-wg/ebml-specification (+1/-1/=F0=9F=92=AC1) 1 pull requests submitted: - remove sourcecode workaround (by dericed) https://github.com/cellar-wg/ebml-specification/pull/334=20 1 pull requests received 1 new comments: - #331 ABNF cleanup (1 by robUx4) https://github.com/cellar-wg/ebml-specification/pull/331 [clarification= s]=20 1 pull requests merged: - remove sourcecode workaround https://github.com/cellar-wg/ebml-specification/pull/334 [build system]= =20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============6951574002571647323== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday January 19, 2020

Events without label "editorial"

Pull requests

cellar-wg/ebml-specification (+1/-1/=F0=9F=92=AC1)

1 pull requests submitted:

1 pull requests received 1 new comments:

1 pull requests merged:

Repositories tracked by this digest:

--===============6951574002571647323==-- From nobody Sat Jan 25 23:40: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 EAE6A12009C for ; Sat, 25 Jan 2020 23:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ccyOlqd8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fa8ZmD5S 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 i0hn7-osD7tr for ; Sat, 25 Jan 2020 23:40:55 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B4D312008F for ; Sat, 25 Jan 2020 23:40:55 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 01E474C5 for ; Sun, 26 Jan 2020 02:32:37 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 26 Jan 2020 02:32:38 -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=A3+m7qqTOXMfvQWuyak0MfqjOx0w+Ar5mKErLqhUeZY=; b=ccyOlqd8 OeoNiL3VxKs2NdB0xD9chrDxIKYXzGvvOCqi1Rw1JJ+c0J8FKSTdm7gZPMB7+CYx sOiNdDLtbBzTBOu06olllVb+yVOOglweuTxB8Qej+arDZovMyEb9jk39no1Wu2M9 3MtaJM61P9Uk/18rkyvqFq2TmnyfIxGeM6/shjX7mEJBtLaIJT+FvKpJU+8K+kzD 8fNYryQ632eklQUyHQcpGxy+CP+ir+40j/XORnlVXlVxbbQq30Lx6lVSc3w9oujU zRD8BCDjVLzMBo68m/yssTHvgjMlDJ/8q1pezLCTbAGHgRriZrczUVFizVTXEyh6 LLOKBZat4U4rXw== 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=A3+m7qqTOXMfvQWuyak0MfqjOx0w+ Ar5mKErLqhUeZY=; b=fa8ZmD5S2Uj4WhynsnGMhL0gpBSbksZVkmwY+Ibo1Gpk1 OqiIcqvS0zeR55G0YkegkUtKd1UBfx7GRGSl11sse9i3klIaYHRF8uMx9UygaA+T ZDA7jtiqnp+Gy40hu3niqIUMvuYqDx6XIq0vJn2H3fQ4x7ghqhgDyHn7vHSCJbjC Y9HNn7SoyFv38fl4IDDJePndGZJvhhlljKqCd4AfD7o4xAEkdjf1z5iSczUR3PXO 9ZbnhVGQGwO3OH3wnVXyyZVp8W+GQxCt9Ib3OGZ5JKove/Y36SoLfMAt/moIT0CC BgpAtcjJJ2bWuBpROOB9Nzn5OVGxkF1guO7XT/+3Q== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrvdelgdduhecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggghffvufesrgdttdertddtjeenuc fhrhhomheptfgvphhoshhithhorhihucettghtihhvihhthicuufhumhhmrghrhicuueho thcuoeguohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvghtqeenucffohhmrghinhepgh hithhhuhgsrdgtohhmnecukfhppeehvddrudekgedrudeljedrgeenucevlhhushhtvghr ufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgpnhhothgprhgvphhlhi esmhhnohhtrdhnvght X-ME-Proxy: Received: from [10.1.0.4] (unknown [52.184.197.4]) by mail.messagingengine.com (Postfix) with ESMTPA id 6C202328005A for ; Sun, 26 Jan 2020 02:32:37 -0500 (EST) Content-Type: multipart/alternative; boundary="===============6554023421334314072==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20200126073237.6C202328005A@mailuser.nyi.internal> Date: Sun, 26 Jan 2020 02:32:37 -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, 26 Jan 2020 07:40:57 -0000 --===============6554023421334314072== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Pull requests ------------- * cellar-wg/ebml-specification (+0/-0/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #331 ABNF cleanup (1 by robUx4) https://github.com/cellar-wg/ebml-specification/pull/331 [clarification= s]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/matroska-specification * https://github.com/cellar-wg/ebml-specification --===============6554023421334314072== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday January 26, 2020

Events without label "editorial"

Pull requests

cellar-wg/ebml-specification (+0/-0/=F0=9F=92=AC1)

1 pull requests received 1 new comments:

Repositories tracked by this digest:

--===============6554023421334314072==-- From nobody Mon Jan 27 07:57:38 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 C4D7812086B; Mon, 27 Jan 2020 07:57:32 -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: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <158014065272.26539.16455779404969691853@ietfa.amsl.com> Date: Mon, 27 Jan 2020 07:57:32 -0800 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ebml-17.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: Mon, 27 Jan 2020 15:57:33 -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 : Extensible Binary Meta Language Authors : Steve Lhomme Dave Rice Moritz Bunkus Filename : draft-ietf-cellar-ebml-17.txt Pages : 59 Date : 2020-01-27 Abstract: This document defines the Extensible Binary Meta Language (EBML) format as a binary container format designed for audio/video storage. EBML is designed as a binary equivalent to XML and uses a storage- efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ebml-17 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ebml-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ebml-17 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 Jan 28 12:07:10 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 7156F1200A3; Tue, 28 Jan 2020 12:07:05 -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: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <158024202538.4507.14495428195271728656@ietfa.amsl.com> Date: Tue, 28 Jan 2020 12:07:05 -0800 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-12.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, 28 Jan 2020 20:07:06 -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-12.txt Pages : 51 Date : 2020-01-28 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ffv1-12 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-12 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 Jan 28 12:08:34 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 DDB4E12007C; Tue, 28 Jan 2020 12:08:32 -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: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <158024211282.4587.1041584764440599945@ietfa.amsl.com> Date: Tue, 28 Jan 2020 12:08:32 -0800 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-v4-09.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, 28 Jan 2020 20:08:33 -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-09.txt Pages : 51 Date : 2020-01-28 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 are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ffv1-v4-09 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ffv1-v4-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-v4-09 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 Jan 28 13:24:12 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 79765120106; Tue, 28 Jan 2020 13:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 IvUka3oGx4hY; Tue, 28 Jan 2020 13:24:05 -0800 (PST) Received: from relay10.mail.gandi.net (relay10.mail.gandi.net [217.70.178.230]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC1E512011F; Tue, 28 Jan 2020 13:24:04 -0800 (PST) Received: from localhost (213-47-68-29.cable.dynamic.surfer.at [213.47.68.29]) (Authenticated sender: michael@niedermayer.cc) by relay10.mail.gandi.net (Postfix) with ESMTPSA id 934F7240003; Tue, 28 Jan 2020 21:24:01 +0000 (UTC) Date: Tue, 28 Jan 2020 22:24:00 +0100 From: Michael Niedermayer To: Adam Roach Cc: draft-ietf-cellar-ffv1.all@ietf.org, cellar@ietf.org Message-ID: <20200128212400.GN1173@michaelspb> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7R/oUIX7ilUHG0fO" Content-Disposition: inline In-Reply-To: Archived-At: Subject: Re: [Cellar] AD Review: draft-ietf-cellar-ffv1 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, 28 Jan 2020 21:24:11 -0000 --7R/oUIX7ilUHG0fO Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 02, 2020 at 05:26:07PM -0600, Adam Roach wrote: [...] >=20 > =A73.8.1.2: > >=A0 exact contexts used are best described by the > >=A0 following code, followed by some comments. >=20 > I can't find the referenced comments. I think this refered to the put_symbol() code below and the comments inside it. pseudo-code | type --------------------------------------------------------------|----- void put_symbol(RangeCoder *c, uint8_t *state, int v, int \ | is_signed) { | int i; | put_rac(c, state+0, !v); | if (v) { | int a=3D abs(v); | int e=3D log2(a); | | for (i =3D 0; i < e; i++) { | put_rac(c, state+1+min(i,9), 1); //1..10 | } | | put_rac(c, state+1+min(i,9), 0); | for (i =3D e-1; i >=3D 0; i--) { | put_rac(c, state+22+min(i,9), (a>>i)&1); //22..31 | } | | if (is_signed) { | put_rac(c, state+11 + min(e, 10), v < 0); //11..21| } | } | } | [...] > -------------------------------------------------------------------------= -- >=20 > =A74.1.17: >=20 > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------+--------------------------= -----------+ > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | value | relationship=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D+ > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 0=A0=A0=A0=A0 | Frames are indepe= ndent or dependent | > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 | (keyframes an= d non keyframes)=A0=A0=A0=A0=A0=A0 | > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------+--------------------------= -----------+ > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | 1=A0=A0=A0=A0 | Frames are indepe= ndent (keyframes=A0=A0 | > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 | only)=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 | > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------+--------------------------= -----------+ > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | Other | reserved for future use= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------+--------------------------= -----------+ > > > >=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 Table 14 >=20 > I'm having a hard time understanding "Other" in this table. Section 4.3 > defines "keyframe" to be of "br" type. I'm confused about how a boolean > variable can take on more than two values. This table does not describe the keyframe flag but the intra value from the global header. I think this should already be clear as it refers to that field "4.1.17. intra " and not the keyframe flag. But we could of course rename the field if that would make it clearer. [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire --7R/oUIX7ilUHG0fO Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEAREIAAYFAl4wpnAACgkQYR7HhwQLD6sNyQCfcpIq0mV5U65fd204dMCvxuEo b+AAn0yU30KtVLsFejejbucaBU9lVCjF =TdLu -----END PGP SIGNATURE----- --7R/oUIX7ilUHG0fO-- From nobody Wed Jan 29 06:06: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 842221200F5; Wed, 29 Jan 2020 06:06:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , villereal@gmail.com, cellar-chairs@ietf.org, cellar@ietf.org, Steven Villereal , draft-ietf-cellar-ebml@ietf.org, alexey.melnikov@isode.com, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <158030678853.2791.11785137623336814373.idtracker@ietfa.amsl.com> Date: Wed, 29 Jan 2020 06:06:28 -0800 Archived-At: Subject: [Cellar] Protocol Action: 'Extensible Binary Meta Language' to Proposed Standard (draft-ietf-cellar-ebml-17.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: Wed, 29 Jan 2020 14:06:29 -0000 The IESG has approved the following document: - 'Extensible Binary Meta Language' (draft-ietf-cellar-ebml-17.txt) as Proposed Standard This document is the product of the Codec Encoding for LossLess Archiving and Realtime transmission Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ Technical Summary This document defines format considerations for Extensible Binary Meta Language, a hierarchical file format for efficient delivery of binary data in defined Elements inspired by XML. It proposes definitions for creating and validating EBML Schemas that define the use and interpretation of Elements within EBML Documents. Working Group Summary This document has been adequately reviewed by working group members and others, through both mailing list discussion and Github issues and pull requests. One minor issue was how to define EBML Elements in a Header document in a forward-compatible way. It was decided Headers could require a specific, minimum or maximum EBMLVersion (which might have different implementations of Elements). Most recent discussion has focused on how Element IDs (unique identifiers for EBML Elements used within a Schema and Document) should be defined and encoded (as Variable Size Integers) with regard to IANA registration. Document Quality There are already several existing implementations of the specification, including ffmpeg, vlc, and most major browsers and many TV boxes. This is a very readable and clearly written document, and represents the inclusion of multiple recent revisions resolving minor outstanding issues. There appears to be strong group consensus on this document’s readiness to move forward in the standardization process. Personnel The document shepherd is Steven Villereal. The responsible Area Director is Alexey Melnikov. From nobody Fri Jan 31 07:06: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 EB95A12083E for ; Fri, 31 Jan 2020 07:06:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.018 X-Spam-Level: X-Spam-Status: No, score=-1.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, TRACKER_ID=0.1, 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 eAuX3xL3s8Pf for ; Fri, 31 Jan 2020 07:06:31 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23085120839 for ; Fri, 31 Jan 2020 07:06:31 -0800 (PST) Received: from [146.96.19.240] (port=53442 helo=[10.10.201.20]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1ixXsG-001xGK-WD; Fri, 31 Jan 2020 10:06:29 -0500 From: Dave Rice Message-Id: <2F73B0E2-D56F-4E8D-AA2D-FD4458CDDCCB@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_07DA342E-2BDF-4FA8-A9A1-D5982F6B6E6F" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 31 Jan 2020 10:06:22 -0500 In-Reply-To: Cc: Michael Richardson , spencerdawkins.ietf@gmail.com, alexey.melnikov@isode.com, Barry Leiba , Adam Roach , Alexey Melnikov , Steven Villereal , Codec Encoding for LossLess Archiving and Realtime transmission To: drafts-approval-comment@iana.org References: <158030678874.2791.1756674491139811730.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.104.11) X-OutGoing-Spam-Status: No, score=-0.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] [IANA #1161138] Protocol Action: 'Extensible Binary Meta Language' to Proposed Standard (draft-ietf-cellar-ebml-17.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: Fri, 31 Jan 2020 15:06:33 -0000 --Apple-Mail=_07DA342E-2BDF-4FA8-A9A1-D5982F6B6E6F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Amanda, > On Jan 30, 2020, at 8:16 PM, Amanda Baber via RT = wrote: >=20 > Dear Authors/Chairs, >=20 > Before we upload the new EBML registries, we have a question about = values that aren't mentioned in the document. >=20 > Most one-, two-, three-, four-, and five-octet values have their = meaning specified in the IANA Considerations section: assigned, = available for assignment (described as "Unassigned" in the registry), = Reserved, or "Not valid for use as an Element ID." However, we don't = know how to describe these values in the registry: Most of these values are "Not valid for use as an Element ID=E2=80=9D. = In https://www.ietf.org/id/draft-ietf-cellar-ebml-17.html#section-5 = is a = rule for Element IDs that says "The VINT_DATA component of the Element = ID MUST be encoded at the shortest valid length=E2=80=9D but there are = other reasons within these ranges so I=E2=80=99m noting the reason for = each value. > 0x4001-0x407E The range 0x4001-0x407E is invalid as Element ID as they can be written = more succinctly as 0x81-0xFE. > 0x200001-0x203FFE 0x200001-0x203FFE is invalid as Element ID as they can be written more = succinctly as 0x81-0xFE and 0x40FF-0x7FFE. > 0x10000001-0x101FFFFE 0x10000001-0x101FFFFE is invalid as Element ID as they can be written = more succinctly as 0x81-0xFE and 0x40FF-0x7FFE and 0x207FFF-0x3FFFFE. > 0x0000000000-0x080FFFFFFE The range of 0x0000000000-0x080FFFFFFE is more complex. - 0x0000000000 is invalid for other reasons as there is no VINT Marker. = It=E2=80=99s not an Element ID at all. - 0x0000000001-0x7FFFFFFFF are invalid as the VINT_WIDTH indicates a = width greater than the 5 byte width of the value range. - 0x0800000000 is invalid as the VINT_DATA of an Element ID can not be = all zero - 0x0800000001-0x80FFFFFFE are not valid as they can be written more = succinctly as 0x81-0xFE and 0x40FF-0x7FFE and 0x207FFF-0x3FFFFE and = 0x103FFFFF-0x1FFFFFFE > 0x0FFFFFFFFF-0xFFFFFFFFFF The 0x0FFFFFFFFF-0xFFFFFFFFFF is easier but different :) - 0x0FFFFFFFFF is invalid since "The bits of the VINT_DATA component of = the Element ID MUST NOT be all 0 values or all 1 values.=E2=80=9D = (section 5) - 0x1000000000-0xFFFFFFFFFF are invalid since the length of these values = is 5 bytes, but the VINT_WIDTH is not equal to 4 null bits. > How should we fill in the "Element Name" field for these values? I'm = attaching a PDF version of our first draft of the registry so that you = can see them in context.=20 [=E2=80=A6] I hope this helps. :) Kind Regards and thanks for your attention on this, Dave Rice= --Apple-Mail=_07DA342E-2BDF-4FA8-A9A1-D5982F6B6E6F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Amanda,

On Jan 30, 2020, at 8:16 PM, Amanda Baber via = RT <drafts-approval-comment@iana.org> wrote:

Dear = Authors/Chairs,

Before we upload the new = EBML registries, we have a question about values that aren't mentioned = in the document.

Most one-, two-, three-, = four-, and five-octet values have their meaning specified in the IANA = Considerations section: assigned, available for assignment (described as = "Unassigned" in the registry), Reserved, or "Not valid for use as an = Element ID." However, we don't know how to describe these values in the = registry:

Most of these values are "Not valid for use as an = Element ID=E2=80=9D. In https://www.ietf.org/id/draft-ietf-cellar-ebml-17.html#section-= 5 is a rule for Element IDs that says "The VINT_DATA component = of the Element ID MUST be encoded at the shortest valid length=E2=80=9D = but there are other reasons within these ranges so I=E2=80=99m noting = the reason for each value.

0x4001-0x407E

The = range 0x4001-0x407E is invalid as Element ID as they can be = written more succinctly as 0x81-0xFE.

0x200001-0x203FFE

0x200001-0x203FFE is invalid as Element ID as they = can be written more succinctly as 0x81-0xFE and 0x40FF-0x7FFE.

0x10000001-0x101FFFFE

0x10000001-0x101FFFFE is invalid as Element ID as = they can be written more succinctly as 0x81-0xFE and 0x40FF-0x7FFE and = 0x207FFF-0x3FFFFE.

0x0000000000-0x080FFFFFFE

The range of 0x0000000000-0x080FFFFFFE is more = complex.
- 0x0000000000 is invalid for other = reasons as there is no VINT Marker. It=E2=80=99s not an Element ID at = all.
- 0x0000000001-0x7FFFFFFFF are invalid as the = VINT_WIDTH indicates a width greater than the 5 byte width of the value = range.
- 0x0800000000 is invalid as the = VINT_DATA of an Element ID can not be all zero
- = 0x0800000001-0x80FFFFFFE are not valid as they can be written more = succinctly as 0x81-0xFE and 0x40FF-0x7FFE and 0x207FFF-0x3FFFFE and = 0x103FFFFF-0x1FFFFFFE

0x0FFFFFFFFF-0xFFFFFFFFFF

The 0x0FFFFFFFFF-0xFFFFFFFFFF is easier but different = :)
- 0x0FFFFFFFFF is invalid since "The bits of the = VINT_DATA component of the Element ID MUST NOT be all 0 values = or all 1 values.=E2=80=9D (section 5)
- = 0x1000000000-0xFFFFFFFFFF are invalid since the length of these values = is 5 bytes, but the VINT_WIDTH is not equal to 4 null = bits.

How should we fill in the "Element Name" = field for these values? I'm attaching a PDF version of our first draft = of the registry so that you can see them in context.

[=E2=80=A6]

I hope this helps. :)
Kind Regards and thanks for your attention on this,

Dave = Rice
= --Apple-Mail=_07DA342E-2BDF-4FA8-A9A1-D5982F6B6E6F-- From nobody Fri Jan 31 13:43: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 364C712004F for ; Fri, 31 Jan 2020 13:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.928 X-Spam-Level: X-Spam-Status: No, score=-2.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, 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 wP_pTS8b_SX8 for ; Fri, 31 Jan 2020 13:42:57 -0800 (PST) Received: from smtp01.icann.org (smtp01.icann.org [192.0.33.81]) (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 D3537120043 for ; Fri, 31 Jan 2020 13:42:57 -0800 (PST) Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id BFC05E07DD; Fri, 31 Jan 2020 21:42:56 +0000 (UTC) Received: by request4.lax.icann.org (Postfix, from userid 48) id B818620482; Fri, 31 Jan 2020 21:42:56 +0000 (UTC) RT-Owner: amanda.baber From: "Amanda Baber via RT" Reply-To: drafts-approval-comment@iana.org In-Reply-To: References: <158030678874.2791.1756674491139811730.idtracker@ietfa.amsl.com> <2F73B0E2-D56F-4E8D-AA2D-FD4458CDDCCB@dericed.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #1161138 X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/) X-RT-Originator: amanda.baber@icann.org CC: villereal@gmail.com, spencerdawkins.ietf@gmail.com, mcr+ietf@sandelman.ca, dave@dericed.com, cellar@ietf.org, barryleiba@computer.org, alexey.melnikov@isode.com, adam@nostrum.com, aamelnikov@fastmail.fm Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Fri, 31 Jan 2020 21:42:56 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: [Cellar] [IANA #1161138] Protocol Action: 'Extensible Binary Meta Language' to Proposed Standard (draft-ietf-cellar-ebml-17.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: Fri, 31 Jan 2020 21:43:00 -0000 Hi Dave, In the registry, should we use the description "Not valid for use as an Element ID" for all of these? If not, can you give us the exact text that should be used for each entry? If more specific text than "Not valid for use as an Element ID" should be used for these, should more text also be added for the ranges currently described as "Not valid for use as an Element ID"? I should add that any information presented in the registry should also be included in or referenced from the IANA Considerations section. thanks, Amanda Baber Lead IANA Services Specialist On Fri Jan 31 16:21:20 2020, dave@dericed.com wrote: > Hi Amanda, > > > On Jan 30, 2020, at 8:16 PM, Amanda Baber via RT > comment@iana.org> wrote: > > > > Dear Authors/Chairs, > > > > Before we upload the new EBML registries, we have a question about > > values that aren't mentioned in the document. > > > > Most one-, two-, three-, four-, and five-octet values have their > > meaning specified in the IANA Considerations section: assigned, > > available for assignment (described as "Unassigned" in the registry), > > Reserved, or "Not valid for use as an Element ID." However, we don't > > know how to describe these values in the registry: > > Most of these values are "Not valid for use as an Element ID”. In > https://www.ietf.org/id/draft-ietf-cellar-ebml-17.html#section-5 > is > a rule for Element IDs that says "The VINT_DATA component of the > Element ID MUST be encoded at the shortest valid length” but there are > other reasons within these ranges so I’m noting the reason for each > value. > > > 0x4001-0x407E > > The range 0x4001-0x407E is invalid as Element ID as they can be > written more succinctly as 0x81-0xFE. > > > 0x200001-0x203FFE > > 0x200001-0x203FFE is invalid as Element ID as they can be written more > succinctly as 0x81-0xFE and 0x40FF-0x7FFE. > > > 0x10000001-0x101FFFFE > > 0x10000001-0x101FFFFE is invalid as Element ID as they can be written > more succinctly as 0x81-0xFE and 0x40FF-0x7FFE and 0x207FFF-0x3FFFFE. > > > 0x0000000000-0x080FFFFFFE > > The range of 0x0000000000-0x080FFFFFFE is more complex. > - 0x0000000000 is invalid for other reasons as there is no VINT > Marker. It’s not an Element ID at all. > - 0x0000000001-0x7FFFFFFFF are invalid as the VINT_WIDTH indicates a > width greater than the 5 byte width of the value range. > - 0x0800000000 is invalid as the VINT_DATA of an Element ID can not be > all zero > - 0x0800000001-0x80FFFFFFE are not valid as they can be written more > succinctly as 0x81-0xFE and 0x40FF-0x7FFE and 0x207FFF-0x3FFFFE and > 0x103FFFFF-0x1FFFFFFE > > > 0x0FFFFFFFFF-0xFFFFFFFFFF > > The 0x0FFFFFFFFF-0xFFFFFFFFFF is easier but different :) > - 0x0FFFFFFFFF is invalid since "The bits of the VINT_DATA component > of the Element ID MUST NOT be all 0 values or all 1 values.” (section > 5) > - 0x1000000000-0xFFFFFFFFFF are invalid since the length of these > values is 5 bytes, but the VINT_WIDTH is not equal to 4 null bits. > > > How should we fill in the "Element Name" field for these values? I'm > > attaching a PDF version of our first draft of the registry so that > > you can see them in context. > > > […] > > I hope this helps. :) > Kind Regards and thanks for your attention on this, > > Dave Rice