From nobody Wed Apr 5 07:59:37 2017 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 CD252127241 for ; Wed, 5 Apr 2017 07:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.721 X-Spam-Level: X-Spam-Status: No, score=-3.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fMbSPfUJIrH for ; Wed, 5 Apr 2017 07:59:33 -0700 (PDT) Received: from hartman.uits.indiana.edu (belushi.uits.indiana.edu [129.79.1.188]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64998128854 for ; Wed, 5 Apr 2017 07:59:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2DYDQAIBeVY/0kBT4FCFwMeBgyCbiFFY?= =?us-ascii?q?YELB7UAgg0BJYlLRhEBAgEBAQEBAQFrHQuFSV4BgQAmAQQbigYBDTGbJJIth38?= =?us-ascii?q?BB4JlAQEBBwEBAQEBAR0Fhk+KDIIFDIJuHwWJJZNLAYFUhSmLS5FFk3Y5DBKBB?= =?us-ascii?q?V0Thxp1AYg7AYEMAQEB?= X-IPAS-Result: =?us-ascii?q?A2DYDQAIBeVY/0kBT4FCFwMeBgyCbiFFYYELB7UAgg0BJYl?= =?us-ascii?q?LRhEBAgEBAQEBAQFrHQuFSV4BgQAmAQQbigYBDTGbJJIth38BB4JlAQEBBwEBA?= =?us-ascii?q?QEBAR0Fhk+KDIIFDIJuHwWJJZNLAYFUhSmLS5FFk3Y5DBKBBV0Thxp1AYg7AYE?= =?us-ascii?q?MAQEB?= X-IronPort-AV: E=Sophos; i="5.36,279,1486443600"; d="scan'208,217"; a="67465406" Received: from mssg-relay.indiana.edu ([129.79.1.73]) by irpt-internal-relay.indiana.edu with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2017 10:59:24 -0400 Received: from bl-cci-exch04.ads.iu.edu (bl-cci-exch04.ads.iu.edu [10.79.80.137]) by mssg-relay.indiana.edu (8.14.4/8.14.4/IU Campus Communications Team - MSSG) with ESMTP id v35ExOvZ025908 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 5 Apr 2017 10:59:24 -0400 Received: from in-cci-exch08.ads.iu.edu (2001:18e8:3:cc1::10b) by bl-cci-exch04.ads.iu.edu (2001:18e8:2:cc1::10d) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 5 Apr 2017 10:59:23 -0400 Received: from in-cci-exch08.ads.iu.edu ([fe80::2107:135f:2c71:792d]) by in-cci-exch08.ads.iu.edu ([fe80::2107:135f:2c71:792d%18]) with mapi id 15.00.1210.000; Wed, 5 Apr 2017 10:59:23 -0400 From: "Casey, Michael T" To: "cellar@ietf.org" Thread-Topic: Video preservation master file formats Thread-Index: AdKuHPqqJ/RCLuZWSseuFWsm/Xe7+Q== Date: Wed, 5 Apr 2017 14:59:23 +0000 Message-ID: <5089c11ead0a43999a90ca46205912e0@in-cci-exch08.ads.iu.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [129.79.49.223] Content-Type: multipart/alternative; boundary="_000_5089c11ead0a43999a90ca46205912e0incciexch08adsiuedu_" MIME-Version: 1.0 Archived-At: Subject: [Cellar] Video preservation master file formats 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, 05 Apr 2017 14:59:35 -0000 --_000_5089c11ead0a43999a90ca46205912e0incciexch08adsiuedu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Indiana University's Media Digitization and Preservation Initiative (MDPI) = has released a white paper exploring its decision to use the FFV1 format an= d the Matroska wrapper for video preservation master files. It is available= from the Resources section of the MDPI website. https://mdpi.iu.edu/resources/index.php Mike ------------ Mike Casey Director of Technical Operations Media Digitization and Preservation Initiative Indiana University 812-855-8090 https://mdpi.iu.edu/ --_000_5089c11ead0a43999a90ca46205912e0incciexch08adsiuedu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Indiana University's Media Digitization and Preserva= tion Initiative (MDPI) has released a white paper exploring its decision to= use the FFV1 format and the Matroska wrapper for video preservation master= files. It is available from the Resources section of the MDPI website.

= https://mdpi.iu.edu/resources/index.php

 

Mike

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

Mi= ke Casey

Direc= tor of Technical Operations

Media= Digitization and Preservation Initiative

India= na University

812-8= 55-8090

=  

https://mdpi.iu.edu= /

 

 

 

--_000_5089c11ead0a43999a90ca46205912e0incciexch08adsiuedu_-- From nobody Tue Apr 11 11:58:13 2017 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 58B6B12EC1D for ; Tue, 11 Apr 2017 11:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 YyHOfJUbCqcZ for ; Tue, 11 Apr 2017 11:58:03 -0700 (PDT) Received: from 5.mo68.mail-out.ovh.net (5.mo68.mail-out.ovh.net [46.105.62.179]) (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 18C0912EC1E for ; Tue, 11 Apr 2017 11:57:09 -0700 (PDT) Received: from player711.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 0851249F84 for ; Tue, 11 Apr 2017 20:57:07 +0200 (CEST) Received: from [192.168.2.101] (p5DDB4468.dip0.t-ipconnect.de [93.219.68.104]) (Authenticated sender: jerome@mediaarea.net) by player711.ha.ovh.net (Postfix) with ESMTPSA id 8229738007E for ; Tue, 11 Apr 2017 20:57:07 +0200 (CEST) From: Jerome Martinez To: Codec Encoding for LossLess Archiving and Realtime transmission Message-ID: Date: Tue, 11 Apr 2017 20:57:06 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------2507018178B3B6684296C10F" X-Ovh-Tracer-Id: 2811090593247137937 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeliedrudeggdduvdelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: [Cellar] FFV1 JPEG2000-RCT not really as described for bit depth 9 to 15? With patch 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: Tue, 11 Apr 2017 18:58:06 -0000 This is a multi-part message in MIME format. --------------2507018178B3B6684296C10F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi CELLAR, In the experience of creating an independent FFV1 decoder from the specification, I found an issue with JPEG2000-RCT color space and bit depth from 9 to 15. During decoding, the colors are not the expected ones. For 8 and 16 -bit, JPEG2000-RCT is used as expressed in the draft specification. For 9/10/12/14 -bit, looks like this is not JPEG2000-RCT but a variant, inverting b and g. If I follow correctly the source code: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/ffv1dec_template.c#L151-L160 - for 8-bit (and below), it is transformed to packed "bgr0" FFmpeg pixel format - else for 16-bit (and above), it is transformed to planar "gbrpX" (X= bit depth) FFmpeg pixel format - else it is transformed to planar "bgrpX" FFmpeg pixel format in a "gbrpX" FFmpeg pixel format, see https://github.com/FFmpeg/FFmpeg/blob/549045254c4614d5d61b5c36e340171a6914d57c/libavcodec/ffv1dec.c#L667-L673 Reading encoding part, looks like same, I understand it as like if order of planes was considered as the same as order of bytes for 8-bit packed order but it was a bug (bgr vs gbr). Thus g (green) is not the "reference" for RGB to YCbCr transform, but b (blue) is used instead. If I am correct, I suggest the attached patch. In the details: - for bit depth from 9 to 15, I suggest to support the "bug" for hypothetical bit depths of 11, 13, and 15 too so we have a test >=9 && <=15 instead of a list of values. We have this exception about bit depths 9 to 15 in order to support files already in the wild. - as for the bug in the context computing, I suggest to remove this bug in the next incompatible version (version 4) so we will have a version 4 with a more coherent specification (identical formulas whatever is the bit depth). Jérôme --------------2507018178B3B6684296C10F Content-Type: text/plain; charset=UTF-8; name="0001-JPEG2000-RCT-formula-update.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="0001-JPEG2000-RCT-formula-update.patch" RnJvbSAzZGEzNzhkMDM0YzdmMTc1NmYxYTc3NjZlZTIxODc0NjQ5ZDRmMTUwIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Sj1DMz1BOXI9QzM9QjRtZT0yME1h cnRpbmV6Pz0gPGplcm9tZUBtZWRpYWFyZWEubmV0PgpEYXRlOiBUdWUsIDExIEFwciAyMDE3 IDE4OjQzOjU4ICswMjAwClN1YmplY3Q6IFtQQVRDSF0gSlBFRzIwMDAtUkNUIGZvcm11bGEg dXBkYXRlCgpJbiBvcmRlciB0byBiZSBjb21wYXRpYmxlIHdpdGggZmlsZXMgaW4gdGhlIHdp bGQKLS0tCiBmZnYxLm1kIHwgMzUgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr KysKIDEgZmlsZSBjaGFuZ2VkLCAzNSBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEvZmZ2 MS5tZCBiL2ZmdjEubWQKaW5kZXggMGFmMzQxYi4uM2JkN2QwZSAxMDA2NDQKLS0tIGEvZmZ2 MS5tZAorKysgYi9mZnYxLm1kCkBAIC0yNzIsNiArMjcyLDQxIEBAIFJGQzpgYGAKIFJGQzpi PUNiK2cKIFJGQzpgYGAKIAorRXhjZXB0aW9uIGZvciB0aGUgdHJhbnNmb3JtOiAgCitpZiBi aXRzX3Blcl9yYXdfc2FtcGxlIGlzIGJldHdlZW4gOSBhbmQgMTQgaW5jbHVkZWQsIHRoZSBm b2xsb3dpbmcgdHJhbnNmb3JtIE1VU1QgYmUgdXNlZDoKKworUERGOiQkQ2I9Zy1iJCQKK1JG QzpgYGAKK1JGQzpDYj1nLWIKK1JGQzpgYGAKKworUERGOiQkQ3I9ci1iJCQKK1JGQzpgYGAK K1JGQzpDcj1yLWIKK1JGQzpgYGAKKworUERGOiQkWT1iKyhDYitDcik+PjIkJAorUkZDOmBg YAorUkZDOlk9YisoQ2IrQ3IpPj4yCitSRkM6YGBgCisKK1BERjokJGI9WS0oQ2IrQ3IpPj4y JCQKK1JGQzpgYGAKK1JGQzpiPVktKENiK0NyKT4+MgorUkZDOmBgYAorCitQREY6JCRyPUNy K2IkJAorUkZDOmBgYAorUkZDOnI9Q3IrYgorUkZDOmBgYAorCitQREY6JCRnPUNiK2IkJAor UkZDOmBgYAorUkZDOmc9Q2IrYgorUkZDOmBgYAorCitCYWNrZ3JvdW5kOiB3aGVuIGJpdHNf cGVyX3Jhd19zYW1wbGUgaXMgbW9yZSB0aGFuIDgsIEdCUiBwbGFuZXMgd2hlcmUgdXNlZCBh cyBCR1IgcGxhbmVzIGR1cmluZyBlbmNvZGluZyB0aGVuIGRlY29kaW5nIGluIGFsbCBrbm93 biBpbXBsZW1lbnRhdGlvbnMgb2YgRkZWMSBiaXRzdHJlYW0uIE5vdGUgdGhhdCB3aGVuIHRo ZSBpc3N1ZSBpcyBkaXNjb3ZlcmVkLCB0aGUgb25seSBjb25maWd1cmF0aW9ucyBvZiBhbGwg a25vd24gaW1wbGVtZW50YXRpb25zIGJlaW5nIGltcGFjdGVkIGFyZSB3aXRoIGJpdHNfcGVy X3Jhd19zYW1wbGUgb2YgOSwgMTAsIDEyLCAxNCwgYnV0IGl0IGlzIHN1Z2dlc3RlZCB0byBz aW1wbGlmeSB0aGUgY2hlY2sgd2l0aCBhbGwgYmV0d2VlbiA5IGFuZCAxNC4gSW4gdGhlIG1l YW53aGlsZSwgMTYtYml0IEpQRUcyMDAwLVJDVCBjb2xvciBzcGFjZSB3YXMgaW1wbGVtZW50 ZWQgd2l0aG91dCB0aGlzIGlzc3VlIGluIG9uZSBpbXBsZW1lbnRhdGlvbiBhbmQgdmFsaWRh dGVkIGJ5IG9uZSBjb25mb3JtYW5jZSBjaGVja2VyLiBJdCBpcyBleHBlY3RlZCAodG8gYmUg Y29uZmlybWVkKSB0byByZW1vdmUgdGhpcyBleGNlcHRpb24gZm9yIHRoZSB0cmFuc2Zvcm0g aW4gdGhlIG5leHQgdmVyc2lvbiBvZiB0aGUgYml0c3RyZWFtLgorCiBbQCFJU08uMTU0NDQt MS4yMDE2XQogCiBBbiBGRlYxIGZyYW1lIHVzaW5nIEpQRUcyMDAwLVJDVCBNVVNUIHVzZSBv bmUgb2YgdGhlIGZvbGxvd2luZyBhcnJhbmdlbWVudHM6Ci0tIAoyLjcuMC53aW5kb3dzLjEK Cg== --------------2507018178B3B6684296C10F-- From nobody Tue Apr 11 12:51:09 2017 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 CCB2212EBA1 for ; Tue, 11 Apr 2017 12:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=unavailable 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 szaKzqeULioz for ; Tue, 11 Apr 2017 12:51:07 -0700 (PDT) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BD2A12F251 for ; Tue, 11 Apr 2017 12:44:34 -0700 (PDT) Received: from eris.local (dynamic-adsl-84-221-238-148.clienti.tiscali.it [84.221.238.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 1D77534167D for ; Tue, 11 Apr 2017 19:44:32 +0000 (UTC) To: cellar@ietf.org References: From: Luca Barbato Message-ID: <5e4d0a07-a668-50cd-818b-4dba68701a3a@libav.org> Date: Tue, 11 Apr 2017 21:44:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] FFV1 JPEG2000-RCT not really as described for bit depth 9 to 15? With patch 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: Tue, 11 Apr 2017 19:51:08 -0000 On 11/04/2017 20:57, Jerome Martinez wrote: > - as for the bug in the context computing, I suggest to remove this bug > in the next incompatible version (version 4) so we will have a version 4 > with a more coherent specification (identical formulas whatever is the > bit depth). Sounds good, I would suggest to make sure version 4 doesn't have anything new but just remove all the quirks so it is a little more regular. lu From nobody Tue Apr 11 13:09:05 2017 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 8E3361294B2 for ; Tue, 11 Apr 2017 13:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 7ZjGzSlpm-rp for ; Tue, 11 Apr 2017 13:09:01 -0700 (PDT) Received: from 5.mo68.mail-out.ovh.net (5.mo68.mail-out.ovh.net [46.105.62.179]) (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 4850D131446 for ; Tue, 11 Apr 2017 13:09:00 -0700 (PDT) Received: from player711.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 17C434A54C for ; Tue, 11 Apr 2017 22:08:58 +0200 (CEST) Received: from [192.168.2.101] (p5DDB4468.dip0.t-ipconnect.de [93.219.68.104]) (Authenticated sender: jerome@mediaarea.net) by player711.ha.ovh.net (Postfix) with ESMTPSA id A78B1380085 for ; Tue, 11 Apr 2017 22:08:58 +0200 (CEST) To: Codec Encoding for LossLess Archiving and Realtime transmission References: <5e4d0a07-a668-50cd-818b-4dba68701a3a@libav.org> From: Jerome Martinez Message-ID: <69528eed-f087-e342-1ede-a48031a8cf02@mediaarea.net> Date: Tue, 11 Apr 2017 22:08:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5e4d0a07-a668-50cd-818b-4dba68701a3a@libav.org> Content-Type: multipart/mixed; boundary="------------0F6206489B25A2809E1C4540" X-Ovh-Tracer-Id: 4024529217627754641 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeliedrudeggddugeefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] FFV1 JPEG2000-RCT not really as described for bit depth 9 to 15? With patch 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: Tue, 11 Apr 2017 20:09:03 -0000 This is a multi-part message in MIME format. --------------0F6206489B25A2809E1C4540 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 11/04/2017 à 21:44, Luca Barbato a écrit : > On 11/04/2017 20:57, Jerome Martinez wrote: >> - as for the bug in the context computing, I suggest to remove this bug >> in the next incompatible version (version 4) so we will have a version 4 >> with a more coherent specification (identical formulas whatever is the >> bit depth). > Sounds good, I would suggest to make sure version 4 doesn't have > anything new but just remove all the quirks so it is a little more regular. I think that having a version bump only for removal of all the quirks is not necessary, we can have both quirks removed and new features in the same version, the version number being for incompatibility info for decoder. BTW, the patch I sent was an outdated one, attached is the one I wanted to send. --------------0F6206489B25A2809E1C4540 Content-Type: text/plain; charset=UTF-8; name="0001-JPEG2000-RCT-formula-update.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-JPEG2000-RCT-formula-update.patch" >From 071a9277035a64d93966db7273490699a65f5900 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= Date: Tue, 11 Apr 2017 18:43:58 +0200 Subject: [PATCH] JPEG2000-RCT formula update In order to be compatible with files in the wild --- ffv1.md | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/ffv1.md b/ffv1.md index 0af341b..f55ebe9 100644 --- a/ffv1.md +++ b/ffv1.md @@ -272,6 +272,41 @@ RFC:``` RFC:b=Cb+g RFC:``` +Exception for the reversible conversions between YCbCr and RGB: +if bits_per_raw_sample is between 9 and 15 inclusive, the following reversible conversions between YCbCr and RGB MUST be used instead of the ones above: + +PDF:$$Cb=g-b$$ +RFC:``` +RFC:Cb=g-b +RFC:``` + +PDF:$$Cr=r-b$$ +RFC:``` +RFC:Cr=r-b +RFC:``` + +PDF:$$Y=b+(Cb+Cr)>>2$$ +RFC:``` +RFC:Y=b+(Cb+Cr)>>2 +RFC:``` + +PDF:$$b=Y-(Cb+Cr)>>2$$ +RFC:``` +RFC:b=Y-(Cb+Cr)>>2 +RFC:``` + +PDF:$$r=Cr+b$$ +RFC:``` +RFC:r=Cr+b +RFC:``` + +PDF:$$g=Cb+b$$ +RFC:``` +RFC:g=Cb+b +RFC:``` + +Background: At the time of this writing, in all known implementations of FFV1 bitstream, when bits_per_raw_sample was between 9 and 15 inclusive, GBR planes were used as BGR planes during both encoding and decoding. In the meanwhile, 16-bit JPEG2000-RCT color space was implemented without this issue in one implementation and validated by one conformance checker. It is expected (to be confirmed) to remove this exception for the transform in the next version of the bitstream. + [@!ISO.15444-1.2016] An FFV1 frame using JPEG2000-RCT MUST use one of the following arrangements: -- 2.7.0.windows.1 --------------0F6206489B25A2809E1C4540-- From nobody Wed Apr 12 09:10:35 2017 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 E3DC9128DF6 for ; Wed, 12 Apr 2017 09:10:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADgyjbpetX3T for ; Wed, 12 Apr 2017 09:10:32 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9495312EA74 for ; Wed, 12 Apr 2017 09:10:32 -0700 (PDT) Received: from [146.96.19.240] (port=29736 helo=[10.10.201.10]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cyKql-0040Su-0P; Wed, 12 Apr 2017 12:10:31 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dave Rice In-Reply-To: <69528eed-f087-e342-1ede-a48031a8cf02@mediaarea.net> Date: Wed, 12 Apr 2017 12:10:29 -0400 Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Transfer-Encoding: quoted-printable Message-Id: <18F53830-FF50-490F-BB4D-DE0A33A6BE47@dericed.com> References: <5e4d0a07-a668-50cd-818b-4dba68701a3a@libav.org> <69528eed-f087-e342-1ede-a48031a8cf02@mediaarea.net> To: Jerome Martinez X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] FFV1 JPEG2000-RCT not really as described for bit depth 9 to 15? With patch 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, 12 Apr 2017 16:10:34 -0000 > On Apr 11, 2017, at 4:08 PM, Jerome Martinez = wrote: >=20 > Le 11/04/2017 =C3=A0 21:44, Luca Barbato a =C3=A9crit : >> On 11/04/2017 20:57, Jerome Martinez wrote: >>> - as for the bug in the context computing, I suggest to remove this = bug >>> in the next incompatible version (version 4) so we will have a = version 4 >>> with a more coherent specification (identical formulas whatever is = the >>> bit depth). >> Sounds good, I would suggest to make sure version 4 doesn't have >> anything new but just remove all the quirks so it is a little more = regular. >=20 > I think that having a version bump only for removal of all the quirks = is not necessary, we can have both quirks removed and new features in = the same version, the version number being for incompatibility info for = decoder. >=20 > BTW, the patch I sent was an outdated one, attached is the one I = wanted to send. > = <0001-JPEG2000-RCT-formula-update.patch>__________________________________= _____________ Minor wording suggestions: (use the same terminology as the intro to the RCT formulae) "the following reversible conversions" -> "the following formulae for = reversible conversions" (could be more specific about the next version) "in the next version of the bitstream" -> "in the first stable variant = of version 4 of the bitstream" Other than that, LGTM, Dave= From nobody Thu Apr 13 01:01:36 2017 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 4DAE612EC98 for ; Thu, 13 Apr 2017 01:01:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 S8hNjBzBJA0T for ; Thu, 13 Apr 2017 01:01:29 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B01DF12ECED for ; Thu, 13 Apr 2017 01:01:29 -0700 (PDT) Received: from [10.0.0.11] (1360030002.d-dsl.at [::ffff:81.16.105.50]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Thu, 13 Apr 2017 10:01:26 +0200 id 0000000000000080.0000000058EF3056.000047F5 Message-ID: <58EF3056.1050504@das-werkstatt.com> Date: Thu, 13 Apr 2017 10:01:26 +0200 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Codec Encoding for LossLess Archiving and Realtime transmission References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] FFV1 JPEG2000-RCT not really as described for bit depth 9 to 15? With patch 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, 13 Apr 2017 08:01:32 -0000 On 04/11/2017 08:57 PM, Jerome Martinez wrote: > If I am correct, I suggest the attached patch. > In the details: > - for bit depth from 9 to 15, I suggest to support the "bug" for > hypothetical bit depths of 11, 13, and 15 too so we have a test >=9 && > <=15 instead of a list of values. We have this exception about bit > depths 9 to 15 in order to support files already in the wild. > - as for the bug in the context computing, I suggest to remove this > bug in the next incompatible version (version 4) so we will have a > version 4 with a more coherent specification (identical formulas > whatever is the bit depth). Summing it up to make sure I understand you correctly: * This means that the current FFV1 sourcecode uses a different order of RGB values below 8bpc than >8bits? * Your suggestion is to keep this behavior as-is (for backwards compatibility) and apply the coherent RGB order in future FFV1 versions? Right? :) Regards, Pb From nobody Thu Apr 13 01:08:45 2017 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 5CF1A13010C for ; Thu, 13 Apr 2017 01:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8roSfYuaslky for ; Thu, 13 Apr 2017 01:08:37 -0700 (PDT) Received: from 2.mo68.mail-out.ovh.net (2.mo68.mail-out.ovh.net [46.105.52.162]) (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 50A6F130133 for ; Thu, 13 Apr 2017 01:08:37 -0700 (PDT) Received: from player711.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 75CB84AAFB for ; Thu, 13 Apr 2017 10:08:35 +0200 (CEST) Received: from [192.168.2.101] (p5DDB4468.dip0.t-ipconnect.de [93.219.68.104]) (Authenticated sender: jerome@mediaarea.net) by player711.ha.ovh.net (Postfix) with ESMTPSA id 1441E38008F for ; Thu, 13 Apr 2017 10:08:34 +0200 (CEST) To: cellar@ietf.org References: <58EF3056.1050504@das-werkstatt.com> From: Jerome Martinez Message-ID: <706a2548-5ef7-c4c3-4a6a-f55bbb34ad26@mediaarea.net> Date: Thu, 13 Apr 2017 10:08:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <58EF3056.1050504@das-werkstatt.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 3603724130898153617 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeliedrudejgddufedvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] FFV1 JPEG2000-RCT not really as described for bit depth 9 to 15? With patch 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, 13 Apr 2017 08:08:44 -0000 Le 13/04/2017 à 10:01, Peter B. a écrit : > On 04/11/2017 08:57 PM, Jerome Martinez wrote: >> If I am correct, I suggest the attached patch. >> In the details: >> - for bit depth from 9 to 15, I suggest to support the "bug" for >> hypothetical bit depths of 11, 13, and 15 too so we have a test >=9 && >> <=15 instead of a list of values. We have this exception about bit >> depths 9 to 15 in order to support files already in the wild. >> - as for the bug in the context computing, I suggest to remove this >> bug in the next incompatible version (version 4) so we will have a >> version 4 with a more coherent specification (identical formulas >> whatever is the bit depth). > Summing it up to make sure I understand you correctly: > > * This means that the current FFV1 sourcecode uses a different order > of RGB values below 8bpc than >8bits? RGB is not stored as is, it is converted (lossless) to YCbCr So a different formula i.e. Y = (R + G + 2B) / 4 instead of Y = (R + 2G + B) / 4 and similar difference for Cb and Cr. (again, this is what I understand, don't hesitate to counter-argument if someone thinks this is wrong) > * Your suggestion is to keep this behavior as-is (for backwards > compatibility) and apply the coherent RGB order in future FFV1 versions? Right. > > Right? > :) > > From nobody Thu Apr 13 03:30:12 2017 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 2397F1314D1 for ; Thu, 13 Apr 2017 03:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 vCBX55O8uTIP for ; Thu, 13 Apr 2017 03:30:08 -0700 (PDT) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [IPv6:2001:4b98:c:538::199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBA991314DA for ; Thu, 13 Apr 2017 03:30:03 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by relay9-d.mail.gandi.net (Postfix) with ESMTPS id 5F2B740758 for ; Thu, 13 Apr 2017 12:30:01 +0200 (CEST) Received: from mfilter35-d.gandi.net (mfilter35-d.gandi.net [217.70.178.166]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id D9BC7FB8DA for ; Thu, 13 Apr 2017 12:30:01 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter35-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter35-d.gandi.net (mfilter35-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id XAq3Lzj8fENg for ; Thu, 13 Apr 2017 12:30:00 +0200 (CEST) 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 relay6-d.mail.gandi.net (Postfix) with ESMTPSA id D0A32FB8C8 for ; Thu, 13 Apr 2017 12:29:59 +0200 (CEST) Date: Thu, 13 Apr 2017 12:29:29 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20170413102929.GH4730@nb4> References: <58EF3056.1050504@das-werkstatt.com> <706a2548-5ef7-c4c3-4a6a-f55bbb34ad26@mediaarea.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7BtE0xW96okrVgVt" Content-Disposition: inline In-Reply-To: <706a2548-5ef7-c4c3-4a6a-f55bbb34ad26@mediaarea.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] FFV1 JPEG2000-RCT not really as described for bit depth 9 to 15? With patch 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, 13 Apr 2017 10:30:10 -0000 --7BtE0xW96okrVgVt Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 13, 2017 at 10:08:34AM +0200, Jerome Martinez wrote: > Le 13/04/2017 =E0 10:01, Peter B. a =E9crit : > >On 04/11/2017 08:57 PM, Jerome Martinez wrote: > >>If I am correct, I suggest the attached patch. > >>In the details: > >>- for bit depth from 9 to 15, I suggest to support the "bug" for > >>hypothetical bit depths of 11, 13, and 15 too so we have a test >=3D9 && > >><=3D15 instead of a list of values. We have this exception about bit > >>depths 9 to 15 in order to support files already in the wild. > >>- as for the bug in the context computing, I suggest to remove this > >>bug in the next incompatible version (version 4) so we will have a > >>version 4 with a more coherent specification (identical formulas > >>whatever is the bit depth). > >Summing it up to make sure I understand you correctly: > > > > * This means that the current FFV1 sourcecode uses a different order > >of RGB values below 8bpc than >8bits? >=20 > RGB is not stored as is, it is converted (lossless) to YCbCr > So a different formula i.e. Y =3D (R + G + 2B) / 4 instead of Y =3D (R + > 2G + B) / 4 and similar difference for Cb and Cr. > (again, this is what I understand, don't hesitate to > counter-argument if someone thinks this is wrong) >=20 > > * Your suggestion is to keep this behavior as-is (for backwards > >compatibility) and apply the coherent RGB order in future FFV1 versions? >=20 > Right. I think we should take the oppertunity and improve the color decorrelation transform. Better decorrelation and compression should be achievable with probably minor complexity If people agree, ideas, papers and comparissions in that direction would be interresting ... the suggested patch LGTM thanks [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn --7BtE0xW96okrVgVt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAljvUwkACgkQYR7HhwQLD6t1PQCeNI5+XL7D0dclIgJcC/O9+Ea3 ijYAn0SdXgJJwktweHpKMwupCR1jZBmO =u9mK -----END PGP SIGNATURE----- --7BtE0xW96okrVgVt-- From nobody Thu Apr 13 03:36:32 2017 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 C7A661314D3 for ; Thu, 13 Apr 2017 03:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Daxs-iaXwOHF for ; Thu, 13 Apr 2017 03:36:28 -0700 (PDT) Received: from 9.mo68.mail-out.ovh.net (9.mo68.mail-out.ovh.net [46.105.78.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDBC12EB7B for ; Thu, 13 Apr 2017 03:36:21 -0700 (PDT) Received: from player711.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 7B76D4BB4A for ; Thu, 13 Apr 2017 12:36:19 +0200 (CEST) Received: from [192.168.2.101] (p5DDB4468.dip0.t-ipconnect.de [93.219.68.104]) (Authenticated sender: jerome@mediaarea.net) by player711.ha.ovh.net (Postfix) with ESMTPSA id 110393800C9 for ; Thu, 13 Apr 2017 12:36:18 +0200 (CEST) To: cellar@ietf.org References: <58EF3056.1050504@das-werkstatt.com> <706a2548-5ef7-c4c3-4a6a-f55bbb34ad26@mediaarea.net> <20170413102929.GH4730@nb4> From: Jerome Martinez Message-ID: <31befe74-37ad-8208-4d1d-29c2779da0fe@mediaarea.net> Date: Thu, 13 Apr 2017 12:36:18 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170413102929.GH4730@nb4> Content-Type: multipart/mixed; boundary="------------F253BCC751F2A3A92BC42714" X-Ovh-Tracer-Id: 6098718321013035153 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeliedrudekgdeftdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] FFV1 JPEG2000-RCT not really as described for bit depth 9 to 15? With patch 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, 13 Apr 2017 10:36:31 -0000 This is a multi-part message in MIME format. --------------F253BCC751F2A3A92BC42714 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 13/04/2017 à 12:29, Michael Niedermayer a écrit : > On Thu, Apr 13, 2017 at 10:08:34AM +0200, Jerome Martinez wrote: >> Le 13/04/2017 à 10:01, Peter B. a écrit : >>> On 04/11/2017 08:57 PM, Jerome Martinez wrote: >>>> If I am correct, I suggest the attached patch. >>>> In the details: >>>> - for bit depth from 9 to 15, I suggest to support the "bug" for >>>> hypothetical bit depths of 11, 13, and 15 too so we have a test >=9 && >>>> <=15 instead of a list of values. We have this exception about bit >>>> depths 9 to 15 in order to support files already in the wild. >>>> - as for the bug in the context computing, I suggest to remove this >>>> bug in the next incompatible version (version 4) so we will have a >>>> version 4 with a more coherent specification (identical formulas >>>> whatever is the bit depth). >>> Summing it up to make sure I understand you correctly: >>> >>> * This means that the current FFV1 sourcecode uses a different order >>> of RGB values below 8bpc than >8bits? >> RGB is not stored as is, it is converted (lossless) to YCbCr >> So a different formula i.e. Y = (R + G + 2B) / 4 instead of Y = (R + >> 2G + B) / 4 and similar difference for Cb and Cr. >> (again, this is what I understand, don't hesitate to >> counter-argument if someone thinks this is wrong) >> >>> * Your suggestion is to keep this behavior as-is (for backwards >>> compatibility) and apply the coherent RGB order in future FFV1 versions? >> Right. > I think we should take the oppertunity and improve the color > decorrelation transform. > Better decorrelation and compression should be achievable with probably > minor complexity > > If people agree, ideas, papers and comparissions in that direction > would be interresting ... Beyond my skills :p > > the suggested patch LGTM updated one, with first change proposal from Dave. I am not in favor of the second change proposal as it is a copy/paste from the first exception text, I suggest to have this change in a more global patch related to wording of exceptions. --------------F253BCC751F2A3A92BC42714 Content-Type: text/plain; charset=UTF-8; name="0001-JPEG2000-RCT-formula-update.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-JPEG2000-RCT-formula-update.patch" >From 2df09d4de2b00003ede06367e2ed60cead490728 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= Date: Tue, 11 Apr 2017 18:43:58 +0200 Subject: [PATCH] JPEG2000-RCT formula update In order to be compatible with files in the wild --- ffv1.md | 35 +++++++++++++++++++++++++++++++++++ 1 file changed, 35 insertions(+) diff --git a/ffv1.md b/ffv1.md index 0af341b..706f340 100644 --- a/ffv1.md +++ b/ffv1.md @@ -272,6 +272,41 @@ RFC:``` RFC:b=Cb+g RFC:``` +Exception for the reversible conversions between YCbCr and RGB: +if bits_per_raw_sample is between 9 and 15 inclusive, the following formulae for reversible conversions between YCbCr and RGB MUST be used instead of the ones above: + +PDF:$$Cb=g-b$$ +RFC:``` +RFC:Cb=g-b +RFC:``` + +PDF:$$Cr=r-b$$ +RFC:``` +RFC:Cr=r-b +RFC:``` + +PDF:$$Y=b+(Cb+Cr)>>2$$ +RFC:``` +RFC:Y=b+(Cb+Cr)>>2 +RFC:``` + +PDF:$$b=Y-(Cb+Cr)>>2$$ +RFC:``` +RFC:b=Y-(Cb+Cr)>>2 +RFC:``` + +PDF:$$r=Cr+b$$ +RFC:``` +RFC:r=Cr+b +RFC:``` + +PDF:$$g=Cb+b$$ +RFC:``` +RFC:g=Cb+b +RFC:``` + +Background: At the time of this writing, in all known implementations of FFV1 bitstream, when bits_per_raw_sample was between 9 and 15 inclusive, GBR planes were used as BGR planes during both encoding and decoding. In the meanwhile, 16-bit JPEG2000-RCT color space was implemented without this issue in one implementation and validated by one conformance checker. It is expected (to be confirmed) to remove this exception for the transform in the next version of the bitstream. + [@!ISO.15444-1.2016] An FFV1 frame using JPEG2000-RCT MUST use one of the following arrangements: -- 2.7.0.windows.1 --------------F253BCC751F2A3A92BC42714-- From nobody Thu Apr 13 04:12:57 2017 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 10C93127B31 for ; Thu, 13 Apr 2017 04:12:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.001 X-Spam-Level: X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mp5dGoPSBP7e for ; Thu, 13 Apr 2017 04:12:54 -0700 (PDT) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (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 B9C3C12E05D for ; Thu, 13 Apr 2017 04:12:54 -0700 (PDT) Received: from eris.local (dynamic-adsl-84-221-238-148.clienti.tiscali.it [84.221.238.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 604953406B7 for ; Thu, 13 Apr 2017 11:12:53 +0000 (UTC) To: cellar@ietf.org References: <58EF3056.1050504@das-werkstatt.com> <706a2548-5ef7-c4c3-4a6a-f55bbb34ad26@mediaarea.net> <20170413102929.GH4730@nb4> From: Luca Barbato Message-ID: Date: Thu, 13 Apr 2017 13:12:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.0 MIME-Version: 1.0 In-Reply-To: <20170413102929.GH4730@nb4> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] FFV1 JPEG2000-RCT not really as described for bit depth 9 to 15? With patch 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, 13 Apr 2017 11:12:56 -0000 On 13/04/2017 12:29, Michael Niedermayer wrote: > I think we should take the oppertunity and improve the color > decorrelation transform. > Better decorrelation and compression should be achievable with probably > minor complexity I would not conflate the two in the same iteration, there are loads of interesting techniques we could consider for an evolution (daala's ones might be the quickest to import and test IMHO), but would take more time than just amend a small quirk and go forward in having a good base standardized. lu From nobody Thu Apr 13 06:37:58 2017 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 733DC12946F for ; Thu, 13 Apr 2017 06:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 E5lTt15KCJGT for ; Thu, 13 Apr 2017 06:37:54 -0700 (PDT) Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [IPv6:2001:4b98:c:538::199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FDC129482 for ; Thu, 13 Apr 2017 06:37:53 -0700 (PDT) Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by relay9-d.mail.gandi.net (Postfix) with ESMTPS id B119E40751 for ; Thu, 13 Apr 2017 15:37:51 +0200 (CEST) Received: from mfilter14-d.gandi.net (mfilter14-d.gandi.net [217.70.178.142]) by relay6-d.mail.gandi.net (Postfix) with ESMTP id 34C92FB8D6 for ; Thu, 13 Apr 2017 15:37:51 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter14-d.gandi.net Received: from relay6-d.mail.gandi.net ([IPv6:::ffff:217.70.183.198]) by mfilter14-d.gandi.net (mfilter14-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id 8CX__0wYb_uu for ; Thu, 13 Apr 2017 15:37:49 +0200 (CEST) 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 relay6-d.mail.gandi.net (Postfix) with ESMTPSA id A0E9CFB8C8 for ; Thu, 13 Apr 2017 15:37:47 +0200 (CEST) Date: Thu, 13 Apr 2017 15:37:17 +0200 From: Michael Niedermayer To: cellar@ietf.org Message-ID: <20170413133717.GI4730@nb4> References: <58EF3056.1050504@das-werkstatt.com> <706a2548-5ef7-c4c3-4a6a-f55bbb34ad26@mediaarea.net> <20170413102929.GH4730@nb4> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qx89ETaB+CVBQ6X0" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Cellar] FFV1 JPEG2000-RCT not really as described for bit depth 9 to 15? With patch 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, 13 Apr 2017 13:37:56 -0000 --Qx89ETaB+CVBQ6X0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Apr 13, 2017 at 01:12:49PM +0200, Luca Barbato wrote: > On 13/04/2017 12:29, Michael Niedermayer wrote: > > I think we should take the oppertunity and improve the color > > decorrelation transform. > > Better decorrelation and compression should be achievable with probably > > minor complexity >=20 > I would not conflate the two in the same iteration, there are loads of > interesting techniques we could consider for an evolution (daala's ones > might be the quickest to import and test IMHO), but would take more time > than just amend a small quirk and go forward in having a good base > standardized. Everything we add to the standard adds burden to people implementing it. I think its better if we have 2 instead of 3 variants that need to be supported [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact --Qx89ETaB+CVBQ6X0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAljvfw0ACgkQYR7HhwQLD6thHQCZAabfJQeOvMm2JBh8T6xl6SQF SLYAnjGAmItu3ifzgUetKViQiXHUHV8k =3CKZ -----END PGP SIGNATURE----- --Qx89ETaB+CVBQ6X0-- From nobody Thu Apr 13 07:00:37 2017 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 7CFEA12945B for ; Thu, 13 Apr 2017 07:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.322 X-Spam-Level: X-Spam-Status: No, score=-2.322 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 0PVu4WqOKNVc for ; Thu, 13 Apr 2017 07:00:28 -0700 (PDT) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06DEB124D68 for ; Thu, 13 Apr 2017 07:00:27 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v3DE0PYx007844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 13 Apr 2017 16:00:25 +0200 Received: from Castor.local (22.233.197.178.dynamic.wless.lssmb00p-cgnat.res.cust.swisscom.ch [178.197.233.22]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v3DE0OmG039507 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 13 Apr 2017 16:00:25 +0200 Date: Thu, 13 Apr 2017 16:00:24 +0200 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] FFV1 JPEG2000-RCT not really as described for bit depth 9 to 15? With patch 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, 13 Apr 2017 14:00:35 -0000 Michael Niedermayer wrote: >I think we should take the oppertunity and improve the color >decorrelation transform. >Better decorrelation and compression should be achievable with >probably minor complexity I strongly second this. >If people agree, ideas, papers and comparissions in that >direction would be interresting ... I will check sometime after Easter if and what I can contribute. Best regards, Reto From nobody Thu Apr 13 10:55:44 2017 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 27E8E12EAF3 for ; Thu, 13 Apr 2017 10:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 i7gYeSAuadr1 for ; Thu, 13 Apr 2017 10:55:41 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59BB12EACF for ; Thu, 13 Apr 2017 10:55:40 -0700 (PDT) Received: from [146.96.19.240] (port=25079 helo=[10.10.201.10]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cyiy2-00223S-K3; Thu, 13 Apr 2017 13:55:39 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dave Rice In-Reply-To: <58EF3056.1050504@das-werkstatt.com> Date: Thu, 13 Apr 2017 13:55:37 -0400 Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Transfer-Encoding: quoted-printable Message-Id: <3487EC8D-EA18-400D-920B-FBEC6EA5F69F@dericed.com> References: <58EF3056.1050504@das-werkstatt.com> To: Peter Bubestinger X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] FFV1 JPEG2000-RCT not really as described for bit depth 9 to 15? With patch 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, 13 Apr 2017 17:55:43 -0000 > On Apr 13, 2017, at 4:01 AM, Peter B. wrote: >=20 > On 04/11/2017 08:57 PM, Jerome Martinez wrote: >> If I am correct, I suggest the attached patch. >> In the details: >> - for bit depth from 9 to 15, I suggest to support the "bug" for >> hypothetical bit depths of 11, 13, and 15 too so we have a test >=3D9 = && >> <=3D15 instead of a list of values. We have this exception about bit >> depths 9 to 15 in order to support files already in the wild. >> - as for the bug in the context computing, I suggest to remove this >> bug in the next incompatible version (version 4) so we will have a >> version 4 with a more coherent specification (identical formulas >> whatever is the bit depth). >=20 > Summing it up to make sure I understand you correctly: >=20 > * This means that the current FFV1 sourcecode uses a different order > of RGB values below 8bpc than >8bits? AFAIK there has never been an FFV1 implementation that supported <8 bit = RGB, thus for instance a Road Pizza encoding could not be encoded = losslessly in FFV1. This issue is specific to bits depths from 9-15 = inclusive. > * Your suggestion is to keep this behavior as-is (for backwards > compatibility) and apply the coherent RGB order in future FFV1 = versions? >=20 > Right? > :) >=20 >=20 > Regards, > Pb >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Thu Apr 13 17:58:43 2017 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 809481286AB for ; Thu, 13 Apr 2017 17:58:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149213152152.28281.3511109686721278801.idtracker@ietfa.amsl.com> Date: Thu, 13 Apr 2017 17:58:41 -0700 From: IETF Secretariat Archived-At: Subject: [Cellar] Milestones changed for cellar WG X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 00:58:41 -0000 Changed milestone "Submit specification for EBML to IESG (Standards Track)", set due date to April 2017 from June 2016. Changed milestone "Submit informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication", set due date to April 2017 from July 2016, added draft-niedermayer-cellar-ffv1 to milestone. Changed milestone "Submit informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication", set due date to July 2017 from June 2016. Changed milestone "Submit specification for FFV1 video codec version 4 to IESG (Standards Track)", set due date to July 2017 from September 2016. Changed milestone "Submit specification for Matroska container format version 4 to IESG (Standards Track)", set due date to September 2017 from July 2016, added draft-lhomme-cellar-matroska to milestone. Changed milestone "Submit specification for FLAC audio codec to IESG (Standards Track)", set due date to December 2017 from December 2016. URL: https://datatracker.ietf.org/wg/cellar/about/ From nobody Thu Apr 13 18:15:10 2017 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B6412947D; Thu, 13 Apr 2017 18:15:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149213250939.16154.3098627789333185829.idtracker@ietfa.amsl.com> Date: Thu, 13 Apr 2017 18:15:09 -0700 Archived-At: Subject: [Cellar] The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state "Call For Adoption By WG Issued" X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Apr 2017 01:15:09 -0000 The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state Call For Adoption By WG Issued (entered by Tessa Fallon) The document is available at https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1/ Comment: Picking this up from earlier this spring. This is a call to adopt the document draft-niedermayer-cellar-ffv1 for FF Video Codec 1 as a working group document. Comments and feedback welcome. From nobody Fri Apr 14 07:34:23 2017 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 6DEE71300BC for ; Fri, 14 Apr 2017 07:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 5DWZlZdtVzJY for ; Fri, 14 Apr 2017 07:34:18 -0700 (PDT) Received: from 10.mo68.mail-out.ovh.net (10.mo68.mail-out.ovh.net [46.105.79.203]) (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 C90EA130019 for ; Fri, 14 Apr 2017 07:34:17 -0700 (PDT) Received: from player711.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 6BAD24C2A4 for ; Fri, 14 Apr 2017 16:34:15 +0200 (CEST) Received: from [192.168.2.101] (p5DDB4468.dip0.t-ipconnect.de [93.219.68.104]) (Authenticated sender: jerome@mediaarea.net) by player711.ha.ovh.net (Postfix) with ESMTPSA id DF854380084 for ; Fri, 14 Apr 2017 16:34:14 +0200 (CEST) From: Jerome Martinez To: Codec Encoding for LossLess Archiving and Realtime transmission Message-ID: Date: Fri, 14 Apr 2017 16:34:13 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------02233FB064E1206BDA1E572B" X-Ovh-Tracer-Id: 15989749006268502161 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeliedrvddtgdejkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: [Cellar] [PATCH FFV1] Quantization table sets and contexts 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: Fri, 14 Apr 2017 14:34:21 -0000 This is a multi-part message in MIME format. --------------02233FB064E1206BDA1E572B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I had difficulties to understand FFV1 quantization table sets, quantization tables and context, with some items not defined (e.g. abs() of a table). I propose the following patch: - I reuse "quantization table set" name when relevant (this words were already present, I put them everywhere) - I added info about which quantization table set is used (or did I miss it somewhere else?) - "Table_" replaced by quant_tables[i][j][k] as it is already used elsewhere in the spec - Looks like the scale is indicated twice (in "Quantization Tables" chapter and in "context" chapter), I removed one (the one in "context" chapter) - "The second half doesn’t need to be stored as it is identical to the first with flipped sign." is misleading from my point of view as values are mirrored, the first value of this second half is a copy of the last value of the first half so the the first value is discarded during the "identical" process, I removed the sentence and added a reference to the pseudo code. Is it intended that it is not an exact mirror? (I have no idea about maths behind that, I just see an incoherency between text and code) - I changed the type of the length of "number of equal entries -1" from signed to unsigned, looks like this is unsigned in reality - removed MAX_CONTEXT_INPUTS as this constant is hard coded to "5" everywhere in the spec and depends of design choices about the context - some formatting A Pull request is open on GitHub: https://github.com/FFmpeg/FFV1/pull/56 Jérôme --------------02233FB064E1206BDA1E572B Content-Type: text/plain; charset=UTF-8; name="0001-Improvement-of-context-and-quantization-tables-parag.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename*0="0001-Improvement-of-context-and-quantization-tables-parag.pa"; filename*1="tch" RnJvbSA1ODIzYTcyMDA1NGM4OTQ1MDUyZTkxYmQ5N2I5ZTAyMmFiODk0ZDIwIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/Sj1DMz1BOXI9QzM9QjRtZT0yME1h cnRpbmV6Pz0gPGplcm9tZUBtZWRpYWFyZWEubmV0PgpEYXRlOiBGcmksIDE0IEFwciAyMDE3 IDE0OjI1OjU2ICswMjAwClN1YmplY3Q6IFtQQVRDSF0gSW1wcm92ZW1lbnQgb2YgY29udGV4 dCBhbmQgcXVhbnRpemF0aW9uIHRhYmxlcyBwYXJhZ3JhcGhzCgotLS0KIGZmdjEubWQgfCA2 NyArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDQwIGluc2VydGlvbnMoKyksIDI3IGRl bGV0aW9ucygtKQoKZGlmZiAtLWdpdCBhL2ZmdjEubWQgYi9mZnYxLm1kCmluZGV4IDBhZjM0 MWIuLjgwMjExNzQgMTAwNjQ0Ci0tLSBhL2ZmdjEubWQKKysrIGIvZmZ2MS5tZApAQCAtMTkx LDYgKzE5MSw4IEBAIEJhY2tncm91bmQ6IGEgdHdvJ3MgY29tcGxlbWVudCBzaWduZWQgMTYt Yml0IHNpZ25lZCBpbnRlZ2VyIHdhcyB1c2VkIGZvciBzdG9yaW5nCiAKICMjIENvbnRleHQK IAorRm9yIHNhbXBsZXMsIGNvbXBhcmVkIHRvIHBpeGVsIFgsIG5hbWVkOgorCiBgYGAKICst LS0rLS0tKy0tLSstLS0rCiB8ICAgfCAgIHwgVCB8ICAgfApAQCAtMjAxLDI4ICsyMDMsNDEg QEAgQmFja2dyb3VuZDogYSB0d28ncyBjb21wbGVtZW50IHNpZ25lZCAxNi1iaXQgc2lnbmVk IGludGVnZXIgd2FzIHVzZWQgZm9yIHN0b3JpbmcKICstLS0rLS0tKy0tLSstLS0rCiBgYGAK IAotVGhlIHF1YW50aXplZCBzYW1wbGUgZGlmZmVyZW5jZXMgTC1sLCBsLXRsLCB0bC10LCB0 LVQsIHQtdHIgYXJlIHVzZWQgYXMgY29udGV4dDoKK1RoZSBxdWFudGl6ZWQgc2FtcGxlIGRp ZmZlcmVuY2VzIGFyZSB1c2VkIGFzIGNvbnRleHQ6CiAKLVBERjokJGNvbnRleHQ9UV97MH1b bC10bF0rXGxlZnR8UV97MH1ccmlnaHR8KFFfezF9W3RsLXRdK1xsZWZ0fFFfezF9XHJpZ2h0 fChRX3syfVt0LXRyXStcbGVmdHxRX3syfVxyaWdodHwoUV97M31bTC1sXStcbGVmdHxRX3sz fVxyaWdodHxRX3s0fVtULXRdKSkpJCQKK1BERjokJGNvbnRleHQ9UV97MH1bbC10bF0rUV97 MX1bdGwtdF0rUV97Mn1bdC10cl0rUV97M31bTC1sXStRX3s0fVtULXRdJCQKIFJGQzpgYGAK LVJGQzpjb250ZXh0ID0gICAgICAgICAgICAgIFFfMFts4oiSdGxdICsKLVJGQzogICAgICAg ICAgYWJzKFFfMCkgKiAoIFFfMVt0bOKIknRdICsKLVJGQzogICAgICAgICAgYWJzKFFfMSkg KiAoIFFfMlt04oiSdHJdICsKLVJGQzogICAgICAgICAgYWJzKFFfMikgKiAoIFFfM1tM4oiS bF0gICsKLVJGQzogICAgICAgICAgYWJzKFFfMykgKiAgIFFfNFtU4oiSdF0gICkpKQorUkZD OmNvbnRleHQgPSBRX3swfVtsIOKIkiB0bF0gKworUkZDOiAgICAgICAgICBRX3sxfVt0bCDi iJIgdF0gKworUkZDOiAgICAgICAgICBRX3syfVt0IOKIkiB0cl0gKworUkZDOiAgICAgICAg ICBRX3szfVtMIOKIkiBsXSAgKworUkZDOiAgICAgICAgICBRX3s0fVtUIOKIkiB0XQogUkZD OmBgYAogCi1JZiB0aGUgY29udGV4dCBpcyBzbWFsbGVyIHRoYW4gMCB0aGVuIC1jb250ZXh0 IGlzIHVzZWQgYW5kIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHNhbXBsZSBhbmQgaXRz IHByZWRpY3RlZCB2YWx1ZSBpcyBlbmNvZGVkIHdpdGggYSBmbGlwcGVkIHNpZ24uCitJZiBj b250ZXh0ID49IDAgdGhlbiBgY29udGV4dGAgaXMgdXNlZCBhbmQgdGhlIGRpZmZlcmVuY2Ug YmV0d2VlbiB0aGUgc2FtcGxlIGFuZCBpdHMgcHJlZGljdGVkIHZhbHVlIGlzIGVuY29kZWQg YXMgaXMsIGVsc2UgYC1jb250ZXh0YCBpcyB1c2VkIGFuZCB0aGUgZGlmZmVyZW5jZSBiZXR3 ZWVuIHRoZSBzYW1wbGUgYW5kIGl0cyBwcmVkaWN0ZWQgdmFsdWUgaXMgZW5jb2RlZCB3aXRo IGEgZmxpcHBlZCBzaWduLgogCi0jIyBRdWFudGl6YXRpb24KKyMjIFF1YW50aXphdGlvbiB0 YWJsZXMKIAotVGhlcmUgYXJlIDUgcXVhbnRpemF0aW9uIHRhYmxlcyBmb3IgdGhlIDUgc2Ft cGxlIGRpZmZlcmVuY2VzLCBib3RoIHRoZSBudW1iZXIgb2YgcXVhbnRpemF0aW9uIHN0ZXBz IGFuZCB0aGVpciBkaXN0cmlidXRpb24gYXJlIHN0b3JlZCBpbiB0aGUgYml0c3RyZWFtLiBF YWNoIHF1YW50aXphdGlvbiB0YWJsZSBoYXMgZXhhY3RseSAyNTYgZW50cmllcywgYW5kIHRo ZSA4IGxlYXN0IHNpZ25pZmljYW50IGJpdHMgb2YgdGhlIHNhbXBsZSBkaWZmZXJlbmNlIGFy ZSB1c2VkIGFzIGluZGV4OgorRm9yIGVhY2ggcXVhbnRpemF0aW9uIHRhYmxlIHNldCwgdGhl cmUgYXJlIDUgcXVhbnRpemF0aW9uIHRhYmxlcyBmb3IgdGhlIDUgc2FtcGxlIGRpZmZlcmVu Y2VzLCBib3RoIHRoZSBudW1iZXIgb2YgcXVhbnRpemF0aW9uIHN0ZXBzIGFuZCB0aGVpciBk aXN0cmlidXRpb24gYXJlIHN0b3JlZCBpbiB0aGUgYml0c3RyZWFtLiBFYWNoIHF1YW50aXph dGlvbiB0YWJsZSBoYXMgZXhhY3RseSAyNTYgZW50cmllcywgYW5kIHRoZSA4IGxlYXN0IHNp Z25pZmljYW50IGJpdHMgb2YgdGhlIHNhbXBsZSBkaWZmZXJlbmNlIGFyZSB1c2VkIGFzIGlu ZGV4OgogCi1QREY6JCRRX3tpfVthLWJdPVRhYmxlX3tpfVsoYS1iKVwmMjU1XSQkCitQREY6 JCRRX3tqfVtrXT1xdWFudF90YWJsZXNbaV1bal1ba1wmMjU1XSQkCiBSRkM6YGBgCi1SRkM6 UV97aX1bYSDiiJIgYl0gPSBUYWJsZV97aX1bKGEg4oiSIGIpJjI1NV0KK1JGQzpRX3tqfVtr XSA9IHF1YW50X3RhYmxlc1tpXVtqXVtrJjI1NV0KIFJGQzpgYGAKIAorSW4gdGhpcyBmb3Jt dWxhLCBgaWAgaXMgdGhlIHF1YW50aXphdGlvbiB0YWJsZSBzZXRzIGluZGV4IChzZWUgYmVs b3cpLgorCisjIyBRdWFudGl6YXRpb24gdGFibGUgc2V0cworCitTZXZlcmFsIHF1YW50aXph dGlvbiB0YWJsZSBzZXRzIGNhbiBiZSB1c2VkIGluIHRoZSBzYW1lIGJpdHN0cmVhbS4KKwor Rm9yIGVhY2ggcGxhbmUgb2YgZWFjaCBzbGljZSwgYSBxdWFudGl6YXRpb24gdGFibGUgc2V0 IGlzIHNlbGVjdGVkIGZyb20gYW4gaW5kZXg6CistIEZvciBZIHBsYW5lLCBgcXVhbnRfdGFi bGVfaW5kZXggWyAwIF1gIGluZGV4IGlzIHVzZWQKKy0gRm9yIENiIGFuZCBDciBwbGFuZXMs IGBxdWFudF90YWJsZV9pbmRleCBbIDEgXWAgaW5kZXggaXMgdXNlZAorLSBGb3IgQWxwaGEg cGxhbmUsIGBxdWFudF90YWJsZV9pbmRleCBbICh2ZXJzaW9uIDw9IDMgfHwgY2hyb21hX3Bs YW5lcykgPyAyIDogMSBdYCBpbmRleCBpcyB1c2VkCisKK0JhY2tncm91bmQ6IGluIGZpcnN0 IGltcGxlbWVudGF0aW9ucyBvZiBGRlYxIGJpdHN0cmVhbSwgdGhlIGluZGV4IGZvciBDYiBh bmQgQ3IgcGxhbmVzIHdhcyBzdG9yZWQgZXZlbiBpZiBpdCBpcyBub3QgdXNlZCAoY2hyb21h X3BsYW5lcyBzZXQgdG8gMCksIHRoaXMgaW5kZXggaXMga2VwdCBmb3IgdmVyc2lvbiA8PSAz IG9uIG9yZGVyIHRvIGtlZXAgY29tcGF0aWJpbGl0eSB3aXRoIGJpdHN0cmVhbXMgaW4gdGhl IHdpbGQuCisKICMjIENvbG9yc3BhY2UKIAogRkZWMSBzdXBwb3J0cyB0d28gY29sb3JzcGFj ZXM6IFlDYkNyIGFuZCBKUEVHMjAwMC1SQ1QuIEJvdGggY29sb3JzcGFjZXMgYWxsb3cgYW4g b3B0aW9uYWwgQWxwaGEgcGxhbmUgdGhhdCBjYW4gYmUgdXNlZCB0byBjb2RlIHRyYW5zcGFy ZW5jeSBkYXRhLgpAQCAtOTI0LDEwICs5MzksMTAgQEAgUGFyYW1ldGVycyggKSB7ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgaWYgKHZl cnNpb24gPj0gMykgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwK ICAgICAgICAgbnVtX2hfc2xpY2VzIC0gMSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgfCB1cgogICAgICAgICBudW1fdl9zbGljZXMgLSAxICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICB8IHVyCi0gICAgICAgIHF1YW50X3RhYmxlX2NvdW50 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgdXIKKyAgICAgICAgcXVh bnRfdGFibGVfc2V0X2NvdW50ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCB1 cgogICAgIH0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICB8Ci0gICAgZm9yKCBpID0gMDsgaSA8IHF1YW50X3RhYmxlX2NvdW50OyBp KysgKSAgICAgICAgICAgICAgICAgIHwKLSAgICAgICAgUXVhbnRpemF0aW9uVGFibGUoIGkg KSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAorICAgIGZvciggaSA9IDA7IGkg PCBxdWFudF90YWJsZV9zZXRfY291bnQ7IGkrKyApICAgICAgICAgICAgICB8CisgICAgICAg IFF1YW50aXphdGlvblRhYmxlUGVyU2V0KCBpICkgICAgICAgICAgICAgICAgICAgICAgICAg IHwKICAgICBpZiAodmVyc2lvbiA+PSAzKSB7ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgfAogICAgICAgICBmb3IoIGkgPSAwOyBpIDwgcXVhbnRfdGFibGVfY291 bnQ7IGkrKyApIHsgICAgICAgICAgICB8CiAgICAgICAgICAgICBzdGF0ZXNfY29kZWQgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwgYnIKQEAgLTEwNjEsOSArMTA3 Niw5IEBAIEluZmVycmVkIHRvIGJlIDEgaWYgbm90IHByZXNlbnQuCiBgbnVtX3Zfc2xpY2Vz YCBpbmRpY2F0ZXMgdGhlIG51bWJlciBvZiB2ZXJ0aWNhbCBlbGVtZW50cyBvZiB0aGUgc2xp Y2UgcmFzdGVyLgogSW5mZXJyZWQgdG8gYmUgMSBpZiBub3QgcHJlc2VudC4KIAotIyMjIHF1 YW50X3RhYmxlX2NvdW50CisjIyMgcXVhbnRfdGFibGVfc2V0X2NvdW50CiAKLWBxdWFudF90 YWJsZV9jb3VudGAgaW5kaWNhdGVzIHRoZSBudW1iZXIgb2YgcXVhbnRpemF0aW9uIHRhYmxl IHNldHMuCitgcXVhbnRfdGFibGVfc2V0X2NvdW50YCBpbmRpY2F0ZXMgdGhlIG51bWJlciBv ZiBxdWFudGl6YXRpb24gdGFibGUgc2V0cy4KIEluZmVycmVkIHRvIGJlIDEgaWYgbm90IHBy ZXNlbnQuCiAKICMjIyBzdGF0ZXNfY29kZWQKQEAgLTExMDUsMjAgKzExMjAsMjAgQEAgaW5p dGlhbFxfc3RhdGVbIGkgXVsgaiBdWyBrIF0gPSAoIHByZWQgKyBpbml0aWFsXF9zdGF0ZVxf ZGVsdGFbIGkgXVsgaiBdWyBrIF0gKQogCiAjIyBRdWFudGl6YXRpb24gVGFibGVzCiAKLVRo ZSBxdWFudGl6YXRpb24gdGFibGVzIGFyZSBzdG9yZWQgYnkgc3RvcmluZyB0aGUgbnVtYmVy IG9mIGVxdWFsIGVudHJpZXMgLTEgb2YgdGhlIGZpcnN0IGhhbGYgb2YgdGhlIHRhYmxlIHVz aW5nIHRoZSBtZXRob2QgZGVzY3JpYmVkIGluIFtSYW5nZSBOb24gQmluYXJ5IFZhbHVlc10o I3JhbmdlLW5vbi1iaW5hcnktdmFsdWVzKS4gVGhlIHNlY29uZCBoYWxmIGRvZXNu4oCZdCBu ZWVkIHRvIGJlIHN0b3JlZCBhcyBpdCBpcyBpZGVudGljYWwgdG8gdGhlIGZpcnN0IHdpdGgg ZmxpcHBlZCBzaWduLgorVGhlIHF1YW50aXphdGlvbiB0YWJsZXMgYXJlIHN0b3JlZCBieSBz dG9yaW5nIHRoZSBudW1iZXIgb2YgZXF1YWwgZW50cmllcyBtaW51cyBvbmUgb2YgdGhlIGZp cnN0IGhhbGYgb2YgdGhlIHRhYmxlIHVzaW5nIHRoZSBtZXRob2QgZGVzY3JpYmVkIGluIFtS YW5nZSBOb24gQmluYXJ5IFZhbHVlc10oI3JhbmdlLW5vbi1iaW5hcnktdmFsdWVzKS4gVGhl IHNlY29uZCBoYWxmIGRvZXNu4oCZdCBuZWVkIHRvIGJlIHN0b3JlZCBhcyBpdCBpcyBjb21w dXRlZCBmb2xsb3dpbmcgdGhlIGZvcm11bGEgYmVsb3cuCiAKIGV4YW1wbGU6CiAKLVRhYmxl OiAwIDAgMSAxIDEgMSAyIDItMi0yLTItMS0xLTEtMSAwCitUYWJsZTogMCAwIDEgMSAxIDEg MiAyIC0yIC0yIC0yIC0xIC0xIC0xIC0xIDAKIAogU3RvcmVkIHZhbHVlczogMSwgMywgMQog CiBgYGBjCiBmdW5jdGlvbiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwgdHlwZQogLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS18LS0tLS0KLVF1YW50aXphdGlvblRh YmxlKCBpICkgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAorUXVh bnRpemF0aW9uVGFibGVQZXJTZXQoIGkgKSB7ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICB8CiAgICAgc2NhbGUgPSAxICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwKLSAgICBmb3IoIGogPSAwOyBqIDwgTUFYX0NPTlRFWFRfSU5Q VVRTOyBqKysgKSB7ICAgICAgICAgICAgICAgfAorICAgIGZvciggaiA9IDA7IGogPCA1OyBq KysgKSB7ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgIFF1YW50 aXphdGlvblRhYmxlUGVyQ29udGV4dCggaSwgaiwgc2NhbGUgKSAgICAgICAgICAgIHwKICAg ICAgICAgc2NhbGUgKj0gMiAqIGxlbl9jb3VudFsgaSBdWyBqIF0gLSAxICAgICAgICAgICAg ICAgICAgfAogICAgIH0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8CkBAIC0xMTI2LDE2ICsxMTQxLDE0IEBAIFF1YW50aXphdGlv blRhYmxlKCBpICkgeyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog fSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8CiBgYGAKIAotTUFYXF9DT05URVhUXF9JTlBVVFMgaXMgNS4KLQogYGBgYwog ZnVuY3Rpb24gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8IHR5cGUKIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfC0tLS0tCiBRdWFudGl6YXRpb25UYWJsZVBlckNv bnRleHQoaSwgaiwgc2NhbGUpIHsgICAgICAgICAgICAgICAgICAgIHwKICAgICB2ID0gMCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfAog ICAgIGZvciggayA9IDA7IGsgPCAxMjg7ICkgeyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8Ci0gICAgICAgIGxlbiAtIDEgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwgc3IKLSAgICAgICAgZm9yKCBhID0gMDsgYSA8IGxlbjsg YSsrICkgeyAgICAgICAgICAgICAgICAgICAgICAgICAgfAorICAgICAgICBsZW5fbWludXMx ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8IHVyCisgICAg ICAgIGZvciggYSA9IDA7IGEgPCBsZW5fbWludXMxICsgMTsgYSsrICkgeyAgICAgICAgICAg ICAgIHwKICAgICAgICAgICAgIHF1YW50X3RhYmxlc1sgaSBdWyBqIF1bIGsgXSA9IHNjYWxl KiB2ICAgICAgICAgICAgfAogICAgICAgICAgICAgaysrICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8CiAgICAgICAgIH0gICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKQEAgLTExNTMsMTEgKzEx NjYsMTEgQEAgUXVhbnRpemF0aW9uVGFibGVQZXJDb250ZXh0KGksIGosIHNjYWxlKSB7ICAg ICAgICAgICAgICAgICAgICB8CiAKICMjIyBxdWFudF90YWJsZXMKIAotYHF1YW50X3RhYmxl c2AgaW5kaWNhdGVzIHRoZSBxdWFudGlmaWNhdGlvbiB0YWJsZSB2YWx1ZXMuCitgcXVhbnRf dGFibGVzYCBpbmRpY2F0ZXMgdGhlIHF1YW50aWZpY2F0aW9uIHRhYmxlIHZhbHVlcyBmb3Ig cXVhbnRpemF0aW9uIHRhYmxlIHNldCBgaWAuCiAKICMjIyBjb250ZXh0X2NvdW50CiAKLWBj b250ZXh0X2NvdW50YCBpbmRpY2F0ZXMgdGhlIGNvdW50IG9mIGNvbnRleHRzLgorYGNvbnRl eHRfY291bnRgIGluZGljYXRlcyB0aGUgY291bnQgb2YgY29udGV4dHMgZm9yIHF1YW50aXph dGlvbiB0YWJsZSBzZXQgYGlgLgogCiAjIyMgUmVzdHJpY3Rpb25zCiAKLS0gCjIuNy4wLndp bmRvd3MuMQoK --------------02233FB064E1206BDA1E572B-- From nobody Fri Apr 14 10:47:53 2017 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 CB98B1294CF for ; Fri, 14 Apr 2017 10:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qT4xLLC6909V for ; Fri, 14 Apr 2017 10:47:50 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C0D51294F0 for ; Fri, 14 Apr 2017 10:47:50 -0700 (PDT) Received: from [146.96.19.240] (port=18100 helo=[10.10.201.10]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cz5K0-00103f-Lc; Fri, 14 Apr 2017 13:47:49 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dave Rice In-Reply-To: Date: Fri, 14 Apr 2017 13:47:47 -0400 Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Transfer-Encoding: quoted-printable Message-Id: <1FDD08A8-59F8-42B7-98A3-032CBBCB11FC@dericed.com> References: To: Jerome Martinez X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] [PATCH FFV1] Quantization table sets and contexts 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: Fri, 14 Apr 2017 17:47:52 -0000 > On Apr 14, 2017, at 10:34 AM, Jerome Martinez = wrote: >=20 > I had difficulties to understand FFV1 quantization table sets, = quantization tables and context, with some items not defined (e.g. abs() = of a table). >=20 > I propose the following patch: > - I reuse "quantization table set" name when relevant (this words were = already present, I put them everywhere) > - I added info about which quantization table set is used (or did I = miss it somewhere else?) > - "Table_" replaced by quant_tables[i][j][k] as it is already used = elsewhere in the spec > - Looks like the scale is indicated twice (in "Quantization Tables" = chapter and in "context" chapter), I removed one (the one in "context" = chapter) > - "The second half doesn=E2=80=99t need to be stored as it is = identical to the first with flipped sign." is misleading from my point = of view as values are mirrored, the first value of this second half is a = copy of the last value of the first half so the the first value is = discarded during the "identical" process, I removed the sentence and = added a reference to the pseudo code. Is it intended that it is not an = exact mirror? (I have no idea about maths behind that, I just see an = incoherency between text and code) > - I changed the type of the length of "number of equal entries -1" = from signed to unsigned, looks like this is unsigned in reality > - removed MAX_CONTEXT_INPUTS as this constant is hard coded to "5" = everywhere in the spec and depends of design choices about the context > - some formatting >=20 > A Pull request is open on GitHub: > https://github.com/FFmpeg/FFV1/pull/56 I added a review directly on the pull request at = https://github.com/FFmpeg/FFV1/pull/56/files. [...] Dave Rice= From nobody Mon Apr 17 11:36:55 2017 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 CA66D128CD5; Mon, 17 Apr 2017 11:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.779 X-Spam-Level: X-Spam-Status: No, score=0.779 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W3brxvYe4Usg; Mon, 17 Apr 2017 11:36:52 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C793128C83; Mon, 17 Apr 2017 11:36:49 -0700 (PDT) Received: from [146.96.19.240] (port=38149 helo=[10.10.201.17]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1d0BW3-002I6S-IG; Mon, 17 Apr 2017 14:36:48 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dave Rice In-Reply-To: <149213250939.16154.3098627789333185829.idtracker@ietfa.amsl.com> Date: Mon, 17 Apr 2017 14:36:45 -0400 Cc: cellar@ietf.org, draft-niedermayer-cellar-ffv1@ietf.org, cellar-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <149213250939.16154.3098627789333185829.idtracker@ietfa.amsl.com> To: IETF Secretariat X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state "Call For Adoption By WG Issued" 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, 17 Apr 2017 18:36:54 -0000 Hi all, > On Apr 13, 2017, at 9:15 PM, IETF Secretariat = wrote: >=20 >=20 > The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state=20 > Call For Adoption By WG Issued (entered by Tessa Fallon) >=20 > The document is available at > https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1/ >=20 >=20 > Comment: > Picking this up from earlier this spring. This is a call to adopt the > document draft-niedermayer-cellar-ffv1 for FF Video Codec 1 as a = working > group document. >=20 > Comments and feedback welcome. I reviewed the definition of WG Document as documented at = https://wiki.tools.ietf.org/html/rfc6174#section-4.2.4. = draft-niedermayer-cellar-ffv1 seems to meet the criteria well and is = presently the focus of active work. I support = draft-niedermayer-cellar-ffv1 being adopted by the working group as a = working group document. Dave Rice From nobody Mon Apr 17 11:49:57 2017 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 32601131771; Mon, 17 Apr 2017 11:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.81 X-Spam-Level: X-Spam-Status: No, score=-2.81 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=0.01, 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 fiBrn6nAw_PW; Mon, 17 Apr 2017 11:49:53 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EED0124281; Mon, 17 Apr 2017 11:49:53 -0700 (PDT) Received: from smtp6.infomaniak.ch (smtp6.infomaniak.ch [83.166.132.19]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v3HInpVd020028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 17 Apr 2017 20:49:51 +0200 Received: from Castor.local (77-56-128-186.dclient.hispeed.ch [77.56.128.186]) (authenticated bits=0) by smtp6.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v3HInoEH041732 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 17 Apr 2017 20:49:51 +0200 Date: Mon, 17 Apr 2017 20:49:51 +0200 From: Reto Kromer To: IETF Secretariat cc: cellar@ietf.org, draft-niedermayer-cellar-ffv1@ietf.org, cellar-chairs@ietf.org X-Priority: 3 In-Reply-To: <149213250939.16154.3098627789333185829.idtracker@ietfa.amsl.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state "Call For Adoption By WG Issued" 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, 17 Apr 2017 18:49:56 -0000 IETF Secretariat wrote: >The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state=20 >Call For Adoption By WG Issued (entered by Tessa Fallon) > >The document is available at >https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1/ > > >Comment: >Picking this up from earlier this spring. This is a call to >adopt the document draft-niedermayer-cellar-ffv1 for FF Video >Codec 1 as a working group document. > >Comments and feedback welcome. I second that the WG adopts FF Video Codec 1 draft-niedermayer-cellar-ffv1-01 as a WG Document. Best regards, Reto Kromer From nobody Mon Apr 17 12:00:00 2017 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 E8DDF13157C; Mon, 17 Apr 2017 11:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9ujtM-73ftc; Mon, 17 Apr 2017 11:59:57 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 39160131598; Mon, 17 Apr 2017 11:59:57 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id o81so39788677wmb.1; Mon, 17 Apr 2017 11:59:57 -0700 (PDT) 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=nA9RbQ1/vVVh5cpKJF0MeqeUkmzf7XfeVOlKGOWuQJ0=; b=cLrY6ecBF/gXb1TVXWfYZ5XK1CS8WqjdiZ0K7krpCMzJ8kIAxO1UH0HNC+NyPzO5N0 NDmFS67040RqCsxVMUydRONSRWLTGwoNuyuW5ZCRbd9H5C8Bypuie5NNe9o+1qe3raj9 IamEvCe6HWQSmpwTaOeM9fFWV1oO/JUWcWIpDhetYQaLzfle/MLq9xLfcVS8goEdk+Uu LFRcBFJgV+rimQjZmA8/3FKZRnU/8Qz6RlP+qZjE5ij3TP/uwV1oltWXYv1oD5ohSPK2 R1VcHF14/P/KGSpZdIpmYdyVfyLid6GHNeljTpIYf2J46871DeS5cQMAcaNp9BsUfPyc l6iw== 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=nA9RbQ1/vVVh5cpKJF0MeqeUkmzf7XfeVOlKGOWuQJ0=; b=YcjJAHjgHer4hgButlhg50rW78CZDs6HEvBvkHOAQurMlz/oyD+fMTNjKXv/du3zzG 6uX/QJnwiAFSvCywcyy3T9LRyamr6pU1P5n1I9ndKlApsujW2spb4t3S9Qzo332KeHRp yTplXs+0X71U24UoE5LI2T6YMEt94vwf4uTNG6GHd/nocPLwy39BpEvjCbFHMhvCV6D9 eMBwrwrJphUOTjYs9pyP6FmrKTusw4yMzQyqDU72uvm7hh/nKdXWrJ3zVSpN1OmW32xg EojHfKBbwYKEDduBsklnN30usPmG2ZJZyZrz9fdfmbDrDFz2qCL4KZDeUSgKGp7XBjeF VBDw== X-Gm-Message-State: AN3rC/4ZZRWg7fGeUboW/b+OxwyXYsATJr1hrywdu2l5CXeoIE2nUdTa VBxZS3uroSyX9lMN46b+W1+VkOxzgg== X-Received: by 10.28.191.145 with SMTP id o17mr10700911wmi.20.1492455595801; Mon, 17 Apr 2017 11:59:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.135.148 with HTTP; Mon, 17 Apr 2017 11:59:55 -0700 (PDT) In-Reply-To: References: <149213250939.16154.3098627789333185829.idtracker@ietfa.amsl.com> From: Kieran O Leary Date: Mon, 17 Apr 2017 19:59:55 +0100 Message-ID: To: Reto Kromer Cc: IETF Secretariat , cellar@ietf.org, draft-niedermayer-cellar-ffv1@ietf.org, cellar-chairs@ietf.org Content-Type: multipart/alternative; boundary=94eb2c06d54aa186be054d61654c Archived-At: Subject: Re: [Cellar] The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state "Call For Adoption By WG Issued" 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, 17 Apr 2017 18:59:59 -0000 --94eb2c06d54aa186be054d61654c Content-Type: text/plain; charset=UTF-8 I also support that the WG adopts draft-niedermayer-cellar-ffv1-01 as a WG document. -Kieran O'Leary On Mon, Apr 17, 2017 at 7:49 PM, Reto Kromer wrote: > IETF Secretariat wrote: > > >The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state > >Call For Adoption By WG Issued (entered by Tessa Fallon) > > > >The document is available at > >https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1/ > > > > > >Comment: > >Picking this up from earlier this spring. This is a call to > >adopt the document draft-niedermayer-cellar-ffv1 for FF Video > >Codec 1 as a working group document. > > > >Comments and feedback welcome. > > > I second that the WG adopts > > FF Video Codec 1 > draft-niedermayer-cellar-ffv1-01 > > as a WG Document. > > Best regards, Reto Kromer > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --94eb2c06d54aa186be054d61654c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also support that the WG adopts=C2=A0draft-niedermayer-cellar-ffv1-01 as a WG document.

-Kieran O'Leary

On Mon, Apr 17, 2017 at 7:49 PM, Reto Krome= r <= lists@reto.ch> wrote:
IETF Secretariat wrote:

>The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state
>Call For Adoption By WG Issued (entered by Tessa Fallon)
>
>The document is available at
>https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1/
>
>
>Comment:
>Picking this up from earlier this spring.=C2=A0 This is a call to
>adopt the document draft-niedermayer-cellar-ffv1 for FF Video
>Codec 1 as a working group document.
>
>Comments and feedback welcome.


I second that the WG adopts

=C2=A0 FF Video Codec 1
=C2=A0 draft-niedermayer-cellar-ffv1-01

as a WG Document.

Best regards, Reto Kromer

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

--94eb2c06d54aa186be054d61654c-- From nobody Mon Apr 17 12:03:25 2017 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 0431B1315D3 for ; Mon, 17 Apr 2017 12:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 KY0g-ZsfaUkh for ; Mon, 17 Apr 2017 12:03:21 -0700 (PDT) Received: from 3.mo68.mail-out.ovh.net (3.mo68.mail-out.ovh.net [46.105.58.60]) (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 3383D13160A for ; Mon, 17 Apr 2017 12:03:19 -0700 (PDT) Received: from player711.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 47AD649388 for ; Mon, 17 Apr 2017 21:03:17 +0200 (CEST) Received: from [192.168.2.101] (p5DDB4468.dip0.t-ipconnect.de [93.219.68.104]) (Authenticated sender: jerome@mediaarea.net) by player711.ha.ovh.net (Postfix) with ESMTPSA id D31C6380086; Mon, 17 Apr 2017 21:03:13 +0200 (CEST) References: <149213250939.16154.3098627789333185829.idtracker@ietfa.amsl.com> Cc: IETF Secretariat , draft-niedermayer-cellar-ffv1@ietf.org, cellar-chairs@ietf.org To: cellar@ietf.org From: Jerome Martinez Message-ID: <7552b800-ceb9-8683-1cfb-c345daaf3c6a@mediaarea.net> Date: Mon, 17 Apr 2017 21:03:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CD33A52F01E0E7A68B91A375" X-Ovh-Tracer-Id: 1257911673755406392 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeliedrvdeigddufeefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state "Call For Adoption By WG Issued" 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, 17 Apr 2017 19:03:23 -0000 This is a multi-part message in MIME format. --------------CD33A52F01E0E7A68B91A375 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Same Le 17/04/2017 à 20:59, Kieran O Leary a écrit : > I also support that the WG adopts draft-niedermayer-cellar-ffv1-01 as > a WG document. > > -Kieran O'Leary > > On Mon, Apr 17, 2017 at 7:49 PM, Reto Kromer > wrote: > > IETF Secretariat wrote: > > >The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state > >Call For Adoption By WG Issued (entered by Tessa Fallon) > > > >The document is available at > >https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1/ > > > > > > >Comment: > >Picking this up from earlier this spring. This is a call to > >adopt the document draft-niedermayer-cellar-ffv1 for FF Video > >Codec 1 as a working group document. > > > >Comments and feedback welcome. > > > I second that the WG adopts > > FF Video Codec 1 > draft-niedermayer-cellar-ffv1-01 > > as a WG Document. > > Best regards, Reto Kromer > > _______________________________________________ > 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 --------------CD33A52F01E0E7A68B91A375 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Same

Le 17/04/2017 à 20:59, Kieran O Leary a écrit :
I also support that the WG adopts draft-niedermayer-cellar-ffv1-01 as a WG document.

-Kieran O'Leary

On Mon, Apr 17, 2017 at 7:49 PM, Reto Kromer <lists@reto.ch> wrote:
IETF Secretariat wrote:

>The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state
>Call For Adoption By WG Issued (entered by Tessa Fallon)
>
>The document is available at
>https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1/
>
>
>Comment:
>Picking this up from earlier this spring.  This is a call to
>adopt the document draft-niedermayer-cellar-ffv1 for FF Video
>Codec 1 as a working group document.
>
>Comments and feedback welcome.


I second that the WG adopts

  FF Video Codec 1
  draft-niedermayer-cellar-ffv1-01

as a WG Document.

Best regards, Reto Kromer

_______________________________________________
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


--------------CD33A52F01E0E7A68B91A375-- From nobody Mon Apr 17 12:04:28 2017 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 E62B21315C6; Mon, 17 Apr 2017 12:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8sFUAAbH5PJ; Mon, 17 Apr 2017 12:04:25 -0700 (PDT) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D02813157C; Mon, 17 Apr 2017 12:04:25 -0700 (PDT) Received: by mail-io0-x229.google.com with SMTP id o22so42175880iod.3; Mon, 17 Apr 2017 12:04:25 -0700 (PDT) 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=1PQIBC7TIuPg529hvQO/PRb+JwSybszi8mFkXy7tBjk=; b=olXC6tkt6mJHgqu0mz1b9syzVN2psTZaLe1cz9AsvazqDQEJ7sKbyfQ497wgRasf4N bCwEMl2oiqpGBiWhSw67wZk2/1GkUphey0L1adwj851BDf7vgx04xHHasSokDLU3lZzF jJrFJEhX9/xZb7kopyc0giuiVG4M0K5MajXmgTJFm5AL4SrYhFBd3A+B73+Q7SKfMxTJ n8+MYrdJ1IvjxkkOw9tKsJrxZk9nQ364m+85x1s1Ny/s6XlS2zEwZkV4qY30UYpsqczk lFuKD9p9QcQ2+34K4nsRCJdxmgxctJXTRjfXE7xxhuFUGQtxfbZ9guaXmYAC/RkwDLLr 6Jtw== 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=1PQIBC7TIuPg529hvQO/PRb+JwSybszi8mFkXy7tBjk=; b=XWFj9LYTuIPwP41YTr/PjcdU4/XO3dhZcXKdeLcvFKCJ7KbjgYMXvX9koJrs7JE4kl 6saYtVLPoo/KocJ4p5BLrGB5+fP64dHUNkliFm/O6UCzdV2t/fYKEfT14YkPiiZzxV7Q YqtugQ8RDU10PEybZhu/XewtZE6xjZr9aPcgzqXol5e1o2kjVyblm3fxnsARnRoYsLcL 5ZJR65cGxZDR5S9M26SByUbB6ei9Ga1Fy2FDutKaHq2jNJyFCLoeBMKXTedtitb6XUTJ HIzoWGciFcqTx0JEzR7F1bpZga3DfBuWoI1WkPtYT1YwTtc04gdVEfm65wrczNYH6av6 o6Kw== X-Gm-Message-State: AN3rC/4uWqvYVDgq/YOIEA/L1XzMPMSm2tmSQOA7AhWGhcgMJ+QyGeDQ qKalT5EbomXQ4Jx9K+VvaMDgTqm00RBJezE= X-Received: by 10.36.26.81 with SMTP id 78mr9814292iti.91.1492455864604; Mon, 17 Apr 2017 12:04:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.159.85 with HTTP; Mon, 17 Apr 2017 12:04:24 -0700 (PDT) In-Reply-To: <7552b800-ceb9-8683-1cfb-c345daaf3c6a@mediaarea.net> References: <149213250939.16154.3098627789333185829.idtracker@ietfa.amsl.com> <7552b800-ceb9-8683-1cfb-c345daaf3c6a@mediaarea.net> From: Ashley Blewer Date: Mon, 17 Apr 2017 15:04:24 -0400 Message-ID: To: Jerome Martinez Cc: Codec Encoding for LossLess Archiving and Realtime transmission , IETF Secretariat , draft-niedermayer-cellar-ffv1@ietf.org, cellar-chairs@ietf.org Content-Type: multipart/alternative; boundary=001a1144648aa72f0a054d617573 Archived-At: Subject: Re: [Cellar] The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state "Call For Adoption By WG Issued" 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, 17 Apr 2017 19:04:27 -0000 --001a1144648aa72f0a054d617573 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hey, me too! I support that the WG adopts draft-niedermayer-cellar-ffv1-01 as a WG document. On Mon, Apr 17, 2017 at 3:03 PM, Jerome Martinez wrote: > Same > > > Le 17/04/2017 =C3=A0 20:59, Kieran O Leary a =C3=A9crit : > > I also support that the WG adopts draft-niedermayer-cellar-ffv1-01 as a > WG document. > > -Kieran O'Leary > > On Mon, Apr 17, 2017 at 7:49 PM, Reto Kromer wrote: > >> IETF Secretariat wrote: >> >> >The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state >> >Call For Adoption By WG Issued (entered by Tessa Fallon) >> > >> >The document is available at >> >https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1/ >> > >> > >> >Comment: >> >Picking this up from earlier this spring. This is a call to >> >adopt the document draft-niedermayer-cellar-ffv1 for FF Video >> >Codec 1 as a working group document. >> > >> >Comments and feedback welcome. >> >> >> I second that the WG adopts >> >> FF Video Codec 1 >> draft-niedermayer-cellar-ffv1-01 >> >> as a WG Document. >> >> Best regards, Reto Kromer >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> > > > > _______________________________________________ > Cellar mailing listCellar@ietf.orghttps://www.ietf.org/mailman/listinfo/c= ellar > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --001a1144648aa72f0a054d617573 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hey, me too! I=C2=A0support that the WG adopts draft-niede= rmayer-cellar-ffv1-01 as a WG document.
On Mon, Apr 17, 2017 at 3:03 PM, Jerome Martine= z <jerome@mediaarea.net> wrote:
=20 =20 =20
Same


Le 17/04/2017 =C3=A0 20:59, Kieran O Leary a =C3=A9crit=C2=A0:
I also support that the WG adopts=C2=A0draft-niedermayer-cellar-ffv1-01 as a WG document.

-Kieran O'Leary

On Mon, Apr 17, 2017 at 7:49 PM, Reto Kromer <lists@reto.ch> wrote:
IETF Secretariat wrote:

>The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state
>Call For Adoption By WG Issued (entered by Tessa Fallon)
>
>The document is available at
>https://datatracker= .ietf.org/doc/draft-niedermayer-cellar-ffv1/
>
>
>Comment:
>Picking this up from earlier this spring.=C2=A0 This is a call to
>adopt the document draft-niedermayer-cellar-ffv1 for FF Video
>Codec 1 as a working group document.
>
>Comments and feedback welcome.


I second that the WG adopts

=C2=A0 FF Video Codec 1
=C2=A0 draft-niedermayer-cellar-ffv1-01

as a WG Document.

Best regards, Reto Kromer

_______________________________________________
Cellar mailing list
Cellar= @ietf.org
https://www.ietf.org/mailman/listin= fo/cellar



_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/m=
ailman/listinfo/cellar



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

--001a1144648aa72f0a054d617573-- From nobody Mon Apr 17 13:00:27 2017 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E18661200FC; Mon, 17 Apr 2017 13:00:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Cc: ben@nostrum.com, tessa.fallon@gmail.com, cellar@ietf.org, cellar-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149245922583.17799.10588076244988604919.idtracker@ietfa.amsl.com> Date: Mon, 17 Apr 2017 13:00:25 -0700 Archived-At: Subject: [Cellar] cellar - New Meeting Session Request for IETF 99 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.22 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, 17 Apr 2017 20:00:26 -0000 A new meeting session request has just been submitted by Tessa Fallon, a Chair of the cellar working group. --------------------------------------------------------- Working Group Name: Codec Encoding for LossLess Archiving and Realtime transmission Area Name: Applications and Real-Time Area Session Requester: Tessa Fallon Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 50 Conflicts to Avoid: First Priority: netvc Second Priority: rtcweb Third Priority: codec People who must be present: Ben Campbell Tim Terriberry Tessa Fallon Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Apr 17 13:04:08 2017 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 E9B83129445 for ; Mon, 17 Apr 2017 13:04:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjR4Bw-k__Rq for ; Mon, 17 Apr 2017 13:04:05 -0700 (PDT) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5CF2129454 for ; Mon, 17 Apr 2017 13:04:02 -0700 (PDT) Received: by mail-io0-x231.google.com with SMTP id r16so162726693ioi.2 for ; Mon, 17 Apr 2017 13:04:02 -0700 (PDT) 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; bh=piI/chzQPyWqVilAH9ctLQt/21Sm6UD4/YkVQTLMMF8=; b=veKKn6W5OH1lq+4TTbOw5tcPhoWyhnlVgyRmI75hhfxsaUFNER/S7Z+GqevXw2YTRf KojFl/A5Mz2C2uz4Qp/wxHMc1ZIGAhNdyNczfyjX0piQI33BqwkS6qKg8GjZuytwcuSw zrm51tQ8OU9bTK1qONybo2Q/1Aj5yu0nQ4uTaVUd2+Izg3WbIv0WDDnxYSRLvnAO/UyL qNh6fYDQcprYKWUnJ/3gQf7IrQMm2QgTZ3VP60NxCELs/w0mp6v/BxzhdPSo0SnJ6LEN Uh2PR0lCgVqSwWCdmKuZJrpbQfoNE9QjwZA8P92fzWHV0cOAxbLyGs55EdGFgpEhyCI3 t8qA== 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; bh=piI/chzQPyWqVilAH9ctLQt/21Sm6UD4/YkVQTLMMF8=; b=p90WZ2l48gjr8SAtI7yvSvL/7JGAYdHCdfAJwvEItWagbqBlev3kS3ed/sGKGjmSv2 7bqy3t2cjLiCUiZ1JxFVUMuHubNsb5j16y6881VCS7yx3DEHOQibJX7ysrH13Qyql0iq LvGMbWcemaFH9A8SKsyof8bV+1PQa5Wyi+f1n+o8tnKFqTjcENnG6z5ijIduVq52bTUv Hawaly6PxEVof230Tlh/fwBRbg0BKw9MM7hpMsEL8GBdOtCaHCfaWwgeu05AjSpxwj35 yKyEJ+XXFQ7uaerMnxCWgtdS0Q8P5x6PRGa6ljWC9aB+1pfSgJJwk/UyDipTKIgYRz25 3gpw== X-Gm-Message-State: AN3rC/7z59wnyHTxvd4SNt/fLi8vATqOCDQFDn476hx46kOafC8erb6w 6ifLFGC1sk6Df2n21oG/J0fHQpsfLjyxU7M= X-Received: by 10.107.9.231 with SMTP id 100mr10100051ioj.90.1492459441508; Mon, 17 Apr 2017 13:04:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.41.19 with HTTP; Mon, 17 Apr 2017 13:03:21 -0700 (PDT) In-Reply-To: <149245922583.17799.10588076244988604919.idtracker@ietfa.amsl.com> References: <149245922583.17799.10588076244988604919.idtracker@ietfa.amsl.com> From: Tessa Fallon Date: Mon, 17 Apr 2017 16:03:21 -0400 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary=001a113eb66ada5a73054d624ad3 Archived-At: Subject: Re: [Cellar] cellar - New Meeting Session Request for IETF 99 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, 17 Apr 2017 20:04:07 -0000 --001a113eb66ada5a73054d624ad3 Content-Type: text/plain; charset=UTF-8 For the IETF 99 July 16-21 (https://www.ietf.org/meeting/99/), I've requested 1.5 hours for a CELLAR meeting, estimating a max of 50 people. Based on last year's meeting in Berlin, this seems sufficient to me. I'd be interested in getting an informal count from the list of how many folks are considering attending--I know it's early! Thanks, Tessa On Mon, Apr 17, 2017 at 4:00 PM, "IETF Meeting Session Request Tool" < session_request_developers@ietf.org> wrote: > > > A new meeting session request has just been submitted by Tessa Fallon, a > Chair of the cellar working group. > > > --------------------------------------------------------- > Working Group Name: Codec Encoding for LossLess Archiving and Realtime > transmission > Area Name: Applications and Real-Time Area > Session Requester: Tessa Fallon > > Number of Sessions: 1 > Length of Session(s): 1.5 Hours > Number of Attendees: 50 > Conflicts to Avoid: > First Priority: netvc > Second Priority: rtcweb > Third Priority: codec > > > People who must be present: > Ben Campbell > Tim Terriberry > Tessa Fallon > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > > --001a113eb66ada5a73054d624ad3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For the IETF 99 July 16-21 (https://www.ietf.org/meeting/99/), I've requested 1.= 5 hours for a CELLAR meeting, estimating a max of 50 people.=C2=A0 Based on= last year's meeting in Berlin, this seems sufficient to me. =C2=A0
I'd be interested in getting an informal count from the= list of how many folks are considering attending--I know it's early!

Thanks,

Tessa

On Mon, Apr 17, 2017 at 4:= 00 PM, "IETF Meeting Session Request Tool" <= se= ssion_request_developers@ietf.org> wrote:


A new meeting session request has just been submitted by Tessa Fallon, a Ch= air of the cellar working group.


---------------------------------------------------------
Working Group Name: Codec Encoding for LossLess Archiving and Realtime tran= smission
Area Name: Applications and Real-Time Area
Session Requester: Tessa Fallon

Number of Sessions: 1
Length of Session(s):=C2=A0 1.5 Hours
Number of Attendees: 50
Conflicts to Avoid:
=C2=A0First Priority:=C2=A0 netvc
=C2=A0Second Priority:=C2=A0 rtcweb
=C2=A0Third Priority:=C2=A0 codec


People who must be present:
=C2=A0 Ben Campbell
=C2=A0 Tim Terriberry
=C2=A0 Tessa Fallon

Resources Requested:

Special Requests:

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


--001a113eb66ada5a73054d624ad3-- From nobody Mon Apr 17 13:11:43 2017 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 D415D12944D for ; Mon, 17 Apr 2017 13:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 Goynhyiu-yEZ for ; Mon, 17 Apr 2017 13:11:38 -0700 (PDT) Received: from 4.mo68.mail-out.ovh.net (4.mo68.mail-out.ovh.net [46.105.59.63]) (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 36766127A97 for ; Mon, 17 Apr 2017 13:11:38 -0700 (PDT) Received: from player711.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo68.mail-out.ovh.net (Postfix) with ESMTP id 33D8E4C600 for ; Mon, 17 Apr 2017 22:11:36 +0200 (CEST) Received: from [192.168.2.101] (p5DDB4468.dip0.t-ipconnect.de [93.219.68.104]) (Authenticated sender: jerome@mediaarea.net) by player711.ha.ovh.net (Postfix) with ESMTPSA id E2C36380085 for ; Mon, 17 Apr 2017 22:11:35 +0200 (CEST) To: cellar@ietf.org References: <149245922583.17799.10588076244988604919.idtracker@ietfa.amsl.com> From: Jerome Martinez Message-ID: Date: Mon, 17 Apr 2017 22:11:34 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------E140AA62401FF66DFA078ACE" X-Ovh-Tracer-Id: 2411677603247820945 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeliedrvdeigddugeeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] cellar - New Meeting Session Request for IETF 99 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, 17 Apr 2017 20:11:41 -0000 This is a multi-part message in MIME format. --------------E140AA62401FF66DFA078ACE Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I'll be present. Le 17/04/2017 à 22:03, Tessa Fallon a écrit : > For the IETF 99 July 16-21 (https://www.ietf.org/meeting/99/), I've > requested 1.5 hours for a CELLAR meeting, estimating a max of 50 > people. Based on last year's meeting in Berlin, this seems sufficient > to me. > > I'd be interested in getting an informal count from the list of how > many folks are considering attending--I know it's early! > > Thanks, > > Tessa > > On Mon, Apr 17, 2017 at 4:00 PM, "IETF Meeting Session Request Tool" > > wrote: > > > > A new meeting session request has just been submitted by Tessa > Fallon, a Chair of the cellar working group. > > > --------------------------------------------------------- > Working Group Name: Codec Encoding for LossLess Archiving and > Realtime transmission > Area Name: Applications and Real-Time Area > Session Requester: Tessa Fallon > > Number of Sessions: 1 > Length of Session(s): 1.5 Hours > Number of Attendees: 50 > Conflicts to Avoid: > First Priority: netvc > Second Priority: rtcweb > Third Priority: codec > > > People who must be present: > Ben Campbell > Tim Terriberry > Tessa Fallon > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --------------E140AA62401FF66DFA078ACE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
I'll be present.

Le 17/04/2017 à 22:03, Tessa Fallon a écrit :
For the IETF 99 July 16-21 (https://www.ietf.org/meeting/99/), I've requested 1.5 hours for a CELLAR meeting, estimating a max of 50 people.  Based on last year's meeting in Berlin, this seems sufficient to me.  

I'd be interested in getting an informal count from the list of how many folks are considering attending--I know it's early!

Thanks,

Tessa

On Mon, Apr 17, 2017 at 4:00 PM, "IETF Meeting Session Request Tool" <session_request_developers@ietf.org> wrote:


A new meeting session request has just been submitted by Tessa Fallon, a Chair of the cellar working group.


---------------------------------------------------------
Working Group Name: Codec Encoding for LossLess Archiving and Realtime transmission
Area Name: Applications and Real-Time Area
Session Requester: Tessa Fallon

Number of Sessions: 1
Length of Session(s):  1.5 Hours
Number of Attendees: 50
Conflicts to Avoid:
 First Priority:  netvc
 Second Priority:  rtcweb
 Third Priority:  codec


People who must be present:
  Ben Campbell
  Tim Terriberry
  Tessa Fallon

Resources Requested:

Special Requests:

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




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


--------------E140AA62401FF66DFA078ACE-- From nobody Wed Apr 19 00:38:42 2017 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 D966013153F; Wed, 19 Apr 2017 00:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.121 X-Spam-Level: * X-Spam-Status: No, score=1.121 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7] 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 qpVwgbghb_R8; Wed, 19 Apr 2017 00:38:39 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1FA913153E; Wed, 19 Apr 2017 00:38:38 -0700 (PDT) Received: from [10.0.0.11] (1360030002.d-dsl.at [::ffff:81.16.105.50]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 19 Apr 2017 09:38:43 +0200 id 0000000000000029.0000000058F71403.0000671A Message-ID: <58F713F9.1020902@das-werkstatt.com> Date: Wed, 19 Apr 2017 09:38:33 +0200 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 CC: IETF Secretariat , Codec Encoding for LossLess Archiving and Realtime transmission , draft-niedermayer-cellar-ffv1@ietf.org, cellar-chairs@ietf.org References: <149213250939.16154.3098627789333185829.idtracker@ietfa.amsl.com> <7552b800-ceb9-8683-1cfb-c345daaf3c6a@mediaarea.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] The CELLAR WG has placed draft-niedermayer-cellar-ffv1 in state "Call For Adoption By WG Issued" 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, 19 Apr 2017 07:38:41 -0000 On 04/17/2017 09:04 PM, Ashley Blewer wrote: > Hey, me too! I support that the WG adopts draft-niedermayer-cellar-ffv1-01 > as a WG document. I second that too. Kind regards, Peter Bubestinger From nobody Mon Apr 24 07:20:43 2017 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 E899612950A for ; Mon, 24 Apr 2017 07:20:41 -0700 (PDT) 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 ucVC-EYtqIET for ; Mon, 24 Apr 2017 07:20:40 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 787001294DC for ; Mon, 24 Apr 2017 07:20:40 -0700 (PDT) Received: from [10.0.0.11] (1360030002.d-dsl.at [::ffff:81.16.105.50]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Mon, 24 Apr 2017 16:20:54 +0200 id 000000000000003B.0000000058FE09C6.000076A2 Message-ID: <58FE09B4.8030709@das-werkstatt.com> Date: Mon, 24 Apr 2017 16:20:36 +0200 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cellar] Average compression on VHS/DigiBeta material? 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, 24 Apr 2017 14:20:42 -0000 Hi everyone! I'm increasingly being asked for compression performance of FFV1. All my tests so far have shown that it is very depending on the source material. So I thought it might be a good idea to collect real-world numbers :) Therefore, I'd be very grateful if you could provide your experiences. For example, the numbers I know for 8bpc for example are like this: (PAL 720x576 4:2:2, PCM 48kHz/16bit) ------------------- * VHS: 370 MB/Min average (but can go up to 600+ with very broken material) * DigiBeta: 650 MB/Min average (but can go up to over 700 MB) ------------------- Compression for other sources (especially film) are of course interesting too, but I thought it'd be good to start with something small and easy :) Thanks and nice greetings, Peter From nobody Wed Apr 26 00:51:55 2017 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 5A1E7131C65 for ; Wed, 26 Apr 2017 00:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1v9PaG6H5P9 for ; Wed, 26 Apr 2017 00:51:47 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 731C7131C60 for ; Wed, 26 Apr 2017 00:51:40 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id 203so103889643ywe.0 for ; Wed, 26 Apr 2017 00:51:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=ozX0OqqUHD4YngPnsSFn/dckzusm4eujdkAzuazmdnM=; b=kfI/cZ5ZslAodfyExZqZlRe3wuV+UmSmr6v0DLuiA7yS9H7EDp54i8LP34KyliFDTt lXKogP2gqxkT7H0uC0Em7GwVB4DO9GdM+cZQgGLjE1+vgH+drSLRtZxpUJUooEnLCUef +haHY1I8zOta1sM2Gl4VnwMb+GqIJAi8IuoIINIt10JIOEgXiL7d49Cb/8J5/mIiuG9Q xs4p2LrMixGx953/1J53A7B5nQMxEYq7gmXDyNNOw6LOy+5rXco5dXJVeTtiadkxDl8A tDqf6kiGvwiOoT08RJhEQUTu6vk8mncwgxra8b0H21sfqQqsT5WVnrx7eTYqpnOxVSVA 2/TA== 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:content-transfer-encoding; bh=ozX0OqqUHD4YngPnsSFn/dckzusm4eujdkAzuazmdnM=; b=E5Tm8ItKseIz5dAebpvVcM0DMEClenpvbgFinj+MExGjfigcN2CSEc1HuTWYpDFjS/ tVVocvO7m8KolY8sJmqo6OPOQzj0QmeLBPdyOXs+TbpROxPGli3l2inhiK9+hcE6TxZE +VS5T8Zpiqptmj1NHeT5+JIN4eMYshbXKJu6SshVScxwWE183L51Qd+UTMapI7w6OiBk whiwIYnd11IJdFQ5it9DP9N6nPYtmoxvcOY5K8iVI/Iz3tjWVdiK1/l3411vClVviOtq cAGwio1oAGNlAft3OctdABw6Tm0FrjTfxRYt9HXmuGvCpkbutm3lpQq2SoM4Ov01UmpZ nDog== X-Gm-Message-State: AN3rC/7JyYFtm5eKIjui7ZvsCwaYR0h2tYFhcmW8XpRWma0smERufhFx y6x3BxEI7YmbPqmApDwzJ+CtAiJHgg== X-Received: by 10.129.103.11 with SMTP id b11mr13321447ywc.75.1493193099273; Wed, 26 Apr 2017 00:51:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.4.215 with HTTP; Wed, 26 Apr 2017 00:51:38 -0700 (PDT) In-Reply-To: <1db0fb80-2441-a4f0-729e-bc5b5cfd1a84@mediaarea.net> References: <2651a6f3-9c9a-6f76-2ee7-4d5c23b1ce57@mediaarea.net> <922C5404-EC19-462D-A836-C952E66C2FD8@dericed.com> <9244b201-9097-365f-b7da-f2d8553616ee@mediaarea.net> <79FE60E9-88D8-4922-AE76-9D1924E1D6EB@dericed.com> <43056655-cf09-9d54-6552-4ed4b655e74f@mediaarea.net> <34CA7943-497F-449A-81DA-3237CB87BDD7@dericed.com> <1db0fb80-2441-a4f0-729e-bc5b5cfd1a84@mediaarea.net> From: Steve Lhomme Date: Wed, 26 Apr 2017 09:51:38 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] QuickTime timecode tracks in Matroska, was Ancillary data in Matroska 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, 26 Apr 2017 07:51:49 -0000 A bit late on the party but I agree with the move to a more specific track type for timecodes rather than the generic ancillary data. 2017-03-20 22:07 GMT+01:00 Jerome Martinez : > Le 20/03/2017 =C3=A0 21:37, Dave Rice a =C3=A9crit : >> >> [...] >>>> >>>> I=E2=80=99ve only seen a single value stored but then sometimes an edi= t list >>>> used to alter the ordering of the timecode (in case when its >>>> non-sequential). For Matroska possibly it could simply store a new tim= ecode >>>> Block at any case when it is not sequential. >>> >>> What about seeking? >> >> Isn't the seeking similar to QuickTime. > > > Difference is that in QuickTime, a wrong "seek table" makes the playback > impossible, so developers are more careful about it. and in the file I > remember (I must still find it), there was only one offset in the offset > table of QuickTime and a single "chunk" of time code with byte size of 4 > bytes per frame (to be confirmed as you say you saw edit lists instead) > >> In QuickTime you'd need the offset table of the timecode track to >> understand the number and location of all timecode samples. In Matroska = you >> would use the associated CuePoints of the timecode track for the same >> reference. By parsing Cues the reader should be able to determine if the >> timecode is stripped or not and if not then have the CueTimes for each >> associated timecode Cluster. >> >>> If you have a timecode block at the first frame and also at the middle = of >>> the file, how a player can know that there is a timecode block breaking= the >>> sequential order without parsing the whole file when there is a seek re= quest >>> to the last minute of content? In that case, time code real value would= be >>> set to "waiting for new block" (and this block never comes). I don't th= ink >>> that forcing full parsing of the file with time code for seeking is a g= ood >>> solution. >> >> Same. But in the case of video if you seek to a P-frame then you have to >> go backwards and decode from the I-frame. Similarly if seeking to a >> timepoint without a timecode Cluster (analogous to a P-frame), then the >> reader would have to use the Cues to decode the prior timecode Cluster >> (analogous to I-frame) in order to determine the timecode value of the s= eek >> point. > > > Possible. > But we need to be careful, what does it means? > examples of issue: > 1/ can a player consider that if there is only one CuePoint with CueTrack= =3D > the ID of the time code track, it means that this is a stripped content a= nd > time codes are in sequential order? > 2/ can a player consider that if there are only 2 CuePoints with CueTrack= =3D > the ID of the time code track, it means that this is a stripped content a= nd > time codes are in sequential order except for one place and there is a > single discontinuity? > 3/ or must a player consider that if there only 2 CuePoints (let say fram= e 0 > and frame 1000) with CueTrack =3D the ID of the time code track, it means= that > it must seek to 0 if the requested frame is 999 (so a loooooong read of t= he > file on disk before being able to play frame 999) > If answers are 2/ yes 3/ no, I understand that the only method for storin= g a > time code track with all values not sequential is to have a CuePoint for > each time code frame (which makes the Cues huge, 15-20 bytes of CuePoint = per > time code frame). > > Please provide example about how you imagine CuePoints in the cases: > 1/ sequential time codes during 2000 frames > 2/ sequential time codes during 2000 frames except one discontinuity at > frame 1000 > 3/ 2000 different times codes > and where a player must seek if the request is to seek to frame 999. Are timecode frames supposed to be matching a specific video frame or audio frame ? Or they are loose ? If the former case it may be best to be attached as a BlockAdditional. Otherwise they should always be in sequential/display order, just like audio is. Even if video is not. Having a separate track means the timestamps may not match exactly the video or audio tracks. So in case of seeking/discontinuity it's like you said, there's a state where you need to way for the next Timecode block to know where you are. But in general a Timecode block should/must be placed before the audio/video it corresponds to. It's the same requirement there is in WebM that audio blocks are muxed before video blocks. Timecode would be even more prioritary. > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Wed Apr 26 01:13:35 2017 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 D82451319D8 for ; Wed, 26 Apr 2017 01:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrvsx6LnELCr for ; Wed, 26 Apr 2017 01:13:33 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB8A131890 for ; Wed, 26 Apr 2017 01:13:33 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id 203so104094902ywe.0 for ; Wed, 26 Apr 2017 01:13:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=NPyycaa4zU578AJp8QEUHhMzPSXncrqmTDUTIg95cUM=; b=MoZOB2OBkA1ZtOMXdNwZ3FUwhki8/V+MEkaDSsj++Ast4Xji3s890DUe/yXhuW9/NN Wvlu8keubD7SmaJZBTSQ8AqNrOQSKMuL2prhwOwGjTHdJBur/sR79Ak9yIb66csSuBr7 G2tXcmbQLBbsjZVp6V6g/xN8gYA88tzKTURq2abx/WL3+/Es8CCDYmPiS9Y6rQmV8tSF NtJ+2v1UtSnA3b95N/9Il81Cbf6gE+z5pr8Ar5WLHP98sVTvuLx6lBr6ejbEvrsnI0SK yC8ftNHT8mWnqpLcL6P7ynjOCFoHsOIXuc3+KpzQ5Am70xKgQ4fGm4TB79F+f+YzcgKu mkpg== 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:content-transfer-encoding; bh=NPyycaa4zU578AJp8QEUHhMzPSXncrqmTDUTIg95cUM=; b=d7fcY0qhY1t0qSHyEjpLIBICGu8V2uLja1/wWk5vzAQw7PQNEI3nlItz5zCqawJBo/ dt5EL5Wh7qlNHzpVRVhpqxURik1zgYHzOFbder5wYw2PPNh9z0lvfGLc+Ua+ewX3wxIh OXf0JONVKeB38oH9quvYRYKiwKw9t/eFd40SdtsCbCWLrfQiVK8zINYFJj+RfyLTD60/ Ix15dnu+QpP2FfazFdY8K84pBkbqj4dePR7DR0+4Dvq65jHl68OGRoJyGjrRRrOiT4XY 7Zm2onAAkJGTQghkzggVpHZKXlKqZYDJe/9C/Euo8N0V6Zx7XSWUc4VuhyXjRoXcnJrE /gnQ== X-Gm-Message-State: AN3rC/7rzViURknWPTFodwTCBSapmTciF/eQq6l0j/qXAx/gQ9Vedspw wtcYBBOC+3p8RhdklKiQOiL9+wZBXA== X-Received: by 10.129.83.2 with SMTP id h2mr350906ywb.17.1493194412681; Wed, 26 Apr 2017 01:13:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.4.215 with HTTP; Wed, 26 Apr 2017 01:13:32 -0700 (PDT) In-Reply-To: References: <149245922583.17799.10588076244988604919.idtracker@ietfa.amsl.com> From: Steve Lhomme Date: Wed, 26 Apr 2017 10:13:32 +0200 Message-ID: To: Jerome Martinez Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] cellar - New Meeting Session Request for IETF 99 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, 26 Apr 2017 08:13:35 -0000 I'd be interrested but can't cover (most of) the cost of an IETF meeting. Also I don't know yet my plans for this summer. But I can adjust if we all go a few days and get things going forward. 2017-04-17 22:11 GMT+02:00 Jerome Martinez : > I'll be present. > > > Le 17/04/2017 =C3=A0 22:03, Tessa Fallon a =C3=A9crit : > > For the IETF 99 July 16-21 (https://www.ietf.org/meeting/99/), I've > requested 1.5 hours for a CELLAR meeting, estimating a max of 50 people. > Based on last year's meeting in Berlin, this seems sufficient to me. > > I'd be interested in getting an informal count from the list of how many > folks are considering attending--I know it's early! > > Thanks, > > Tessa > > On Mon, Apr 17, 2017 at 4:00 PM, "IETF Meeting Session Request Tool" > wrote: >> >> >> >> A new meeting session request has just been submitted by Tessa Fallon, a >> Chair of the cellar working group. >> >> >> --------------------------------------------------------- >> Working Group Name: Codec Encoding for LossLess Archiving and Realtime >> transmission >> Area Name: Applications and Real-Time Area >> Session Requester: Tessa Fallon >> >> Number of Sessions: 1 >> Length of Session(s): 1.5 Hours >> Number of Attendees: 50 >> Conflicts to Avoid: >> First Priority: netvc >> Second Priority: rtcweb >> Third Priority: codec >> >> >> People who must be present: >> Ben Campbell >> Tim Terriberry >> Tessa Fallon >> >> Resources Requested: >> >> Special Requests: >> >> --------------------------------------------------------- >> > > > > _______________________________________________ > 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 > --=20 Steve Lhomme Matroska association Chairman From nobody Wed Apr 26 01:25:25 2017 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 A415A131D36 for ; Wed, 26 Apr 2017 01:25:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lLi7ggWif0nX for ; Wed, 26 Apr 2017 01:25:22 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002: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 9CAAF131D34 for ; Wed, 26 Apr 2017 01:25:22 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id 8so7511715ybw.1 for ; Wed, 26 Apr 2017 01:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=p4E4LCgqPSVBkf5rCVuWsosg8JNOWh/Lfa7c4i25TTY=; b=b2dPXTU9QCuyEhD2+4yh0RX7ro3CNdhuS9lyqwyo+qPXWR7EomgnQnASqIlISOeCKZ l7vWb6D1x8bS2CtxCw56knJUABXx9ZUNRfvaiEipJcOYRSl96mWEWGJOU7dsOMboRc22 Nhsi8zodJrtJP+/60Lr24Yer8xhLi03z7xfQsOLM+cA5HLks2reki+RwvV4LoyB/3/CN bi2w0LGdyljwrd+dNRHm+/Sp0AaRPLKF7XUiy5rWmIb9OQ6GJfApe0gQVLBPM59SZ3n9 0WKRdpnSzVdicIx4kRM0bluMMjTzSu5tJvz1nCLVzZj5xd0rV4rUhMx8iZE+Y/Rt/eze 9tDw== 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:content-transfer-encoding; bh=p4E4LCgqPSVBkf5rCVuWsosg8JNOWh/Lfa7c4i25TTY=; b=iRl+bL2jk12dLsyh2osmTFNtr/U/X8mHQxNqc32ShI9OMQZpx44GTuzn3yv2yPk624 j/P0fYNnsyh/ZsiZUBpUfgenkt7gUxglkqka6ANRMXBY5BwTPS6DHZYkuk3RXRGVol+0 6Or+f/Qij23kWASXWoL8wlxdJOtz0aTiYlgkCh2iXDfIuUJwaGzi4BwOZ5nYrlDPbbE9 tL5UhcSCvBLoRbvUbhnhegJbZBocpeYNhN4uPvoazy9A/l98SvQorfZqxTSb1tHRzfY6 cKQw1bR4z2LVmpvxWCgZdpEvWJcts+DzTyJ5yBYNhFg6Z/p8Kla5FJzNpfNbWqO1HVXv d4nw== X-Gm-Message-State: AN3rC/5xtaA9RsoM4VahBpL9FfxC6ClFPsDZn6nNjZobLXeZSFyTaoW6 loPuoQoubZtyIaWCziYwTpUNYm7vuA== X-Received: by 10.37.97.211 with SMTP id v202mr12330355ybb.179.1493195121584; Wed, 26 Apr 2017 01:25:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.4.215 with HTTP; Wed, 26 Apr 2017 01:25:21 -0700 (PDT) In-Reply-To: <922C5404-EC19-462D-A836-C952E66C2FD8@dericed.com> References: <2651a6f3-9c9a-6f76-2ee7-4d5c23b1ce57@mediaarea.net> <922C5404-EC19-462D-A836-C952E66C2FD8@dericed.com> From: Steve Lhomme Date: Wed, 26 Apr 2017 10:25:21 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Ancillary data in Matroska 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, 26 Apr 2017 08:25:25 -0000 It seems a lot of these formats include timecodes (or are basically timecodes). There is still debate whether timecodes should have their own track and ancillary data a different type of tracks. As expressed in a different thread I think timecodes Blocks should come before the video/audio block they are meant to match. Is it the same with ancillary data ? Do ancillary data match a specific video frame compared to timecodes that are more generally loose ? I think this consideration will define how we should go forward handling these data. I agree with Jerome that we're not going to reinvent yet another timecode format. We should support the main ones. Same thing for ancillary data. 2017-02-24 5:18 GMT+01:00 Dave Rice : > Hi all, > > On Jan 7, 2017, at 11:57 AM, Dave Rice wrote: > > > [=E2=80=A6] > > On Dec 27, 2016, at 3:22 PM, Jerome Martinez wrote= : > > > [=E2=80=A6] > > "N_" prefix arbitrary used (2nd letter of "Ancillary" because first lette= r > is already used) > > > Please also add a patch for the TrackType Element in ebml_matroska.xml as > we=E2=80=99ll need an unsigned integer to represent the =E2=80=98ancillar= y=E2=80=99 type of track. > > N_QUICKTIME: is a pure copy of V_QUICKTIME and A_QUICKTIME already suppor= ted > in Matroska, N_ would be used which would be used for e.g. tmcd codec > (QuickTime time code). Exactly same principles as video and audio. Note t= hat > classic usage is to store only the first frame content and other content = is > computed from it, so a player would have to read the first frame even if > there is a direct seek request to another place; this could be avoided wi= th > some "hack" in the track header, could be the next step after this one is > accepted. > > > Would need a clear caveat in the definition that this implementation woul= d > only support storage of the first timecode value and computation of each > additional value. A transwrap from a mov file with a timecode track that > uses an edit list to handle non-continuous timecode could not be a lossle= ss > transwrap in this case, since the edit list would be lost and the new > timecode track in the Matroska file would appear continuous. > > Also reference to tmcd atom is not clear enough. Is it tref/tmcd, gmhd/tm= cd, > stsd/tmcd. > > If this is stsd/tmcd (I presume), then what time scale should be used? Th= e > time scale stored in tmcd or the time scale of the Matroska track? > > I like that copying stsd/tmcd copies in the timecode label as well. > > > I started a draft of a PR for defining QuickTime-style timecode in Matros= ka > based on Jerome=E2=80=99s suggestion, see > https://github.com/Matroska-Org/matroska-specification/pull/102. I left > CodecPrivate as containing the entire Sample description table array of t= he > stsd atom, rather than starting after the track type atom (such as the im= age > descriptor, sound descriptor), because in the case of timecode, values of > the tmcd are needed to interpret what the successive timecode values will > be. The description of the Codec Mapping uses timecode as an example of > ancillary data but not exclusively. Perhaps we should constrain what > quicktime media types are relevant here, as several of the media types > defined at > https://developer.apple.com/library/content/documentation/QuickTime/QTFF/= QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-SW1 > could be considered as ancillary. Comments? > > Best Regards, > Dave Rice > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Wed Apr 26 01:36:21 2017 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 AC27C127698 for ; Wed, 26 Apr 2017 01:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HazxQN_z0ASl for ; Wed, 26 Apr 2017 01:36:18 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190F11319EB for ; Wed, 26 Apr 2017 01:36:16 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id s22so74414311ybe.3 for ; Wed, 26 Apr 2017 01:36:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=WlamhpcK1eMBbXiwun11C/jTcA/gTI+v1mtAZUqdsk4=; b=QW4+0VjzhmkeYtjn7Iy/y+l32Pbbbut5I1D+NMJ2ZtQFPJsAi229lRTtMdZnpkPMMx wRr0IsUvt+MwILHpuYFPZWiT7ZS415OqvIjcFjcF/dcOpW4fQVn/EA7G2xr1ps9ao2+8 cwrLe5urQU2c1EtjeQQqIuiqRcKwCXFfZKnS+hOMj23COBkVRld2bx6ykYn9kgXcBsAF S69sR7dBFlaM4Q5kPOEzhDNBd5BfjMuXzeLcQxP7AKRkZ63LRpaNS2h04fIar3PbpDi0 wZ+BUvBmeJ1Ov+/gp6exGbnRbPnT31StLABWtA2pDv3Ft7hIdYJhbLPXFKKHOeP9VEN4 59hg== 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:content-transfer-encoding; bh=WlamhpcK1eMBbXiwun11C/jTcA/gTI+v1mtAZUqdsk4=; b=GUbDWNAUU4c2emQFcs8pzsaSYya8scQxEtO4MlERHRomwIx22lc+zO72dsl9+ulORn sgp89yCWZumBP2M4fp/iLztF8kP3e3NwajFo9h5uj/HUXCfP4QMFsTUWrPGVRoIdAN/e xPd4arIpcSj74If8CKBu9vgiTb11KOAEV4pvAlc047nM4X+wvdM9JRz09EAWJhzUYvCQ kfjEunBJ+c7lvl3ca63LVsMer62733C8hdMwMhNnnSeHgDko+MNzz8VM15i/jWL0IJOO bSM519LdlQwFpqoKhTil5PHkXxIlNAHNvdMwy0Ub6VmiHhm9q6Azo4EuJXOMJRpeu620 P1hQ== X-Gm-Message-State: AN3rC/5bzMofnxwqdVLAb8eNTYn1Xb9JxdALquvJb+zIL7/VqWdOIyV7 MpepS6ZW7OMX1wuKYUxY87EobrHtrOvE X-Received: by 10.37.173.131 with SMTP id z3mr12910053ybi.64.1493195775053; Wed, 26 Apr 2017 01:36:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.4.215 with HTTP; Wed, 26 Apr 2017 01:36:14 -0700 (PDT) In-Reply-To: <04A7F638-0E15-4949-BB49-98BD88082667@dericed.com> References: <04A7F638-0E15-4949-BB49-98BD88082667@dericed.com> From: Steve Lhomme Date: Wed, 26 Apr 2017 10:36:14 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] mkv ColourSpace and uncompressed video 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, 26 Apr 2017 08:36:20 -0000 2017-02-06 0:21 GMT+01:00 Dave Rice : > Hi cellar, > > I=E2=80=99m hoping to clarify the use of uncompressed video in Matroska a= nd find a > way to avoid muxing errors such as > https://github.com/FFmpeg/FFmpeg/blob/8c1342e631d635f6cad13f9374c4f2005c2= 2b9e5/libavformat/matroskaenc.c#L1117-L1118. > > Currently Matroska supports a Codec ID of V_Uncompressed which relies on = the > ColourSpace Element to detail how the uncompressed video is stored. There= is > not much documentation here but the ColourSpace references a value in AVI > (which seems to be the biCompression value of BITMAPINFOHEADER. I=E2=80= =99d like to > clean up this documentation but would like something more clear than a va= gue > reference to AVI. > > Is there a reliable authority of fourcc=E2=80=99s that we can reference t= o There's a http://fourcc.org/ but it's nothing official. > uncompressed video or should ColourSpace be defined with an enumeration l= ist > which provides a list of value (such as I420, NV12, NV21, RGBA, UYVY, Y41= B, > Y42B, Y800, YUV9, YUY2, YVYU) along with their definitions? Sometimes vendors use different names for the same thing. http://www.fourcc.org/yuv.php There may be other formats (XYZ?) not listed on that website that may be usefull as uncompressed. We may need to maintain a list of uncompressed formats (audio and video) like we maintain a list of known codecs and their mapping. > Also I can only find occasions of ColourSpace used when the Codec is > V_Uncompressed. Are there instances when it is valid to use ColourSpace w= hen > the Codec ID is not V_Uncompressed. Was there any reason that ColourSpace > was used to store the fourcc, rather than using CodecPrivate as done with > VFW? Because CodecPrivate is not meant to be parsed and analyzed for the user. All values at the container level may be. Also the ColourSpace may be useful for compressed formats as well. > Dave Rice > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Wed Apr 26 01:47:13 2017 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 D404D131A01 for ; Wed, 26 Apr 2017 01:47:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1tofEyeQedjd for ; Wed, 26 Apr 2017 01:47:09 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ECC51319EB for ; Wed, 26 Apr 2017 01:47:09 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id k11so60550803ywb.1 for ; Wed, 26 Apr 2017 01:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IRDMk7GjCGHZ1x+GaiHGoi3WP/cbCys+nQXID66oc1g=; b=d+ns8HsFmPopbfGtx7xh1TEGnZUSPKDp3+HgRemXFh20HtG3XiklEX+nooVQbVfMKf mLuuEexfhKCsGcecAkbwOxtQeeanjdhRrr7C4Qfz/LulnLwC6aQGCeLpGANB/DI7RJq8 LsbPNJwlMw7qM6dn5L8WtqIPM8/ImZ42RNhCwUor6feOSG7Ufq4FMlc9hNHjb0J0MRrm EDE8vNT9D9AnXRJCLzsLwAHTqViaIK+eu2xAS2Nkph3xgwbWbp/22LZ9YfGJ0a1JaeEO kiW/bwOF5H9SuWSyyH2rLTdWzjfp/IyEBd0gGhgttUBTcXuzbQHWmWEZrowOD/bu4PkB BPSQ== 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=IRDMk7GjCGHZ1x+GaiHGoi3WP/cbCys+nQXID66oc1g=; b=D6aTUkGY5qrcnQqqnQ7l9ASnuy3xOVLu1Zp+lum38Xf2OGoMPYOx7kIJg9P1NgGKKC wTVvVuQGx2u0OOgAROL52jhVt7M0OJsVNaJuUHFRMZcVK1eG62gXmTATLFQPWjeuIlwP GvU0EW/+b44kRBRS88jDAXyJugt6AMXMb/aYpeTqVqK8SImoaxq/G/+f98OB/qySbVyI Pc0kDi5uYneYKm35kNOamEVc9qqgamr4xlQZVJBFDfNyxCeM6wB7AbWPE6HyqMoUu+13 rBh9uNMPuGim4EcuCs2hLWDXrgE/gW+mriJ2WQ6xaxqDT/nGDpTCMNctFoDbHMYY/OwV 19/A== X-Gm-Message-State: AN3rC/5LeRr3C4WFLR0qs8Zg26HVy1ArwbZEnWMjsnGU513YP2ZIlHNk wCF56zTA7OCbYuTGC4woPk5Mq21Ltw== X-Received: by 10.129.102.130 with SMTP id a124mr12189002ywc.266.1493196428485; Wed, 26 Apr 2017 01:47:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.4.215 with HTTP; Wed, 26 Apr 2017 01:47:08 -0700 (PDT) In-Reply-To: References: <90625ABD-48AE-41CC-AFE1-24BD57A62415@dericed.com> From: Steve Lhomme Date: Wed, 26 Apr 2017 10:47:08 +0200 Message-ID: To: Matt Gruenke Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Cellar] TrackTypes for non-standard data formats 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, 26 Apr 2017 08:47:11 -0000 2017-02-27 3:21 GMT+01:00 Matt Gruenke : > Where are the complex & ancillary TrackTypes described? If ancillary tracks 'complex' is track type 3: https://github.com/Matroska-Org/matroska-specification/blob/master/ebml_matroska.xml#L198 Ancillary is not defined yet. IMO it's less generic/custom than Complex. > can be named, that would probably be sufficient. I think the CodecID should > describe only how the data is encoded, which might be insufficient to convey > its meaning or relationship to the other tracks. There's 'TrackOverlay' that defined one type of relation between tracks but that's it. I think it would be hard to describe all kinds relations that can exist between custom (non standard) tracks and other custom tracks. > In all of the examples I mentioned, I can foresee cases where these would > need to be time-stamped frames that might have a different sampling rate > than the video or audio streams, if present. In fact, this is the case for > one camera I've used, where the depth sensor operates at a different rate > than the primary image sensor. There is no 'sampling rate' in Matroska. Only the timestamp of a Block matters. So audio/video/other don't need to share anything in that regard. > > Matt > > > On Sun, Feb 26, 2017 at 11:24 AM, Steve Lhomme wrote: >> >> In general when there's something you want to multiplex there's always >> the "complex" type in which you may put whatever you want. >> >> But it is recommended to use existing things or create what's missing. >> >> 2017-01-25 5:39 GMT+01:00 Matt Gruenke : >> > If it'd help to deal with specifics, some examples I have in mind are >> > scene >> > geometry (e.g. point clouds, polygonal meshes, Z-buffer), camera pose >> > (e.g. >> > position & orientation as vector & quaternion pairs, GPS coordinates, >> > compass readings), and various telemetry data (plenty of examples at >> > https://en.wikipedia.org/wiki/Telemetry ). >> >> For things like camera position/GPS, if it doesn't change, a tag on a >> chapter for that specific thing is probably better. It's easier to >> lookup such information among files (theoretically). But obviously >> there are lots of cases where this is not the case and we probably >> need a kind of track specific for that (sport cameras like Go Pros >> come to mind) with proper definition. Maybe the ancillary name is >> generic enough to cover all these and then depending on the codec you >> know what kind of information you would get. >> >> For the scene geometry I'm not familiar with this. Does it need to be >> interleaved with the audio/video things ? A chapter tag is not enough >> ? >> >> > Although nothing specific comes to mind that wouldn't have a stream-like >> > structure, one might allow for more such things as menus and button >> > tracks. >> > Perhaps a game streaming application might use a track for player >> > information and statistics. >> > >> > In considering the utility & possible necessity of multiple, >> > application-defined TrackTypes, perhaps it's worth reviewing the >> > purposes >> > they serve. One function of TrackType is certainly to simplify semantic >> > mapping of the available tracks. To this end, it can prove more >> > reliable >> > than CodecID, since it's certainly possible to use the same encoding for >> > tracks with different semantics. >> > >> > Of course, TrackType also dictates the content model of TrackEntry. >> > Though, >> > I don't know enough about EBML to have a sense of whether it's practical >> > and >> > reasonable for applications to extend the schema to allow for custom >> > track >> > metadata. >> > >> > I guess I'd ask why *not* allow ancillary data to have one of ~8 >> > TrackTypes? >> > At the very least, I'd suggest using somewhere near the top of the >> > range. >> > Then, more values for ancillary data could be added, subsequently, while >> > keeping the range contiguous. >> > >> > >> > Matt >> > >> > >> > On Tue, Jan 24, 2017 at 10:24 AM, Dave Rice wrote: >> >> >> >> >> >> IIRC the proposal for ancillary tracks was to have Codec_IDs prefixed >> >> with >> >> "N_". If your binary data stream is wholly private with contents that >> >> are >> >> not intended to be known by the Matroska specification then perhaps a >> >> private Codec ID prefix (such a "X_") would be worthwhile to define. On >> >> the >> >> other hand, if you could be more transparent you could also consider >> >> defining your codec openly, perhaps the application specific use could >> >> have >> >> wider interest. >> >> >> >> Or could OggKate store the values you need? Perhaps it's worthwhile to >> >> define storage for a time-based metadata track such as this. >> >> >> >> Dave Rice >> > >> > >> > >> > _______________________________________________ >> > Cellar mailing list >> > Cellar@ietf.org >> > https://www.ietf.org/mailman/listinfo/cellar >> > >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman > > -- Steve Lhomme Matroska association Chairman From nobody Wed Apr 26 01:58:53 2017 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 0528C131A32 for ; Wed, 26 Apr 2017 01:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9TqRdrpEgtD for ; Wed, 26 Apr 2017 01:58:49 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EF5E131A12 for ; Wed, 26 Apr 2017 01:58:49 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id 8so7682307ybw.1 for ; Wed, 26 Apr 2017 01:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-transfer-encoding; bh=5hWQwLhUQD5rTPiXfiul9yytVMXr7W1N0dOIKDo9y7g=; b=iQxwCyjvoKUBujj7XTsdFCMRRkkVc8Scts9eIGvcvuMBQyBGNAeZz8W/63cK966hjP bZUuA57/DUsmrei++iTcLIPlR3uQTyc7Vi7UK7eCXDDlbI5kHbEjSwspLPAeMLzmmz+R jxaEj8apt5jT9G8sKdD3aBgpsrvJ5SqmyNnOs0s7BU1UF2e7XiGf/ub4WI/ESBxw/3yv M1UI712EZsZv7M+fzjsdYKXsqjONZlBw7dBDisOvNk+rTL85Ig38Dw5YMgULbp6sA01g 2HZiZUfkZ0xerEurdgMbOgtJjpFebbM0NeAdj8AFX36hVHMKD3m7F3XafH+rswsOvsq2 YE/A== 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:content-transfer-encoding; bh=5hWQwLhUQD5rTPiXfiul9yytVMXr7W1N0dOIKDo9y7g=; b=H3z7PHxOjkPOwW71YbdW+/DJRUtp+jJya1dn8f5sBnP7lrdMonjqL98foqYeA8wd/Y 5tFNeAX1OpxQihSC5uwi3nEt1iEB1uU1jrUxhm0BZGb4biuM4ga+2hE5v6eGWYkFVo0d ls3WmjWMpVbLChVGN3bk6AKBDtd53DngAFwNPsB9t5pWziUQJPvW0RhVSHD/q5TOBkrg cARqZjgTooD1gDLcKp7HHh4BgZNYUEd8G0GY+2kyJBbSxyWNp7jR5kbDQoJMf+2LwMwS HRV/l4u2KUI1rCtON9J/YfJPBqlMS1khW9UPPM+oD04zv7vQbKxYiDpRWxpLCj8RQtZK tH+w== X-Gm-Message-State: AN3rC/5Wc2M9SspOWhMs16W+KcaaswX3WGIB34WDnTXTRgZFB5ObqEU6 octPOm4zioPYKlUGXG9Q2WraOLKm3w== X-Received: by 10.37.173.131 with SMTP id z3mr12963173ybi.64.1493197128241; Wed, 26 Apr 2017 01:58:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.4.215 with HTTP; Wed, 26 Apr 2017 01:58:47 -0700 (PDT) In-Reply-To: <31b2ba89-917f-d614-5688-d86b348a10e9@mediaarea.net> References: <31b2ba89-917f-d614-5688-d86b348a10e9@mediaarea.net> From: Steve Lhomme Date: Wed, 26 Apr 2017 10:58:47 +0200 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] CodecIDs for non-standard and unregistered data formats 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, 26 Apr 2017 08:58:51 -0000 2017-02-26 17:59 GMT+01:00 Jerome Martinez : > Le 26/02/2017 =C3=A0 17:29, Steve Lhomme a =C3=A9crit : >> >> 2017-02-14 7:46 GMT+01:00 Matt Gruenke : >>> >>> Related to my recent query about TrackTypes for non-standard data >>> formats, >>> I'd like to discuss CodecIDs. I had previously raised this issue, on t= he >>> matroska-devel list, and was advised to take it up, here. In the >>> interim, >>> my thinking on the matter has evolved. >>> >>> I wonder why not allow IANA Media Types (aka MIME types), as a sub-clas= s >>> of >>> CodecIDs? Of course, the official Matroska CodecID would be preferred, >>> for >>> all formats for which one has been designated. However, this would >>> enable >>> broader use of Matroska files, including for private, >>> application-specific >>> data stream formats. >> >> The main goal of Matroska is multimedia interleaved/timestamped data. >> It's possible to have "complex" track and put in it whatever you want. >> If a timestamp is required. If it's not, using attachment is what you >> want and it already has a MIME type. >> >>> Perhaps a prefix like 'X_MEDIATYPE/' could simply be prepended to media >>> type >>> names conforming with RFC 6838. The value of TrackType would still >>> determine whether video, audio, or any other type-specific elements can >>> be >>> used in such tracks. >> >> Although tempting I think it's better to avoid interleaving all kinds >> of stuff with audio/video. You could want to embed a "video/quicktime" >> but it would not be interleaved, or you'd need to parse/mux the data >> and then it's not a clean "video/quicktime" you get anymore. > > > I don't think this is the point. > Let's imagine we don't have any AVI compatibility layer (for whatever > reason, e.g. lawyers convinced a country that BITMAPINFOHEADER / > WAVEFORMATEX structure are patented), we have no other way for having e.g= . > AMR, G719, G729 and so on because it is not defined in native Matroska co= dec > identifiers, but IANA media types have them (so a muxer could use > "X_MEDIATYPE/audio/G729"). > Consider Matt suggestion as similar to the AVI compatibility layer: this = is > just another way to define a codec identifier, also for > interleaved/timestamped video and audio content. > > Right now, I am thinking to TTML fragments (subtitles), instead of defini= ng > any TTML stuff in Matroska specs, "X_MEDIATYPE/application/ttml+xml" coul= d > be used and we rely on > https://www.iana.org/assignments/media-types/application/ttml+xml . > For crazy ideas but we should not forbid crazy ideas :), someone may want= to > use PDF as a video format with one PDF page per video frame (similar to > MJPEG), and instead of defining and requesting a "V_PDF" codec identifier= , > one would use "X_MEDIATYPE/application/pdf". But if the goal is to be played as a video, it should use the video track type. And so it should probably use a V_SOMETHING name. I don't think there's anything in the specs that forbid using your own V_SOMETHING name. Adding V_MIME/your-mime/here may be a good idea though. > At long term, a potential decision would be to delegate codec identifiers > management to IANA as they already do the job (for RTP and so on) in orde= r > to not duplicate efforts, and use Matroska list only when IANA does not f= it > Matroska needs, i.e. why should we care of having a spec about > "V_MPEG4/ISO/AVC" (note: it is not on the codec spec page but a lot used)= if > we could rely on "video/H264" registration? (this is theoretical, > "V_MPEG4/ISO/AVC" is already used. but we could do that for upcoming AV1 > defined by IETF). > > J=C3=A9r=C3=B4me --=20 Steve Lhomme Matroska association Chairman From nobody Wed Apr 26 02:13:39 2017 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 7CBDB13181B for ; Wed, 26 Apr 2017 02:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y9TiwbLLHGz9 for ; Wed, 26 Apr 2017 02:13:35 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2262129AF4 for ; Wed, 26 Apr 2017 02:13:34 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id u70so107564444ywe.2 for ; Wed, 26 Apr 2017 02:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r0PV/6tkxXZ8GnoLW/IxAee7owymzMaiCBABAubjMNc=; b=YPSG3Wuc9swm23Ik3S/sIEn+/lX3GDBESjYSUINhBfYBqUqupQZBz0zfd8BQq5fpmj z03GvreCeciG9IlUM24XAkRAMQW6vKJnguOKaTz4nwoBF0YZucV2oa0M+DY/sjJZ2CBV paPEutjkvGQpXWCXkWn8mcHQV1gd/NJc4XdtuG+uwteC6f3rQdjt8HWdVXAWS2ZLzQYX XpSQOWk+5yZxl8cK3OKUBSiPed8D8Rw03F0RSP3TFuZDP3qy4gR9f8Kp7VSYkyo07/ry /JbQhA0Eu2kCkX4o3X/Wzgr85FCZEB8THh/N4Q9kfjFDFYEvAdbxWwYJosF+VQ0wkr7G ctyw== 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=r0PV/6tkxXZ8GnoLW/IxAee7owymzMaiCBABAubjMNc=; b=GfL1lAQ5998xL2q3WPYK5+tN1znLX59Y9truit4HR6h9moDU7jgCRRUWt2EJyrLtjl 44NWEKAke0/CJSxgJBkP9U2Jd8Q4ALGdCm0211E4a1LSq5EWIJTnADvE2NGkJapX6itM wuSUXOrgwiqvUroWqy4zp1AssUtMdADUg7oOGZWWDZwH+Rp3RkCOa3Ft97l1FXVyGo2/ gu8svfJ4ILOtNC+TgD4rIDTAIQyRacv15jYh1g4jcftINa4hpuASmGqotD8VYBOtnwIB bd068nEsHTe0+Le6rsMjUO5kpY11lJVTaW+HqsoAo/gh2KoVyAJk0KsvwmQvgc0AK8AT s/kg== X-Gm-Message-State: AN3rC/4q+S2cR8B6T3zVdTPkfKc4KgvFnieWndaoDE6tC2oMZwLRpomw wjjklV5JEMf27j4+e/LxEZwjG04e5g== X-Received: by 10.129.141.76 with SMTP id w12mr11172056ywj.131.1493198014121; Wed, 26 Apr 2017 02:13:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.4.215 with HTTP; Wed, 26 Apr 2017 02:13:33 -0700 (PDT) In-Reply-To: References: From: Steve Lhomme Date: Wed, 26 Apr 2017 11:13:33 +0200 Message-ID: To: Matt Gruenke Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Cellar] CodecIDs for non-standard and unregistered data formats 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, 26 Apr 2017 09:13:37 -0000 2017-02-27 4:04 GMT+01:00 Matt Gruenke : > Let's take this example of a camera having both a visible light sensor and a > depth sensor, as well as a stereo microphone. For various reasons, its > depth sensor captures frames at different times and a different rate than > its color image sensor. I'd like to record a video file containing an audio > track, a normal video track, and a depth track. I'd like the audio and > video portions to be playable in normal video player apps. When using > enhanced apps, the depth data may also be utilized. It seems that the depth data cannot be used on their own and would need to be coupled with the video frames. So that would probably go as a BlockAddition data (or something similar as it's currently tied to the Track codec). Even if they are repeated for each video frame which the sensor doesn't change the value. > Today, most players I've tried will behave as I've described, if I simply > write the depth data using an unspecified TrackType and having a custom > CodecID. However, not all players handle it gracefully (or at all), and > there's no guarantee that the others will continue to work. > > Having a dedicated TrackType (or range, thereof) would solve one potential > problem. Perhaps the Ancillary TrackType already meets this need. > > Using nonstandard CodecIDs is another concern. I thought about schemes for > doing this, but none seemed as sensible as trying to build upon what IANA > already has. The private & vendor-specific trees provide a mechanism by > which there's at least some record of a given format's origin, which is > clearly better than it being completely ad hoc. The only downside I can see > is that two apps might start using the same media type, but with different > mappings to Matroska's syntactic structures (i.e. CodecPrivate and > CodecState). Hopefully, any encoding common enough to have independent > implementations by multiple apps would've already been promoted to have an > official Matroska CodecID, whereupon such implementation details can be > specified. It seems to me it should not be a different track, so I'll use this hypothesis. We may need to add more elements to the Track to define what each BlockAdditionID is, maybe using a MIME type or something similar. Maybe a type like depth data or extra lossless complement (for the only case I know of using BlockAddition: lossy part in the regular Block and lossless complement in the BlockAddition). >> Although tempting I think it's better to avoid interleaving all kinds of >> stuff with audio/video. > > It's a valid and understandable position, but what attracted me to the > Matroska format was my understanding that it's an open and extensible > format. If it's too resistant to innovation, then developers might seek > alternatives. This is how file formats get superseded and fall into disuse. > Therefore, I think it's important for Matroska to offer extension mechanisms > that strike the right balance between flexibility and compatibility. You're right, it's extensible. But it would be wrong if people extend it in a bogus way. For example non-interleaved data shouldn't go in the interleaved parts of the format. There are already all kinds of lesser known mechanism to extend Matroska in a clean way. We must emphasis on that. > > Matt > > > On Sun, Feb 26, 2017 at 11:29 AM, Steve Lhomme wrote: >> >> 2017-02-14 7:46 GMT+01:00 Matt Gruenke : >> > Related to my recent query about TrackTypes for non-standard data >> > formats, >> > I'd like to discuss CodecIDs. I had previously raised this issue, on >> > the >> > matroska-devel list, and was advised to take it up, here. In the >> > interim, >> > my thinking on the matter has evolved. >> > >> > I wonder why not allow IANA Media Types (aka MIME types), as a sub-class >> > of >> > CodecIDs? Of course, the official Matroska CodecID would be preferred, >> > for >> > all formats for which one has been designated. However, this would >> > enable >> > broader use of Matroska files, including for private, >> > application-specific >> > data stream formats. >> >> The main goal of Matroska is multimedia interleaved/timestamped data. >> It's possible to have "complex" track and put in it whatever you want. >> If a timestamp is required. If it's not, using attachment is what you >> want and it already has a MIME type. >> >> > Perhaps a prefix like 'X_MEDIATYPE/' could simply be prepended to media >> > type >> > names conforming with RFC 6838. The value of TrackType would still >> > determine whether video, audio, or any other type-specific elements can >> > be >> > used in such tracks. >> >> Although tempting I think it's better to avoid interleaving all kinds >> of stuff with audio/video. You could want to embed a "video/quicktime" >> but it would not be interleaved, or you'd need to parse/mux the data >> and then it's not a clean "video/quicktime" you get anymore. >> >> > Thank you for considering my suggestion. >> > >> > >> > Matt >> > >> > >> > _______________________________________________ >> > Cellar mailing list >> > Cellar@ietf.org >> > https://www.ietf.org/mailman/listinfo/cellar >> > >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman > > -- Steve Lhomme Matroska association Chairman From nobody Wed Apr 26 07:14:22 2017 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 76A5212EB3B for ; Wed, 26 Apr 2017 07:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 h1RJ5wj4W9Re for ; Wed, 26 Apr 2017 07:14:19 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9FDB12EB39 for ; Wed, 26 Apr 2017 07:08:36 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id g66so39738728ite.1 for ; Wed, 26 Apr 2017 07:08:36 -0700 (PDT) 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=eGtUr9kb/rmbEdW1fGPPiPhGTm+J9sZDihyumPnWGbU=; b=CBsefjU5bPVatNySmpCVuwUeHzi5aI3obconjJ62/joK+ZGP8MNhGtzJt2MVO8Q3gI Q+ZujuVrjQrvZAIsOwQy5tDErQLdR2ZfdXPoM1UZJhrC3GCiOtHYB68aLVpsKPMR8s0Q qeFVtmsgpNDFkC+z8abhXB0HoNo+cD/7h49MO5vwjpQvNHpedz5XDet/S4XO5+/tEHJW Hgit3+8w3HVMpr9BAuVWuU39LfI8l497TZesxsBK1x8KIkcfJ2S6ryF+usF1ZzY8s7qT o8anKg5zUh+p6Yz4tY+J+FJS0xMaAaFuUCp/aO+OU7e+na5385Nd9JaTQU1e0GGvSmsL zECQ== 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=eGtUr9kb/rmbEdW1fGPPiPhGTm+J9sZDihyumPnWGbU=; b=J9jxOZuzGxxZQzwwk6fdpA7kvFR3ZQek+qlF+K5ih5tuT1Yp3F3dVSQLaDxQvDvuP0 fWNxA3LCnjaGdOXFIGFFfwF+Pf0tQboQF6RVYS7s5FWz2mRDxi1Edvg8vD3LHu4pkN7W VApReW9DjDSOAeBwFsEkEBjuc64ZM0OtY5ycful6Z9INRDREepsu392gRLzcn6cGWl1z klxRkvDH/qqhd4jYRe+vGuXsAbTh6roRHEqk+bJGz4kwyY4Rk2yAyMZvUTcjXcRQhvBG 8YTyIfYL7VkrXgirarFNMS32/xM9HpyNmfvMqfpfwmBFMSNFgA+S+Kb30MsaYJilJpyE BMjg== X-Gm-Message-State: AN3rC/5R9vOagpSV8pKggi1aekt+DOuegIkyhBGM8+rr/KdqOZcJ2ru/ 1fOlXZpzfdMMu/QnMQJDkWUpQVMsMn8m X-Received: by 10.36.98.21 with SMTP id d21mr1230696itc.94.1493215715808; Wed, 26 Apr 2017 07:08:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.79.159.16 with HTTP; Wed, 26 Apr 2017 07:08:35 -0700 (PDT) In-Reply-To: References: <149245922583.17799.10588076244988604919.idtracker@ietfa.amsl.com> From: Ashley Blewer Date: Wed, 26 Apr 2017 10:08:35 -0400 Message-ID: To: Steve Lhomme Cc: Jerome Martinez , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary=001a113f6a24505fd3054e1260f8 Archived-At: Subject: Re: [Cellar] cellar - New Meeting Session Request for IETF 99 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, 26 Apr 2017 14:14:21 -0000 --001a113f6a24505fd3054e1260f8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Fortunately for everyone on the list interested in this meeting but can't hop over to Prague, IETF does an excellent job of ensuring remote participation! Ashley On Wed, Apr 26, 2017 at 4:13 AM, Steve Lhomme wrote: > I'd be interrested but can't cover (most of) the cost of an IETF > meeting. Also I don't know yet my plans for this summer. But I can > adjust if we all go a few days and get things going forward. > > 2017-04-17 22:11 GMT+02:00 Jerome Martinez : > > I'll be present. > > > > > > Le 17/04/2017 =C3=A0 22:03, Tessa Fallon a =C3=A9crit : > > > > For the IETF 99 July 16-21 (https://www.ietf.org/meeting/99/), I've > > requested 1.5 hours for a CELLAR meeting, estimating a max of 50 people= . > > Based on last year's meeting in Berlin, this seems sufficient to me. > > > > I'd be interested in getting an informal count from the list of how man= y > > folks are considering attending--I know it's early! > > > > Thanks, > > > > Tessa > > > > On Mon, Apr 17, 2017 at 4:00 PM, "IETF Meeting Session Request Tool" > > wrote: > >> > >> > >> > >> A new meeting session request has just been submitted by Tessa Fallon,= a > >> Chair of the cellar working group. > >> > >> > >> --------------------------------------------------------- > >> Working Group Name: Codec Encoding for LossLess Archiving and Realtime > >> transmission > >> Area Name: Applications and Real-Time Area > >> Session Requester: Tessa Fallon > >> > >> Number of Sessions: 1 > >> Length of Session(s): 1.5 Hours > >> Number of Attendees: 50 > >> Conflicts to Avoid: > >> First Priority: netvc > >> Second Priority: rtcweb > >> Third Priority: codec > >> > >> > >> People who must be present: > >> Ben Campbell > >> Tim Terriberry > >> Tessa Fallon > >> > >> Resources Requested: > >> > >> Special Requests: > >> > >> --------------------------------------------------------- > >> > > > > > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > > > -- > Steve Lhomme > Matroska association Chairman > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --001a113f6a24505fd3054e1260f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Fortunately for everyone on the list interested in this me= eting but can't hop over to Prague, IETF does an excellent job of ensur= ing remote participation!

Ashley

On Wed, Apr 26, 2017 at 4:1= 3 AM, Steve Lhomme <slhomme@matroska.org> wrote:
I'd be interrested but can't cover (most = of) the cost of an IETF
meeting. Also I don't know yet my plans for this summer. But I can
adjust if we all go a few days and get things going forward.

2017-04-17 22:11 GMT+02:00 Jerome Martinez <jerome@mediaarea.net>:
> I'll be present.
>
>
> Le 17/04/2017 =C3=A0 22:03, Tessa Fallon a =C3=A9crit :
>
> For the IETF 99 July 16-21 (https://www.ietf.org/meeting/9= 9/), I've
> requested 1.5 hours for a CELLAR meeting, estimating a max of 50 peopl= e.
> Based on last year's meeting in Berlin, this seems sufficient to m= e.
>
> I'd be interested in getting an informal count from the list of ho= w many
> folks are considering attending--I know it's early!
>
> Thanks,
>
> Tessa
>
> On Mon, Apr 17, 2017 at 4:00 PM, "IETF Meeting Session Request To= ol"
> <session_req= uest_developers@ietf.org> wrote:
>>
>>
>>
>> A new meeting session request has just been submitted by Tessa Fal= lon, a
>> Chair of the cellar working group.
>>
>>
>> ---------------------------------------------------------
>> Working Group Name: Codec Encoding for LossLess Archiving and Real= time
>> transmission
>> Area Name: Applications and Real-Time Area
>> Session Requester: Tessa Fallon
>>
>> Number of Sessions: 1
>> Length of Session(s):=C2=A0 1.5 Hours
>> Number of Attendees: 50
>> Conflicts to Avoid:
>>=C2=A0 First Priority:=C2=A0 netvc
>>=C2=A0 Second Priority:=C2=A0 rtcweb
>>=C2=A0 Third Priority:=C2=A0 codec
>>
>>
>> People who must be present:
>>=C2=A0 =C2=A0Ben Campbell
>>=C2=A0 =C2=A0Tim Terriberry
>>=C2=A0 =C2=A0Tessa Fallon
>>
>> Resources Requested:
>>
>> Special Requests:
>>
>> ---------------------------------------------------------
>>
>
>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
>
>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
>



--
Steve Lhomme
Matroska association Chairman

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

--001a113f6a24505fd3054e1260f8-- From nobody Wed Apr 26 12:43:50 2017 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 46268129450 for ; Wed, 26 Apr 2017 12:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 CcAicP5Vn5hp for ; Wed, 26 Apr 2017 12:43:47 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4974F1293F4 for ; Wed, 26 Apr 2017 12:43:46 -0700 (PDT) Received: from [10.0.0.11] (1360030002.d-dsl.at [::ffff:81.16.105.50]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Wed, 26 Apr 2017 21:44:06 +0200 id 0000000000000045.000000005900F886.00004F61 Message-ID: <5900F86F.2080502@das-werkstatt.com> Date: Wed, 26 Apr 2017 21:43:43 +0200 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Codec Encoding for LossLess Archiving and Realtime transmission References: <149245922583.17799.10588076244988604919.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] cellar - New Meeting Session Request for IETF 99 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, 26 Apr 2017 19:43:49 -0000 I'd be participating remotely, too :D Cheers, Peter On 04/26/2017 04:08 PM, Ashley Blewer wrote: > Fortunately for everyone on the list interested in this meeting but can't > hop over to Prague, IETF does an excellent job of ensuring remote > participation! > > Ashley > From nobody Thu Apr 27 01:29:59 2017 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 8D4321243FE for ; Thu, 27 Apr 2017 01:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hku0RGVjDp0X for ; Thu, 27 Apr 2017 01:29:55 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 2C24F126B6D for ; Thu, 27 Apr 2017 01:29:55 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id u70so12185483ywe.2 for ; Thu, 27 Apr 2017 01:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QlHjvgXOpR8qOGYPqONHWLrlk9LPhJ7e10btE5mNEAc=; b=K7kTwZpFHsoRSSLofLMHE0j3vtC940doJ4E4ycW3W84HajmdHLcSm+c88MTKjobiDq H/6G9mhT+8d/xog7e0GZcH5k+8uznz0IRUEv1ixetOpnL76Byg8XgVA52mE1uNkZeNMh VQis5CMK+O0kN4gJLNMEvCs5VIt+CBFMFbK8KEhAY56EDN6zOsPy1sbaqKTqdqjiBq68 ntsg2Hcd6yFIdmKgVSyU9qoawa257Vk3fmcDcTdY8kFCk84fmeDedOv6nzrx1W1xqdc1 iAsrNa3sfnxxZG4cYwaKK/m0c+bTUvFsIBs4IRY4alFl3D002IHH3nSApden1SVHo0Ww 3jwA== 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=QlHjvgXOpR8qOGYPqONHWLrlk9LPhJ7e10btE5mNEAc=; b=Dlzh6hnEj/hVWmIl4/VJz6jqn37fuCu+pKAh/c/lFQki/AuhSCiVUfMbKEcmQ1qbIA +0NuhBxJNj3QNOEVUi2K/czYfSbkj0y3CfF0uiVWGHrvvpOl4Fu0FGtONddE31MiTAhg 5lWtDq/yQl0gMIgZOKH5gJ9Q6DXqwgxrnB+CEA+oRhNReAVNay44sQE7l+MPXqt6+D2o NNneSC3cdUn7Jvd40znyE7iNkFs/eb+JDh0jMNhWm+qeuI3KL7MBeZcZSdUMgeRBHBJY n5EuRTmn9AYMSG/JqwlxifuM1aqbJmYRvuqQj64m2Evb/idMviteLRqiw+Qgi+jVRKe5 kKvg== X-Gm-Message-State: AN3rC/7nwUVei+1upH7QPtuY16JuiP3hmEXZAW9yj54t8a4AU3thfhU2 Hnng3dhNzoKM5P/0ZuT34igszWLkig== X-Received: by 10.129.106.4 with SMTP id f4mr3387656ywc.210.1493281794244; Thu, 27 Apr 2017 01:29:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.83.4.215 with HTTP; Thu, 27 Apr 2017 01:29:53 -0700 (PDT) In-Reply-To: <5900F86F.2080502@das-werkstatt.com> References: <149245922583.17799.10588076244988604919.idtracker@ietfa.amsl.com> <5900F86F.2080502@das-werkstatt.com> From: Steve Lhomme Date: Thu, 27 Apr 2017 10:29:53 +0200 Message-ID: To: "Peter B." Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Cellar] cellar - New Meeting Session Request for IETF 99 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, 27 Apr 2017 08:29:57 -0000 I'll probably do that as well. 2017-04-26 21:43 GMT+02:00 Peter B. : > I'd be participating remotely, too :D > > > Cheers, > Peter > > On 04/26/2017 04:08 PM, Ashley Blewer wrote: >> Fortunately for everyone on the list interested in this meeting but can't >> hop over to Prague, IETF does an excellent job of ensuring remote >> participation! >> >> Ashley >> > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Thu Apr 27 03:40:36 2017 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 C6F65127B31 for ; Thu, 27 Apr 2017 03:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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, 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 giw72Wdqj-ov for ; Thu, 27 Apr 2017 03:40:33 -0700 (PDT) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38D5C126C89 for ; Thu, 27 Apr 2017 03:40:32 -0700 (PDT) Received: from smtp5.infomaniak.ch (smtp5.infomaniak.ch [83.166.132.18]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v3RAeUi6025147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 27 Apr 2017 12:40:30 +0200 Received: from Castor.local (rrcs-70-60-109-178.midsouth.biz.rr.com [70.60.109.178]) (authenticated bits=0) by smtp5.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v3RAeSkJ054069 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Thu, 27 Apr 2017 12:40:30 +0200 Date: Thu, 27 Apr 2017 12:40:29 +0200 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: Re: [Cellar] cellar - New Meeting Session Request for IETF 99 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, 27 Apr 2017 10:40:36 -0000 Please count me as remote attendee. Thank you! Reto Steve Lhomme wrote: >I'll probably do that as well. > >2017-04-26 21:43 GMT+02:00 Peter B. : >> I'd be participating remotely, too :D >> >> >> Cheers, >> Peter >> >> On 04/26/2017 04:08 PM, Ashley Blewer wrote: >>> Fortunately for everyone on the list interested in this meeting but=20 >can't >>> hop over to Prague, IETF does an excellent job of ensuring remote >>> participation! >>> >>> Ashley >>> >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar > From nobody Thu Apr 27 19:55:33 2017 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 3F6CB1296B0 for ; Thu, 27 Apr 2017 19:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6KNZaXr5HHv for ; Thu, 27 Apr 2017 19:55:29 -0700 (PDT) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E2951293F4 for ; Thu, 27 Apr 2017 19:53:20 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id t7so7546133pgt.3 for ; Thu, 27 Apr 2017 19:53:20 -0700 (PDT) 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=b7fOW1f3fcGggJq5UdQcW2cXIXbPuWZWPnmlHmD+0Q4=; b=FFJImDI8BXTYKkG1Vo55jsWK4gzOJT+UmLAY6kl220qSBeiDvx/3bVPaSg8w+fY4/r JLhemoW7Oc/CPUJlpLKSQbAntNI9ymq6eASUTdYcTCkg0MVnih61RxwuKgY7h16xBUpq LjRWCHM8fHnGZMHAMDewjQF0zePAEnIx0YweNlMu/FRKLWAqUKL5F8KLqDB+0tGZLM/c ZByy0ITLkt0u7FqY+l9QYA1PvpBuXaraMIYGYDAbCTq6jrR1r4HyuDDWM+RE/zDsIHug x7kUdiRfodNxTgVZkh2WXOF4FNBpoMqi53K3eG0HQfQW5zDRk9XE47pHYBAJPxCUOTHq Tj4w== 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=b7fOW1f3fcGggJq5UdQcW2cXIXbPuWZWPnmlHmD+0Q4=; b=RlJyaDpsM7Wlr+ejYKg49hgc5u3kj/iREn7BCmiDKFIGHo7bDvuPMKpkwvTn3V65m6 Fi6wZl8b0FGAQT8dJ1aeEcSvivRQ8xUHCTUvVMVH8orGpJYfOOPahZb0njfxmZdwBZP2 yVgtSm53TFnSkItEKztKFfDd/lLARhuh9sV01/VuQcfTeSLl4jL9OtBUHF/nB/VSpqHL uxdZpDhnPzghs6jZhZNlLZSkveOSftA1pFpVPc1mZ4BrZoFOuE7mGd8ZuiXRow1RZT3o j4vkZoBX7rH1zNCsEOgoVIlPL/nPcoCPrFmBZYO1fTkK0YJGQMod+HoJlNRO0gpjRSVP BBzQ== X-Gm-Message-State: AN3rC/710vRbsAPTtiiig4QIKWi6OQ4LtgeKj8r1i9/gM1QfbVymAvCT 0rghllTMYN8K1Vdfs0dP4SDxsN4BYQ== X-Received: by 10.99.163.67 with SMTP id v3mr9294646pgn.206.1493347999916; Thu, 27 Apr 2017 19:53:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.148.101 with HTTP; Thu, 27 Apr 2017 19:53:19 -0700 (PDT) In-Reply-To: References: <90625ABD-48AE-41CC-AFE1-24BD57A62415@dericed.com> From: Matt Gruenke Date: Thu, 27 Apr 2017 22:53:19 -0400 Message-ID: To: Steve Lhomme Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary=f4030436399c0faca7054e312dbe Archived-At: Subject: Re: [Cellar] TrackTypes for non-standard data formats 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: Fri, 28 Apr 2017 02:55:32 -0000 --f4030436399c0faca7054e312dbe Content-Type: text/plain; charset=UTF-8 On Wed, Apr 26, 2017 at 4:47 AM, Steve Lhomme wrote: > 2017-02-27 3:21 GMT+01:00 Matt Gruenke : > > > In all of the examples I mentioned, I can foresee cases where these would > > need to be time-stamped frames that might have a different sampling rate > > than the video or audio streams, if present. In fact, this is the case > for > > one camera I've used, where the depth sensor operates at a different rate > > than the primary image sensor. > > There is no 'sampling rate' in Matroska. Only the timestamp of a Block > matters. So audio/video/other don't need to share anything in that > regard. > What I meant by 'sampling rate' wasn't that there would be some exact frame rate. I simply meant that there might not be a 1-to-1 relationship between frames of different types. Again, to use the example of a certain camera with a depth sensor, it can capture RGB frames at a different rate than depth frames. I mention this simply to point out that the depth frames seem like they belong in their own track. Matt --f4030436399c0faca7054e312dbe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 26, 2017 at 4:47 AM, Steve Lhomme <slhomme@matroska.org>= wrote:
2017-02-2= 7 3:21 GMT+01:00 Matt Gruenke <matt.gruenke@gmail.com>:
=C2=A0
> = In all of the examples I mentioned, I can foresee cases where these would > need to be time-stamped frames that might have a different sampling ra= te
> than the video or audio streams, if present.=C2=A0 In fact, this is th= e case for
> one camera I've used, where the depth sensor operates at a differe= nt rate
> than the primary image sensor.

There is no 'sampling rate' in Matroska. Only the timestamp = of a Block
matters. So audio/video/other don't need to share anything in that
regard.

What I meant by 'sampling r= ate' wasn't that there would be some exact frame rate.=C2=A0 I simp= ly meant that there might not be a 1-to-1 relationship between frames of di= fferent types.=C2=A0 Again, to use the example of a certain camera with a d= epth sensor, it can capture RGB frames at a different rate than depth frame= s.

I mention this simply to point out that the dep= th frames seem like they belong in their own track.


Matt

--f4030436399c0faca7054e312dbe-- From nobody Thu Apr 27 20:18:40 2017 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 2E6E8128B88 for ; Thu, 27 Apr 2017 20:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fu8Ruk3J_FIE for ; Thu, 27 Apr 2017 20:18:37 -0700 (PDT) Received: from mail-pf0-x231.google.com (mail-pf0-x231.google.com [IPv6:2607:f8b0:400e:c00::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B54128DF6 for ; Thu, 27 Apr 2017 20:16:42 -0700 (PDT) Received: by mail-pf0-x231.google.com with SMTP id 194so42335258pfv.3 for ; Thu, 27 Apr 2017 20:16:42 -0700 (PDT) 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=MrhNdVIctwFb3i5e9ERrnks91ZRoJdvWDQuQ9pllBdg=; b=qcc9QtnpE3CbUhP578OgXeJb+ImgqOw6lYZ06kCd5unutE+muORtkr+dKjKVP2nf6R 9inVH9cVCRv9kdTZhioNvOQQK4HuK4M/Mv7x6IoH/eXgeNSJRGWmnJw7Qr8pVAntAzrF lUam3/zozFOiEV+llgmnpoWZfbNHeHBAUIVasVQYNTaokxDIjd+tuut+RQVrqmQKJy4O ZCBWJ8MCW1zb9gmTkwRtmk0BjAUX+HQichphbXhTlqXIzTco7GoGYUDSKFmqrZH6dSEn IAlXth5V6E2cUJhmcFqA1xTJOY3QzTfXsgDo29tnj/2PL6d0yWgXBEGRTnHx+ydT7VzM hmIw== 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=MrhNdVIctwFb3i5e9ERrnks91ZRoJdvWDQuQ9pllBdg=; b=NVVni7XSYlGYTejpQvDbIl2IU7dCUXJEmaOZSIsN50d3xjKmEUyHeuugn9XQWeNUbB eZ0HpmdNA3w5m2RUnzlScMSF6l8DoaXDhvtRAoqpNxs+RxpinVj05Jkes+rSqm1b7mOY hlR6pfPLFUdojAiAweysNEn+0/M+Rt5NY30StGA8+f/bJaGiTLZ27QzSSrvPWLGll2ph 92L2T1zWuAZ/pcRjqk2BbfwlRuYVTp9cdhipWH2f1UZRoawIllUooCI8EdUIG5SjDM3N Wkj/vzunl/taT1U5RVHNZLe0vJ71c6EOGrQgwHZl6Jzwv+7Z7G/Ke8giMN5NsopQsIVu LTpQ== X-Gm-Message-State: AN3rC/6EwjIlZc5yxBAJPW2usmSFl2j/ciuXxiKDeYnGDdNMaC7m9NyB Qi5mW8EGe+gzJ8PKdLc1kE9vC44SYg== X-Received: by 10.99.114.3 with SMTP id n3mr9613948pgc.130.1493349402192; Thu, 27 Apr 2017 20:16:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.148.101 with HTTP; Thu, 27 Apr 2017 20:16:41 -0700 (PDT) In-Reply-To: References: From: Matt Gruenke Date: Thu, 27 Apr 2017 23:16:41 -0400 Message-ID: To: Steve Lhomme Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary=f403045ccfe8a4b1ee054e318036 Archived-At: Subject: Re: [Cellar] CodecIDs for non-standard and unregistered data formats 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: Fri, 28 Apr 2017 03:18:39 -0000 --f403045ccfe8a4b1ee054e318036 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 26, 2017 at 5:13 AM, Steve Lhomme wrote: > 2017-02-27 4:04 GMT+01:00 Matt Gruenke : > > Let's take this example of a camera having both a visible light sensor > and a > > depth sensor, as well as a stereo microphone. For various reasons, its > > depth sensor captures frames at different times and a different rate than > > its color image sensor. I'd like to record a video file containing an > audio > > track, a normal video track, and a depth track. I'd like the audio and > > video portions to be playable in normal video player apps. When using > > enhanced apps, the depth data may also be utilized. > > It seems that the depth data cannot be used on their own and would > need to be coupled with the video frames. So that would probably go as > a BlockAddition data (or something similar as it's currently tied to > the Track codec). Even if they are repeated for each video frame which > the sensor doesn't change the value. > I'd say it's no more or less coupled than audio. If a movie has an audio track, people will typically watch the video with the audio, but sometimes without. They rarely listen to the audio without the video, but they could (and some do). I think it's a good analogy for depth - it's an optional augmentation of the video and could be paired with one of several different video tracks (e.g. if the same file has a depth track and video from both a visible light & a thermal sensor). More importantly, if the depth frames are taken at slightly different times than video, it's critical they have timestamps which reflect this. Furthermore, it would be a really problematic to repeat the same data on subsequent frames, in cases where no new depth frames have been captured in between. These kinds of sins some people committed with video created substantial headaches for video processing. Depth must be synchronized with video as precisely as possible. Any fudging of timestamps or duplication of data will interfere with attempts to interpolate the depth frames to match the video (or vice versa). It might not be feasible or desirable to perform this interpolation at capture time. Matt --f403045ccfe8a4b1ee054e318036 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Apr 26, 2017 at 5:13 AM, Steve Lhomme <slhomme@matroska.org>= wrote:
2017-02-2= 7 4:04 GMT+01:00 Matt Gruenke <matt.gruenke@gmail.com>:
> Let's take this example of a camera having both a visible light se= nsor and a
> depth sensor, as well as a stereo microphone.=C2=A0 For various reason= s, its
> depth sensor captures frames at different times and a different rate t= han
> its color image sensor.=C2=A0 I'd like to record a video file cont= aining an audio
> track, a normal video track, and a depth track.=C2=A0 I'd like the= audio and
> video portions to be playable in normal video player apps.=C2=A0 When = using
> enhanced apps, the depth data may also be utilized.

It seems that the depth data cannot be used on their own and would need to be coupled with the video frames. So that would probably go as
a BlockAddition data (or something similar as it's currently tied to the Track codec). Even if they are repeated for each video frame which
the sensor doesn't change the value.

I'd say it's no more or less coupled than audio.=C2=A0 If a movie= has an audio track, people will typically watch the video with the audio, = but sometimes without.=C2=A0 They rarely listen to the audio without the vi= deo, but they could (and some do).=C2=A0 I think it's a good analogy fo= r depth - it's an optional augmentation of the video and could be paire= d with one of several different video tracks (e.g. if the same file has a d= epth track and video from both a visible light & a thermal sensor).

More importantly, if the depth frames are taken at sl= ightly different times than video, it's critical they have timestamps w= hich reflect this.=C2=A0 Furthermore, it would be a really problematic to r= epeat the same data on subsequent frames, in cases where no new depth frame= s have been captured in between.=C2=A0 These kinds of sins some people comm= itted with video created substantial headaches for video processing.
<= div>
Depth must be synchronized with video as precisely as po= ssible.=C2=A0 Any fudging of timestamps or duplication of data will interfe= re with attempts to interpolate the depth frames to match the video (or vic= e versa).=C2=A0 It might not be feasible or desirable to perform this inter= polation at capture time.


Matt

--f403045ccfe8a4b1ee054e318036-- From nobody Fri Apr 28 17:39:50 2017 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 AC3BA126D05 for ; Fri, 28 Apr 2017 17:39:48 -0700 (PDT) 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, 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 6m6v4Rn6etkl for ; Fri, 28 Apr 2017 17:39:46 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C609112956B for ; Fri, 28 Apr 2017 17:37:36 -0700 (PDT) Received: from [172.56.2.170] (port=41821 helo=[172.20.10.2]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1d4GOB-000bIC-5C; Fri, 28 Apr 2017 20:37:36 -0400 From: Dave Rice Message-Id: <52163786-3428-4524-A772-0C5E121D991A@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C5F9A4E9-0685-4D15-AC89-A5B5ADF953E6" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Fri, 28 Apr 2017 20:37:27 -0400 In-Reply-To: Cc: Steve Lhomme , Codec Encoding for LossLess Archiving and Realtime transmission To: Matt Gruenke References: <90625ABD-48AE-41CC-AFE1-24BD57A62415@dericed.com> X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] TrackTypes for non-standard data formats 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, 29 Apr 2017 00:39:49 -0000 --Apple-Mail=_C5F9A4E9-0685-4D15-AC89-A5B5ADF953E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Apr 27, 2017, at 10:53 PM, Matt Gruenke = wrote: >=20 > On Wed, Apr 26, 2017 at 4:47 AM, Steve Lhomme > wrote: > 2017-02-27 3:21 GMT+01:00 Matt Gruenke >: > =20 > > In all of the examples I mentioned, I can foresee cases where these = would > > need to be time-stamped frames that might have a different sampling = rate > > than the video or audio streams, if present. In fact, this is the = case for > > one camera I've used, where the depth sensor operates at a different = rate > > than the primary image sensor. >=20 > There is no 'sampling rate' in Matroska. Only the timestamp of a Block > matters. So audio/video/other don't need to share anything in that > regard. >=20 > What I meant by 'sampling rate' wasn't that there would be some exact = frame rate. I simply meant that there might not be a 1-to-1 = relationship between frames of different types. Again, to use the = example of a certain camera with a depth sensor, it can capture RGB = frames at a different rate than depth frames. >=20 > I mention this simply to point out that the depth frames seem like = they belong in their own track. I regards to this discussion, I ended up reviewing = https://tools.ietf.org/html/rfc6648 = which covers the deprecation of = the "X-" prefix as a method to distinguish standardized and = unstandardized descriptions. In particular I think the recommendations = here https://tools.ietf.org/html/rfc6648#section-3 = make sense to follow in = the use of Codec IDs, in that a developer of an unstandardized codec id = should do so with an assumption that that Codec ID may become = standardized. I sent a pull request for review at = https://github.com/Matroska-Org/matroska-specification/pull/117 = , which = adds this to the Codec Mapping page. ## Recommendations for the Creation of New Codec Mappings Creators of new Codec Mappins to be used in the context of Matroska: - SHOULD assume that all Codec Mappings they create might become = standardized, public, commonly deployed, or usable across multiple = implementations. - SHOULD employ meaningful values for Codec ID and Codec Name that they = have reason to believe are currently unused. - SHOULD NOT prefix their Codec ID with "X-" or similar constructs. These recommendations are based upon Section 3 of [@!RFC6648]. Best Regards, Dave Rice --Apple-Mail=_C5F9A4E9-0685-4D15-AC89-A5B5ADF953E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Apr 27, 2017, at 10:53 PM, Matt Gruenke <matt.gruenke@gmail.com> wrote:

On Wed, = Apr 26, 2017 at 4:47 AM, Steve Lhomme <slhomme@matroska.org> wrote:
2017-02-27 3:21 GMT+01:00 Matt Gruenke <matt.gruenke@gmail.com>:
 
> In all of the examples I = mentioned, I can foresee cases where these would
> need to be time-stamped frames that might have a different sampling = rate
> than the video or audio streams, if present.  In fact, this is = the case for
> one camera I've used, where the depth sensor operates at a = different rate
> than the primary image sensor.

There is no 'sampling rate' in Matroska. Only the timestamp of a = Block
matters. So audio/video/other don't need to share anything in that
regard.

What I meant by 'sampling rate' wasn't = that there would be some exact frame rate.  I simply meant that = there might not be a 1-to-1 relationship between frames of different = types.  Again, to use the example of a certain camera with a depth = sensor, it can capture RGB frames at a different rate than depth = frames.

I = mention this simply to point out that the depth frames seem like they = belong in their own track.

I regards to this discussion, I ended up = reviewing https://tools.ietf.org/html/rfc6648 which covers the = deprecation of the "X-" prefix as a method to distinguish standardized = and unstandardized descriptions. In particular I think the = recommendations here https://tools.ietf.org/html/rfc6648#section-3 make = sense to follow in the use of Codec IDs, in that a developer of an = unstandardized codec id should do so with an assumption that that Codec = ID may become standardized.

I sent a = pull request for review at https://github.com/Matroska-Org/matroska-specification/pull/117= , which adds this to the Codec Mapping page.

## Recommendations for the Creation of New Codec = Mappings

Creators of new Codec Mappins to = be used in the context of Matroska:

- = SHOULD assume that all Codec Mappings they create might become = standardized, public, commonly deployed, or usable across multiple = implementations.

- SHOULD employ meaningful = values for Codec ID and Codec Name that they have reason to believe = are currently unused.

- SHOULD NOT prefix = their Codec ID with "X-" or similar constructs.

These recommendations are based upon Section 3 of = [@!RFC6648].

Best = Regards,
Dave Rice


= --Apple-Mail=_C5F9A4E9-0685-4D15-AC89-A5B5ADF953E6-- From nobody Fri Apr 28 18:30:32 2017 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 7649E129465 for ; Fri, 28 Apr 2017 18:30:31 -0700 (PDT) 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, 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 9VnGCUKKAZ_q for ; Fri, 28 Apr 2017 18:30:29 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77358120727 for ; Fri, 28 Apr 2017 18:28:06 -0700 (PDT) Received: from [172.56.2.170] (port=30886 helo=[172.20.10.2]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1d4HB1-001IVW-Of; Fri, 28 Apr 2017 21:28:04 -0400 From: Dave Rice Message-Id: <55C1196B-7F06-44C0-85B1-C69E8C496C5C@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_87B7935B-FFEE-409E-B95E-6A98EDA46633" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Fri, 28 Apr 2017 21:27:54 -0400 In-Reply-To: Cc: Codec Encoding for LossLess Archiving and Realtime transmission To: Steve Lhomme References: <04A7F638-0E15-4949-BB49-98BD88082667@dericed.com> X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] mkv ColourSpace and uncompressed video 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, 29 Apr 2017 01:30:31 -0000 --Apple-Mail=_87B7935B-FFEE-409E-B95E-6A98EDA46633 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Apr 26, 2017, at 4:36 AM, Steve Lhomme = wrote: >=20 > 2017-02-06 0:21 GMT+01:00 Dave Rice : >> Hi cellar, >>=20 >> I=E2=80=99m hoping to clarify the use of uncompressed video in = Matroska and find a >> way to avoid muxing errors such as >> = https://github.com/FFmpeg/FFmpeg/blob/8c1342e631d635f6cad13f9374c4f2005c22= b9e5/libavformat/matroskaenc.c#L1117-L1118. >>=20 >> Currently Matroska supports a Codec ID of V_Uncompressed which relies = on the >> ColourSpace Element to detail how the uncompressed video is stored. = There is >> not much documentation here but the ColourSpace references a value in = AVI >> (which seems to be the biCompression value of BITMAPINFOHEADER. I=E2=80= =99d like to >> clean up this documentation but would like something more clear than = a vague >> reference to AVI. >>=20 >> Is there a reliable authority of fourcc=E2=80=99s that we can = reference to >=20 > There's a http://fourcc.org/ but it's nothing official. >=20 >> uncompressed video or should ColourSpace be defined with an = enumeration list >> which provides a list of value (such as I420, NV12, NV21, RGBA, UYVY, = Y41B, >> Y42B, Y800, YUV9, YUY2, YVYU) along with their definitions? >=20 > Sometimes vendors use different names for the same thing. > http://www.fourcc.org/yuv.php > There may be other formats (XYZ?) not listed on that website that may > be usefull as uncompressed. >=20 > We may need to maintain a list of uncompressed formats (audio and > video) like we maintain a list of known codecs and their mapping. >=20 >> Also I can only find occasions of ColourSpace used when the Codec is >> V_Uncompressed. Are there instances when it is valid to use = ColourSpace when >> the Codec ID is not V_Uncompressed. Was there any reason that = ColourSpace >> was used to store the fourcc, rather than using CodecPrivate as done = with >> VFW? >=20 > Because CodecPrivate is not meant to be parsed and analyzed for the > user. All values at the container level may be. Also the ColourSpace > may be useful for compressed formats as well. In this pull request, = https://github.com/Matroska-Org/matroska-specification/pull/118 = , I = changed the definition of ColourSpace from "Same value as in AVI (32 = bits)." to: > Specify the pixel format used for the Track's data as a "fourcc". This = Element is MANDATORY in TrackEntry when the CodecID Element of the = TrackEntry is set to "V_Uncompressed". Best Regards, Dave Rice --Apple-Mail=_87B7935B-FFEE-409E-B95E-6A98EDA46633 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Apr 26, 2017, at 4:36 AM, Steve Lhomme <slhomme@matroska.org> wrote:

2017-02-06 0:21 GMT+01:00 Dave Rice <dave@dericed.com>:
Hi cellar,

I=E2=80=99m hoping to clarify the use of = uncompressed video in Matroska and find a
way to avoid = muxing errors such as
https://github.com/FFmpeg/FFmpeg/blob/8c1342e631d635f6cad13f937= 4c4f2005c22b9e5/libavformat/matroskaenc.c#L1117-L1118.

Currently Matroska supports a Codec ID of = V_Uncompressed which relies on the
ColourSpace Element to = detail how the uncompressed video is stored. There is
not = much documentation here but the ColourSpace references a value in AVI
(which seems to be the biCompression value of = BITMAPINFOHEADER. I=E2=80=99d like to
clean up this = documentation but would like something more clear than a vague
reference to AVI.

Is there a = reliable authority of fourcc=E2=80=99s that we can reference to

There's a http://fourcc.org/ but it's = nothing official.

uncompressed video or should ColourSpace be defined with an = enumeration list
which provides a list of value (such as = I420, NV12, NV21, RGBA, UYVY, Y41B,
Y42B, Y800, YUV9, = YUY2, YVYU) along with their definitions?

Sometimes vendors use different names for the same thing.
http://www.fourcc.org/yuv.php
There may be = other formats (XYZ?) not listed on that website that may
be = usefull as uncompressed.

We may need to = maintain a list of uncompressed formats (audio and
video) = like we maintain a list of known codecs and their mapping.

Also I = can only find occasions of ColourSpace used when the Codec is
V_Uncompressed. Are there instances when it is valid to use = ColourSpace when
the Codec ID is not V_Uncompressed. Was = there any reason that ColourSpace
was used to store the = fourcc, rather than using CodecPrivate as done with
VFW?

Because CodecPrivate is not meant = to be parsed and analyzed for the
user. All values at the = container level may be. Also the ColourSpace
may be useful = for compressed formats as well.

In this pull request, https://github.com/Matroska-Org/matroska-specification/pull/118= , I changed the definition of ColourSpace from "Same value as in AVI = (32 bits)." to:

Specify the pixel format used for the Track's data as a = "fourcc". This Element is MANDATORY in TrackEntry when the CodecID = Element of the TrackEntry is set to = "V_Uncompressed".

Best Regards,
Dave = Rice

= --Apple-Mail=_87B7935B-FFEE-409E-B95E-6A98EDA46633-- From nobody Fri Apr 28 19:05:52 2017 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 B1A30129AA7 for ; Fri, 28 Apr 2017 19:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AabMZghn4uir for ; Fri, 28 Apr 2017 19:05:49 -0700 (PDT) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9CF7129AB2 for ; Fri, 28 Apr 2017 19:03:33 -0700 (PDT) Received: from ec2-52-44-2-169.compute-1.amazonaws.com ([52.44.2.169]:57274 helo=[10.101.2.210]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1d4HjO-001jc0-Kh; Fri, 28 Apr 2017 22:03:32 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) From: Dave Rice In-Reply-To: Date: Fri, 28 Apr 2017 22:03:24 -0400 Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Transfer-Encoding: quoted-printable Message-Id: References: <2651a6f3-9c9a-6f76-2ee7-4d5c23b1ce57@mediaarea.net> <922C5404-EC19-462D-A836-C952E66C2FD8@dericed.com> <9244b201-9097-365f-b7da-f2d8553616ee@mediaarea.net> <79FE60E9-88D8-4922-AE76-9D1924E1D6EB@dericed.com> <43056655-cf09-9d54-6552-4ed4b655e74f@mediaarea.net> <34CA7943-497F-449A-81DA-3237CB87BDD7@dericed.com> <1db0fb80-2441-a4f0-729e-bc5b5cfd1a84@mediaarea.net> To: Steve Lhomme X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] QuickTime timecode tracks in Matroska, was Ancillary data in Matroska 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, 29 Apr 2017 02:05:51 -0000 > On Apr 26, 2017, at 3:51 AM, Steve Lhomme = wrote: >=20 > A bit late on the party but I agree with the move to a more specific > track type for timecodes rather than the generic ancillary data. >=20 > 2017-03-20 22:07 GMT+01:00 Jerome Martinez : >> Le 20/03/2017 =C3=A0 21:37, Dave Rice a =C3=A9crit : >>>=20 >>> [...] >>>>>=20 >>>>> I=E2=80=99ve only seen a single value stored but then sometimes an = edit list >>>>> used to alter the ordering of the timecode (in case when its >>>>> non-sequential). For Matroska possibly it could simply store a new = timecode >>>>> Block at any case when it is not sequential. >>>>=20 >>>> What about seeking? >>>=20 >>> Isn't the seeking similar to QuickTime. >>=20 >>=20 >> Difference is that in QuickTime, a wrong "seek table" makes the = playback >> impossible, so developers are more careful about it. and in the file = I >> remember (I must still find it), there was only one offset in the = offset >> table of QuickTime and a single "chunk" of time code with byte size = of 4 >> bytes per frame (to be confirmed as you say you saw edit lists = instead) >>=20 >>> In QuickTime you'd need the offset table of the timecode track to >>> understand the number and location of all timecode samples. In = Matroska you >>> would use the associated CuePoints of the timecode track for the = same >>> reference. By parsing Cues the reader should be able to determine if = the >>> timecode is stripped or not and if not then have the CueTimes for = each >>> associated timecode Cluster. >>>=20 >>>> If you have a timecode block at the first frame and also at the = middle of >>>> the file, how a player can know that there is a timecode block = breaking the >>>> sequential order without parsing the whole file when there is a = seek request >>>> to the last minute of content? In that case, time code real value = would be >>>> set to "waiting for new block" (and this block never comes). I = don't think >>>> that forcing full parsing of the file with time code for seeking is = a good >>>> solution. >>>=20 >>> Same. But in the case of video if you seek to a P-frame then you = have to >>> go backwards and decode from the I-frame. Similarly if seeking to a >>> timepoint without a timecode Cluster (analogous to a P-frame), then = the >>> reader would have to use the Cues to decode the prior timecode = Cluster >>> (analogous to I-frame) in order to determine the timecode value of = the seek >>> point. >>=20 >>=20 >> Possible. >> But we need to be careful, what does it means? >> examples of issue: >> 1/ can a player consider that if there is only one CuePoint with = CueTrack =3D >> the ID of the time code track, it means that this is a stripped = content and >> time codes are in sequential order? >> 2/ can a player consider that if there are only 2 CuePoints with = CueTrack =3D >> the ID of the time code track, it means that this is a stripped = content and >> time codes are in sequential order except for one place and there is = a >> single discontinuity? >> 3/ or must a player consider that if there only 2 CuePoints (let say = frame 0 >> and frame 1000) with CueTrack =3D the ID of the time code track, it = means that >> it must seek to 0 if the requested frame is 999 (so a loooooong read = of the >> file on disk before being able to play frame 999) >> If answers are 2/ yes 3/ no, I understand that the only method for = storing a >> time code track with all values not sequential is to have a CuePoint = for >> each time code frame (which makes the Cues huge, 15-20 bytes of = CuePoint per >> time code frame). >>=20 >> Please provide example about how you imagine CuePoints in the cases: >> 1/ sequential time codes during 2000 frames >> 2/ sequential time codes during 2000 frames except one discontinuity = at >> frame 1000 >> 3/ 2000 different times codes >> and where a player must seek if the request is to seek to frame 999. >=20 > Are timecode frames supposed to be matching a specific video frame or > audio frame ? Or they are loose ? If the former case it may be best to > be attached as a BlockAdditional. Otherwise they should always be in > sequential/display order, just like audio is. Even if video is not. I'd propose to limit the use case to the former. The idea of storing = timecode data within BlockAdditional is interesting, but would that = limit the metadata possibilities. For instance if timecode data is = stored as it's own TrackEntry, then potentially a file may contain two = timecode TrackEntries, one depicting timecode values from the original = source materials used (likely non-continuous), whereas another = TrackEntry could represent a new continuous timecode track that served = some purpose in a video production. With these timecodes as two = TrackEntries with their own Clusters, they could have distinct names and = could be independently described with flags, so one may be enabled and = default while the other is disabled. With timecode in BlockAddition, there could potentially be two sets of = timecode (two BlockMore), but they would be indistinguishable and could = not be controlled or labelled independently. > Having a separate track means the timestamps may not match exactly the > video or audio tracks. So in case of seeking/discontinuity it's like > you said, there's a state where you need to way for the next Timecode > block to know where you are. This is the case if the there's one timecode value stored per video = frame, but this may not be the case. We also discussed using QuickTime's = strategy of storing an integer as a timecode while the timecode track's = private data notes what equation to use to convert the integer into a = timecode (flags like max24, timebase, etc). In this case a timecode = value would only need to be stored at a point in time when the timecode = is non-continuous. > But in general a Timecode block > should/must be placed before the audio/video it corresponds to. It's > the same requirement there is in WebM that audio blocks are muxed > before video blocks. Timecode would be even more prioritary. Does Matroska have the same ordering requirement? I don't see them. Is = it valid to store Clusters in reverse timestamp order? Dave Rice From nobody Sat Apr 29 13:22:52 2017 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 6D46C129516 for ; Sat, 29 Apr 2017 13:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.098 X-Spam-Level: X-Spam-Status: No, score=-0.098 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ux31G4ahaXsE for ; Sat, 29 Apr 2017 13:22:49 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC16129AA3 for ; Sat, 29 Apr 2017 13:20:39 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id q66so17885033pfi.3 for ; Sat, 29 Apr 2017 13:20:39 -0700 (PDT) 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=z6ez2+X6/FKn3vlV94+6ZGUKfyL4n9Mny7oiurLmKl4=; b=nbLZcxnYactoCrinsTE0KyGWOrKAKH1cXh8ZLkyPsg6tLzOaq/gk9znZMFFF1NklPU o746pkuITFi4ykt199m8qA0EDF6Fy7238Fk78FTwiBfEp9Bw8mdzD98x+lDWsMdW6YLG 2ug28JdaZwG0AElfrG00/EcmKyGf82gpM1QEtlS+MhAsur0W2/yM03xecLlvdfav64mk UXaWO3N871SO+I+b1ubEGRLwRebaf+6i42MiiRMPCgr9Msok0NVOHCCvW92nJOCzI4qL UExzv/oiI9evqHGBF2dPMHOVQ2sbAx4fIJmWu1hOE77nwD4yhvulh6JcKDm5uXRcN7wO Nxkw== 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=z6ez2+X6/FKn3vlV94+6ZGUKfyL4n9Mny7oiurLmKl4=; b=l+CGrW1BhIB9YPfDI4mpv6ZB4XNUfLEbeqRup5g44lXH5rd8TNmoDrcpiacAMpZNFQ wLnRtLnJgDPvwjIufk7sFn2tfi861skbcd93sRk5wQbPgcqj9EtChwbETkl+qbajNMZe A4eDND2KUt6mIHoH6lPv5UzuUYUDeCEXX5eLNg6MR599HuO1NB09t8gW+5f6r3WD3dT7 GYZ4xioFK4TQo8iahaCUfsZVJwA5YIpJ0ogaSPH6Ru0TPb8THAnxyO2ZPTLYdSLqDmlu 2zxdIauXxzCQoXCoxVSy4W12FPXq2VEz/0JoggUQZokQbylQRCvU2Ow6TXUJzEKnDIK5 b7Dg== X-Gm-Message-State: AN3rC/6SJMHguhWWoh1a7WjHxkIoEc532MeMK5kfe4fz1PDmqIUu95yJ yzAd+dSDoaZiszFYvzcOOlGQOdBcKhmA X-Received: by 10.98.50.67 with SMTP id y64mr9855338pfy.117.1493497239375; Sat, 29 Apr 2017 13:20:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.148.101 with HTTP; Sat, 29 Apr 2017 13:20:38 -0700 (PDT) In-Reply-To: <52163786-3428-4524-A772-0C5E121D991A@dericed.com> References: <90625ABD-48AE-41CC-AFE1-24BD57A62415@dericed.com> <52163786-3428-4524-A772-0C5E121D991A@dericed.com> From: Matt Gruenke Date: Sat, 29 Apr 2017 16:20:38 -0400 Message-ID: To: Dave Rice Cc: Steve Lhomme , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary=94eb2c11de006d1702054e53ec10 Archived-At: Subject: Re: [Cellar] TrackTypes for non-standard data formats 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, 29 Apr 2017 20:22:51 -0000 --94eb2c11de006d1702054e53ec10 Content-Type: text/plain; charset=UTF-8 On Fri, Apr 28, 2017 at 8:37 PM, Dave Rice wrote: > I sent a pull request for review at https://github.com/ > Matroska-Org/matroska-specification/pull/117, which adds this to the > Codec Mapping page. > > ## Recommendations for the Creation of New Codec Mappings > > Creators of new Codec Mappins to be used in the context of Matroska: > > - SHOULD assume that all Codec Mappings they create might become > standardized, public, commonly deployed, or usable across multiple > implementations. > > - SHOULD employ meaningful values for Codec ID and Codec Name that they > have reason to believe are currently unused. > > - SHOULD NOT prefix their Codec ID with "X-" or similar constructs. > > These recommendations are based upon Section 3 of [@!RFC6648]. > It's important to note that while IANA deprecated the X- prefix, they *replaced *it with the Vendor and Personal trees. https://tools.ietf.org/html/rfc6838#section-3 So, you can certainly say "don't use X_". But, if someone has an encoding that doesn't fit any of the existing prefixes, then using "Y_" is just as bad (or worse). Matt --94eb2c11de006d1702054e53ec10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Apr 28, 2017 at 8:37 PM, Dave Rice <dave@dericed.com> wro= te:
=C2=A0
<= div style=3D"word-wrap:break-word">
I sent a pull request for review at= =C2=A0https://github.com/Matroska-Org/matroska-specification/pull/117, which adds this to the Codec Mapping page.

## Recommendations for the Creation of New Codec Mapp= ings

Creators of new Codec Mappins to be used in the context of Matr= oska:

- SHOULD assume that all Codec Mappings they create might beco= me standardized, public,=C2=A0commonly deployed, or usable across multiple = implementations.

- SHOULD employ meaningful values for Codec ID and = Codec Name that they have reason to=C2=A0believe are currently unused.
<= br>- SHOULD NOT prefix their Codec ID with "X-" or similar constr= ucts.

These recommendations are based upon Section 3 of [@!RFC6648].=

It's important to note tha= t while IANA deprecated the X- prefix, they replaced it with the Ven= dor and Personal trees.

<= div class=3D"gmail_quote">
=


So, you can certainly say "don't = use X_".=C2=A0 But, if someone has an encoding that doesn't fit an= y of the existing prefixes, then using "Y_" is just as bad (or wo= rse).


Matt

--94eb2c11de006d1702054e53ec10--