From nobody Sat Feb 3 01:57:53 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D7A1270AB for ; Sat, 3 Feb 2018 01:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 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 Ef8-s2EjbNmC for ; Sat, 3 Feb 2018 01:57:49 -0800 (PST) Received: from 4.mo5.mail-out.ovh.net (4.mo5.mail-out.ovh.net [178.33.111.247]) (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 206711200FC for ; Sat, 3 Feb 2018 01:57:48 -0800 (PST) Received: from player786.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo5.mail-out.ovh.net (Postfix) with ESMTP id BE059186F35 for ; Sat, 3 Feb 2018 10:57:46 +0100 (CET) Received: from [192.168.2.120] (p5DDB56EF.dip0.t-ipconnect.de [93.219.86.239]) (Authenticated sender: zen-lists@mediaarea.net) by player786.ha.ovh.net (Postfix) with ESMTPSA id D3A558008A; Sat, 3 Feb 2018 10:57:44 +0100 (CET) To: ffmpeg-devel@ffmpeg.org References: <63dcf4c8-53bf-ef81-140a-025d6181818c@mediaarea.net> <20180202231056.GZ3063@michaelspb> Cc: Codec Encoding for LossLess Archiving and Realtime transmission From: Jerome Martinez Message-ID: <0a425851-80b5-70b8-41a2-14e16d928ec3@mediaarea.net> Date: Sat, 3 Feb 2018 10:57:44 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180202231056.GZ3063@michaelspb> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Ovh-Tracer-Id: 9771122344503087249 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtfedrtdekgdduvdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 09:57:52 -0000 On 03/02/2018 00:10, Michael Niedermayer wrote: > On Thu, Feb 01, 2018 at 01:43:00PM +0100, Jerome Martinez wrote: >> Add support for 16-bit/component RGB with Alpha encoding and decoding in >> FFV1, both RGBA64 and GBRAP16 for encoding, GBRAP16 for decoding. >> >> Resulting bitstream was tested about lossless encoding/decoding by the >> compression from DPX to FFV1 then decompression from FFV1 to DPX, see >> commands below (resulting framemd5 hashes are all same). >> Resulting bitstream is decodable by another decoder (with same resulting >> framemd5 hash). >> Resulting bitstream passed through a conformance checker compared to current >> FFV1 specification IETF draft. >> >> About the patch: >> - some modified lines are not used (the ones not used when f->use32bit is >> 1), but it makes the code more coherent (especially because decode_rgb_frame >> signature is same for both 16-bit and 32-bit version) and prepares the >> support of RGBA with 10/12/14 bits/component. >> - GBRAP16 was chosen for decoding because GBRP16 is already used when no >> alpha, and the code is more prepared for planar pix_fmt when bit depth is >>> 8. >> - "s->transparency = desc->nb_components == 4 || desc->nb_components == 2;" >> is a copy of a line a bit above about the detection of transparency, I >> preferred to reuse it as is even if "YA" 16-bit/component is not (yet) >> supported. >> >> FFmpeg commands used for tests: >> ./ffmpeg -i in.dpx -c:v ffv1 out.mkv >> ./ffmpeg -i in.dpx -pix_fmt gbrap16 -strict -2 -c:v ffv1 out2.mkv >> ./ffmpeg -i out.mkv out.dpx >> >> ./ffmpeg -i in.dpx -f framemd5 in.dpx.framemd5 >> ./ffmpeg -i out.mkv -pix_fmt rgba64be -f framemd5 out.mkv.framemd5 >> ./ffmpeg -i out2.mkv -pix_fmt rgba64be -f framemd5 out2.mkv.framemd5 >> ./ffmpeg -i out.dpx -f framemd5 out.dpx.framemd5 >> >> Test file used (renamed to in.dpx): >> https://mediaarea.net/temp/uncropped_DPX_4K_16bit_Overscan15pros.dpx > I would prefer if the algorithm would be tuned to 16bit data before > adding more formats to the encoder which require all decoders to support > them. > > Dont you agree that this would be the better strategy ? ccing CELLAR. My remarks are the same as with RGB48 support (including that the compression performance of RGB48 so RGBA64 is already very good without touching on the algorithm, and IMO tuning should be for v4 for all bit depths), with addition that since the last debate on that on ffmpeg-devel there was no patch proposal so no consensus on CELLAR for limiting the specifications to what exists in FFmpeg implementation (so current consensus is that FFV1 specs are for all bit depths for all supported color spaces), and since the last debate FFV1 specs draft were sent to IETF tracker so it is close to the end. This patch is just adding the support of RGBA64 conforming to the current specs and without big changes (no complex stuff, just mapping to the right pix_fmt), and the current specs are the ones with very high chances to be the standard (up to now nobody suggested on CELLAR, the place for the spec, to limit the support to a set of bit depths / color spaces, and nobody suggested a tuning for some bit depths), with the main advantage that the specs are clear about all bit depths for all color spaces supported (it is good that it is generic). Will this patch be accepted after the IETF flags the current specs as stable if there is no changes on the wording about the support of all bit depths? on my side, I can not spend time on FFV1 v4 R&D (tuning and more) when I spend time with such blocking (for me) issue about v3 (i.e. agreement in specs draft on all bit depths for all supported color spaces but no agreement in practice on all bit depths for all supported color spaces). So for answering directly to the question, no I don't agree that changing v3 bitstream with specific tuning of the bitstream depending of the bit depth is a better strategy, actually this is the opposite (I think that the best strategy is to support as many bit depths as possible in implementations with current v3 specs and that all tuning should be in the version flagged as experimental, not the one flagged as stable even before working on IETF version, if we change a bitstream marked as stable we break the trust in the spec being stable, IMO any tuning of the bitstream should be done in v4, and any performance improvement without breaking the bitstream could be done after this patch without problem). Jérôme From nobody Sat Feb 3 04:07:40 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAA71243FE for ; Sat, 3 Feb 2018 04:07:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.509 X-Spam-Level: X-Spam-Status: No, score=-1.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L3=1.08, 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 dJzVez4-8NSX for ; Sat, 3 Feb 2018 04:07:37 -0800 (PST) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12951242F7 for ; Sat, 3 Feb 2018 04:07:37 -0800 (PST) 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 relay5-d.mail.gandi.net (Postfix) with ESMTPSA id BFC6741C09B; Sat, 3 Feb 2018 13:07:35 +0100 (CET) Date: Sat, 3 Feb 2018 13:07:34 +0100 From: Michael Niedermayer To: ffmpeg-devel@ffmpeg.org Cc: Codec Encoding for LossLess Archiving and Realtime transmission Message-ID: <20180203120734.GL3129@michaelspb> References: <63dcf4c8-53bf-ef81-140a-025d6181818c@mediaarea.net> <20180202231056.GZ3063@michaelspb> <0a425851-80b5-70b8-41a2-14e16d928ec3@mediaarea.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3xQkynibq3FKlJyM" Content-Disposition: inline In-Reply-To: <0a425851-80b5-70b8-41a2-14e16d928ec3@mediaarea.net> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 12:07:40 -0000 --3xQkynibq3FKlJyM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 03, 2018 at 10:57:44AM +0100, Jerome Martinez wrote: > On 03/02/2018 00:10, Michael Niedermayer wrote: > >On Thu, Feb 01, 2018 at 01:43:00PM +0100, Jerome Martinez wrote: > >>Add support for 16-bit/component RGB with Alpha encoding and decoding in > >>FFV1, both RGBA64 and GBRAP16 for encoding, GBRAP16 for decoding. > >> > >>Resulting bitstream was tested about lossless encoding/decoding by the > >>compression from DPX to FFV1 then decompression from FFV1 to DPX, see > >>commands below (resulting framemd5 hashes are all same). > >>Resulting bitstream is decodable by another decoder (with same resulting > >>framemd5 hash). > >>Resulting bitstream passed through a conformance checker compared to cu= rrent > >>FFV1 specification IETF draft. > >> > >>About the patch: > >>- some modified lines are not used (the ones not used when f->use32bit = is > >>1), but it makes the code more coherent (especially because decode_rgb_= frame > >>signature is same for both 16-bit and 32-bit version) and prepares the > >>support of RGBA with 10/12/14 bits/component. > >>- GBRAP16 was chosen for decoding because GBRP16 is already used when no > >>alpha, and the code is more prepared for planar pix_fmt when bit depth = is > >>>8. > >>- "s->transparency =3D desc->nb_components =3D=3D 4 || desc->nb_compone= nts =3D=3D 2;" > >>is a copy of a line a bit above about the detection of transparency, I > >>preferred to reuse it as is even if "YA" 16-bit/component is not (yet) > >>supported. > >> > >>FFmpeg commands used for tests: > >>./ffmpeg -i in.dpx -c:v ffv1 out.mkv > >>./ffmpeg -i in.dpx -pix_fmt gbrap16 -strict -2 -c:v ffv1 out2.mkv > >>./ffmpeg -i out.mkv out.dpx > >> > >>./ffmpeg -i in.dpx -f framemd5 in.dpx.framemd5 > >>./ffmpeg -i out.mkv -pix_fmt rgba64be -f framemd5 out.mkv.framemd5 > >>./ffmpeg -i out2.mkv -pix_fmt rgba64be -f framemd5 out2.mkv.framemd5 > >>./ffmpeg -i out.dpx -f framemd5 out.dpx.framemd5 > >> > >>Test file used (renamed to in.dpx): > >>https://mediaarea.net/temp/uncropped_DPX_4K_16bit_Overscan15pros.dpx > >I would prefer if the algorithm would be tuned to 16bit data before > >adding more formats to the encoder which require all decoders to support > >them. > > > >Dont you agree that this would be the better strategy ? >=20 > ccing CELLAR. >=20 > My remarks are the same as with RGB48 support (including that the > compression performance of RGB48 so RGBA64 is already very good without > touching on the algorithm, and IMO tuning should be for v4 for all bit > depths), with addition that since the last debate on that on ffmpeg-devel > there was no patch proposal so no consensus on CELLAR for limiting the > specifications to what exists in FFmpeg implementation (so current consen= sus > is that FFV1 specs are for all bit depths for all supported color spaces), > and since the last debate FFV1 specs draft were sent to IETF tracker so it > is close to the end. >=20 > This patch is just adding the support of RGBA64 conforming to the current > specs and without big changes (no complex stuff, just mapping to the right > pix_fmt), and the current specs are the ones with very high chances to be > the standard (up to now nobody suggested on CELLAR, the place for the spe= c, > to limit the support to a set of bit depths / color spaces, and nobody > suggested a tuning for some bit depths), with the main advantage that the > specs are clear about all bit depths for all color spaces supported (it is > good that it is generic). Will this patch be accepted after the IETF flags > the current specs as stable if there is no changes on the wording about t= he > support of all bit depths? >=20 > on my side, I can not spend time on FFV1 v4 R&D (tuning and more) when I > spend time with such blocking (for me) issue about v3 (i.e. agreement in > specs draft on all bit depths for all supported color spaces but no > agreement in practice on all bit depths for all supported color spaces). >=20 > So for answering directly to the question, no I don't agree that changing= v3 > bitstream with specific tuning of the bitstream depending of the bit depth > is a better strategy, That was not meant. To clarify my suggestion, the algorithm should be tuned for high bit depth before using it for long t= erm storage. This would be v4 (or later). Personally i would wait for v4 and not use v3 for high bit depth. Which is why i think its not smart to extend the v3 implementation with more high de= pth support. > actually this is the opposite (I think that the best > strategy is to support as many bit depths as possible in implementations > with current v3 specs and that all tuning should be in the version flagged > as experimental, not the one flagged as stable even before working on IETF > version, if we change a bitstream marked as stable we break the trust in = the > spec being stable, IMO any tuning of the bitstream should be done in v4, = and > any performance improvement without breaking the bitstream could be done > after this patch without problem). IIRC teh v3 draft was intended to describe the format generated by the exis= ting implementation. The existing implementation allowed 16bit RGB only when the= user specified flags indicating that they are creating non standard files. "16bit RGB is experimental and under development, only use it for experimen= ts" There was no standard 16bit RGB or higher depth supported, these where in= =20 development on the specification and implementation side. IIUC people created such files somehow beliving that the IMO clear warning somehow suggested that this was stable. And with that we are a bit stuck with this for v3 you are technically correct that the current draft allows it and the additi= ons but iam not sure its really a good idea to add more cases under this. Thanks [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt compla= in" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" --3xQkynibq3FKlJyM Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlp1pgYACgkQYR7HhwQLD6tR8QCdFH3INN+WzLLI71LFu5wdq6WH hxkAn2QzbZVhHquxFCCkldNAF3EwEb/j =Jrt9 -----END PGP SIGNATURE----- --3xQkynibq3FKlJyM-- From nobody Sat Feb 3 04:58:21 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF871128C0A for ; Sat, 3 Feb 2018 04:58:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 5MFnZYxsn5jR for ; Sat, 3 Feb 2018 04:58:17 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009C712D72F for ; Sat, 3 Feb 2018 04:58:16 -0800 (PST) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w13Cw8Dm022972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 3 Feb 2018 13:58:09 +0100 Received: from Castor.local (84-73-238-96.dclient.hispeed.ch [84.73.238.96]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w13Cw8Ze062706 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 3 Feb 2018 13:58:08 +0100 Date: Sat, 3 Feb 2018 13:58:10 +0100 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission cc: ffmpeg-devel@ffmpeg.org X-Priority: 3 In-Reply-To: <20180203120734.GL3129@michaelspb> 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] [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 12:58:20 -0000 Michael Niedermayer wrote: >To clarify my suggestion, >the algorithm should be tuned for high bit depth before using >it for long term storage. This would be v4 (or later). >Personally i would wait for v4 and not use v3 for high bit >depth. Which is why i think its not smart to extend the v3 >implementation with more high depth support. The issue is that in the real world we need to use the format now. Otherwise the film archives must use MXF/DPX instead of =D0=9C=D0=B0=D1=82=D1=80=D1=91=D1=88=D0=BA=D0=B0/FFV1. That's the point! I presented to the industry this solution in August 2016 at "The Reel Thing" technical symposium in Hollywood, and an article on it was published in April 2017 in FIAF's "Journal of Film Preservation". The archives cannot wait forever! And they are indeed important users of FFmpeg, in my opinion. I already paid EUR 7000 for the FFV1 use in the archival world, and will pay EUR 5000 additionally in the next months. >IIUC people created such files somehow beliving that the IMO >clear warning somehow suggested that this was stable. And with >that we are a bit stuck with this for v3 I presented last November at the "No Time to Wait" symposium (nomen est omen) in Vienna - i.e. in your city - how we have to work today and how we hope to modify container and codec during the next data migration. Last but not least, since almost two years now it's impossible to work on the development of FFV1 v4. It's always the wrong time and/or the wrong place every time I am doing something for this cause. Why? This is extremely frustrating. Best regards, Reto From nobody Sat Feb 3 05:48:30 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D81EF12D886 for ; Sat, 3 Feb 2018 05:48:28 -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 z_DZy-QHwsR2 for ; Sat, 3 Feb 2018 05:48:27 -0800 (PST) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D086127201 for ; Sat, 3 Feb 2018 05:48:27 -0800 (PST) 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 relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 215621720AE; Sat, 3 Feb 2018 14:48:24 +0100 (CET) Date: Sat, 3 Feb 2018 14:48:24 +0100 From: Michael Niedermayer To: Codec Encoding for LossLess Archiving and Realtime transmission Cc: ffmpeg-devel@ffmpeg.org Message-ID: <20180203134824.GM3129@michaelspb> References: <20180203120734.GL3129@michaelspb> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GeONROBiaq1zPAtT" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 13:48:29 -0000 --GeONROBiaq1zPAtT Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 03, 2018 at 01:58:10PM +0100, Reto Kromer wrote: > Michael Niedermayer wrote: >=20 > >To clarify my suggestion, > >the algorithm should be tuned for high bit depth before using > >it for long term storage. This would be v4 (or later). > >Personally i would wait for v4 and not use v3 for high bit > >depth. Which is why i think its not smart to extend the v3 > >implementation with more high depth support. >=20 > The issue is that in the real world we need to use the format > now. Otherwise the film archives must use MXF/DPX instead of > =D0=9C=D0=B0=D1=82=D1=80=D1=91=D1=88=D0=BA=D0=B0/FFV1. That's the point! Then using the v3 16bit is probably the most realistic option. And jeromes patch should probably be applied I hope this will not reduce interrest in working on a improved=20 9-16bit mode in v4. [...] > Last but not least, since almost two years now it's impossible > to work on the development of FFV1 v4. It's always the wrong > time and/or the wrong place every time I am doing something for > this cause. Why? This is extremely frustrating. I want to understand this too. IMO v4 development should be more important than or at least equally to the v3 draft polishing and neither=20 should block the other. --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle --GeONROBiaq1zPAtT Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlp1vagACgkQYR7HhwQLD6vkOgCfeEX2cMx/Vi7MqTdQWFZFjqiO EkIAni/o8nMFlE1faI36t7SIm3sVBmGm =qJRJ -----END PGP SIGNATURE----- --GeONROBiaq1zPAtT-- From nobody Sat Feb 3 06:50:00 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F8812D854 for ; Sat, 3 Feb 2018 06:49:58 -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, 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 8GxHiqJ5cShb for ; Sat, 3 Feb 2018 06:49:56 -0800 (PST) Received: from mx02.mail.netstorage.at (mx02.mail.netstorage.at [89.207.146.155]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510AF12702E for ; Sat, 3 Feb 2018 06:49:55 -0800 (PST) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx02.mail.netstorage.at (Postfix) with ESMTPS id 5D418A0016; Sat, 3 Feb 2018 15:49:38 +0100 (CET) Received: from wien.noa-archive.com (unknown [78.142.187.230]) by p1002.netstorage.at (Postfix) with ESMTPSA id 21F34819A9; Sat, 3 Feb 2018 15:49:38 +0100 (CET) Received: from EX2K14.noa-vienna.local (192.168.22.6) by EX2K14.noa-vienna.local (192.168.22.6) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 3 Feb 2018 15:49:36 +0100 Received: from EX2K14.noa-vienna.local ([192.168.22.6]) by EX2K14.noa-vienna.local ([192.168.22.6]) with mapi id 15.00.1320.000; Sat, 3 Feb 2018 15:49:36 +0100 From: Jean-Christophe Kummer To: Michael Niedermayer , "Codec Encoding for LossLess Archiving and Realtime transmission" CC: "ffmpeg-devel@ffmpeg.org" Thread-Topic: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16 Thread-Index: AQHTnNWclrA9kV/SCE2JZa70pvfKv6OShLcAgAAOIwCAAA4JAIAAGeDw Date: Sat, 3 Feb 2018 14:49:36 +0000 Message-ID: References: <20180203120734.GL3129@michaelspb> <20180203134824.GM3129@michaelspb> In-Reply-To: <20180203134824.GM3129@michaelspb> Accept-Language: de-AT, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [62.178.108.220] x-gfi-smtp-submission: 1 x-gfi-smtp-hellodomain: EX2K14.noa-vienna.local x-gfi-smtp-remoteip: 192.168.22.6 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PPP-Message-ID: <20180203144938.30128.16482@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com X-NetStorage-MailScanner-Information: Please contact the ISP for more information X-NetStorage-MailScanner-ID: 5D418A0016.A675B X-NetStorage-MailScanner: Found to be clean X-NetStorage-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (nicht zwischen gespeichert, Wertung=10, benoetigt 6, BAYES_00 -0.50, KAM_NUMSUBJECT 0.50, RCVD_IN_PBL 5.50, RCVD_IN_SORBS_DUL 4.50) X-NetStorage-MailScanner-From: c.kummer@noa-archive.com Archived-At: Subject: Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 14:49:59 -0000 TG9vb2tpbmcgdG8gaXQgZnJvbSBhIHByYWdtYXRpYyBtYW5hZ2VtZW50IHBvaW50IG9mIHZpZXcs IHRoZXJlIGlzIGEgbG90IG9mIG9wZW4gc291cmNlIHVuZnJpZW5kbHkgY29tbXVuaXR5IGZyb20g dGhlIEVCVS9TTVBURSB3b3JsZCB3aGljaCB3b3VsZCBoYXZlIHRoZWlyIG9waW5pb24gYWJvdXQg YSBmYWlsZWQgb3IgZXZlbiBtb3JlIGRlbGF5ZWQgSUVURiBzcGVjIGZpbmFsaXNhdGlvbi4NCg0K SSB0aGluayAtIGdpdmVuIHRoZSBlZmZvcnRzIHdoaWNoIGhhdmUgYmVlbiBwdXQgaW50byBpdCwg dGhlIGJlYXV0eSB3aXRoIHdoYXQgIGlzIEFMUkVBRFkgZXhpc3RpbmcsIA0KY29leGlzdGVuY3kg b2YgdjQgd29yayBhbmQgZmluYWxpc2F0aW9uIG9mIHYzIHdvcmsgdG93YXJkcyBJRVRGIHN0YW5k YXJkaXphdGlvbiBpcyB0aGUgc3RyYXRlZ3kgd2hpY2ggDQp3ZSBzaG91bGQgY29uY2VudHJhdGUg b24uICANCg0KMTZiaXQgaW4gdjM6IFBsZWFzZSBnbyBmb3IgaXQuIEFuZCBhbGxvdyBmb3IgdjQg Zm9yIG90aGVyIGRpc2N1c3Npb25zLiANCg0KTm90IHRvIGZvcmdldCBhYm91dCBhbGwgdmlkZW8g cHJvamVjdHMgd2hpY2ggd291bGQgYmUgaGFwcHkgdG8gc2VlIHRoYXQgSUVURiBhbmQgdGhlIGNv bW11bml0eSBmaW5hbGlzZXMgdjMgYWxzbyBmb3IgaXTCtHMgIDgvMTBiaXQgZm9ybWF0cyB3aGlj aCBoYXZlIGFuIGV2ZW4gaGlnaGVyIHJlcHJlc2VudGF0aW9uIGluIGh1bmRyZWQgdGhvdXNhbmRz IG9mIGFyY2hpdmUgaG91cnMgYWxyZWFkeSBub3cuIA0KDQoNCklmIHRoZXJlIGlzIHNvbWV0aGlu ZyBJIGNhbiBkbyBwbGVhc2UgY29udGFjdCBtZS4NCg0KDQpDaHJpc3RvcGhlDQpOT0ENCg0KDQoN Cg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0tLQ0KVm9uOiBDZWxsYXIgW21haWx0 bzpjZWxsYXItYm91bmNlc0BpZXRmLm9yZ10gSW0gQXVmdHJhZyB2b24gTWljaGFlbCBOaWVkZXJt YXllcg0KR2VzZW5kZXQ6IFNhbXN0YWcsIDAzLiBGZWJydWFyIDIwMTggMTQ6NDgNCkFuOiBDb2Rl YyBFbmNvZGluZyBmb3IgTG9zc0xlc3MgQXJjaGl2aW5nIGFuZCBSZWFsdGltZSB0cmFuc21pc3Np b24gPGNlbGxhckBpZXRmLm9yZz4NCkNjOiBmZm1wZWctZGV2ZWxAZmZtcGVnLm9yZw0KQmV0cmVm ZjogUmU6IFtDZWxsYXJdIFtGRm1wZWctZGV2ZWxdIFtQQVRDSF0gYXZjb2RlYy9mZnYxOiBTdXBw b3J0IGZvciBSR0JBNjQgYW5kIEdCUkFQMTYNCg0KT24gU2F0LCBGZWIgMDMsIDIwMTggYXQgMDE6 NTg6MTBQTSArMDEwMCwgUmV0byBLcm9tZXIgd3JvdGU6DQo+IE1pY2hhZWwgTmllZGVybWF5ZXIg d3JvdGU6DQo+IA0KPiA+VG8gY2xhcmlmeSBteSBzdWdnZXN0aW9uLA0KPiA+dGhlIGFsZ29yaXRo bSBzaG91bGQgYmUgdHVuZWQgZm9yIGhpZ2ggYml0IGRlcHRoIGJlZm9yZSB1c2luZyBpdCBmb3Ig DQo+ID5sb25nIHRlcm0gc3RvcmFnZS4gVGhpcyB3b3VsZCBiZSB2NCAob3IgbGF0ZXIpLg0KPiA+ UGVyc29uYWxseSBpIHdvdWxkIHdhaXQgZm9yIHY0IGFuZCBub3QgdXNlIHYzIGZvciBoaWdoIGJp dCBkZXB0aC4gDQo+ID5XaGljaCBpcyB3aHkgaSB0aGluayBpdHMgbm90IHNtYXJ0IHRvIGV4dGVu ZCB0aGUgdjMgaW1wbGVtZW50YXRpb24gDQo+ID53aXRoIG1vcmUgaGlnaCBkZXB0aCBzdXBwb3J0 Lg0KPiANCj4gVGhlIGlzc3VlIGlzIHRoYXQgaW4gdGhlIHJlYWwgd29ybGQgd2UgbmVlZCB0byB1 c2UgdGhlIGZvcm1hdCBub3cuIA0KPiBPdGhlcndpc2UgdGhlIGZpbG0gYXJjaGl2ZXMgbXVzdCB1 c2UgTVhGL0RQWCBpbnN0ZWFkIG9mINCc0LDRgtGA0ZHRiNC60LAvRkZWMS4gDQo+IFRoYXQncyB0 aGUgcG9pbnQhDQoNClRoZW4gdXNpbmcgdGhlIHYzIDE2Yml0IGlzIHByb2JhYmx5IHRoZSBtb3N0 IHJlYWxpc3RpYyBvcHRpb24uDQpBbmQgamVyb21lcyBwYXRjaCBzaG91bGQgcHJvYmFibHkgYmUg YXBwbGllZA0KDQpJIGhvcGUgdGhpcyB3aWxsIG5vdCByZWR1Y2UgaW50ZXJyZXN0IGluIHdvcmtp bmcgb24gYSBpbXByb3ZlZCA5LTE2Yml0IG1vZGUgaW4gdjQuDQoNCg0KWy4uLl0NCg0KPiBMYXN0 IGJ1dCBub3QgbGVhc3QsIHNpbmNlIGFsbW9zdCB0d28geWVhcnMgbm93IGl0J3MgaW1wb3NzaWJs ZQ0KPiB0byB3b3JrIG9uIHRoZSBkZXZlbG9wbWVudCBvZiBGRlYxIHY0LiBJdCdzIGFsd2F5cyB0 aGUgd3JvbmcNCj4gdGltZSBhbmQvb3IgdGhlIHdyb25nIHBsYWNlIGV2ZXJ5IHRpbWUgSSBhbSBk b2luZyBzb21ldGhpbmcgZm9yDQo+IHRoaXMgY2F1c2UuIFdoeT8gVGhpcyBpcyBleHRyZW1lbHkg ZnJ1c3RyYXRpbmcuDQoNCkkgd2FudCB0byB1bmRlcnN0YW5kIHRoaXMgdG9vLiBJTU8gdjQgZGV2 ZWxvcG1lbnQgc2hvdWxkIGJlIG1vcmUNCmltcG9ydGFudCB0aGFuIG9yIGF0IGxlYXN0IGVxdWFs bHkgdG8gdGhlIHYzIGRyYWZ0IHBvbGlzaGluZyBhbmQgbmVpdGhlciANCnNob3VsZCBibG9jayB0 aGUgb3RoZXIuDQoNCg0KLS0gDQpNaWNoYWVsICAgICBHbnVQRyBmaW5nZXJwcmludDogOUZGMjEy OEIxNDdFRjY3MzBCQURGMTMzNjExRUM3ODcwNDBCMEZBQg0KDQpSZXB1YmxpY3MgZGVjbGluZSBp bnRvIGRlbW9jcmFjaWVzIGFuZCBkZW1vY3JhY2llcyBkZWdlbmVyYXRlIGludG8NCmRlc3BvdGlz bXMuIC0tIEFyaXN0b3RsZQ0K From nobody Sat Feb 3 10:24:25 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D34512D96A for ; Sat, 3 Feb 2018 10:24:24 -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_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EV9lfJ53rzVB for ; Sat, 3 Feb 2018 10:24:23 -0800 (PST) Received: from server172-2.web-hosting.com (server172-2.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 118E6124239 for ; Sat, 3 Feb 2018 10:24:23 -0800 (PST) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:47807 helo=[10.0.1.2]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1ei2U9-0046Rm-Ax for cellar@ietf.org; Sat, 03 Feb 2018 13:24:22 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_0152A0A9-4EA0-4AF5-908C-66034FD7596F" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: Date: Sat, 3 Feb 2018 13:24:15 -0500 To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: Apple Mail (2.3445.4.7) 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] generate a version (0, 1, 3) and version 4 FFV1 document from single source X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 18:24:24 -0000 --Apple-Mail=_0152A0A9-4EA0-4AF5-908C-66034FD7596F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi cellar, I=E2=80=99ve drafted a pull request at = https://github.com/FFmpeg/FFV1/pull/102 based on Michael Niedermayer=E2=80= =99s suggestion = https://github.com/FFmpeg/FFV1/pull/93#issuecomment-356348383 = . This = attempts to create a method where the FFV1 specification may be worked = upon within a single document while the parts that only relevant to the = version 0,1,3 document are suppressed from the version 4 document and = vice versa. To do this I=E2=80=99d created a method of ending lines with = with "{V3}=E2=80=9D (for version 3 and prior) or =E2=80=9C{V4}=E2=80=9D = for version 4 or greater. I think this will help enable work to progress = on the version 4 document as defined in our charter even while the = version 0,1,3 hasn=E2=80=99t been reviewed by the IESG yet. However some IETF questions: In the PR the new outputs of the Makefile are: draft-ietf-cellar-ffv1-01 (defines version 0, 1 and 3 of FFV1) draft-ietf-cellar-ffv1-v4-00 (defines version 4 of FFV1) This keeps the same id for version 0, 1, and 3 but would something else = be more clear? Any examples of naming when IETF defines multiple = versions of the same thing in separate documents? I=E2=80=99ve separated the document version numbers for each, so = draft-ietf-cellar-ffv1 stays at 01 and draft-ietf-cellar-ffv1-v4 starts = at 00. Work? In the version 4 output there are references to exceptions defined in = our work on version 0,1,3. These include all lines starting with = =E2=80=9CBackground=E2=80=9D. I suggest resolving these in a subsequent = commit, but perhaps the version 4 document need not include these but = could only reference exceptions existed in prior version. Best Regards, Dave Rice --Apple-Mail=_0152A0A9-4EA0-4AF5-908C-66034FD7596F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = cellar,

I=E2=80=99ve = drafted a pull request at https://github.com/FFmpeg/FFV1/pull/102 based on Michael = Niedermayer=E2=80=99s suggestion https://github.com/FFmpeg/FFV1/pull/93#issuecomment-356348383. This attempts to create a method where the FFV1 specification may be = worked upon within a single document while the parts that only relevant = to the version 0,1,3 document are suppressed from the version 4 document = and vice versa. To do this I=E2=80=99d created a method of ending lines = with with "{V3}=E2=80=9D (for version 3 and prior) or =E2=80=9C{V4}=E2=80=9D= for version 4 or greater. I think this will help enable work to = progress on the version 4 document as defined in our charter even while = the version 0,1,3 hasn=E2=80=99t been reviewed by the IESG = yet.

However = some IETF questions:

In the PR the new outputs of the Makefile are:
draft-ietf-cellar-ffv1-01 (defines version 0, 1 and 3 of = FFV1)
draft-ietf-cellar-ffv1-v4-00 (defines version = 4 of FFV1)

This = keeps the same id for version 0, 1, and 3 but would something else be = more clear? Any examples of naming when IETF defines multiple versions = of the same thing in separate documents?

I=E2=80=99ve separated the document = version numbers for each, so draft-ietf-cellar-ffv1 stays at 01 and = draft-ietf-cellar-ffv1-v4 starts at 00. Work?

In the version 4 output there are = references to exceptions defined in our work on version 0,1,3. These = include all lines starting with =E2=80=9CBackground=E2=80=9D. I suggest = resolving these in a subsequent commit, but perhaps the version 4 = document need not include these but could only reference exceptions = existed in prior version.

Best Regards,
Dave Rice


= --Apple-Mail=_0152A0A9-4EA0-4AF5-908C-66034FD7596F-- From nobody Sat Feb 3 10:54:09 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40E412DA04 for ; Sat, 3 Feb 2018 10:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 uuxkZnyijCYt for ; Sat, 3 Feb 2018 10:54:05 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5662A12DA00 for ; Sat, 3 Feb 2018 10:54:05 -0800 (PST) Received: from smtp7.infomaniak.ch (smtp7.infomaniak.ch [83.166.132.30]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w13Is3PT021234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Sat, 3 Feb 2018 19:54:03 +0100 Received: from Castor.local (84-73-238-96.dclient.hispeed.ch [84.73.238.96]) (authenticated bits=0) by smtp7.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w13Is29a079526 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Sat, 3 Feb 2018 19:54:03 +0100 Date: Sat, 3 Feb 2018 19:54:05 +0100 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (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] generate a version (0, 1, 3) and version 4 FFV1 document from single source X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 18:54:08 -0000 Hello Dave, thank you very much indeed for this! >perhaps the version 4 document need not >include these but could only reference exceptions existed in >prior version. In my personal opinion, this is exactly the way to go. Best regards, Reto From nobody Sat Feb 3 11:08:40 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD22212711E for ; Sat, 3 Feb 2018 11:08:39 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBYtSnQKKFsw for ; Sat, 3 Feb 2018 11:08:37 -0800 (PST) Received: from 4.mo177.mail-out.ovh.net (4.mo177.mail-out.ovh.net [46.105.37.72]) (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 A28CB1252BA for ; Sat, 3 Feb 2018 11:08:37 -0800 (PST) Received: from player779.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id 67EE29C465 for ; Sat, 3 Feb 2018 20:08:35 +0100 (CET) Received: from [192.168.0.166] (d51a4d9c9.access.telenet.be [81.164.217.201]) (Authenticated sender: jerome@mediaarea.net) by player779.ha.ovh.net (Postfix) with ESMTPSA id AB6E27C008D for ; Sat, 3 Feb 2018 20:08:34 +0100 (CET) To: cellar@ietf.org References: From: Jerome Martinez Message-ID: <95c5cb77-4762-57ae-62de-989b7a644ae5@mediaarea.net> Date: Sat, 3 Feb 2018 20:08:32 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 626563300505161873 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtfedrtdekgdduvdehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] generate a version (0, 1, 3) and version 4 FFV1 document from single source X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 19:08:40 -0000 On 03/02/2018 19:24, Dave Rice wrote: > > In the version 4 output there are references to exceptions defined in > our work on version 0,1,3. These include all lines starting with > “Background”. I suggest resolving these in a subsequent commit, but > perhaps the version 4 document need not include these but could only > reference exceptions existed in prior version. IMO we should remove exceptions in v4, in order to have a easy and coherent bitstream specifications (and I expect that the compression is slightly better without the exceptions, I'll run some tests) so “Background” would be marked v3 doc only, without any reference in v4. I'll open a separate thread about that when I do the tests. From nobody Sun Feb 4 09:05:40 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0C0212762F for ; Sun, 4 Feb 2018 09:05:38 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 QbNBJLXdWC6z for ; Sun, 4 Feb 2018 09:05:36 -0800 (PST) Received: from server172-2.web-hosting.com (server172-2.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 04D1E1275C5 for ; Sun, 4 Feb 2018 09:05:33 -0800 (PST) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:34276 helo=[10.0.1.2]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1eiNjP-002A74-Rw for cellar@ietf.org; Sun, 04 Feb 2018 12:05:33 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_E5A5972D-4BD4-487C-B88E-5840DB0A1306" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <480D5A6E-0001-49D8-BF73-E6B65EC12A37@dericed.com> Date: Sun, 4 Feb 2018 12:05:24 -0500 To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: Apple Mail (2.3445.4.7) 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] draft IANA Considerations section for FFV1 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Feb 2018 17:05:39 -0000 --Apple-Mail=_E5A5972D-4BD4-487C-B88E-5840DB0A1306 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi cellar, The IANA Considerations section is one of remaining requirements for the = FFV1 draft. I=E2=80=99ve updated this pull request with an update on = that which also adds a Media Type Definition section per RFC6838 and = RFC4855. Here=E2=80=99s the rendering of my draft which is also = reviewable in https://github.com/FFmpeg/FFV1/pull/71 = . Comments welcome as this is my = first attempt at an IETF Media Type Definition. 7. Media Type Definition This registration is done using the template defined in [RFC6838] and = following [RFC4855]. Type name: video Subtype name: FFV1 Required parameters: None. Optional parameters: This parameter is used to signal the capabilities of a receiver = implementation. This parameter MUST NOT be used for any other purpose. version: The version of the FFV1 encoding as defined by Section 4.8.1. Encoding considerations: This media type is defined for encapsulation in several audiovisual = container formats and contains binary data; see Section 4.1.3. This = media type is framed binary data Section 4.8 of [RFC4288]. Security considerations: See Section 6 of RFC xxxx. [RFC Editor: Upon publication as an RFC, please replace "XXXX" with the = number assigned to this document and remove this note.] Interoperability considerations: None. Published specification: [I-D.ietf-cellar-ffv1] and RFC XXXX. [RFC Editor: Upon publication as an RFC, please replace "XXXX" with the = number assigned to this document and remove this note.] Applications which use this media type: Any application that requires the transport of lossless video can use = this media type. Some examples are, but not limited to screen recording, = scientific imaging, and digital video preservation. Fragment identifier considerations: N/A. Additional information: None. Person & email address to contact for further information: TODO [Pick a = contact] Intended usage: COMMON Restrictions on usage: None. Author: TODO [Pick a contact] Change controller: IETF cellar working group delegated from the IESG. 8. IANA Considerations The IANA is requested to register the following values: =E2=80=A2 Media type registration as described in Section 7. Kind Regards, Dave Rice= --Apple-Mail=_E5A5972D-4BD4-487C-B88E-5840DB0A1306 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = cellar,

The IANA = Considerations section is one of remaining requirements for the FFV1 = draft. I=E2=80=99ve updated this pull request with an update on that = which also adds a Media Type Definition section per RFC6838 and = RFC4855. Here=E2=80=99s the rendering of my draft which is also = reviewable in https://github.com/FFmpeg/FFV1/pull/71. Comments welcome = as this is my first attempt at an IETF Media Type Definition.

7. Media Type = Definition

This registration is done using = the template defined in [RFC6838] and = following [RFC4855].

Type name: = video

Subtype name: FFV1

Required parameters: None.

Optional parameters:

This = parameter is used to signal the capabilities of a receiver = implementation. This parameter MUST NOT be used for any other = purpose.

version: The version of the FFV1 = encoding as defined by Section 4.8.1.

Encoding considerations:

This = media type is defined for encapsulation in several audiovisual container = formats and contains binary data; see Section 4.1.3. This = media type is framed binary data Section 4.8 of [RFC4288].

Security considerations:

See Section 6 of RFC xxxx.

[RFC Editor: Upon publication as an RFC, please replace = "XXXX" with the number assigned to this document and remove this = note.]

Interoperability considerations: = None.

Published specification:

[I-D.ietf-cellar-ffv1] and RFC XXXX.

[RFC Editor: Upon publication as an RFC, = please replace "XXXX" with the number assigned to this document = and remove this note.]

Applications = which use this media type:

Any application = that requires the transport of lossless video can use this media type. = Some examples are, but not limited to screen recording, scientific = imaging, and digital video preservation.

Fragment identifier considerations: N/A.

Additional information: None.

Person & email address to contact for further = information: TODO [Pick a contact]

Intended = usage: COMMON

Restrictions on usage: = None.

Author: TODO [Pick a contact]

Change controller: IETF cellar working group = delegated from the IESG.

8. IANA = Considerations

The IANA is requested to = register the following values:

= =E2=80=A2 Media type registration as described in Section = 7.


Kind Regards,
Dave = Rice
= --Apple-Mail=_E5A5972D-4BD4-487C-B88E-5840DB0A1306-- From nobody Mon Feb 5 12:44:18 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2FDE12D879 for ; Mon, 5 Feb 2018 12:44:17 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 5T0Emh12mDzW for ; Mon, 5 Feb 2018 12:44:16 -0800 (PST) Received: from server172-2.web-hosting.com (server172-2.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 1A158128954 for ; Mon, 5 Feb 2018 12:44:16 -0800 (PST) Received: from [146.96.19.240] (port=63193 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1eincR-002ZBj-Mo for cellar@ietf.org; Mon, 05 Feb 2018 15:44:10 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_E3DDA176-2FA2-46C6-9AE6-01027ECB1ECF" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 5 Feb 2018 15:43:57 -0500 References: <95c5cb77-4762-57ae-62de-989b7a644ae5@mediaarea.net> To: Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: <95c5cb77-4762-57ae-62de-989b7a644ae5@mediaarea.net> Message-Id: <6BD2AD61-E318-4771-BA29-F58DAE313FB1@dericed.com> X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] generate a version (0, 1, 3) and version 4 FFV1 document from single source X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 20:44:18 -0000 --Apple-Mail=_E3DDA176-2FA2-46C6-9AE6-01027ECB1ECF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 3, 2018, at 2:08 PM, Jerome Martinez = wrote: >=20 > On 03/02/2018 19:24, Dave Rice wrote: >>=20 >> In the version 4 output there are references to exceptions defined in = our work on version 0,1,3. These include all lines starting with = =E2=80=9CBackground=E2=80=9D. I suggest resolving these in a subsequent = commit, but perhaps the version 4 document need not include these but = could only reference exceptions existed in prior version. >=20 > IMO we should remove exceptions in v4, in order to have a easy and = coherent bitstream specifications (and I expect that the compression is = slightly better without the exceptions, I'll run some tests) so = =E2=80=9CBackground=E2=80=9D would be marked v3 doc only, without any = reference in v4. > I'll open a separate thread about that when I do the tests. FYI, on this issue there was more discussion at = https://github.com/FFmpeg/FFV1/pull/102 = . The results are now merged = in, so the Makefile process for the FFV1 repository will create two = documents: draft-ietf-cellar-ffv1-01: FFV1 Video Coding Format Version 0, 1, and 3 and draft-ietf-cellar-ffv1-v4-00: FFV1 Video Coding Format Version 4 At this point, all issues in Github related to =E2=80=9CFFV1 Version 0, = 1, and 3=E2=80=9D are resolved, but there are two open pull requests: https://github.com/FFmpeg/FFV1/pull/87 = - minor change in terminology = about bitstream components https://github.com/FFmpeg/FFV1/pull/71 = - IANA Considerations I suggest that once these are pull requests are resolved to increment = the version numbering and post draft-ietf-cellar-ffv1-02 for a last call = and to post an initial post of draft-ietf-cellar-ffv1-v4-00. Best Regards, Dave Rice --Apple-Mail=_E3DDA176-2FA2-46C6-9AE6-01027ECB1ECF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 3, 2018, at 2:08 PM, Jerome Martinez <jerome@mediaarea.net> wrote:

On 03/02/2018 19:24, Dave Rice wrote:

In the = version 4 output there are references to exceptions defined in our work = on version 0,1,3. These include all lines starting with = =E2=80=9CBackground=E2=80=9D. I suggest resolving these in a subsequent = commit, but perhaps the version 4 document need not include these but = could only reference exceptions existed in prior version.

IMO we should remove exceptions = in v4, in order to have a easy and coherent bitstream specifications = (and I expect that the compression is slightly better without the = exceptions, I'll run some tests) so =E2=80=9CBackground=E2=80=9D would = be marked v3 doc only, without any reference in v4.
I'll = open a separate thread about that when I do the tests.

FYI, on this issue there was more discussion at https://github.com/FFmpeg/FFV1/pull/102. The results are = now merged in, so the Makefile process for the FFV1 repository will = create two documents:

draft-ietf-cellar-ffv1-01: FFV1 Video Coding = Format Version 0, 1, and 3
and
draft-ietf-cellar-ffv1-v4-00: FFV1 Video Coding Format = Version 4

At this point, all issues in Github related to =E2=80=9CFFV1 = Version 0, 1, and 3=E2=80=9D are resolved, but there are two open pull = requests:

https://github.com/FFmpeg/FFV1/pull/87 - minor = change in terminology about bitstream components
https://github.com/FFmpeg/FFV1/pull/71 - IANA = Considerations

I= suggest that once these are pull requests are resolved to increment the = version numbering and post draft-ietf-cellar-ffv1-02 for a last call and = to post an initial post of draft-ietf-cellar-ffv1-v4-00.

Best Regards,
Dave Rice

= --Apple-Mail=_E3DDA176-2FA2-46C6-9AE6-01027ECB1ECF-- From nobody Mon Feb 5 12:50:01 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED0E12D94A for ; Mon, 5 Feb 2018 12:50:00 -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 XmRiwnp-aaYK for ; Mon, 5 Feb 2018 12:49:58 -0800 (PST) Received: from 17.mo5.mail-out.ovh.net (17.mo5.mail-out.ovh.net [46.105.56.132]) (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 DFE9E128954 for ; Mon, 5 Feb 2018 12:49:57 -0800 (PST) Received: from player786.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo5.mail-out.ovh.net (Postfix) with ESMTP id 88BAC18752E for ; Mon, 5 Feb 2018 21:49:55 +0100 (CET) Received: from [192.168.2.120] (p5DDB56EF.dip0.t-ipconnect.de [93.219.86.239]) (Authenticated sender: jerome@mediaarea.net) by player786.ha.ovh.net (Postfix) with ESMTPSA id EF87D80092 for ; Mon, 5 Feb 2018 21:49:53 +0100 (CET) To: cellar@ietf.org References: <95c5cb77-4762-57ae-62de-989b7a644ae5@mediaarea.net> <6BD2AD61-E318-4771-BA29-F58DAE313FB1@dericed.com> From: Jerome Martinez Message-ID: <346e1398-8c0a-4978-030e-6fe78d40770f@mediaarea.net> Date: Mon, 5 Feb 2018 21:49:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <6BD2AD61-E318-4771-BA29-F58DAE313FB1@dericed.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Ovh-Tracer-Id: 14083318988181213329 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtfedruddvgddugeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] generate a version (0, 1, 3) and version 4 FFV1 document from single source X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 20:50:00 -0000 On 05/02/2018 21:43, Dave Rice wrote: > > > At this point, all issues in Github related to “FFV1 Version 0, 1, and > 3” are resolved, A bit late on it, but a question: how will be handled FFV1 v3.5, if we decide to have such version? FFV1 v4 is for incompatible changes, but micro_version seems planned for compatible changes (e.g. adding metadata like matrix coefficients for YUV in the configuration record part) From nobody Mon Feb 5 13:20:56 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45D612D958 for ; Mon, 5 Feb 2018 13:20:55 -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 uekmpWX2Apqw for ; Mon, 5 Feb 2018 13:20:53 -0800 (PST) Received: from 8.mo5.mail-out.ovh.net (8.mo5.mail-out.ovh.net [178.32.116.78]) (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 B209212711E for ; Mon, 5 Feb 2018 13:20:53 -0800 (PST) Received: from player786.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo5.mail-out.ovh.net (Postfix) with ESMTP id 50314185EC5 for ; Mon, 5 Feb 2018 22:20:51 +0100 (CET) Received: from [192.168.2.120] (p5DDB56EF.dip0.t-ipconnect.de [93.219.86.239]) (Authenticated sender: zen-lists@mediaarea.net) by player786.ha.ovh.net (Postfix) with ESMTPSA id C24D18007E; Mon, 5 Feb 2018 22:20:49 +0100 (CET) References: <20180203120734.GL3129@michaelspb> <20180203134824.GM3129@michaelspb> From: Jerome Martinez To: FFmpeg development discussions and patches , Codec Encoding for LossLess Archiving and Realtime transmission Message-ID: <40210041-ca4b-969e-eba1-2cfd6a11819d@mediaarea.net> Date: Mon, 5 Feb 2018 22:20:49 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180203134824.GM3129@michaelspb> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Ovh-Tracer-Id: 14606018017724272785 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtfedruddvgdduheduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm Archived-At: Subject: Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 21:20:56 -0000 On 03/02/2018 14:48, Michael Niedermayer wrote: > > I hope this will not reduce interrest in working on a improved > 9-16bit mode in v4. I don't like to put politics in technical stuff, but here this is politics, and I think that blocking an easy improvement of FFV1 v3 encoding/decoding in FFmpeg (actually just using the current FFV1 v3, and also v1 actually, specification without having artificial limitations about bit depths for a specific color space, i.e. 16-bit support was already there for YUV before I work on FFV1) just for forcing people to do a completely different work (e.g. working on FFV1 v4) is not fair and IMO is not in the idea behind open source. IMO if interest for 9-16bit (side note: I don't see why 8-bit should not be in the range, some ideas I have for v4 are useful also for 8-bit) mode in v4 is reduced, that would only mean that v3 is already so great and/or just that people have no better idea right now, it is not bad, and both works (using v3 at the maximum of its possibilities and working on v4) are separate works. FYI criticism I saw about FFV1 is not compression ratio but speed (playing a 4K stream is just impossible on a "normal" machine, you need a very expensive CPU for that) so my plan is to focus on speed improvement in priority. It could be v4 stuff (incompatible changes), or v3 (encoder/decoder optimization), depending of what I find. > > > [...] > >> Last but not least, since almost two years now it's impossible >> to work on the development of FFV1 v4. It's always the wrong >> time and/or the wrong place every time I am doing something for >> this cause. Why? This is extremely frustrating. > I want to understand this too. IMO v4 development should be more > important than or at least equally to the v3 draft polishing and neither > should block the other. Also politics, but I don't understand who is blocking v4 from your point of view. "impossible to work on v4"? Where? As far as I see 1 person (me) said his priority is having FFV1 v3 becoming a standard (so IETF related work) and widely used (so any bit depth for any supported color space in v3 because it is an easy demonstration that FFV1 is versatile without having to wait for v4 R&D, especially because v3 bitstream design is already pretty good and versatile) because this is what I need, and my personal case is not blocking anyone else for sending patches for either FFV1 specifications or FFmpeg code about v4. Eager to see patch proposals for v4 (and v3 if it does not break support of files in the wild), whoever feeling blocked with his patches should send patch proposals to either FFmpeg (code) or CELLAR mailing list (bitstream format). That said, I plan to add more pix_fmt support for FFV1 v3 (which is already a good format!) support in FFmpeg and some optimization ideas beside my work for IETF spec, with the hope we could speak about technical issues (e.g. more optimization hints or info about wrong code or warning about that it breaks the bitstream specs as currently written), leaving aside politics. From nobody Mon Feb 5 14:03:14 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6529212DA0A for ; Mon, 5 Feb 2018 14:03:12 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 zi158YKL2tjK for ; Mon, 5 Feb 2018 14:03:11 -0800 (PST) Received: from server172-2.web-hosting.com (server172-2.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 23968120724 for ; Mon, 5 Feb 2018 14:03:11 -0800 (PST) Received: from [146.96.19.240] (port=14910 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1eioqt-003ELI-Nb; Mon, 05 Feb 2018 17:03:05 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dave Rice In-Reply-To: <40210041-ca4b-969e-eba1-2cfd6a11819d@mediaarea.net> Date: Mon, 5 Feb 2018 17:03:02 -0500 Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180203120734.GL3129@michaelspb> <20180203134824.GM3129@michaelspb> <40210041-ca4b-969e-eba1-2cfd6a11819d@mediaarea.net> To: FFmpeg development discussions and patches X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] [FFmpeg-devel] [PATCH] avcodec/ffv1: Support for RGBA64 and GBRAP16 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 22:03:12 -0000 > On Feb 5, 2018, at 4:20 PM, Jerome Martinez = wrote: >=20 > On 03/02/2018 14:48, Michael Niedermayer wrote: >>=20 >> I hope this will not reduce interrest in working on a improved >> 9-16bit mode in v4. >=20 > I don't like to put politics in technical stuff, but here this is = politics, and I think that blocking an easy improvement of FFV1 v3 = encoding/decoding in FFmpeg (actually just using the current FFV1 v3, = and also v1 actually, specification without having artificial = limitations about bit depths for a specific color space, i.e. 16-bit = support was already there for YUV before I work on FFV1) just for = forcing people to do a completely different work (e.g. working on FFV1 = v4) is not fair and IMO is not in the idea behind open source. > IMO if interest for 9-16bit (side note: I don't see why 8-bit should = not be in the range, some ideas I have for v4 are useful also for 8-bit) = mode in v4 is reduced, that would only mean that v3 is already so great = and/or just that people have no better idea right now, it is not bad, = and both works (using v3 at the maximum of its possibilities and working = on v4) are separate works. FYI criticism I saw about FFV1 is not = compression ratio but speed (playing a 4K stream is just impossible on a = "normal" machine, you need a very expensive CPU for that) so my plan is = to focus on speed improvement in priority. It could be v4 stuff = (incompatible changes), or v3 (encoder/decoder optimization), depending = of what I find. IMHO, improved higher bit depths in version 4 is very interesting. We = already have a few noted exceptions where version 4 is intended to fix = and optimize a few things of version 3 (signed 16 bit handling, RGB = plane order for 9-15 bits), so a change in optimization of high bit = depth handling seems already appropriate for consideration. >> [...] >>=20 >>> Last but not least, since almost two years now it's impossible >>> to work on the development of FFV1 v4. It's always the wrong >>> time and/or the wrong place every time I am doing something for >>> this cause. Why? This is extremely frustrating. >> I want to understand this too. IMO v4 development should be more >> important than or at least equally to the v3 draft polishing and = neither >> should block the other. >=20 > Also politics, but I don't understand who is blocking v4 from your = point of view. "impossible to work on v4"? Where? As far as I see 1 = person (me) said his priority is having FFV1 v3 becoming a standard (so = IETF related work) and widely used (so any bit depth for any supported = color space in v3 because it is an easy demonstration that FFV1 is = versatile without having to wait for v4 R&D, especially because v3 = bitstream design is already pretty good and versatile) because this is = what I need, and my personal case is not blocking anyone else for = sending patches for either FFV1 specifications or FFmpeg code about v4. = Eager to see patch proposals for v4 (and v3 if it does not break support = of files in the wild), whoever feeling blocked with his patches should = send patch proposals to either FFmpeg (code) or CELLAR mailing list = (bitstream format). >=20 > That said, I plan to add more pix_fmt support for FFV1 v3 (which is = already a good format!) support in FFmpeg and some optimization ideas = beside my work for IETF spec, with the hope we could speak about = technical issues (e.g. more optimization hints or info about wrong code = or warning about that it breaks the bitstream specs as currently = written), leaving aside politics. In the cellar charter and timeline, the effort to produce a = informational specification for FFV1 video codec versions 0, 1 and 3 = precedes the effort to produce a specification for FFV1 video codec = version 4. Initially I anticipated that the version 4 specification = would be a fork from the completed version 0,1,3 draft; however, I think = the current approach (one doc that =E2=80=98makes=E2=80=99 both outputs) = works well to allow version 4 work to proceed without blocking any = remaining version 0,1,3 work. Still I suggest that we resolve = https://github.com/FFmpeg/FFV1/pull/87 and = https://github.com/FFmpeg/FFV1/pull/71 soon as IMHO the version 0,1,3 = informational specification is very close to a last call and submission = to the IESG (chairs are welcome to offer other opinions ;) ). So while I = encourage resolution to these pull requests, it seems we have a good = system to manage concurrent work on both FFV1 goals of the charter. Kind Regards, Dave Rice From nobody Wed Feb 7 07:55:17 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A4E12DA73 for ; Wed, 7 Feb 2018 07:55:15 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 LREKdFqIoTR4 for ; Wed, 7 Feb 2018 07:55:14 -0800 (PST) Received: from server172-2.web-hosting.com (server172-2.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 597B112DA70 for ; Wed, 7 Feb 2018 07:55:14 -0800 (PST) Received: from [146.96.19.240] (port=27802 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1ejS3q-003S3g-D6; Wed, 07 Feb 2018 10:55:03 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Dave Rice In-Reply-To: <346e1398-8c0a-4978-030e-6fe78d40770f@mediaarea.net> Date: Wed, 7 Feb 2018 10:54:50 -0500 Cc: cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6FBAB28A-7F73-46C4-AF01-3FF93127C29B@dericed.com> References: <95c5cb77-4762-57ae-62de-989b7a644ae5@mediaarea.net> <6BD2AD61-E318-4771-BA29-F58DAE313FB1@dericed.com> <346e1398-8c0a-4978-030e-6fe78d40770f@mediaarea.net> To: Jerome Martinez X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] generate a version (0, 1, 3) and version 4 FFV1 document from single source X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 15:55:15 -0000 > On Feb 5, 2018, at 3:49 PM, Jerome Martinez = wrote: >=20 > On 05/02/2018 21:43, Dave Rice wrote: >>=20 >>=20 >> At this point, all issues in Github related to =E2=80=9CFFV1 Version = 0, 1, and 3=E2=80=9D are resolved, >=20 > A bit late on it, but a question: how will be handled FFV1 v3.5, if we = decide to have such version? FFV1 v4 is for incompatible changes, but = micro_version seems planned for compatible changes (e.g. adding metadata = like matrix coefficients for YUV in the configuration record part) Others may know better, but since FFV1 version 0,1,3 is an informational = specification then IIUC an updated revision can be created by the cellar = working group. Such post-stable minor_version updates for version 4 may = be more involved, not sure if it would need a new IESG review. Dave= From nobody Wed Feb 7 10:55:41 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F181B1272E1 for ; Wed, 7 Feb 2018 10:55:40 -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 Pkq48XquZvqP for ; Wed, 7 Feb 2018 10:55:38 -0800 (PST) Received: from 9.mo4.mail-out.ovh.net (9.mo4.mail-out.ovh.net [46.105.40.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 317FA127275 for ; Wed, 7 Feb 2018 10:55:37 -0800 (PST) Received: from player759.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo4.mail-out.ovh.net (Postfix) with ESMTP id DB8BA147771 for ; Wed, 7 Feb 2018 19:55:35 +0100 (CET) Received: from [192.168.2.120] (p5DDB56EF.dip0.t-ipconnect.de [93.219.86.239]) (Authenticated sender: jerome@mediaarea.net) by player759.ha.ovh.net (Postfix) with ESMTPSA id 2BC8C64009A for ; Wed, 7 Feb 2018 19:55:34 +0100 (CET) To: Codec Encoding for LossLess Archiving and Realtime transmission From: Jerome Martinez Message-ID: <4fc9424d-a983-c82a-65c1-1cfec1814791@mediaarea.net> Date: Wed, 7 Feb 2018 19:55:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Ovh-Tracer-Id: 5451325876948766865 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 50 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtfedrudeigdduvddtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenucgoteefjeefqddtgeculdehtddm Archived-At: Subject: [Cellar] FFV1 metadata X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 18:55:41 -0000 In order to be able to transport metadata (optional items not having any impact on the decoding, e.g. matrix coefficients) directly in the FFV1 bitstream in order to avoid to lose metadata during transmux and to have a self describing bitstream, I propose to expand current FFV1 specification, here is a draft of patch for FFV1 specification: https://github.com/FFmpeg/FFV1/pull/104 Please comment. From nobody Thu Feb 8 03:16:41 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E2A12D94D for ; Thu, 8 Feb 2018 03:16:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, 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 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 E8dsKKchZgwd for ; Thu, 8 Feb 2018 03:16:37 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58CB9126D74 for ; Thu, 8 Feb 2018 03:16:36 -0800 (PST) Received: from smtp8.infomaniak.ch (smtp8.infomaniak.ch [83.166.132.38]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w18BGYFC002242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 8 Feb 2018 12:16:34 +0100 Received: from Castor.local (84-73-238-96.dclient.hispeed.ch [84.73.238.96]) (authenticated bits=0) by smtp8.infomaniak.ch (8.14.5/8.14.5) with ESMTP id w18BGXnJ055104 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 8 Feb 2018 12:16:34 +0100 Date: Thu, 8 Feb 2018 12:16:34 +0100 From: Reto Kromer To: Codec Encoding for LossLess Archiving and Realtime transmission X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: [Cellar] CfP "Codecs and Standards" X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 11:16:40 -0000 Hello Cellar, the number 5 of "FKT" ("Fachzeitschrift f=C3=BCr Fernsehen, Film und elektronische Medien") will be devoted to "Codecs and Standards". There is a call for papers in German or English and the deadline is 28 February 2018: https://www.fkt-online.de/call-for-papers/ Best regards, Reto From nobody Mon Feb 12 08:32:09 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04BE112D870 for ; Mon, 12 Feb 2018 08:32:08 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 5RLRkxRvtfoO for ; Mon, 12 Feb 2018 08:32:05 -0800 (PST) Received: from server172-2.web-hosting.com (server172-2.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 10B8812D86E for ; Mon, 12 Feb 2018 08:32:05 -0800 (PST) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:40538 helo=[10.0.1.2]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1elH1E-000NHS-0G; Mon, 12 Feb 2018 11:31:54 -0500 From: Dave Rice Message-Id: <498A8E37-D9C4-4A0E-B7E6-C7EB185FC79A@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2427076D-DAB8-41F5-A1F3-0F160A12C248" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Mon, 12 Feb 2018 11:31:50 -0500 In-Reply-To: Cc: Codec Encoding for LossLess Archiving and Realtime transmission To: Steve Lhomme References: X-Mailer: Apple Mail (2.3445.4.7) 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] EBML Error Handling X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 16:32:08 -0000 --Apple-Mail=_2427076D-DAB8-41F5-A1F3-0F160A12C248 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Nov 26, 2017, at 11:36 AM, Steve Lhomme = wrote: >=20 > 2017-11-26 16:13 GMT+01:00 Steve Lhomme : >> Hi, >>=20 >> The last remaining issues to fix before we can issue the last call on >> the EBML specs is more text to explain how error handling is done. It >> covers many possible cases. >>=20 >> Here are the cases I can think of (some mentioned here [1] and here = [2]): >=20 > Here's what libebml does and how we originally wanted to handle those > cases. Let me know if it could be improved or if it's just wrong. >=20 >> - multiple unique elements >=20 > libebml doesn't actually for reading unique elements only once. But > there is a helper to read the first element of one EBML ID. So by > default the first value encountered is the one that readers would use. > Different parsers (like the one in VLC) usually work differently, they > parse an EBML level and finding a known value that should be unique > (for example video width) they set that value. If the element is > encountered many time the value is overwritten. So the last value is > actually used. I don't have any preference. I'm curious to know what > mkvmerge does. We should also check what ffmpeg does. >=20 > Given the streaming nature of EBML/Matroska it would make sense that > the first value encountered is used ASAP. But on the other hand a > unique value usually sets a state that must be interpreted when the > whole master element is read. So it may not matter that much. But > there is the case of the ClusterTimecode. It does matter for > streaming, it even has to be early in the Cluster. For this element > subsequent values should be ignored (unless they're equal, which makes > no difference). That would favor the 'first found sets the value' > approach. >=20 >> - CRC element misplaced (it should always be first) >=20 > IMO it should be considered as a false positive detection. In other > words if the parser reads [BF] as an ID but it's not the first > element, the data is probably incorrect and so should be handled as > such (see further in the mail). There's no way a correct writer would > misplace the CRC element. >=20 >> - ClusterTimecode misplaced (it should always be first or after the = CRC) >=20 > Should not go in the EBML specs. But that's a case that needs to be > considered (see above). >=20 >> - CRC mismatch with the content >=20 > libebml doesn't enforce any behavior. It just tells if you the CRC-32 > is valid when you ask. In the case of VLC (using libebml and > libmatroska), it doesn't care. A player in general will try to play > content even if it's partly bogus/damaged. So it's more a concern for > data analysis/recovery. So we may not need to define any policy at > all. An invalid CRC-32 value just means there's something wrong, but > you don't know where. >=20 >> - invalid EBML ID >=20 > libebml just skips data until it finds a proper ID. That is an ID that > is valid at the semantic level. The library also has a mode that > allows reading bogus data that seem to make sense (dummy reading). > That's useful for forward compatibility with files. It's the preferred > approach in VLC (it's optional and was the other way around in the > past). So here we may not define a specific policy either. forward > compatibility is something that is very important so it should > probably be the default way of handling things. Using dummy elements > also allow remuxing a file and keeping the original data even if you > don't understand them. It's not foolproof though if dummy data depend > on data or metadata (like position) that may be altered during > remuxing. >=20 > libebml has a twist though. Even if it finds a dummy element, it also > checks that the length is legit in the context (ie not bigger than the > parent). If it doesn't then the dummy ID is considered invalid and it > starts parsing the next octets. Meaning there's a "hole" in the EBML > data. >=20 >> - invalid EBML length >=20 > That's the case described above. libebml doesn't allow elements > outside of the parent boundaries. That helps with false positive when > encountering unknown element IDs. If such an error is detected, it > starts parsing the next octets, resulting in a "hole" in the EBML > data. >=20 > By next octet I mean the first octet after the EBML ID+Length fields. > So if you have [AA][BB][CC] octets, it will start parsing the next ID > using the [BB] octet and further. The hole is the [AA] octet. >=20 > Just like with the CRC-32 a player will not care much about those > errors. It's more important for data analysis and possibly detecting > the position of bogus data. >=20 >> - Master element with junk data (most likely unidentified or bogus = IDs) >=20 > Again, we live in a world where bogus files will exist, even > unintentionally. Players (at least the sane ones) will try to extract > as much valid data from the source and not care about the rest. > Regular users will not care if something may be wrong somewhere in the > file. So the question is more for data analysis/recovery. >=20 > As seen above, there might be dummy data. That looks totally right but > are unknown. And there might be "holes" for data that really didn't > make sense the EBML way. Data analysis programs may want to treat them > differently. But I'm not sure defining a policy makes much sense. What > is more important is that the same bogus data is handled the same way > between parsers. As mentioned during No Time To Wait 2, the same bits > should produce the same output. So we should probably agree on how > these 2 kinds data error are generated rather than what to do with > them. >=20 >> - reserved EBML ID values >=20 > For libebml it falls in the category of dummy data. > The specs currently say "Any Element ID with the VINT_DATA component > set as all zero values or all one values MUST be ignored and MUST NOT > be considered an error in the EBML Document". It doesn't say what to > do with [80] as an ID for example. IMO it should be considered an > invalid ID (see above) and so skip to the next octet (EBML "hole"). >=20 >> - elements not found anymore >=20 > libebml doesn't do any version check on the semantic. This may not be > good. Finding old IDs may be a sign of damaged data rather than bogus > writer. On the other mkvalidator does such check and it's common to > find mismatches. Especially with an ever evolving format like WebM. I > think it's better to read these elements and let the upper level > reader deal with the version mismatch. >=20 > In the case of deprecated value there's a big chance it's element that > are supposedly never used, so the data can be handled as valid but > unused by the upper layer. >=20 >> or not yet for the given DocType >=20 > This is related to the Doctype 0/Experimental field/DTD discussion. > libebml currently reads them as valid "dummy" elements (unless you > disable dummy mode). As seen above the data could be remuxed as is > even when not knowing what they do. I don't think they should be > handled as errors. But it may change depending on how we define for > experimental IDs. Especially how we handle current existing files, if > they are considered as strict (therefore all unknown IDs are junk > data, not dummy elements). >=20 >> - IDs with the inefficient size >=20 > libebml predates the decision of enforcing the most efficient size for > IDs. So it allows that. > Now the specs say "The VINT_DATA component of the Element ID MUST be > encoded at the shortest valid length". So when a data with the > improper size is encountered, it must be considered as junk data. I > don't think any files exist with IDs stored as such (or very early > Matroska files). So it should be safe to go that way. >=20 >> - huge EBML Master size that can't hold in memory >=20 > "640 KB ought to be enough for everyone" is famous for being right at > the time and wrong now. So it would be hard to set a hard limit. And > if we don't it would violate the "same bit produces the same data > rule". Also the amount of memory available really depends on the > particular machine the program runs on at a given time. Also Unknown > Size elements are not meant to be held in memory anyway but to > minimize latency (and backward writing when it's not possible). > Not sure what to do here. >=20 >> - Elements with no default value with a size 0 >=20 > libebml gives 0 for an integer with no size. Should it be considered a > bug in the writing app or bogus data ? Not sure what to do here. If we > decide to read it as the element it is (ie not as junk data producing > a hole) it is in an unreadable state. It has no value that can be > read. And it cannot be used without a value. >=20 >> - EBML element not in the right place according to the semantic >=20 > libebml would produce a dummy element or a hole depending on the > reading mode. IMO it's junk data. If a writer writes this it cannot > expect the data to be handled properly. > Depending on the philosophy we use here will define how strict the > writer output needs to be. If we say it's OK then it's kinda OK to > have such bugs in writers. >=20 >> There are all reading/parsing errors. Based on what the reader is >> supposed to do will also define the possibilities to create safe = files >> for a writer (see [2]). >>=20 >> I will reply to this email with what libebml does and how it was >> originally designed to work. I think it's better we agree on the = rules >> for each case before doing patches for the specs. >=20 > So this is a long reply to a complex topic. We have 2 current outcomes > (dummy and hole) in libebml. Maybe you can think of different ways to > handle things. >=20 >> [1] https://github.com/Matroska-Org/ebml-specification/issues/48 >> [2] https://github.com/Matroska-Org/ebml-specification/issues/92 = A minor start but I began a section of =E2=80=9CConsiderations for = Reading EBML=E2=80=9D can can contain these topics. See = https://github.com/Matroska-Org/ebml-specification/pull/177 = . If this = approach works, we can start to incorporate the other topics you=E2=80=99r= e listing. Kind Regards, Dave Rice --Apple-Mail=_2427076D-DAB8-41F5-A1F3-0F160A12C248 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Nov 26, 2017, at 11:36 AM, Steve Lhomme <slhomme@matroska.org> wrote:

2017-11-26 16:13 GMT+01:00 Steve Lhomme <slhomme@matroska.org>:
Hi,

The last = remaining issues to fix before we can issue the last call on
the EBML specs is more text to explain how error handling is = done. It
covers many possible cases.

Here are the cases I can think of (some mentioned here [1] = and here [2]):

Here's what = libebml does and how we originally wanted to handle those
cases. Let me know if it could be improved or if it's just = wrong.

-= multiple unique elements

libebml doesn't actually for reading unique elements only = once. But
there is a helper to read the first element of = one EBML ID. So by
default the first value encountered is = the one that readers would use.
Different parsers (like = the one in VLC) usually work differently, they
parse an = EBML level and finding a known value that should be unique
(for example video width) they set that value. If the element = is
encountered many time the value is overwritten. So the = last value is
actually used. I don't have any preference. = I'm curious to know what
mkvmerge does. We should also = check what ffmpeg does.

Given the streaming = nature of EBML/Matroska it would make sense that
the first = value encountered is used ASAP. But on the other hand a
unique value usually sets a state that must be interpreted = when the
whole master element is read. So it may not = matter that much. But
there is the case of the = ClusterTimecode. It does matter for
streaming, it even has = to be early in the Cluster. For this element
subsequent = values should be ignored (unless they're equal, which makes
no difference). That would favor the 'first found sets the = value'
approach.

- CRC element misplaced (it should always be = first)

IMO it should be = considered as a false positive detection. In other
words = if the parser reads [BF] as an ID but it's not the first
element, the data is probably incorrect and so should be = handled as
such (see further in the mail). There's no way = a correct writer would
misplace the CRC element.

- = ClusterTimecode misplaced (it should always be first or after the = CRC)

Should not go in the EBML = specs. But that's a case that needs to be
considered (see = above).

- CRC mismatch with the content

libebml doesn't enforce any behavior. It just tells if you = the CRC-32
is valid when you ask. In the case of VLC = (using libebml and
libmatroska), it doesn't care. A player = in general will try to play
content even if it's partly = bogus/damaged. So it's more a concern for
data = analysis/recovery. So we may not need to define any policy at
all. An invalid CRC-32 value just means there's something = wrong, but
you don't know where.

- invalid EBML ID

libebml just skips data until it = finds a proper ID. That is an ID that
is valid at the = semantic level. The library also has a mode that
allows = reading bogus data that seem to make sense (dummy reading).
That's useful for forward compatibility with files. It's the = preferred
approach in VLC (it's optional and was the other = way around in the
past). So here we may not define a = specific policy either. forward
compatibility is something = that is very important so it should
probably be the = default way of handling things. Using dummy elements
also = allow remuxing a file and keeping the original data even if you
don't understand them. It's not foolproof though if dummy = data depend
on data or metadata (like position) that may = be altered during
remuxing.

libebml has a twist though. Even if it finds a dummy element, = it also
checks that the length is legit in the context (ie = not bigger than the
parent). If it doesn't then the dummy = ID is considered invalid and it
starts parsing the next = octets. Meaning there's a "hole" in the EBML
data.

- invalid = EBML length

That's the case = described above. libebml doesn't allow elements
outside of = the parent boundaries. That helps with false positive when
encountering unknown element IDs. If such an error is = detected, it
starts parsing the next octets, resulting in = a "hole" in the EBML
data.

By = next octet I mean the first octet after the EBML ID+Length fields.
So if you have [AA][BB][CC] octets, it will start parsing the = next ID
using the [BB] octet and further. The hole is the = [AA] octet.

Just like with the CRC-32 a = player will not care much about those
errors. It's more = important for data analysis and possibly detecting
the = position of bogus data.

- Master element with junk data (most likely = unidentified or bogus IDs)

Again, we live in a world where bogus files will exist, = even
unintentionally. Players (at least the sane ones) = will try to extract
as much valid data from the source and = not care about the rest.
Regular users will not care if = something may be wrong somewhere in the
file. So the = question is more for data analysis/recovery.

As seen above, there might be dummy data. That looks totally = right but
are unknown. And there might be "holes" for data = that really didn't
make sense the EBML way. Data analysis = programs may want to treat them
differently. But I'm not = sure defining a policy makes much sense. What
is more = important is that the same bogus data is handled the same way
between parsers. As mentioned during No Time To Wait 2, the = same bits
should produce the same output. So we should = probably agree on how
these 2 kinds data error are = generated rather than what to do with
them.

- = reserved EBML ID values

For = libebml it falls in the category of dummy data.
The specs = currently say "Any Element ID with the VINT_DATA component
set as all zero values or all one values MUST be ignored and = MUST NOT
be considered an error in the EBML Document". It = doesn't say what to
do with [80] as an ID for example. IMO = it should be considered an
invalid ID (see above) and so = skip to the next octet (EBML "hole").

- elements not found = anymore

libebml doesn't do any = version check on the semantic. This may not be
good. = Finding old IDs may be a sign of damaged data rather than bogus
writer. On the other mkvalidator does such check and it's = common to
find mismatches. Especially with an ever = evolving format like WebM. I
think it's better to read = these elements and let the upper level
reader deal with = the version mismatch.

In the case of = deprecated value there's a big chance it's element that
are = supposedly never used, so the data can be handled as valid but
unused by the upper layer.

or not yet for the given = DocType

This is related to the = Doctype 0/Experimental field/DTD discussion.
libebml = currently reads them as valid "dummy" elements (unless you
disable dummy mode). As seen above the data could be remuxed = as is
even when not knowing what they do. I don't think = they should be
handled as errors. But it may change = depending on how we define for
experimental IDs. = Especially how we handle current existing files, if
they = are considered as strict (therefore all unknown IDs are junk
data, not dummy elements).

- IDs with the = inefficient size

libebml = predates the decision of enforcing the most efficient size for
IDs. So it allows that.
Now the specs say "The = VINT_DATA component of the Element ID MUST be
encoded at = the shortest valid length". So when a data with the
improper= size is encountered, it must be considered as junk data. I
don't think any files exist with IDs stored as such (or very = early
Matroska files). So it should be safe to go that = way.

- = huge EBML Master size that can't hold in memory

"640 KB ought to be enough for = everyone" is famous for being right at
the time and wrong = now. So it would be hard to set a hard limit. And
if we = don't it would violate the "same bit produces the same data
rule". Also the amount of memory available really depends on = the
particular machine the program runs on at a given = time. Also Unknown
Size elements are not meant to be held = in memory anyway but to
minimize latency (and backward = writing when it's not possible).
Not sure what to do = here.

- = Elements <NON Master> with no default value with a size 0

libebml gives 0 for an integer = with no size. Should it be considered a
bug in the writing = app or bogus data ? Not sure what to do here. If we
decide = to read it as the element it is (ie not as junk data producing
a hole) it is in an unreadable state. It has no value that = can be
read. And it cannot be used without a value.

- EBML = element not in the right place according to the semantic

libebml would produce a dummy = element or a hole depending on the
reading mode. IMO it's = junk data. If a writer writes this it cannot
expect the = data to be handled properly.
Depending on the philosophy = we use here will define how strict the
writer output needs = to be. If we say it's OK then it's kinda OK to
have such = bugs in writers.

There are all reading/parsing errors. Based on what the = reader is
supposed to do will also define the = possibilities to create safe files
for a writer (see = [2]).

I will reply to this email with what = libebml does and how it was
originally designed to work. I = think it's better we agree on the rules
for each case = before doing patches for the specs.

So this is a long reply to a complex topic. We have 2 current = outcomes
(dummy and hole) in libebml. Maybe you can think = of different ways to
handle things.

[1] https://github.com/Matroska-Org/ebml-specification/issues/48
[2] https://github.com/Matroska-Org/ebml-specification/issues/92

A minor start but I began a section of = =E2=80=9CConsiderations for Reading EBML=E2=80=9D can can contain these = topics. See https://github.com/Matroska-Org/ebml-specification/pull/177= . If this approach works, we can start to incorporate the other topics = you=E2=80=99re listing.

Kind Regards,
Dave Rice

= --Apple-Mail=_2427076D-DAB8-41F5-A1F3-0F160A12C248-- From nobody Mon Feb 12 08:50:34 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78F42126DC2; Mon, 12 Feb 2018 08:50:33 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 KVEoxliyOJ7m; Mon, 12 Feb 2018 08:50:32 -0800 (PST) Received: from server172-2.web-hosting.com (server172-2.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 04436126D45; Mon, 12 Feb 2018 08:50:29 -0800 (PST) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:40718 helo=[10.0.1.2]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1elHJD-000XII-9e; Mon, 12 Feb 2018 11:50:28 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_4F42BDC8-CF19-49FE-A8AA-AA64A4528086" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <5AF37D25-647D-40F6-8480-A4258A604831@dericed.com> Date: Mon, 12 Feb 2018 11:50:25 -0500 To: Codec Encoding for LossLess Archiving and Realtime transmission , cellar-chairs@ietf.org X-Mailer: Apple Mail (2.3445.4.7) 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] doc shepherd appointments X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 16:50:33 -0000 --Apple-Mail=_4F42BDC8-CF19-49FE-A8AA-AA64A4528086 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi cellar chairs and working group, As at least two drafts (EBML and FFV1) are IMHO ready or very close to = ready for a Working Group Last Call I wanted to nudge the working group = chairs on document shepherd appointments. Earlier the chairs sent out a = call on the listserv in regards to assigning a document shephard for = FLAC with some responses, but if = https://datatracker.ietf.org/wg/cellar/documents/ = is up to date, no = document shepherds have been appointed yet. I=E2=80=99m willing to serve as document shepherd for either EBML or = FFV1 but as an active contributing author realize that that may not be = ideal. Are others interested in contributing as document shepherds? Guidance = from the chairs on appointment process or status for shepherds? Background info on the document shepherd role: https://tools.ietf.org/html/rfc4858#section-3 = https://www.ietf.org/iesg/statement/document-shepherds.html = Kind Regards, Dave Rice= --Apple-Mail=_4F42BDC8-CF19-49FE-A8AA-AA64A4528086 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = cellar chairs and working group,

As at least two drafts (EBML and FFV1) are IMHO ready or very = close to ready for a Working Group Last Call I wanted to nudge the = working group chairs on document shepherd appointments. Earlier the = chairs sent out a call on the listserv in regards to assigning a = document shephard for FLAC with some responses, but if https://datatracker.ietf.org/wg/cellar/documents/ is = up to date, no document shepherds have been appointed yet.

I=E2=80=99m willing to = serve as document shepherd for either EBML or FFV1 but as an active = contributing author realize that that may not be ideal.

Are others interested in = contributing as document shepherds? Guidance from the chairs on = appointment process or status for shepherds?

Background info on the document = shepherd role:
https://tools.ietf.org/html/rfc4858#section-3
https://www.ietf.org/iesg/statement/document-shepherds.html=

Kind = Regards,
Dave Rice
= --Apple-Mail=_4F42BDC8-CF19-49FE-A8AA-AA64A4528086-- From nobody Mon Feb 12 09:12:03 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241A012D864; Mon, 12 Feb 2018 09:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEciMiR0PjvC; Mon, 12 Feb 2018 09:12:00 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA46D126DC2; Mon, 12 Feb 2018 09:11:59 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id b21so11289844wme.4; Mon, 12 Feb 2018 09:11:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cIQusoJFjENKUWsP+m31ZhY3FRubspKW4BOIEVZXvkA=; b=mfZxm8E5D7WNYd3Gk81FDiOTZ+RPiaPOjB5VyBJLF8GB0sRkWJGK/VxqvRG17HyvnA oBlZoJ2linrBJG1TwcjLlnIunaXCdk5QFlRFRbR4+Ff2SEwwQsIuOCe2GSYg54qQWsEf zi4VgIZcK2dXrC8aDhyuO7GIyCcz1v8Amch24XwYz+xySWoiSE7iuVroZDals6Qqrbg9 AGBmXUEwOaRPFImQJrAOMCM1FPanQ1bZEM7Fcj9Mgsvs0ea0L+disNO+EiSf+OJSuN2J W8lysUu8BAoQE8ITTUc4d0xG7ToE5i3k5N1lvWzG8DnH20yg+saG3tz3KKv+6T35GBMO fSYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cIQusoJFjENKUWsP+m31ZhY3FRubspKW4BOIEVZXvkA=; b=FKZnW415F4SivY1auQ7bPyUrMAiAumVP3uhLN7cVxq7VktWMeC8gkMGj6M/iwbwJ4y PjFBThk8350Z3e9PgiKUwPPxTL71m5e16lqOB4uKH18Q8iIrwtMvw1Y7/mMHHQKd8d9Q MCMBisbBt6kRogemstYAkKFxOAtYrx5rRy3sJAaywx1VE/za/locfIbdExOyF0jcq3A/ RkB3m5kuY+akR4QNEemb23xyJS9CTMcu0ZebeeWGmYznduZ0NV//ksM9LHOxC+n9kgT0 n/HAd/1SaujQkylSFaWnJCh3mcb8NYNrryQpf/1YjUkWIQyNQeYSSn7WqU9q91nxMmfg GJKw== X-Gm-Message-State: APf1xPD5K3ouEF8aKtuzEWBaST0MvadhFeqvMwF6SD736V4ulrVM8yGQ 5yJcelnI45IJTKjdy6iZEd0s9IayiWisLWgWOHJOMg== X-Google-Smtp-Source: AH8x227STUy293H5Pjrxm/HgecCge87sashVpYLQDevn1Vt64oJA9q30cirocUhyIyvjctRviSCiZN9EJ8iWqOgH3XI= X-Received: by 10.80.178.99 with SMTP id o90mr17133911edd.255.1518455517966; Mon, 12 Feb 2018 09:11:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.151.102 with HTTP; Mon, 12 Feb 2018 09:11:57 -0800 (PST) In-Reply-To: <5AF37D25-647D-40F6-8480-A4258A604831@dericed.com> References: <5AF37D25-647D-40F6-8480-A4258A604831@dericed.com> From: Steven Villereal Date: Mon, 12 Feb 2018 12:11:57 -0500 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Cc: cellar-chairs@ietf.org Content-Type: multipart/alternative; boundary="94eb2c194a6cc177a6056506f9fe" Archived-At: Subject: Re: [Cellar] doc shepherd appointments X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 17:12:02 -0000 --94eb2c194a6cc177a6056506f9fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all=E2=80=93 I've been mostly a lurker here, but willingly volunteer myself as a document shepherd for the EBML documentation! best, steven On Mon, Feb 12, 2018 at 11:50 AM, Dave Rice wrote: > Hi cellar chairs and working group, > > As at least two drafts (EBML and FFV1) are IMHO ready or very close to > ready for a Working Group Last Call I wanted to nudge the working group > chairs on document shepherd appointments. Earlier the chairs sent out a > call on the listserv in regards to assigning a document shephard for FLAC > with some responses, but if https://datatracker.ietf. > org/wg/cellar/documents/ is up to date, no document shepherds have been > appointed yet. > > I=E2=80=99m willing to serve as document shepherd for either EBML or FFV1= but as > an active contributing author realize that that may not be ideal. > > Are others interested in contributing as document shepherds? Guidance fro= m > the chairs on appointment process or status for shepherds? > > Background info on the document shepherd role: > https://tools.ietf.org/html/rfc4858#section-3 > https://www.ietf.org/iesg/statement/document-shepherds.html > > Kind Regards, > Dave Rice > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --94eb2c194a6cc177a6056506f9fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all=E2=80=93

I've been = mostly a lurker here, but willingly volunteer myself as a document shepherd= for the EBML documentation!

best,
steven

On Mon, Feb 12, 201= 8 at 11:50 AM, Dave Rice <dave@dericed.com> wrote:
Hi cellar chairs and working group,

As at least = two drafts (EBML and FFV1) are IMHO ready or very close to ready for a Work= ing Group Last Call I wanted to nudge the working group chairs on document = shepherd appointments. Earlier the chairs sent out a call on the listserv i= n regards to assigning a document shephard for FLAC with some responses, bu= t if=C2=A0https://datatracker.ietf.org/wg/cellar/documents/= =C2=A0is up to date, no document shepherds have been appointed yet.

I=E2=80=99m willing to serve as document shepherd for eit= her EBML or FFV1 but as an active contributing author realize that that may= not be ideal.

Are others interested in contributi= ng as document shepherds? Guidance from the chairs on appointment process o= r status for shepherds?

Background info on t= he document shepherd role:

Kind Reg= ards,
Dave Rice

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

--94eb2c194a6cc177a6056506f9fe-- From nobody Mon Feb 12 09:21:08 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6197712D879 for ; Mon, 12 Feb 2018 09:21:02 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gBkrSh32_wCo for ; Mon, 12 Feb 2018 09:21:00 -0800 (PST) Received: from mxout24.cac.washington.edu (mxout24.cac.washington.edu [140.142.234.158]) (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 1F35D12D864 for ; Mon, 12 Feb 2018 09:21:00 -0800 (PST) Received: from mail-ua0-f200.google.com (mail-ua0-f200.google.com [209.85.217.200]) by mxout24.cac.washington.edu (8.14.4+UW14.03/8.14.4+UW16.03) with ESMTP id w1CHKCeA011128 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=OK) for ; Mon, 12 Feb 2018 09:20:13 -0800 Received: by mail-ua0-f200.google.com with SMTP id 104so10835828uat.5 for ; Mon, 12 Feb 2018 09:20:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=en17M0SALbmqP/TFebHTMRYBAvn0YGS/HV9PpQQOz3U=; b=mRlOnS85iNCoJ0TpHImJoGg7Z5xP1BMVguwWDO4P5EOS/OfY2CWczSlPfP+XelmrxT lbb3wWFGbbtxh34NdG/+XRN6fvHKuyvm8+GP3MOkYCncrA3gDuVMIJqULJUWyi9zTTk9 JnhmARgRGQirqzLaO3iBkwzFd59Ecp4TaYmcHFLNql2ydhndMnBddDBOLEgfRTA/o4m/ Ow4F/UbLekujR/Bv3oCOaOVLLrKHPlN57CPe5liIbdrkNfC8vF+8ewlvaLCy8V5mRlgN a51k/FDaTg9z/87lFcC4crVLVbqE5vVgBV3l9dFBY5Ix8K1fl1YsMUYTmbHqpFHJQcfp A9Lw== X-Gm-Message-State: APf1xPDn5OBdEaZCac2f1pSztTs4arPFO4h2vB3HcAq0Y8ggHlKJDaa7 iE8rgVM8aUVPlhNpxsGm8XiB9hVJJbhP1u6VusWg6K7VsRMjFa3PjwE0D5LjldV4CwLJVdKS3Yq 1n2Ltp+byHQXc9oT9tMyTCgjGYDoEn9NyKtwtDLVUYUyjU8F7 X-Received: by 10.176.93.226 with SMTP id l34mr12300071uag.119.1518456012049; Mon, 12 Feb 2018 09:20:12 -0800 (PST) X-Google-Smtp-Source: AH8x227TAUvjfdc5akZgVrNE0LXKwRS7xpON220QIGw90uybtymfHNhceIP/gVU2J+sQiArWe6y9Ap4a9IyTKO3sgNs= X-Received: by 10.176.93.226 with SMTP id l34mr12299937uag.119.1518456009712; Mon, 12 Feb 2018 09:20:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.89.40 with HTTP; Mon, 12 Feb 2018 09:20:08 -0800 (PST) In-Reply-To: References: <5AF37D25-647D-40F6-8480-A4258A604831@dericed.com> From: Andrew James Weaver Date: Mon, 12 Feb 2018 09:20:08 -0800 Message-ID: To: Steven Villereal Cc: Codec Encoding for LossLess Archiving and Realtime transmission , cellar-chairs@ietf.org Content-Type: multipart/alternative; boundary="f403043eebec11139505650717c2" X-PMX-Version: 6.3.3.2656215, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2018.2.12.171516, AntiVirus-Engine: 5.46.1.0, AntiVirus-Data: 2018.2.12.5461002 X-PMX-Server: mxout24.cac.washington.edu X-Uwash-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_50_70 0.1, MULTIPLE_RCPTS 0.1, BODYTEXTH_SIZE_10000_LESS 0, BODYTEXTH_SIZE_3000_MORE 0, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_5000_5999 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, FROM_NAME_PHRASE 0, IN_REP_TO 0, LEGITIMATE_SIGNS 0, MSG_THREAD 0, REFERENCES 0, SPF_NEUTRAL 0, URI_ENDS_IN_HTML 0, WEBMAIL_SOURCE 0, __ANY_URI 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __DQ_NEG_HEUR 0, __DQ_NEG_IP 0, __FORWARDED_MSG 0, __FRAUD_BODY_WEBMAIL 0, __FRAUD_WEBMAIL 0, __HAS_CC_HDR 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __HELO_GMAIL 0, __HEX28_LC_BOUNDARY 0, __HTML_AHREF_TAG 0, __HTML_TAG_DIV 0, __HTTPS_URI 0, __IN_REP_TO 0, __MIME_HTML 0, __MIME_TEXT_H 0, __MIME_TEXT_H1 0, __MIME_TEXT_H2 0, __MIME_TEXT_P 0, __MIME_TEXT_P1 0, __MIME_TEXT_P2 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __MULTIPLE_URI_HTML 0, __MULTIPLE_URI_TEXT 0, __PHISH_SPEAR_HTTP_RECEIVED 0, __PHISH_SPEAR_STRUCTURE_1 0, __RDNS_GMAIL 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_NEGATE 0, __TO_MALFORMED_2 0, __TO_NAME 0, __TO_NAME_DIFF_FROM_ACC 0, __TO_REAL_NAMES 0, __URI_IN_BODY 0, __URI_NOT_IMG 0, __URI_NS , __URI_WITHOUT_PATH 0, __URI_WITH_PATH 0, __YOUTUBE_RCVD 0' Archived-At: Subject: Re: [Cellar] doc shepherd appointments X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 17:21:02 -0000 --f403043eebec11139505650717c2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi All, I am willing to continue on with the FLAC process in the context of document shepherd! Best, Andrew On Mon, Feb 12, 2018 at 9:11 AM, Steven Villereal wrote: > Hi all=E2=80=93 > > I've been mostly a lurker here, but willingly volunteer myself as a > document shepherd for the EBML documentation! > > best, > steven > > On Mon, Feb 12, 2018 at 11:50 AM, Dave Rice wrote: > >> Hi cellar chairs and working group, >> >> As at least two drafts (EBML and FFV1) are IMHO ready or very close to >> ready for a Working Group Last Call I wanted to nudge the working group >> chairs on document shepherd appointments. Earlier the chairs sent out a >> call on the listserv in regards to assigning a document shephard for FLA= C >> with some responses, but if https://datatracker.ietf.or >> g/wg/cellar/documents/ is up to date, no document shepherds have been >> appointed yet. >> >> I=E2=80=99m willing to serve as document shepherd for either EBML or FFV= 1 but as >> an active contributing author realize that that may not be ideal. >> >> Are others interested in contributing as document shepherds? Guidance >> from the chairs on appointment process or status for shepherds? >> >> Background info on the document shepherd role: >> https://tools.ietf.org/html/rfc4858#section-3 >> https://www.ietf.org/iesg/statement/document-shepherds.html >> >> Kind Regards, >> Dave Rice >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> >> > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --f403043eebec11139505650717c2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I am willing to= continue on with the FLAC process in the context of document shepherd!
=
Best,
Andrew

On Mon, Feb 12, 2018 at 9:11 AM, Steven Villereal <= span dir=3D"ltr"><villereal@gmail.com> wrote:
Hi all=E2=80=93

I've b= een mostly a lurker here, but willingly volunteer myself as a document shep= herd for the EBML documentation!

best,
steven

On Mon, Feb 12, 2018 at 11:50 AM, Dave Rice <<= a href=3D"mailto:dave@dericed.com" target=3D"_blank">dave@dericed.com&g= t; wrote:
Hi cellar chairs and working group,

As at least two drafts (E= BML and FFV1) are IMHO ready or very close to ready for a Working Group Las= t Call I wanted to nudge the working group chairs on document shepherd appo= intments. Earlier the chairs sent out a call on the listserv in regards to = assigning a document shephard for FLAC with some responses, but if=C2=A0https://datatracker.ietf.org/wg/cellar/documents/=C2=A0is up to = date, no document shepherds have been appointed yet.

I=E2=80=99m willing to serve as document shepherd for either EBML or FFV= 1 but as an active contributing author realize that that may not be ideal.<= /div>

Are others interested in contributing as document = shepherds? Guidance from the chairs on appointment process or status for sh= epherds?

Background info on the document she= pherd role:

Kind Regards,
Dave= Rice

_____________________________________= __________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar


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

--f403043eebec11139505650717c2-- From nobody Mon Feb 19 01:11:16 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0EC126CBF; Mon, 19 Feb 2018 01:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 1n4tiwxtYwvE; Mon, 19 Feb 2018 01:11:14 -0800 (PST) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D73912426E; Mon, 19 Feb 2018 01:11:13 -0800 (PST) Received: from [10.0.0.199] (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; Mon, 19 Feb 2018 10:11:12 +0100 id 000000000000010B.000000005A8A94B0.000006E8 To: Dave Rice , Codec Encoding for LossLess Archiving and Realtime transmission , cellar-chairs@ietf.org References: <5AF37D25-647D-40F6-8480-A4258A604831@dericed.com> From: "Peter B." Message-ID: <3d967fbc-f2a3-187b-2857-59d3e873a264@das-werkstatt.com> Date: Mon, 19 Feb 2018 10:11:09 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <5AF37D25-647D-40F6-8480-A4258A604831@dericed.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] doc shepherd appointments X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Feb 2018 09:11:15 -0000 On 2018-02-12 17:50, Dave Rice wrote: > I’m willing to serve as document shepherd for either EBML or FFV1 but as an active contributing author realize that that may not be ideal. > Are others interested in contributing as document shepherds? Guidance from the chairs on appointment process or status for shepherds? I'll read up on the doc-shepherd links you've provided, in order to volunteer for FFV1 :) Kind regards, Pb