From nobody Sat Dec 3 17:29:05 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B750E129472 for ; Sat, 3 Dec 2016 17:29:03 -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, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BM19TvWygerL for ; Sat, 3 Dec 2016 17:29:01 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D868D129477 for ; Sat, 3 Dec 2016 17:29:01 -0800 (PST) Received: from cpe-184-152-56-242.nyc.res.rr.com ([184.152.56.242]:44910 helo=[10.0.1.12]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1cDLbv-002oVO-5V for cellar@ietf.org; Sat, 03 Dec 2016 20:29:01 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_A6F433EC-D322-4B07-8BFE-3791CE30D456" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Message-Id: <54487E61-BE9B-409C-B84C-C103DECB2991@dericed.com> Date: Sat, 3 Dec 2016 20:28:56 -0500 To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] updating FFV1 referencing and formatting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 01:29:03 -0000 --Apple-Mail=_A6F433EC-D322-4B07-8BFE-3791CE30D456 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, I submitted a pull request at https://github.com/FFmpeg/FFV1/pull/25 = which focuses on adjusting the = formatting of ffv1.md for better handling once transformed through = rfc2xml. Note that in the first version of the ffv1 draft, many of the = code blocks and tables are poorly formed, see = https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-00#section-5.2 = = for instance. This PR adjust these sections to present them correctly. The pull request also updates the citations of the ffv1 draft to use the = form suggested by mmark (which prepared markdown for xml2rfc) at = https://github.com/miekg/mmark/wiki/Syntax#citations = . A preview of the rendered text of the pull request is available at = https://gist.github.com/dericed/2f4bf9c7d3b15aa4ba54f59184aa964f = . Dave Rice= --Apple-Mail=_A6F433EC-D322-4B07-8BFE-3791CE30D456 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all,

I = submitted a pull request at https://github.com/FFmpeg/FFV1/pull/25 which focuses = on adjusting the formatting of ffv1.md for better handling once = transformed through rfc2xml. Note that in the first version of the ffv1 = draft, many of the code blocks and tables are poorly formed, see https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-00#se= ction-5.2 for instance. This PR adjust these sections to = present them correctly.

The pull request also updates the citations of the ffv1 draft = to use the form suggested by mmark (which prepared markdown for xml2rfc) = at https://github.com/miekg/mmark/wiki/Syntax#citations.
=

A preview of the = rendered text of the pull request is available at https://gist.github.com/dericed/2f4bf9c7d3b15aa4ba54f59184aa964= f.

Dave = Rice
= --Apple-Mail=_A6F433EC-D322-4B07-8BFE-3791CE30D456-- From nobody Sat Dec 3 19:43:13 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDF61294B1 for ; Sat, 3 Dec 2016 19:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajSyZUOm3LSv for ; Sat, 3 Dec 2016 19:43:09 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9654E12941A for ; Sat, 3 Dec 2016 19:43:09 -0800 (PST) Received: from mfilter22-d.gandi.net (mfilter22-d.gandi.net [217.70.178.150]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id B2B3DA80C4 for ; Sun, 4 Dec 2016 04:43:07 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter22-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter22-d.gandi.net (mfilter22-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id xfR_YlIZQuP7 for ; Sun, 4 Dec 2016 04:43:05 +0100 (CET) X-Originating-IP: 213.47.41.20 Received: from localhost (213-47-41-20.cable.dynamic.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id BE903A80C1 for ; Sun, 4 Dec 2016 04:43:04 +0100 (CET) Date: Sun, 4 Dec 2016 04:42:59 +0100 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20161204034259.GK4757@nb4> References: <54487E61-BE9B-409C-B84C-C103DECB2991@dericed.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cEobB2knsyc5ebfU" Content-Disposition: inline In-Reply-To: <54487E61-BE9B-409C-B84C-C103DECB2991@dericed.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] updating FFV1 referencing and formatting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 03:43:12 -0000 --cEobB2knsyc5ebfU Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Dec 03, 2016 at 08:28:56PM -0500, Dave Rice wrote: > Hi all, >=20 > I submitted a pull request at https://github.com/FFmpeg/FFV1/pull/25 which focuses on adjusting the formatt= ing of ffv1.md for better handling once transformed through rfc2xml. Note t= hat in the first version of the ffv1 draft, many of the code blocks and tab= les are poorly formed, see https://tools.ietf.org/html/draft-niedermayer-ce= llar-ffv1-00#section-5.2 for instance. This PR adjust these sections to pre= sent them correctly. >=20 > The pull request also updates the citations of the ffv1 draft to use the = form suggested by mmark (which prepared markdown for xml2rfc) at https://gi= thub.com/miekg/mmark/wiki/Syntax#citations . i havnt yet had time to really review this but i spoted this: -| = | | -|-------------------------------------------------------------------------= --|------| -| QuantizationTablePerContext(i, j, scale) { = | type | -|=A0=A0=A0=A0v =3D 0 = | | -|=A0=A0=A0=A0for( k =3D 0; k \< 128; ) { = | | -|=A0=A0=A0=A0=A0=A0=A0=A0len - 1 = | sr | -|=A0=A0=A0=A0=A0=A0=A0=A0for( a =3D 0; a \< len; a++ ) { = | | -|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0quant\_tables[ i ][ j ][ k ] =3D scal= e* v | | -|=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0k++ = | | -|=A0=A0=A0=A0=A0=A0=A0=A0} = | | -|=A0=A0=A0=A0=A0=A0=A0=A0v++ = | | -|=A0=A0=A0=A0} = | | -|=A0=A0=A0=A0for( k =3D 1; k \< 128; k++ ) { = | | -|=A0=A0=A0=A0=A0=A0=A0=A0quant\_tables[ i ][ j ][ 256 - k ] =3D -quant\_ta= bles[ i ][ j ][ k ] | | -|=A0=A0=A0=A0} = | | -|=A0=A0=A0=A0quant\_tables[ i ][ j ][ 128 ] =3D -quant\_tables[ i ][ j ][ = 127 ] | | -|=A0=A0=A0=A0len\_count[ i ][ j ] =3D v = | | -|} = | | +```c +QuantizationTablePerContext(i, j, scale) { | type + v =3D 0 | + for( k =3D 0; k \< 128; ) { | + len - 1 | sr + for( a =3D 0; a \< len; a++ ) { | + quant_tables[ i ][ j ][ k ] =3D scale* v | + k++ | + } | + v++ | + } | + for( k =3D 1; k < 128; k++ ) { + quant_tables[ i ][ j ][ 256 - k ] =3D -quant_tables[ i ][ j ][ k ] + } + quant_tables[ i ][ j ][ 128 ] =3D -quant_tables[ i ][ j ][ 127 ] + len_count[ i ][ j ] =3D v +} +``` the right column is shortened also not specific to this patch but the text is formating wise still terrible The SliceFooter contains random \ in the pdf rendered output the type column heading is aligned with the function name there should be a matching heading term on the left column i think or it should be otherwise changed some if() have a space, some do not The Configuration Record has no table style but rather C comments 3.3 Context is horizontally spreat over the whole page in pdf the formating for 2.2.3 and 2.2.4 is different in pdf output =2E.. Ive just today installed pandoc 1.19 on the box where i normally review patches so i didnt fully realize before its that bad looking, i generally assumed my old tools where at fault ... [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws. -- Plato --cEobB2knsyc5ebfU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlhDkMMACgkQYR7HhwQLD6vSrACfS4EyJdM4M+Cs1i+bLjhd8USY 2qIAnRUjcmX+a2VwjSJDnu0tuNRSBSLn =K1no -----END PGP SIGNATURE----- --cEobB2knsyc5ebfU-- From nobody Sun Dec 4 09:29:46 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B50012956F for ; Sun, 4 Dec 2016 09:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7LtsrFAMOw2 for ; Sun, 4 Dec 2016 09:29:43 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698E9128B38 for ; Sun, 4 Dec 2016 09:29:43 -0800 (PST) Received: from cpe-184-152-56-242.nyc.res.rr.com ([184.152.56.242]:41081 helo=[10.0.1.12]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1cDabb-004HNw-On; Sun, 04 Dec 2016 12:29:42 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dave Rice In-Reply-To: <20161204034259.GK4757@nb4> Date: Sun, 4 Dec 2016 12:29:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54487E61-BE9B-409C-B84C-C103DECB2991@dericed.com> <20161204034259.GK4757@nb4> To: Michael Niedermayer X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] updating FFV1 referencing and formatting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 17:29:45 -0000 Hi, > On Dec 3, 2016, at 10:42 PM, Michael Niedermayer = wrote: >=20 > On Sat, Dec 03, 2016 at 08:28:56PM -0500, Dave Rice wrote: >> Hi all, >>=20 >> I submitted a pull request at https://github.com/FFmpeg/FFV1/pull/25 = which focuses on adjusting the = formatting of ffv1.md for better handling once transformed through = rfc2xml. Note that in the first version of the ffv1 draft, many of the = code blocks and tables are poorly formed, see = https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-00#section-5.2 = = for instance. This PR adjust these sections to present them correctly. >>=20 >> The pull request also updates the citations of the ffv1 draft to use = the form suggested by mmark (which prepared markdown for xml2rfc) at = https://github.com/miekg/mmark/wiki/Syntax#citations = . >=20 > i havnt yet had time to really review this but i spoted this: > -| = | | > = -|------------------------------------------------------------------------= ---|------| > -| QuantizationTablePerContext(i, j, scale) { = | type | > -| v =3D 0 = | | > -| for( k =3D 0; k \< 128; ) { = | | > -| len - 1 = | sr | > -| for( a =3D 0; a \< len; a++ ) { = | | > -| quant\_tables[ i ][ j ][ k ] =3D scale* v = | | > -| k++ = | | > -| } = | | > -| v++ = | | > -| } = | | > -| for( k =3D 1; k \< 128; k++ ) { = | | > -| quant\_tables[ i ][ j ][ 256 - k ] =3D -quant\_tables[ i ][ = j ][ k ] | | > -| } = | | > -| quant\_tables[ i ][ j ][ 128 ] =3D -quant\_tables[ i ][ j ][ 127 = ] | | > -| len\_count[ i ][ j ] =3D v = | | > -|} = | | > +```c > +QuantizationTablePerContext(i, j, scale) { | type > + v =3D 0 | > + for( k =3D 0; k \< 128; ) { | > + len - 1 | sr > + for( a =3D 0; a \< len; a++ ) { | > + quant_tables[ i ][ j ][ k ] =3D scale* v | > + k++ | > + } | > + v++ | > + } | > + for( k =3D 1; k < 128; k++ ) { > + quant_tables[ i ][ j ][ 256 - k ] =3D -quant_tables[ i ][ j = ][ k ] > + } > + quant_tables[ i ][ j ][ 128 ] =3D -quant_tables[ i ][ j ][ 127 ] > + len_count[ i ][ j ] =3D v > +} > +``` >=20 > the right column is shortened I had shortened it to prevent the line of code plus the right column = from exceeding the 72 character per line rfc limit. I adjusted this and pushed an update, so now the two lower lines are = wrapped with a backslah, as in: for( k =3D 1; k < 128; k++ ) { | quant_tables[ i ][ j ][ 256 - k ] =3D \ | -quant_tables[ i ][ j ][ k ] | } | quant_tables[ i ][ j ][ 128 ] =3D \ | -quant_tables[ i ][ j ][ 127 ] | | len_count[ i ][ j ] =3D v | > also not specific to this patch but the text is formating wise > still terrible >=20 > The SliceFooter contains random \ in the pdf rendered output Fixed and pushed. In tables the \ were needed for some escaping but in = code blocks they aren't and I neglected to change it in all cases. = Updated now. Please re-review. > the type column heading is aligned with the function name > there should be a matching heading term on the left column i think > or it should be otherwise changed such as? function | type ---------|----- > some if() have a space, some do not I added = https://github.com/FFmpeg/FFV1/pull/25/commits/c298a2f054f965bdf5b026b98a7= 91ec53a3964cd to standardize ifs into `if (...)` form. > The Configuration Record has no table style but rather C comments Updated. > 3.3 Context is horizontally spreat over the whole page in pdf I adjusted this to use a grid table in a codeblock, which seems to be a = good compromise between the rfc and pandoc outputs. ``` +---+---+---+---+ | | | T | | +---+---+---+---+ | |tl | t |tr | +---+---+---+---+ | L | l | X | | +---+---+---+---+ ``` > the formating for 2.2.3 and 2.2.4 is different in pdf output Fixed in = https://github.com/FFmpeg/FFV1/pull/25/commits/ab88dd92d2d1ac6a646d40d313a= 5ebf73dc189dd. > ... >=20 > Ive just today installed pandoc 1.19 on the box where i normally = review > patches so i didnt fully realize before its that bad looking, i > generally assumed my old tools where at fault ... I've been using pandoc 1.19 for my review as well, though please pay = attention to the html and txt outputs of rfc2xml as well. [...] Dave Rice From nobody Sun Dec 4 10:24:29 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6348B12958D for ; Sun, 4 Dec 2016 10:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxtIGb_3Rapk for ; Sun, 4 Dec 2016 10:24:26 -0800 (PST) Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [IPv6:2001:4b98:c:538::195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95DA612958B for ; Sun, 4 Dec 2016 10:24:26 -0800 (PST) Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay3-d.mail.gandi.net (Postfix) with ESMTP id D6386A80CF; Sun, 4 Dec 2016 19:24:24 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay3-d.mail.gandi.net ([IPv6:::ffff:217.70.183.195]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id Vv-TsZgrdXnX; Sun, 4 Dec 2016 19:24:23 +0100 (CET) X-Originating-IP: 213.47.41.20 Received: from localhost (213-47-41-20.cable.dynamic.surfer.at [213.47.41.20]) (Authenticated sender: michael@niedermayer.cc) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 59DC7A80C6; Sun, 4 Dec 2016 19:24:22 +0100 (CET) Date: Sun, 4 Dec 2016 19:24:16 +0100 From: Michael Niedermayer To: Dave Rice Message-ID: <20161204182416.GL4757@nb4> References: <54487E61-BE9B-409C-B84C-C103DECB2991@dericed.com> <20161204034259.GK4757@nb4> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Jl+DbTnyraiZ/loT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] updating FFV1 referencing and formatting X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 18:24:28 -0000 --Jl+DbTnyraiZ/loT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Dec 04, 2016 at 12:29:38PM -0500, Dave Rice wrote: [...] > > the type column heading is aligned with the function name > > there should be a matching heading term on the left column i think > > or it should be otherwise changed >=20 > such as? >=20 > function | type > ---------|----- yes thx [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus --Jl+DbTnyraiZ/loT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlhEX1AACgkQYR7HhwQLD6tjkwCeNf9diENwbCloX14wTapeYoh/ OicAn3bWQ/frTy/yN1kZt6utKpidctIA =sbqi -----END PGP SIGNATURE----- --Jl+DbTnyraiZ/loT-- From nobody Tue Dec 13 16:38:07 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCB712950E for ; Tue, 13 Dec 2016 16:38:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gpe2once09C for ; Tue, 13 Dec 2016 16:38:03 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463931294DF for ; Tue, 13 Dec 2016 16:38:03 -0800 (PST) Received: from cpe-184-152-56-242.nyc.res.rr.com ([184.152.56.242]:34945 helo=[10.0.1.12]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1cGxa4-003zDV-MG; Tue, 13 Dec 2016 19:38:02 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dave Rice In-Reply-To: Date: Tue, 13 Dec 2016 19:38:07 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0C2186DB-4BD7-4932-9FDD-E4B9DE71BF00@dericed.com> References: <20160704105742.vers3666ypusprc5@bunkus.org> To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Moritz Bunkus , Steve Lhomme Subject: Re: [Cellar] Position References vs Linked Segments X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 00:38:05 -0000 > On Jul 4, 2016, at 11:03 AM, Steve Lhomme = wrote: >=20 > 2016-07-04 12:57 GMT+02:00 Moritz Bunkus : >> Hey, >>=20 >>> Although this section is linked to the documentation the term = Position >>> Reference is never used outside the definition. I propose changing = the >>> term from Position Reference to Segment Offset, if I properly >>> understand that the term refers to the offset within from the = Segment >>> or from the first Segment of a Linked Segment. >>=20 >> +1 > +1 >=20 >>> Also, I'm curious if this part of the documentation is correct: "For >>> example to reference a position in the third segment, the position >>> will be: the first segment total size + second segment total size + >>> offset of the element in the third segment." >>=20 >> I'm almost certain that it should be the segment's data sizes that = are >> added excluding their element ID and size field size. >>=20 >>> But are you sure that it is not >>>=20 >>> Segment1:Data + Segment2:TotalSize + Segment3:ElementID + = Segment3:DataSize + Segment3:OffsetToElement =3D >>> 100 + 211 + 4 + 8 + 300 =3D 623 >>=20 >> Meaning I agree that this should be correct. It was probably an >> oversight, or we simply weren't careful enough with our wording. >=20 > Yes, offsets should exclude the EBML header and the Segment header (ID > + length). >=20 > Moritz, when splitting a file with tags or chapters, do you put them > in each segment or refer to them with an offset in one of the segments > ? > Do we have a real life case where we reference an element outside of > its own Segment ? This discussion continued a bit in a pull request, notably: = https://github.com/Matroska-Org/matroska-specification/pull/26#issuecommen= t-230740374 = https://github.com/Matroska-Org/matroska-specification/pull/26#issuecommen= t-232136509 Based on Moritz's comments it seems that the Position Reference refers = to the encapsulating Segment and not the first Segment (as in a Linked = Segment). If this is the case, then it conflicts with the earlier draft = of the Matroska specifications at = https://matroska.org/technical/specs/notes.html where it says: > When data is spanned over mutiple "linked Segments" (in the same file = or in different files), the position represents the accumulated offset = of each Segment. For example to reference a position in the third = segment, the position will be: the first segment total size + second = segment total size + offset of the element in the third segment.=20 I can adjust the pull request to define Position Reference (or the = proposal rename to Segment Position) as only relative to the = encapsulating Segment regardless of Segment Linking, but since this = partly contradicts historical Matroska documentation I wanted to seek = any objections or opinions on the matter. Best Regards, Dave Rice From nobody Thu Dec 15 01:17:05 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 210F0129C07 for ; Thu, 15 Dec 2016 01:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZKZ-A7SEqiN for ; Thu, 15 Dec 2016 01:17:01 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60B96129C31 for ; Thu, 15 Dec 2016 01:16:59 -0800 (PST) Received: from [10.0.0.11] (1360030002.d-dsl.at [::ffff:81.16.105.50]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 15 Dec 2016 10:16:58 +0100 id 00000000000000E1.0000000058525F8A.00003836 Message-ID: <58525F89.5000600@das-werkstatt.com> Date: Thu, 15 Dec 2016 10:16:57 +0100 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cellar] Film: color handling - container or codec? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 09:17:04 -0000 Dear all, Due to recent demands, I would like to follow up on the issue of color handling. Especially the features required for properly handling digital film material (e.g. from DPX). There have been threads addressing this already: "FFV1 Version 4" (2016-01-05) https://mailarchive.ietf.org/arch/msg/cellar/RFYBaQSuoULr8sIw9RfHwnfZKvQ "Colour Format proposal" (2016-02-16) https://mailarchive.ietf.org/arch/msg/cellar/A3DsbrRMsPeps1WKRNJOZQRxYy4 In order to avoid getting lost in detail (which I'm an expert in!), it might be a good starting point to agree on *where* to store color information: ======================= container or codec - or both? ======================= All 3 versions have their pros and cons, but I think having it in both causes more trouble than does good (see below). Here's my current point of view: 1) Container only ======================= PROs: * Independent of codec used * Already existing color-handling in MKV * Higher chance of non-ffmpeg applications supporting it. CONs: * Quote Niedermayer: "if its not stored at codec level and only supported by one of several containers it would have a high chance of being lost" * Restricts to a very limited choice of containers 2) Codec only ======================= PROs: * Independent which container is used. * Higher chance of keeping the information throughout the material's lifecycle * Fresh start possible (no legacy compatibility to consider with FFV1) CONs: * If container already has *some* color-handling, there might be an information conflict (=interoperability issues) * Less chance of non-ffmpeg applications supporting it, compared to container. 3) Both ======================= All PROs of both individual options, *but* with a very very high chance of interpretation- and interoperability issues between different applications and scenarios, depending on whether an application prioritizes data in container or codec. Doesn't matter if they are identical, but I've seen container/codec-mismatching metadata (e.g. aspect-ratio, etc) in real-life, that I do believe this would be a real issue. If all this is a no-brainer and has an absolutely obvious answer, then I'm happy! Thank you very much in advance, Pb From nobody Thu Dec 15 03:05:39 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F141299BC for ; Thu, 15 Dec 2016 03:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2LUNzsP6nV7n for ; Thu, 15 Dec 2016 03:05:35 -0800 (PST) Received: from 9.mo3.mail-out.ovh.net (9.mo3.mail-out.ovh.net [87.98.184.141]) (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 A8C7A12997C for ; Thu, 15 Dec 2016 03:05:00 -0800 (PST) Received: from player771.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id EA5AC6754B for ; Thu, 15 Dec 2016 12:04:58 +0100 (CET) Received: from [192.168.2.101] (p5DDB7A8C.dip0.t-ipconnect.de [93.219.122.140]) (Authenticated sender: jerome@francoallemand.eu) by player771.ha.ovh.net (Postfix) with ESMTPSA id 2B08B84008F for ; Thu, 15 Dec 2016 12:04:46 +0100 (CET) To: cellar@ietf.org References: <58525F89.5000600@das-werkstatt.com> From: Jerome Martinez Message-ID: <514e85ef-609a-6311-92d2-75af72dee09b@mediaarea.net> Date: Thu, 15 Dec 2016 12:04:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <58525F89.5000600@das-werkstatt.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 8704895130952798353 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelfedrieekgddtlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Film: color handling - container or codec? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 11:05:37 -0000 Le 15/12/2016 à 10:16, Peter B. a écrit : > [...] > > 3) Both > ======================= > All PROs of both individual options, *but* with a very very high chance > of interpretation- and interoperability issues between different > applications and scenarios, depending on whether an application > prioritizes data in container or codec. > > Doesn't matter if they are identical, but I've seen > container/codec-mismatching metadata (e.g. aspect-ratio, etc) in > real-life, that I do believe this would be a real issue. You already have mismatches do handle, this would not be new here. So from my point of view having them in both the container and the codec is the only choice if you want to keep such metadata during transcoding / transwrapping in a safe manner in all cases. e.g. someone changes of container from MOV to Matroska without re-encoding, the MOV metadata may be lost (classic) but the codec metadata would be kept. e.g. some codecs (raw video, current FFV1) has not this metadata, we need to support container values. For the DPX issue, a first step could be to adapt FFmpeg in order to correctly read and map the DPX values in the already defined Matroska metadata (with maybe some "upgrade" because some DPX values may not be in the Matroska lists), then we add also a metadata part in the FFV1 global header (update of FFV1 v3 or in new v4, it would depend on if v3 can be expanded, to be studied). Jérôme From nobody Thu Dec 15 04:22:30 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90CB912A067 for ; Thu, 15 Dec 2016 04:22:27 -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] 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 oi02EBgjeGnx for ; Thu, 15 Dec 2016 04:22:25 -0800 (PST) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A2D12A075 for ; Thu, 15 Dec 2016 04:13:06 -0800 (PST) Received: from eris.local (dynamic-adsl-84-221-244-216.clienti.tiscali.it [84.221.244.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 68B68340EEA for ; Thu, 15 Dec 2016 12:13:05 +0000 (UTC) To: cellar@ietf.org References: <58525F89.5000600@das-werkstatt.com> From: Luca Barbato Message-ID: Date: Thu, 15 Dec 2016 13:13:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: <58525F89.5000600@das-werkstatt.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Film: color handling - container or codec? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 12:22:27 -0000 On 15/12/2016 10:16, Peter B. wrote: > 3) Both ======================= > Doesn't matter if they are identical, but I've seen > container/codec-mismatching metadata (e.g. aspect-ratio, etc) in > real-life, that I do believe this would be a real issue. If you care about preserving the data during processing having it in both places gives you a better chance to preserve it. If you focus about conversion, you would enjoy having your master data containing the information at both level so you do not need software that's particularly careful in moving the data from the container-level to the codec level while streamcopying to containers less rich. In my opinion, from the safest to the least safe: - both places Easier to spot inconsistencies Easier to derive content that's correct even if the target container is less than optimal. - codec only Requires to have a decoder to get some information instead of just looking at the container. - container only If you remux to the wrong container you have to guess the information you lost. In general you do not want to rely on a single tool being correct and you'd rather want to have a mean to validate tools that is independent. lu From nobody Thu Dec 15 04:27:02 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B6C1294C5 for ; Thu, 15 Dec 2016 04:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dTnSJXgkKMG for ; Thu, 15 Dec 2016 04:27:00 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C473F129A41 for ; Thu, 15 Dec 2016 04:19:44 -0800 (PST) Received: from [10.0.0.11] (1360030002.d-dsl.at [::ffff:81.16.105.50]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 15 Dec 2016 13:19:43 +0100 id 00000000000000E9.0000000058528A5F.00005E16 Message-ID: <58528A5E.3070909@das-werkstatt.com> Date: Thu, 15 Dec 2016 13:19:42 +0100 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: cellar@ietf.org References: <58525F89.5000600@das-werkstatt.com> <514e85ef-609a-6311-92d2-75af72dee09b@mediaarea.net> In-Reply-To: <514e85ef-609a-6311-92d2-75af72dee09b@mediaarea.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Film: color handling - container or codec? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 12:27:02 -0000 On 12/15/2016 12:04 PM, Jerome Martinez wrote: > You already have mismatches do handle, this would not be new here. I know, but I thought it would be nice to avoid adding new ones :) > So from my point of view having them in both the container and the > codec is the only choice if you want to keep such metadata during > transcoding / transwrapping in a safe manner in all cases. Indeed. Yet, I would like to avoid scenarios where one has to live with wrong metadata, because there is no tool to correct it without requiring re-encoding. If it's supported by both (in an easily compatible way) and there are ways to fix wrong metadata, I'd be happy! > For the DPX issue, a first step could be to adapt FFmpeg in order to > correctly read and map the DPX values in the already defined Matroska > metadata (with maybe some "upgrade" because some DPX values may not be > in the Matroska lists), then we add also a metadata part in the FFV1 > global header (update of FFV1 v3 or in new v4, it would depend on if > v3 can be expanded, to be studied). As I understand it, LUTs would enable the decoder to handle any mapping properly. Whereas a predefined "mapping-referred-to-by-index" would mean that not-so-popular mappings would more likely be unsupported in different applications. I'm not an expert on this, but I would be *very much* in favor of embedded LUTs, as this seems the most self-sustaining way. Any downside of embedded LUTs? Cheers! Pb From nobody Thu Dec 15 04:33:09 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6B6129C81 for ; Thu, 15 Dec 2016 04:33:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ih3YBRb01Zt3 for ; Thu, 15 Dec 2016 04:33:06 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9A0F129E6B for ; Thu, 15 Dec 2016 04:26:59 -0800 (PST) Received: from [10.0.0.11] (1360030002.d-dsl.at [::ffff:81.16.105.50]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 15 Dec 2016 13:26:59 +0100 id 00000000000000F9.0000000058528C13.00006C4F Message-ID: <58528C11.2080707@das-werkstatt.com> Date: Thu, 15 Dec 2016 13:26:57 +0100 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: cellar@ietf.org References: <58525F89.5000600@das-werkstatt.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Film: color handling - container or codec? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 12:33:07 -0000 On 12/15/2016 01:13 PM, Luca Barbato wrote: > In general you do not want to rely on a single tool being correct and > you'd rather want to have a mean to validate tools that is independent. Absolutely on your side. If both (container+codec) contain the same value, it's great to have it in both. But once container and codec don't "agree" for some reason, things get ugly. How is this currently dealt with with existing metadata that exists in both container+codec? Thanksalot, Pb From nobody Thu Dec 15 04:39:00 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ABF4129A45 for ; Thu, 15 Dec 2016 04:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qb3hpWNzmyI9 for ; Thu, 15 Dec 2016 04:38:56 -0800 (PST) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20899129CC9 for ; Thu, 15 Dec 2016 04:36:57 -0800 (PST) Received: from eris.local (dynamic-adsl-84-221-244-216.clienti.tiscali.it [84.221.244.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id AF33A33D3CE for ; Thu, 15 Dec 2016 12:36:55 +0000 (UTC) To: cellar@ietf.org References: <58525F89.5000600@das-werkstatt.com> <58528C11.2080707@das-werkstatt.com> From: Luca Barbato Message-ID: <0567d113-13f7-3936-a6a7-2f6788093d4f@libav.org> Date: Thu, 15 Dec 2016 13:36:51 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Thunderbird/50.0 MIME-Version: 1.0 In-Reply-To: <58528C11.2080707@das-werkstatt.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Film: color handling - container or codec? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 12:38:59 -0000 On 15/12/2016 13:26, Peter B. wrote: > On 12/15/2016 01:13 PM, Luca Barbato wrote: >> In general you do not want to rely on a single tool being correct >> and you'd rather want to have a mean to validate tools that is >> independent. > > Absolutely on your side. If both (container+codec) contain the same > value, it's great to have it in both. But once container and codec > don't "agree" for some reason, things get ugly. I'd call it inconsistent, but it is sort of ok since you easily can spot it and amend it. > How is this currently dealt with with existing metadata that exists > in both container+codec? Usually if you have the information from the codec that's the one to prioritize. lu From nobody Thu Dec 15 04:59:55 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBCC129DA2 for ; Thu, 15 Dec 2016 04:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdRM3Y5D3TIq for ; Thu, 15 Dec 2016 04:59:52 -0800 (PST) Received: from 17.mo3.mail-out.ovh.net (17.mo3.mail-out.ovh.net [87.98.178.58]) (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 E5206129D84 for ; Thu, 15 Dec 2016 04:59:51 -0800 (PST) Received: from player771.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id 8D79669B8E for ; Thu, 15 Dec 2016 13:59:49 +0100 (CET) Received: from [192.168.2.101] (p5DDB7A8C.dip0.t-ipconnect.de [93.219.122.140]) (Authenticated sender: jerome@francoallemand.eu) by player771.ha.ovh.net (Postfix) with ESMTPSA id 34E59840080 for ; Thu, 15 Dec 2016 13:59:48 +0100 (CET) To: cellar@ietf.org References: <58525F89.5000600@das-werkstatt.com> <58528C11.2080707@das-werkstatt.com> From: Jerome Martinez Message-ID: <4159ee69-1bf4-9486-f5b4-026d47630623@mediaarea.net> Date: Thu, 15 Dec 2016 13:59:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <58528C11.2080707@das-werkstatt.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 10647916894391767185 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelfedrieekgddulecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Film: color handling - container or codec? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 12:59:54 -0000 Le 15/12/2016 à 13:26, Peter B. a écrit : > [...] > How is this currently dealt with with existing metadata that exists in > both container+codec? You get all behaviors; depending of the software you use. Yes, it is ugly, but it is the less awful method (it is better to have 2 different values with different behavior than no value). As Luca, I argue for prioritizing the one from the codec because en encoder uses to be more near from the source and anyone can create a (buggy) muxer without a lot of skills, but I know some cases where people use the container for "correcting" the bad value from the wrongly configured digitalizing hardware (instead of patching the hardware, due to different reasons e.g. vendor not willing to patch), so the one from the codec is not always the real one. Unfortunately, no way to know for sure which one is correct when we have 2 different values, this is a manual check. FYI, MediaInfo shows both values when a mismatch is detected, so you can know that there is a mismatch and you can see the 2 values. From nobody Thu Dec 15 05:34:52 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 675D7129DF5 for ; Thu, 15 Dec 2016 05:34:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.691 X-Spam-Level: X-Spam-Status: No, score=-0.691 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=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 cCpXhdhlW-yb for ; Thu, 15 Dec 2016 05:34:46 -0800 (PST) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 589C7129E2A for ; Thu, 15 Dec 2016 05:34:26 -0800 (PST) Received: from smtp5.infomaniak.ch (smtp5.infomaniak.ch [83.166.132.18]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id uBFDYO2O024231 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 15 Dec 2016 14:34:24 +0100 Received: from Castor.local (dynamic.wline.6rd.res.cust.swisscom.ch [IPv6:2a02:1205:5049:39e0:d5f1:a77f:7e84:b8e5] (may be forged)) (authenticated bits=0) by smtp5.infomaniak.ch (8.14.5/8.14.5) with ESMTP id uBFDYNZE027640 for ; Thu, 15 Dec 2016 14:34:23 +0100 Date: Thu, 15 Dec 2016 14:34:23 +0100 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] Film: color handling - container or codec? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 13:34:49 -0000 Luca Barbato wrote: >If you care about preserving the data during processing >having it in both places gives you a better chance to >preserve it. I agree with the idea to have the information twice: in the container and in the codec. In case of differences, I suggest to consider the codec's data over the container's. Best regards, Reto From nobody Thu Dec 15 07:31:34 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB9F1296F9 for ; Thu, 15 Dec 2016 07:31:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZWznZ5g5-iX for ; Thu, 15 Dec 2016 07:31:28 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78C951296FB for ; Thu, 15 Dec 2016 07:31:27 -0800 (PST) Received: from [146.96.19.240] (port=29265 helo=[10.10.201.55]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1cHY0E-00207f-5s for cellar@ietf.org; Thu, 15 Dec 2016 10:31:26 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: dave@dericed.com X-Priority: 3 In-Reply-To: Date: Thu, 15 Dec 2016 10:31:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <107C27FC-AB23-4524-91DD-A593335B8B98@dericed.com> References: To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Film: color handling - container or codec? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 15:31:30 -0000 > On Dec 15, 2016, at 8:34 AM, Reto Kromer wrote: >=20 > Luca Barbato wrote: >=20 >> If you care about preserving the data during processing >> having it in both places gives you a better chance to >> preserve it. >=20 > I agree with the idea to have the information twice: in the > container and in the codec. In case of differences, I > suggest to consider the codec's data over the container's. If the data is intended to or offered to be stored redundantly in both = the container (Matroska) and encoding (FFV1), then perhaps FFV1 should = adopt something semantically identical to the Colour Element of = Matroska. If keeping the Colour of Matroska and FFV1 semantically = identical is agreeable then we could consider the need for LUT storage = by first adding it to the Colour Element of Matroska. To store such Colour data in FFV1, would Colour data be best stored in = Parameters. I see other data that regards the presentation (such as = sar_num and sar_den) stored in the Slice Header, but I don't think it's = feasible for Colour to vary within a frame per slice. Dave Rice= From nobody Mon Dec 19 11:37:55 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 100841295F8 for ; Mon, 19 Dec 2016 11:37:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6CLKIy8N_5tw for ; Mon, 19 Dec 2016 11:37:49 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2CB01295EE for ; Mon, 19 Dec 2016 11:37:49 -0800 (PST) Received: from [146.96.19.240] (port=30718 helo=[10.10.201.55]) by server172.web-hosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.86_1) (envelope-from ) id 1cJ3kp-002yy9-RK for cellar@ietf.org; Mon, 19 Dec 2016 14:37:48 -0500 From: dave@dericed.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Message-Id: <063F3BBA-CB3B-4417-A21F-586226A5464E@dericed.com> Date: Mon, 19 Dec 2016 14:37:46 -0500 To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] building RFC documents X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 19:37:51 -0000 Hi all, For those using Homebrew, there's now an mmark installer in Homebrew = which makes the build environment a little easier to set up. With = homebrew you can get the dependencies for building CELLAR docs with: brew install pandoc mmark xml2rfc Then to build either the Matroska, EBML, or FFV1 specifications, you can = cd into the cloned repository and run 'make'. For instance: git clone https://github.com/FFmpeg/FFV1.git cd FFV1 make This should produce formatted drafts of the outputs: - draft-niedermayer-cellar-ffv1-00.html - draft-niedermayer-cellar-ffv1-00.txt - ffv1.html (non-RFC format) - ffv1.pdf (non-RFC format) In working on the Markdown text I find it helpful to check how it builds = every so often as there are some differences with the outputs. Best Regards, Dave Rice= From nobody Tue Dec 27 12:22:47 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB03129B7F for ; Tue, 27 Dec 2016 12:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUeACSCnJrnk for ; Tue, 27 Dec 2016 12:22:43 -0800 (PST) Received: from 4.mo1.mail-out.ovh.net (4.mo1.mail-out.ovh.net [46.105.76.26]) (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 629A2129B7D for ; Tue, 27 Dec 2016 12:22:42 -0800 (PST) Received: from player770.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo1.mail-out.ovh.net (Postfix) with ESMTP id B91AB2FE7F for ; Tue, 27 Dec 2016 21:22:40 +0100 (CET) Received: from [192.168.2.102] (p4FE1F63A.dip0.t-ipconnect.de [79.225.246.58]) (Authenticated sender: zen@mediaarea.net) by player770.ha.ovh.net (Postfix) with ESMTPSA id 4EF1C3C0077 for ; Tue, 27 Dec 2016 21:22:40 +0100 (CET) To: cellar@ietf.org From: Jerome Martinez Message-ID: <2651a6f3-9c9a-6f76-2ee7-4d5c23b1ce57@mediaarea.net> Date: Tue, 27 Dec 2016 21:22:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------77E45532DECD718A3B10768A" X-Ovh-Tracer-Id: 14812339176257687697 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelgedrtddtgdduudejucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: [Cellar] Ancillary data in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 20:22:46 -0000 This is a multi-part message in MIME format. --------------77E45532DECD718A3B10768A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit We need additional codec to be supported in Matroska in order to be able to transwrap in a lossless manner content from older containers to Matroska, especially time codes (all the codecs defined in the patch can contain 1 or more time codes) The global idea is to be able to transwrap e.g. MOV (from Apple), MXF (from SMPTE), GXF (from Grass Valley, also known as SMPTE ST 360 and SMPTE RDD 14, found in some broadcaster archives), LXF (from Leitch/Harris, found in some broadcaster archives) without losing metadata in some sidecar non visible streams. After agreeing on the format, we will have to update tools e.g. FFmpeg in order to support such lossless transwrap. I added an "Ancillary" section with several mappings in the attached patch, please comment. Comments: The frequent remark is "Why do you need so many time code formats, choose one and stop using the others": in the real world, people consider that one format is the best one, but not the same format as others, and they use only this time code for their work and don't plan to switch. You can have 10+ time codes in a file and each one is important for someone, as well as the sidecar information transported at the same time (never same between each format). There is no consensus about that for years, and I don't think we could achieve a consensus from the different actors (lot of them are not interested by our work at IETF) so the idea here is to be able to move from one container to another one without losing any metadata, absolutely not deciding about a reference time code (and other metadata) format, as Matroska does for e.g. video (Matroska does not say that VP9 should be used instead of AVC, it supports both). "N_" prefix arbitrary used (2nd letter of "Ancillary" because first letter is already used) N_QUICKTIME: is a pure copy of V_QUICKTIME and A_QUICKTIME already supported in Matroska, N_ would be used which would be used for e.g. tmcd codec (QuickTime time code). Exactly same principles as video and audio. Note that classic usage is to store only the first frame content and other content is computed from it, so a player would have to read the first frame even if there is a direct seek request to another place; this could be avoided with some "hack" in the track header, could be the next step after this one is accepted. VBI and ANC: used to transport time codes (LTC, VITC, ATC...), Recording Information, bar and pan/scan data, captions (North American CEA-608, CEA-708, European and Australian WSS/Teletext, Japanese ARIB B37...), camera acquisition dynamic metadata, Audio Metadata, Film Transfer and Video Production Information (in theory, I never saw it)... The "perfect" solution would be to decode VBI and ANC, and put each format in its own specification, but it would be an huge task and we still would have to store opaque content (content is present in the VBI/ANC but we ignore all from it right now), so it is better to start by the beginning and we consider all opaque without trying to decode the data, as do other containers. N_STRIPPEDTIMECODE: the Cluster part will contain no data, but despite of that it must be a complete standalone track, with Track Id ans so on, as it is a standalone track in the source container. N_SDTICP: nearly 1:1 copy of SMPTE ST 385 elements. In order to have all data and being able to have only 1 Matroska block for all STDI-CP elements, I kept also the 2 last bytes of the KLV "Key" and the KLV "Length" in addition of the KLV "Value". Note that something weird, this is a standalone track in source container but the difference with other tracks (including ANC or VBI) is that this stream has no track header so no track number, and Matroska specs makes TrackNumber mandatory, I wonder what should be used during transwrap (fake number?) TODO: support of GXF non stripped time codes Jérôme --------------77E45532DECD718A3B10768A Content-Type: text/plain; charset=UTF-8; name="0001-Embedding-of-ancillary-data-in-Matroska.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0001-Embedding-of-ancillary-data-in-Matroska.patch" RnJvbSA3MDU3YzI1MmMyNDM4ZTFjNGNkYmZmOGY4Zjk3ZGQwYTEwYzNkOGQwIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Sj1DMz1BOXI9QzM9QjRtZT0yME1h cnRpbmV6Pz0gPGplcm9tZUBtZWRpYWFyZWEubmV0PgpEYXRlOiBUdWUsIDI3IERlYyAyMDE2 IDIxOjE0OjM4ICswMTAwClN1YmplY3Q6IFtQQVRDSF0gRW1iZWRkaW5nIG9mIGFuY2lsbGFy eSBkYXRhIGluIE1hdHJvc2thCgotLS0KIGNvZGVjX3NwZWNzLm1kIHwgMzIgKysrKysrKysr KysrKysrKysrKysrKysrKysrKysrKysKIDEgZmlsZSBjaGFuZ2VkLCAzMiBpbnNlcnRpb25z KCspCgpkaWZmIC0tZ2l0IGEvY29kZWNfc3BlY3MubWQgYi9jb2RlY19zcGVjcy5tZAppbmRl eCAzZmRlMTEyLi5mYTkwNzNjIDEwMDY0NAotLS0gYS9jb2RlY19zcGVjcy5tZAorKysgYi9j b2RlY19zcGVjcy5tZApAQCAtMzg0LDMgKzM4NCwzNSBAQCBGb3IgZWFjaCBsaW5lIGNvbnRh aW5pbmcgdGhlIHRpbWVzdGFtcCBhbmQgZmlsZSBwb3NpdGlvbiBkYXRhIGlzIHJlYWQgZnJv bSB0aGUgYQogKipDb2RlYyBJRDoqKiBCX1ZPQkJUTiAgCiAqKkNvZGVjIE5hbWU6KiogVm9i QnRuIEJ1dHRvbnMgICAKICoqRGVzY3JpcHRpb246KiogQmFzZWQgb24gW01QRUcvVk9CIFBD SSBwYWNrZXRzXShodHRwOi8vZHZkLnNvdXJjZWZvcmdlLm5ldC9kdmRpbmZvL3BjaV9wa3Qu aHRtbCkuIFRoZSBmaWxlIGNvbnRhaW5zIGEgaGVhZGVyIGNvbnNpc3Rpbmcgb2YgdGhlIHN0 cmluZyAiYnV0b25EVkQiIGZvbGxvd2VkIGJ5IHRoZSB3aWR0aCBhbmQgaGVpZ2h0IGluIHBp eGVscyAoMTYgYml0cyBpbnRlZ2VyIGVhY2gpIGFuZCA0IHJlc2VydmVkIGJ5dGVzLiBUaGUg cmVzdCBpcyBmdWxsIFtQQ0kgcGFja2V0c10oaHR0cDovL2R2ZC5zb3VyY2Vmb3JnZS5uZXQv ZHZkaW5mby9wY2lfcGt0Lmh0bWwpLgorCisjIyBBbmNpbGxhcnkKKworICAKKyoqQ29kZWMg SUQ6KiogTl9WQkkgIAorKipDb2RlYyBOYW1lOioqIFZlcnRpY2FsIEJsYW5raW5nIEludGVy dmFsICAKKyoqRGVzY3JpcHRpb246KiogdXNlZCBpbiBTRFRWLCBzZWUgaHR0cHM6Ly9lbi53 aWtpcGVkaWEub3JnL3dpa2kvVmVydGljYWxfYmxhbmtpbmdfaW50ZXJ2YWwgZm9yIG1vcmUg aW5mb3JtYXRpb24uIEVhY2ggTWF0cm9za2EgYmxvY2sgY29udGFpbnMgYSBTTVBURSBTVCA0 MzYgVkJJIEZyYW1lIEVsZW1lbnQuICAKKworICAKKyoqQ29kZWMgSUQ6KiogTl9BTkMKKyoq Q29kZWMgTmFtZToqKiBWZXJ0aWNhbCBvciBIb3Jpem9udGFsIEFuY2lsbGFyeSBkYXRhCisq KkRlc2NyaXB0aW9uOioqIHVzZWQgaW4gSERUViwgc2VlIGh0dHBzOi8vZW4ud2lraXBlZGlh Lm9yZy93aWtpL0FuY2lsbGFyeV9kYXRhIGZvciBtb3JlIGluZm9ybWF0aW9uLiBFYWNoIE1h dHJvc2thIGJsb2NrIGNvbnRhaW5zIGEgU01QVEUgU1QgNDM2IFZCSSBGcmFtZSBFbGVtZW50 LgorCisgIAorKipDb2RlYyBJRDoqKiBOX1FVSUNLVElNRSAgCisqKkNvZGVjIE5hbWU6Kiog R2VuZXJpYyBvciBudWxsIGhhbmRsZXJzIChub24gdmlkZW8vYXVkaW8vdGV4dCBoYW5kbGVy cykgdGFrZW4gZnJvbSBRdWlja1RpbWUoVE0pIGZpbGVzICAKKyoqRGVzY3JpcHRpb246Kiog U2V2ZXJhbCBjb2RlY3MgYXJlIHN0b3JlZCBpbiBRdWlja1RpbWUgd2l0aCBhIGdlbmVyaWMg aGFuZGxlciB0eXBlICgiZ21oZCIpIG9yIGEgbnVsbCBoYW5kbGVyIHR5cGUgKCJubWhkIiks IHRoaXMgQ29kZUNJRCBpcyBpbnRlbmRlZCBmb3Igbm9uIHZpc2libGUgc3RyZWFtcyBlLmcu IFRpbWUgY29kZS4gVGhlIENvZGVjUHJpdmF0ZSBjb250YWlucyBhbGwgYWRkaXRpb25hbCBk YXRhIHRoYXQgaXMgc3RvcmVkIGluIHRoZSAnc3RzZCcgKHNhbXBsZSBkZXNjcmlwdGlvbikg YXRvbSBpbiB0aGUgUXVpY2tUaW1lIGZpbGUgKiphZnRlcioqIHRoZSBtYW5kYXRvcnkgdmlk ZW8gZGVzY3JpcHRvciBzdHJ1Y3R1cmUgKHN0YXJ0aW5nIHdpdGggdGhlIHNpemUgYW5kIEZv dXJDQyBmaWVsZHMpLiBGb3IgYW4gZXhwbGFuYXRpb24gb2YgdGhlIFF1aWNrVGltZSBmaWxl IGZvcm1hdCByZWFkIFtRdWlja1RpbWUgRmlsZSBGb3JtYXQgU3BlY2lmaWNhdGlvbl0oaHR0 cHM6Ly9kZXZlbG9wZXIuYXBwbGUuY29tL2xpYnJhcnkvbWFjL2RvY3VtZW50YXRpb24vUXVp Y2tUaW1lL1FURkYvUVRGRlByZWZhY2UvcXRmZlByZWZhY2UuaHRtbCkuCisKKyAgCisqKkNv ZGVjIElEOioqIE5fU1RSSVBQRURUSU1FQ09ERSAgCisqKkNvZGVjIE5hbWU6KiogU3RyaXBw ZWQgdGltZSBjb2RlICAKKyoqRGVzY3JpcHRpb246KiogdHJhY2sgY29udGFpbmluZyBubyBk YXRhIGluIHRoZSBDbHVzdGVyIGVsZW1lbnRzLCBhcyBhbGwgaXMgaW4gdGhlIHRyYWNrIGhl YWRlcjogdGhlIENvZGVjUHJpdmF0ZSBlbGVtZW50IGNvbnRhaW5zLCBpbiBiaWcgZW5kaWFu OiA0IGJ5dGVzIFJhdGUgbnVtZXJhdG9yLCA0IGJ5dGVzIHJhdGUgZGVub21pbmF0b3IsIDQg Ynl0ZXMgY291bnQgb2YgY29uc2VjdXRpdmUgdGltZSBjb2RlcyAvIGZyYW1lcyAodGhlICJk dXJhdGlvbiIsIDAgaWYgdW5rbm93biksIDEgYnl0ZSB0aW1lIGNvZGUgZHJvcCBmcmFtZSBm bGFnICgwIGlzIG5vLCAxIGlzIHllcywgb3RoZXJzIGFyZSByZXNlcnZlZCksIDQgYnl0ZSB0 aGUgc3RhcnQgdGltZSBjb2RlIChpbiBmcmFtZXMpLiBOb3RlOiB0aGlzIHBlcm1pdHMgdG8g bWFwIGEgTVhGIHRpbWUgY29kZSB0cmFjayBvciBhIEdYRiBzdHJpcHBlZCB0aW1lIGNvZGUg dHJhY2sgdG8gTWF0cm9za2EuICAKKworICAKKyoqQ29kZWMgSUQ6KiogTl9TRFRJQ1AxICAK KyoqQ29kZWMgTmFtZToqKiBTZXJpYWwgRGlnaXRhbCBUcmFuc3BvcnQgSW50ZXJmYWNlIENv bnRlbnQgUGFja2FnZSB2ZXJzaW9uIDEgKFNNUFRFIFNUIDMyNikgIAorKipEZXNjcmlwdGlv bjoqKiBUcmFjayBjb250YWluaW5nIFNEVEkgY29udGVudCBlLmcuIHRpbWUgY29kZXMsIHBp Y3R1cmUgbWV0YWRhdGEgYW5kIHNvIG9uLiBNYXRyb3NrYSBibG9jayBjb250YWlucyAxIG9y IG1vcmUgb2YgdGhlIGZvbGxvd2luZyBzZXF1ZW5jZTogMSBieXRlIG9mIGlkZW50aWZpZXIg KDE9U3lzdGVtLCAyPVBhY2thZ2UsIDM9UGljdHVyZSwgND1Tb3VuZCwgNT1EYXRhLCA2PUNv bnRyb2wpLCBCRVIgbG9uZy1mb3JtIGVuY29kaW5nIG9mIHRoZSBTRFRJIGVsZW1lbnQgKHR5 cGljYWx5IDB4ODMgdGhlbiAzIGJ5dGVzIGNvcnJlc3BvbmRpbmcgdGhlIHRoZSBzaXplIGlu IGJpZyBlbmRpYW4pLCB0aGUgU0RUSSBlbGVtZW50IGNvbnRlbnQuICAKKworICAKKyoqQ29k ZWMgSUQ6KiogTl9TWVNURU1TQ0hFTUUxICAKKyoqQ29kZWMgTmFtZToqKiBTeXN0ZW0gU2No ZW1lIDEgKFNNUFRFIFNUIDQwNSkgIAorKipEZXNjcmlwdGlvbjoqKiBUcmFjayBjb250YWlu aW5nIFN5c3RlbSBTY2hlbWUgY29udGVudCBlLmcuIHRpbWUgY29kZXMsIGZyYW1lIHJ0ZSBp bmZvIGFuZCBzbyBvbi4gTWF0cm9za2EgYmxvY2sgY29udGFpbnMgYSBjb21wbGV0ZSBTeXN0 ZW0gU2NoZW1lIDEgZWxlbWVudCAuICAKLS0gCjIuNi40LndpbmRvd3MuMQoK --------------77E45532DECD718A3B10768A-- From nobody Sat Dec 31 09:35:31 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0194129539 for ; Sat, 31 Dec 2016 09:35:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.203 X-Spam-Level: X-Spam-Status: No, score=-3.203 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIDyE04V5yhr for ; Sat, 31 Dec 2016 09:35:28 -0800 (PST) Received: from liselle.bunkus.org (liselle.bunkus.org [IPv6:2a01:4f8:190:8147::105:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4F812952D for ; Sat, 31 Dec 2016 09:35:28 -0800 (PST) Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id AFB2B6540DBB for ; Sat, 31 Dec 2016 18:35:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2016100101; t=1483205725; bh=Su/xzxAp97BOjkgH9a744GqS7Sn8KZV35kpzWtMDz7A=; h=Date:From:To:Subject:From; b=I8jCAdViOGVleT2qkc1Rhqzbgg6zCHQQLm/5VDGaAAnCZ8sKWglscZHWSVTxBMhKY zDn3Stt/5p2xNvsMAX0CGn3DXcLdYeuSR3gc6WiXe9XnoS5kpXzanEKdHZb62vf9Kc tGz9v1IlAmIikAb6mqQ1oZXqWcxi50iVtVSvkT9kmyufHUqkbI9bQ4OGDbiTN/jYAb 6F0lZm5uWT4l5WbzNRf4KqBPm14YeGWr+cvU8cOracfTGK+Lun9ZbV/f5vrWxMXyZm mCSkyke9drjdmvIe6GufLyIPeUlLmXF8IRsmSq/8xAUQWVGPdpifDDMdsrRMAZKC8Z zfBGVlpd7uKsZFg1EI/0gkg44rzi56fwB3FRtuTvdrJ9KsgJ14DTIgU2QoGoEz/umA UdfTGQ2qdi9xct1xwHGzq2PDHq78YZTwGU2PjvmEYvXDC8kmiIf/mn9XyZRipO2/P9 Y5neYOfnWvQY3HSbuNRXGeBotBbpzCQbrSV4rXH7qkZBNXb36Ntodist9NfBWmD2hk SsrneH8V4/rHmAQhSSZ1Z1Wgt4IbjJjYvG+png9SlhwB0c7YqfM7ft0K/MiUuu8kZt WoZWMOpzlSCd2YzFTAMJYL75TGSyiMiuYKnE1sYRBLIScWaznzOo1g4vApbDbyo3El /xwhT0FtKFXT9p1CxdP1mx8M= Received: by sweet-chili.local (Postfix, from userid 1000) id 3FA7FF20D4C; Sat, 31 Dec 2016 18:35:25 +0100 (CET) Date: Sat, 31 Dec 2016 18:35:25 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20161231173524.66jkjpelpq6mninm@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline User-Agent: NeoMutt/20160916 (1.7.0) Archived-At: Subject: [Cellar] Codec specs: graphical Digital Video Broadcasting (DVB) subtitles X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2016 17:35:29 -0000 Hey, The Digital Video Broadcasting standard specifies a graphical subtitle format. There are several programs that have been able to write Matroska files with such tracks for years. mkvmerge has only gained support for it after release 9.7.1. On the demuxer side ffmpeg and MPC-HC are examples of applications that can read and display such S_DVBSUB tracks. Until now the Matroska codec specs have not reflected this practice. I've just posted a pull request[1] to remedy the situation. It describes what is already practice. Nevertheless I ask for reviews. My recommendation is not adopt the current practice as the official storage format. Happy new year, everyone! Kind regards, mosu [1] https://github.com/Matroska-Org/matroska-specification/pull/77 From nobody Sat Dec 31 10:30:57 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581A012956B for ; Sat, 31 Dec 2016 10:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgLG_zdcOmgY for ; Sat, 31 Dec 2016 10:30:54 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF4D6129568 for ; Sat, 31 Dec 2016 10:30:54 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:36907 helo=[10.0.1.12]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cNOQf-003Kxc-EY; Sat, 31 Dec 2016 13:30:54 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dave Rice In-Reply-To: <20161231173524.66jkjpelpq6mninm@bunkus.org> Date: Sat, 31 Dec 2016 13:31:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161231173524.66jkjpelpq6mninm@bunkus.org> To: Moritz Bunkus X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Codec specs: graphical Digital Video Broadcasting (DVB) subtitles X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2016 18:30:56 -0000 > On Dec 31, 2016, at 12:35 PM, Moritz Bunkus wrote: >=20 > Hey, >=20 > The Digital Video Broadcasting standard specifies a graphical subtitle > format. There are several programs that have been able to write = Matroska > files with such tracks for years. mkvmerge has only gained support for > it after release 9.7.1. On the demuxer side ffmpeg and MPC-HC are > examples of applications that can read and display such S_DVBSUB = tracks. >=20 > Until now the Matroska codec specs have not reflected this > practice. I've just posted a pull request[1] to remedy the situation. = It > describes what is already practice. Nevertheless I ask for reviews. My > recommendation is not adopt the current practice as the official = storage > format. >=20 > Happy new year, everyone! >=20 > Kind regards, > mosu >=20 > [1] https://github.com/Matroska-Org/matroska-specification/pull/77 I added some grammar, typo and logic notes within the pull request. I also see that for many Codecs defined in codec_specs.md, the = Description of the Codec contains the requirements for management of = private data (within CodecPrivate), but this pull request puts the = CodecPrivate details within the subtitles.md document. I suggest the = CodecPrivate details get consolidated within codec_specs.md rather than = spread out too much in other documents. I also think we should refine = the 'Description' of a codec support and split that into a general = description and another details value for CodecPrivate handling = specifically. Out of scope for this PR, but perhaps we should refine how = codec support is defined in more detail soon. Best Regards, Dave Rice From nobody Sat Dec 31 10:35:42 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9897E129556 for ; Sat, 31 Dec 2016 10:35:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.102 X-Spam-Level: X-Spam-Status: No, score=-5.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (4096-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGH6EYSxo6Nw for ; Sat, 31 Dec 2016 10:35:39 -0800 (PST) Received: from liselle.bunkus.org (belgarath.bunkus.org [144.76.6.86]) (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 78E3B12944B for ; Sat, 31 Dec 2016 10:35:39 -0800 (PST) Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 81F966540DBB for ; Sat, 31 Dec 2016 19:35:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bunkus.org; s=mail2016100101; t=1483209337; bh=vC4qn6hCsyPhK6pZEROwlwqQHizYAe9j7i6PEO49BBs=; h=Date:From:To:Subject:References:In-Reply-To:From; b=An+ZWP+WLs5ejjtQeAtlPJugrzMx1zjyJTL4n2+SieTJSIcUxO7xlItcqOik0KlxB EivAz29d8Ko5qA8G8dB4cefuQxanyMv0QrRI++UI8mL9uLMQcuGE1ctn/Yfl/nkiP4 AbW9L/UfCB86YXjjPzmRZzIMDKFkZgxlsizW4MDuN37Lf9+0RPQZVChe5Ve9T8aVo0 ajY8s6LSwl2yEVeIdwgZye75ObKoOMdJ9aGs3ucVg3qCX6poPNSYlRaJCCJgT5e5jc zHyFZQbLMCLkXQig1KwHGUsmZXYhf7F/e8tOmYCiXpwUSq4OmV7ZXcmsd05IJXdwRh VpfNQnBbzkbJd2Xh1KlKeV4JHaIE4K8qNw5ZnNkPwNCseNpVBx4rhmgbgUtDd+VI8J 9PQQQ97hhCGSOKMMY0bLvruX9d4hhIBaJa226tRPqOf1K1rYPrH6W7wnsW4dMr3AMz hR/6Fpmq0crCBnmTeBN+aYHi5CeMqcIDZjDXAaRuMVkhhTgV7gon8Il2PKuiDYMeOW PBpU5i82JfRzld7LoTv2Feuu4pF+k/IJ0ggi11qSG/buE+rO13wR1LpKaakNFJhRwd TrX2m5SVjm0oI6q2SksAn6aDDDXMDbU/nbgyxiR1FzNVada5mB14mCswIHPHTny2RJ oNGQVVjwYwF2ms+TvhxHZzEw= Received: by sweet-chili.local (Postfix, from userid 1000) id D05CEF21C0B; Sat, 31 Dec 2016 19:35:36 +0100 (CET) Date: Sat, 31 Dec 2016 19:35:36 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20161231183536.cywy76no6snrply5@bunkus.org> References: <20161231173524.66jkjpelpq6mninm@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20160916 (1.7.0) Archived-At: Subject: Re: [Cellar] Codec specs: graphical Digital Video Broadcasting (DVB) subtitles X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2016 18:35:40 -0000 Hey, > I added some grammar, typo and logic notes within the pull request. Thanks! > I also see that for many Codecs defined in codec_specs.md, the > Description of the Codec contains the requirements for management of > private data (within CodecPrivate), but this pull request puts the > CodecPrivate details within the subtitles.md document. I suggest the > CodecPrivate details get consolidated within codec_specs.md rather > than spread out too much in other documents. I also think we should > refine the 'Description' of a codec support and split that into a > general description and another details value for CodecPrivate > handling specifically. Out of scope for this PR, but perhaps we should > refine how codec support is defined in more detail soon. I agree with that. The first half of the codec_specs.md document could also use a good rework — both regarding its structure as well as its content. It's most obvious when you view the rendered page in Jekyll. But as you said, that's a topic for another PR. Kind regards, mosu From nobody Sat Dec 31 11:53:31 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E92E81294E3 for ; Sat, 31 Dec 2016 11:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9mCKaofmKnT for ; Sat, 31 Dec 2016 11:53:28 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E876129408 for ; Sat, 31 Dec 2016 11:53:28 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:34912 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1cNPiZ-003pVM-Gs for cellar@ietf.org; Sat, 31 Dec 2016 14:53:28 -0500 From: "dave@dericed.com" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <006693EE-3D14-44E3-A2F5-A3F18CF4020F@dericed.com> Date: Sat, 31 Dec 2016 14:53:25 -0500 To: Codec Encoding for LossLess Archiving and Realtime transmission Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] defining how to define codec support X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2016 19:53:30 -0000 Hi all, =46rom comments on the recent subtitle definition, I drafted a pull = request [1] to better document how to define codec support in Matroska. = Mostly this adds a new section called =E2=80=9CDefining Matroska Codec = Support=E2=80=9D which is reviewable at GitHub in rendered form [2]. I = started to document how to construct a Codec ID and broke it down into = the concepts of a Prefix, Major ID, Minor ID, Micro ID, and Delimiter. = If any ABNF authors want to volunteer, it may be useful to rework the = Codec ID definition in ABNF. I also divided the vague concept of Codec Description into three parts = Description, Citation (we should reference the specification of the = codec), and Initialization (to specifically define the data to be stored = in CodecPrivate or CodecState). Once the above revisions are supported, we can rework the existing codec = specs into this form. Also I notice that in many places the word =E2=80=9CCodec=E2=80=9D is = used when it seems that =E2=80=9CEncoding=E2=80=9D is intended. For = instance if many Codecs all encode the same encoding, then the Codec ID = for each it the same although the Codecs are different. Should this be = the Encoding ID? Best Regards, Dave Rice [1] https://github.com/Matroska-Org/matroska-specification/pull/79 [2] = https://github.com/Matroska-Org/matroska-specification/blob/c4d2374c2104e8= de961032035d6122451701ac05/codec_specs.md#defining-matroska-codec-support=