From nobody Tue Mar 14 12:14:41 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 1F2CF129439 for ; Tue, 14 Mar 2017 12:14:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.653 X-Spam-Level: X-Spam-Status: No, score=0.653 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_NEUTRAL=0.652] 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 hKgchc5yI8pd for ; Tue, 14 Mar 2017 12:14:37 -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 E96EC1298AF for ; Tue, 14 Mar 2017 12:14:36 -0700 (PDT) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:47666 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cnrty-001Tzq-KR for cellar@ietf.org; Tue, 14 Mar 2017 15:14:36 -0400 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_918FA47F-D976-4564-8334-409A5D03483B" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 14 Mar 2017 15:14:31 -0400 References: <2651a6f3-9c9a-6f76-2ee7-4d5c23b1ce57@mediaarea.net> <922C5404-EC19-462D-A836-C952E66C2FD8@dericed.com> To: Codec Encoding for LossLess Archiving and Realtime transmission In-Reply-To: <922C5404-EC19-462D-A836-C952E66C2FD8@dericed.com> Message-Id: X-Mailer: Apple Mail (2.3259) 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: Tue, 14 Mar 2017 19:14:39 -0000 --Apple-Mail=_918FA47F-D976-4564-8334-409A5D03483B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 23, 2017, at 11:18 PM, Dave Rice wrote: >=20 > Hi all, >=20 >> On Jan 7, 2017, at 11:57 AM, Dave Rice > wrote: >=20 > [=E2=80=A6] >=20 >>> On Dec 27, 2016, at 3:22 PM, Jerome Martinez > wrote: >=20 > [=E2=80=A6] >=20 >>> "N_" prefix arbitrary used (2nd letter of "Ancillary" because first = letter is already used) >>=20 >> 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=98ancillary=E2=80=99 type of track. >>=20 >>> N_QUICKTIME: is a pure copy of V_QUICKTIME and A_QUICKTIME already = supported in Matroska, N_ would be used which would be used for e.g. = tmcd codec (QuickTime time code). Exactly same principles as video and = audio. Note that classic usage is to store only the first frame content = and other content is computed from it, so a player would have to read = the first frame even if there is a direct seek request to another place; = this could be avoided with some "hack" in the track header, could be the = next step after this one is accepted. >>=20 >> Would need a clear caveat in the definition that this implementation = would 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 lossless transwrap in this case, since the edit list would be lost = and the new timecode track in the Matroska file would appear continuous. >>=20 >> Also reference to tmcd atom is not clear enough. Is it tref/tmcd, = gmhd/tmcd, stsd/tmcd. >>=20 >> If this is stsd/tmcd (I presume), then what time scale should be = used? The time scale stored in tmcd or the time scale of the Matroska = track? >>=20 >> I like that copying stsd/tmcd copies in the timecode label as well. >=20 > I started a draft of a PR for defining QuickTime-style timecode in = Matroska 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 the stsd atom, rather than starting after the track type atom = (such as the image 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/Q= TFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-SW1 = could be = considered as ancillary. Comments? After looking at this some more, I decided to create an alternate = proposal for a T_QUICKTIME codec mapping, rather than to store = QuickTime-style timecode in the more vague concept of an ancillary = N_QUICKTIME. See the pull request at = https://github.com/Matroska-Org/matroska-specification/pull/112 = . For reference the proposed definition of T_QUICKTIME is: { Codec ID: T_QUICKTIME Codec Name: QuickTime timecode track Description: `T_QUICKTIME` is used to identify Timecode tracks as stored = in QuickTime. The `QuickTime Timecode Sample Data` is stored within the = Block's data section. For an explanation of `QuickTime Timecode Sample = Data` read [QuickTime File Format = Specification](https://developer.apple.com/library/content/documentation/Q= uickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-57= 421). Initialisation: The `Private Data` contains the `Timecode Sample = Description` which in QuickTime is stored within the 'tmcd' atom after = the mandatory `data reference index` value. For an explanation of the = `Timecode Sample Description` read [QuickTime File Format = Specification](https://developer.apple.com/library/content/documentation/Q= uickTime/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-69= 831). } Attached is a draft Matroska file with an T_QUICKTIME style timecode = track. The CodecPrivate section uses the QuickTime Timecode Sample Data which = for this attachment is = 000000000000000100007530000003E91E00000000136E616D650007000054415045233534= , which equates to: 00000000 0 Resserved 00000001 1 Timecode flags 00007530 30000 Time scale 000003E9 1001 Frame duration 1E 30 Number of frames 00 0 Reserved 00000013 19 Size of name atom 6E616D65 name Fourcc of name atom 0007 7 Size of Timecode Label 0000 en Language of Timecode Label 54415045233534 TAPE#54 Timecode Label This example includes a timecode label, the shortest possible Private = Data for T_QUICKTIME would be 18 bytes: 00000000 0 Resserved 00000001 1 Timecode flags 00007530 30000 Time scale 000003E9 1001 Frame duration 1E 30 Number of frames 00 0 Reserved The attachment contains a SimpleBlock using the T_QUICKTIME with a = example value of 0x0001fc8c, which according to the QuickTime Timecode = Sample Data is 01:12:23;28 and subsequent timecode values for the track = would be calculated according to the incrementation defined in the = Private Data. Comments? Dave Rice --Apple-Mail=_918FA47F-D976-4564-8334-409A5D03483B Content-Type: multipart/mixed; boundary="Apple-Mail=_887C3FFA-9DB7-472C-BC43-FD8D2619D10E" --Apple-Mail=_887C3FFA-9DB7-472C-BC43-FD8D2619D10E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 23, 2017, at 11:18 PM, Dave Rice <dave@dericed.com> = wrote:

Hi all,

On Jan 7, 2017, at 11:57 AM, = Dave Rice <dave@dericed.com> wrote:

[=E2=80=A6]

On Dec 27, 2016, at 3:22 = PM, Jerome Martinez <jerome@mediaarea.net> = wrote:

[=E2=80=A6]

"N_" prefix arbitrary = used (2nd letter of "Ancillary" because first letter 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=98ancillary=E2=80=99 type of track.

N_QUICKTIME: is a pure copy of V_QUICKTIME and A_QUICKTIME = already supported in Matroska, N_ would be used which would be used for = e.g. tmcd codec (QuickTime time code). Exactly same principles as video = and audio. Note that classic usage is to store only the first frame = content and other content is computed from it, so a player would have to = read the first frame even if there is a direct seek request to another = place; this could be avoided with some "hack" in the track header, could = be the next step after this one is accepted.

Would need a clear caveat in the = definition that this implementation would 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 lossless 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/tmcd, stsd/tmcd.

If this is = stsd/tmcd (I presume), then what time scale should be used? The 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 Matroska 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 the stsd atom, rather than starting after the track type = atom (such as the image 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/Quick= Time/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-SW1 could be considered as ancillary. = Comments?


For reference the proposed = definition of T_QUICKTIME is:
{
Codec ID: = T_QUICKTIME

Codec Name: QuickTime = timecode track

Description: = `T_QUICKTIME` is used to identify Timecode tracks as stored in = QuickTime. The `QuickTime Timecode Sample Data` is stored within the = Block's data section. For an explanation of `QuickTime Timecode Sample = Data` read [QuickTime File Format Specification](https://developer.apple.com/library/content/documentation/Quick= Time/QTFF/QTFFChap3/qtff3.html#//apple_ref/doc/uid/TP40000939-CH205-57421<= /a>).

}


= --Apple-Mail=_887C3FFA-9DB7-472C-BC43-FD8D2619D10E Content-Disposition: attachment; filename=T_QUICKTIME_sample.mkv Content-Type: application/octet-stream; x-unix-mode=0644; name="T_QUICKTIME_sample.mkv" Content-Transfer-Encoding: base64 GkXfo6NChoEBQveBAULygQRC84EIQoKIbWF0cm9za2FCh4EEQoWBAhhTgGf/7ECAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAVSalm1yrXsYMPQkBNgJZMYXZmNTcuNjYuMTA0OyB4bWwybWt2V0GWTGF2ZjU3LjY2LjEw NDsgeG1sMm1rdnOkkN9VCayCkn1iXRu2Kp9FBpBEiYhAVwAAAAAAABZUrmtA8a7k14EBc8WBAZyB ACK1nIN1bmSDgQEj44OEAf0iioaPVl9NUy9WRlcvRk9VUkND4IqwggFAuoHwmoECY6KoKAAAAEAB AADwAAAAAQAYAEZGVjEAhAMAAAAAAAAAAAAAAAAAAAAAAK6214ECc8WBApyBACK1nIN1bmSGhUFf QUFDg4EC4ZGfgQG1iEDliIAAAAAAYmSBIGOihRIIVuUArtHXgQNzxYEDnIEAIrWcg3VuZIOBBCPj g4QB/SKKhotUX1FVSUNLVElNRWOipQAAAAAAAAABAAB1MAAAA+keAAAAABNuYW1lAAcAAFRBUEUj NTQSVMNn+XNzqWPAhGPFgQFnyJ9Fo4dFTkNPREVSRIeSTGF2YzU3LjgzLjEwMCBmZnYxc3OoY8CE Y8WBAmfInkWjh0VOQ09ERVJEh5FMYXZjNTcuODMuMTAwIGFhY3Nzn2PAhGPFgQNnyJVFo4dFTkNP REVSRIeIQGRlcmljZWQfQ7Z1SPHngQCjQQeCAACCAN4CAExhdmM1Ny44My4xMDAAAmCsW6lQcial ePXj9664ltVJapaVJMk7g6EBBhVy8Xca6S1r2l5jwbtjzur5PFLYMz5L55010jzdzbuLYOUuI6+1 TbVs2VTtVZ91ViOFY3FXGzaDZsbYsTcrLcs517E47G4q42a4z1Zjo1+avzV+axz62fW1LPUsdGvz WmavzV+fWz62fWz6qfX5rDNYabOizorUVqKVNjMxmYzMaK1FaitRY02MzGZjExos6K1FaixosZmM zGJKJKeKeKJKJfC+S+SUSU8U8U8US+S+S+S+8U8U8U8US+S/FFFFFFFFFFFFFFFFFFFFFFFFFFFF FFFFwKOJgwAAggAAAfyMo0KMgQAXggD0x1cxqejpdxABfHD9oghrtWptAARkr//////8AAZ///// //4ABl//VVVVVVVVVVVVUAANf////VVVVVVVVVVAAFtVVVVVVVVVVVVVVQAA3VVVVVVVVVVV/+AA YVVVVVV////z//////////////////////////////wAF7///////gD///////8AU///////4AA7 f//////8MX///////A5///////4+///////7///ADVK///////ACf/AAkFVVVVV//8n///wAHZVV VVVVYAAT//////AALJX4ABqqqqqqqqqqqv/+L//4AAN//wAASV/4ABewAAR//////+f///////// gAPSV///AAnbbbbbbbbbbbQANO7u7u7u7u7u622wAE1u5mZmZmZmZmZl3YAGju7u7u7u7u7u7uZg AEx3d3bu7u7u7u7u7oAGh///////d3d3d3dP////////////////4AVHd27u7u7u7u7u7st3MzMz MzMzMzMzIAAWSv//4AAW5d3d3d3d3d3d3dw1///4AAW///+AC13d3VVVVVVtttoP/AHftttttttt ttoY+AAWCAADHtbbbbQAEz/ylJJJJJJJJAAEsEAAK////Jh/////z8kkkkkkkkkkkA8kkkkkkkkk kgAFzbbbbbbbbbbaBrbbbbbbbbbbQAN6ZmZm22222220DW2222222222gAXUkkkkkkkkkkv///// ///////////4Alv///J///4oySSSSSSSSSSAAQMkkkkkkkkkkgAMGSSSSSSSSSSQACAkqqqqqqrX ///v/AE1///4AAR+AAZCAUVVVUAAN1VVSX//wABoEMVVVVVVVWu/////wKNBB4IAF4IAATSa2tJN wGzFTCbMVKJ03U2p5+tXw2+NXdf+nH6/VwXep//S8/r8cBq5v/+31+/tIavjOhJdBBf4mjAw8eXA fZNO7BYpfDaiYXXBmtILtidzjSIfCxdrjYIcbFqaqa1BCpdVNnM/8bQ127+s6JBga7kEhIMDA2Tu EhISDAwM7uEhJwGHMu7hJxoGZBs3tdwkJyX5+ZIbIzQmwl3+EKsNNXEdIMlKKVSRuZWbOyqNzS1t ttsmi0ilNnMlVVFpnUwN8mBv6yEgxIGBgkJJXnBjcoSElSWbgwMbCQkrexzRSyhJW7AQQZeHCzHL xH2uv7w+myrKvynRIScmmOJVtTLCUpXgo0EDggAuggABNJu2y1TCbURILtREesS1+r4uZer0//u/ Xt8cCXc4//pfX17aEbmp8CjfiIRQIZGoMPa2lPB/JjLHmwdhSZ/JisebDDHDFUFPDDHD+rAyn/WQ kGBncJCQYGBndwkJCQYGBndwkJCQYGBndwkJSokQNi7u4SEnKkAAaf2E5ZcDX2iXWJeqs5GaYLUr AjLg1uNZScMG5xrqjDAtVTOmtSkUkb17/jaGCQnNwYGCSru4MDAwTdyd3BgYGK23R/P+e/DKYejF gYSdfaavQvGctZ61xV7njJSq5UWdFuWtda7HK11rk5U6a0TRpMtfKQn6MDBISDAwScOAwMDbIylA r6NCWoEAOAIAABZ///////4AAz///////wADL///////gADVVVVVVVVVVVVVVVQABbVVVVVVVVVV f/4AA1VVf/////4ABh///////n//////////////////////////////wAF3///////3P//////+ R/////////f//////9y///////87///////9d///////5///wAqP//////+e/+ABIKqqqqqqqqqr Sqqqqr/AAdkkkkkkkkkvgL/////+AAWf8L3////qqqqqqqqqqy//+AADf/8AAE//hGQAANVVVVVV VVVVf/f/////////h2qqqqqqqgAJ3///////AA0///////ttttgAJpERERERERERE//4AGju7u7u 7u7u7u7u5gAEx3d3bu7u7u7u7u5gAGh/////93d3d3d3dD/////////////////ACx7d3d3d3d3d 3d3doczMzMzMzMzMzMy46q///ha7u7u7u7u7u7u7uK////1///8xf/bbbbbbbbaX/wBz7bbbbbbb bbaJfAALBBotttttoACYqqrTpJJJJJJJIAAlggoq///u/////+ekkkkkkkkkkkgHkkkkkkkkkkkA AubbbbbbbbbbbQNbbbbbbbbbbaABvTM2222222220DW2222222222gAXUkkkkkkkkkkj//////// /////////AEd///6f///FWSSSSSSSSSSRKkkkkkkkkkkkAC/kkkkkkkkkkok1VVVVVVVP////8AS f///ivgAGQgQqqqqAAG6qqrqqqq/gADQIXKqqqqqquv/////o0DaggBFggABPpu2mjHi9Keh8+/0 1d6vWpP/7Wv8SoAAHTYLK0/Rqo5bAv4EpyaMlgShM0oSuVQSEu8H8v5EH8v5A/l/L4Afy/l/IQg/ l/L+QqX/lh2WAQdEQ4/ogUReACaCT06gC8IgSMUkQIA/HISGIkEAAqIP1354AOIDgn67899S9eAA DDCK/+L/xv99/vgior+xf2L+xftwRUD/+//v/7/+//v/YAD/2/9v/b/2/9v/YAD/2/i/i/i/i/iA AP4v4v4v4v4v4v4v4gAA/i/i/i/i/i/i/i/iAOA= --Apple-Mail=_887C3FFA-9DB7-472C-BC43-FD8D2619D10E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

The CodecPrivate section uses the QuickTime Timecode Sample = Data which for this attachment is = 000000000000000100007530000003E91E00000000136E616D650007000054415045233534= , which equates to:

00000000     =    0           Resserved
00000001        1       =     Timecode flags
00007530       =  30000       Time scale
000003E9 =        1001        Frame = duration
1E             =  30          Number of frames
00              0   =         Reserved
00000013   =      19          Size of name = atom
6E616D65        name   =      Fourcc of name atom
 0007   =         7           Size = of Timecode = Label
 0000 =           en         =  Language of Timecode Label
 54415045233534 TAPE#54     Timecode = Label

This example includes a timecode label, the shortest possible = Private Data for T_QUICKTIME would be 18 bytes:

00000000        0       =     Resserved
00000001 =        1           Timecode = flags
00007530       =  30000       Time scale
000003E9        1001   =      Frame duration
1E =              30       =    Number of frames
00   =            0         =   Reserved

The = attachment contains a SimpleBlock using the T_QUICKTIME with a example = value of 0x0001fc8c, which according to the QuickTime Timecode = Sample Data is 01:12:23;28 and subsequent timecode values for the track = would be calculated according to the incrementation defined in the = Private Data.

Comments?
Dave Rice

= --Apple-Mail=_887C3FFA-9DB7-472C-BC43-FD8D2619D10E-- --Apple-Mail=_918FA47F-D976-4564-8334-409A5D03483B-- From nobody Tue Mar 14 12:40: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 64C3E129A95 for ; Tue, 14 Mar 2017 12:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[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] 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 EY6qTUnG_BNu for ; Tue, 14 Mar 2017 12:40:22 -0700 (PDT) Received: from 12.mo3.mail-out.ovh.net (12.mo3.mail-out.ovh.net [188.165.41.191]) (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 D902F129A90 for ; Tue, 14 Mar 2017 12:40:00 -0700 (PDT) Received: from player693.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id B9CAFB7396 for ; Tue, 14 Mar 2017 20:39:58 +0100 (CET) Received: from [192.168.2.101] (p5DDB5708.dip0.t-ipconnect.de [93.219.87.8]) (Authenticated sender: jerome@mediaarea.net) by player693.ha.ovh.net (Postfix) with ESMTPSA id 669A644007D for ; Tue, 14 Mar 2017 20:39:58 +0100 (CET) To: cellar@ietf.org References: <2651a6f3-9c9a-6f76-2ee7-4d5c23b1ce57@mediaarea.net> <922C5404-EC19-462D-A836-C952E66C2FD8@dericed.com> From: Jerome Martinez Message-ID: <9244b201-9097-365f-b7da-f2d8553616ee@mediaarea.net> Date: Tue, 14 Mar 2017 20:39:56 +0100 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="------------B3E4CDD4B1603E01A70C7134" X-Ovh-Tracer-Id: 5120029830144135313 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelhedrheeigdduvdelucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc 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: Tue, 14 Mar 2017 19:40:34 -0000 This is a multi-part message in MIME format. --------------B3E4CDD4B1603E01A70C7134 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 14/03/2017 à 20:14, Dave Rice a écrit : > [...] > > After looking at this some more, I decided to create an alternate > proposal for a T_QUICKTIME codec mapping, rather than to store > QuickTime-style timecode in the more vague concept of an ancillary > N_QUICKTIME. Trying to find some counter-arguments, I have to agree that this may be better as we don't have any real example for usage of a generic QuickTime ancillary track. > > [...] > > The attachment contains a SimpleBlock using the T_QUICKTIME with a > example value of 0x0001fc8c, which according to the QuickTime Timecode > Sample Data is 01:12:23;28 and subsequent timecode values for the > track would be calculated according to the incrementation defined in > the Private Data. Content location is another issue. Time code may be stripped (only the first time code is stored and other time code must be computed from it + header metadata), and there is no way to know it in Matroska : QuickTime has the list of blocks in the track header so the player knows if the the time code is stripped (1 block of 4 bytes) or not (more than 1 block), this is not the case with Matroska. How could we indicate to the player that the time code is stripped (=only one value stored, then player should compute value of other time code frames)? Jérôme --------------B3E4CDD4B1603E01A70C7134 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Le 14/03/2017 à 20:14, Dave Rice a écrit :
[...]

After looking at this some more, I decided to create an alternate proposal for a T_QUICKTIME codec mapping, rather than to store QuickTime-style timecode in the more vague concept of an ancillary N_QUICKTIME.

Trying to find some counter-arguments, I have to agree that this may be better as we don't have any real example for usage of a generic QuickTime ancillary track.


[...]

The attachment contains a SimpleBlock using the T_QUICKTIME with a example value of 0x0001fc8c, which according to the QuickTime Timecode Sample Data is 01:12:23;28 and subsequent timecode values for the track would be calculated according to the incrementation defined in the Private Data.

Content location is another issue.
Time code may be stripped (only the first time code is stored and other time code must be computed from it + header metadata), and there is no way to know it in Matroska : QuickTime has the list of blocks in the track header so the player knows if the the time code is stripped (1 block of 4 bytes) or not (more than 1 block), this is not the  case with Matroska.
How could we indicate to the player that the time code is stripped (=only one value stored, then player should compute value of other time code frames)?

Jérôme
--------------B3E4CDD4B1603E01A70C7134-- From nobody Tue Mar 14 12:45: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 5D15B13010D for ; Tue, 14 Mar 2017 12:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.653 X-Spam-Level: X-Spam-Status: No, score=0.653 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_NEUTRAL=0.652] 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 NMuPXxoHalyo for ; Tue, 14 Mar 2017 12:45:47 -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 48B45129A8E for ; Tue, 14 Mar 2017 12:45:47 -0700 (PDT) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:46110 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cnsO9-001zLr-F9; Tue, 14 Mar 2017 15:45:46 -0400 From: Dave Rice Message-Id: <79FE60E9-88D8-4922-AE76-9D1924E1D6EB@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_2148901B-DFDC-4D9A-B27C-8C021B09CC8E" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Tue, 14 Mar 2017 15:45:41 -0400 In-Reply-To: <9244b201-9097-365f-b7da-f2d8553616ee@mediaarea.net> Cc: cellar@ietf.org To: Jerome Martinez References: <2651a6f3-9c9a-6f76-2ee7-4d5c23b1ce57@mediaarea.net> <922C5404-EC19-462D-A836-C952E66C2FD8@dericed.com> <9244b201-9097-365f-b7da-f2d8553616ee@mediaarea.net> X-Mailer: Apple Mail (2.3259) 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: Tue, 14 Mar 2017 19:45:48 -0000 --Apple-Mail=_2148901B-DFDC-4D9A-B27C-8C021B09CC8E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 14, 2017, at 3:39 PM, Jerome Martinez = wrote: >=20 > Le 14/03/2017 =C3=A0 20:14, Dave Rice a =C3=A9crit : >> [...] >>=20 >> After looking at this some more, I decided to create an alternate = proposal for a T_QUICKTIME codec mapping, rather than to store = QuickTime-style timecode in the more vague concept of an ancillary = N_QUICKTIME. >=20 > Trying to find some counter-arguments, I have to agree that this may = be better as we don't have any real example for usage of a generic = QuickTime ancillary track. >=20 >>=20 >> [...] >>=20 >> The attachment contains a SimpleBlock using the T_QUICKTIME with a = example value of 0x0001fc8c, which according to the QuickTime Timecode = Sample Data is 01:12:23;28 and subsequent timecode values for the track = would be calculated according to the incrementation defined in the = Private Data. >=20 > Content location is another issue. > Time code may be stripped (only the first time code is stored and = other time code must be computed from it + header metadata), and there = is no way to know it in Matroska : QuickTime has the list of blocks in = the track header so the player knows if the the time code is stripped (1 = block of 4 bytes) or not (more than 1 block), this is not the case with = Matroska. > How could we indicate to the player that the time code is stripped = (=3Donly one value stored, then player should compute value of other = time code frames)? Since the update proposal defines a new media type (timecode) it is = possible to define a Timecode Master element (as similar done with Audio = and Video) to store needed context. OTOH I don=E2=80=99t think I=E2=80=99ve ever seen a QuickTime timecode = track that was non-stripped. 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. Dave --Apple-Mail=_2148901B-DFDC-4D9A-B27C-8C021B09CC8E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Mar 14, 2017, at 3:39 PM, Jerome Martinez <jerome@mediaarea.net> wrote:

=20 =20
Le 14/03/2017 =C3=A0 20:14, Dave Rice = a =C3=A9crit :
[...]

After looking at this some more, I decided to = create an alternate proposal for a T_QUICKTIME codec mapping, rather than to store QuickTime-style timecode in the more vague concept of an ancillary N_QUICKTIME.

Trying to find some counter-arguments, I have to agree that this may be better as we don't have any real example for usage of a generic QuickTime ancillary track.


[...]

The attachment contains a SimpleBlock using the T_QUICKTIME with a example value of 0x0001fc8c, which according to the QuickTime Timecode Sample Data is 01:12:23;28 and subsequent timecode values for the track would be calculated according to the incrementation defined in the Private = Data.

Content location is another issue.
Time code may be stripped (only the first time code is stored and other time code must be computed from it + header metadata), and there is no way to know it in Matroska : QuickTime has the list of blocks in the track header so the player knows if the the time code is stripped (1 block of 4 bytes) or not (more than 1 block), this is not the  case with Matroska.
How could we indicate to the player that the time code is stripped (=3Donly one value stored, then player should compute value of other time code frames)?

Since the update proposal defines a new media type = (timecode) it is possible to define a Timecode Master element (as = similar done with Audio and Video) to store needed = context.

OTOH I don=E2=80=99t think = I=E2=80=99ve ever seen a QuickTime timecode track that was non-stripped. = 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.
Dave

= --Apple-Mail=_2148901B-DFDC-4D9A-B27C-8C021B09CC8E-- From nobody Tue Mar 14 12:57: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 8B2D3129981 for ; Tue, 14 Mar 2017 12:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLKwBuBjU-4d for ; Tue, 14 Mar 2017 12:57:25 -0700 (PDT) Received: from 19.mo3.mail-out.ovh.net (19.mo3.mail-out.ovh.net [178.32.98.231]) (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 0959C129485 for ; Tue, 14 Mar 2017 12:57:24 -0700 (PDT) Received: from player693.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id 9785BB36EF for ; Tue, 14 Mar 2017 20:57:22 +0100 (CET) Received: from [192.168.2.101] (p5DDB5708.dip0.t-ipconnect.de [93.219.87.8]) (Authenticated sender: jerome@mediaarea.net) by player693.ha.ovh.net (Postfix) with ESMTPSA id 62AB244006D; Tue, 14 Mar 2017 20:57:21 +0100 (CET) To: Dave Rice 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> Cc: cellar@ietf.org From: Jerome Martinez Message-ID: <43056655-cf09-9d54-6552-4ed4b655e74f@mediaarea.net> Date: Tue, 14 Mar 2017 20:57:19 +0100 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: <79FE60E9-88D8-4922-AE76-9D1924E1D6EB@dericed.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 5413889704602308753 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelhedrheeigddufeefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm 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: Tue, 14 Mar 2017 19:57:28 -0000 Le 14/03/2017 à 20:45, Dave Rice a écrit : > [...] > >> Time code may be stripped (only the first time code is stored and >> other time code must be computed from it + header metadata), and >> there is no way to know it in Matroska : QuickTime has the list of >> blocks in the track header so the player knows if the the time code >> is stripped (1 block of 4 bytes) or not (more than 1 block), this is >> not the case with Matroska. >> How could we indicate to the player that the time code is stripped >> (=only one value stored, then player should compute value of other >> time code frames)? > > > Since the update proposal defines a new media type (timecode) it is > possible to define a Timecode Master element (as similar done with > Audio and Video) to store needed context. > > OTOH I don’t think I’ve ever seen a QuickTime timecode track that was > non-stripped. OK, I need to check my files but I am pretty sure I have some. > I’ve 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. What about seeking? 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. From nobody Tue Mar 14 12:59: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 3A9A9131476 for ; Tue, 14 Mar 2017 12:59:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibLbfllKKvLS for ; Tue, 14 Mar 2017 12:59:33 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 31EB2129485 for ; Tue, 14 Mar 2017 12:59:33 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id y76so257085317qkb.0 for ; Tue, 14 Mar 2017 12:59:33 -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=31e0pM4btw5XW0Q+3+qz8RDKjVK4JsjLHOWTsEYxjdk=; b=RE6p2HKS+tTye/SzZeH2URexXSysdGtZ1IjUTPAsEI/M5qf/bvoCVGvFp6l3LRKc6s NvqSLwWBFl+kCPL3s8tQFaV0NUnh8kqQTNNDlBQTNupvYH7e50dx4PSH6MxFDnCyItKy zbbQbPzWOw5LKpeHehgcrpwnLPtRFoDd0JI27HCn+jOvvQEfD69aiZGuzGYcOR9vpHCZ 2Wk2BBCC+DSnkYJwLKIXNJSP6NCwDVnAO7+oS7QTzQe0LqkdoHSLXMXQFi90qJeriLSB dO7/+GTacYq8bF0lvNPq/RdfMxuvbEvlu2EtRO/k5ie+LH1evcpsbVVepu+dp+Qn9BVd zvRg== 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=31e0pM4btw5XW0Q+3+qz8RDKjVK4JsjLHOWTsEYxjdk=; b=Q4l/DKENZoTzE/bNhNzA3VlHkBQhI5Ed5hixATSaLOdqdhTCc67AIN1vfDBD9IYXoB +gFfheeWGauy+xpNzX4IR85gqkBMX9FoFkC2fYzkiZmaODERxTqdxsmk4gm78uVH7ofF d2zL1P1uDxRHjwvoFZehYIr5wizWK1PepwOBaLLjWpfyO2aQ6FujWxMQ2pkxrO8iNQ2h E84ajUh9Ei0qFaJagVxSuNjTtfZEO8t6NQCfOw21ByaoqCgBzIxnoYSVjHAdPdKb4ot+ R+1MjLdyfei+ylKKSBVrsrNjzUDQDxF09LwI3fNCjwL+9bMc9sp1I6kXu1t+jV6ZG5Q5 qwMg== X-Gm-Message-State: AMke39mBx9HnZl0S+fwdmWo3KBndBkdiM4l9jXfdu5FC6gQaWn/jzbJhPaa2wDdBAHjMjk5jpnxlDU51B3ryCw== X-Received: by 10.55.100.67 with SMTP id y64mr41090988qkb.290.1489521572262; Tue, 14 Mar 2017 12:59:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.161.194 with HTTP; Tue, 14 Mar 2017 12:59:31 -0700 (PDT) In-Reply-To: <79FE60E9-88D8-4922-AE76-9D1924E1D6EB@dericed.com> 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> From: Kieran O Leary Date: Tue, 14 Mar 2017 19:59:31 +0000 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=001a114846183341cf054ab6442a 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: Tue, 14 Mar 2017 19:59:38 -0000 --001a114846183341cf054ab6442a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi On Tue, Mar 14, 2017 at 7:45 PM, Dave Rice wrote: > > > OTOH I don=E2=80=99t think I=E2=80=99ve ever seen a QuickTime timecode tr= ack that was > non-stripped. I=E2=80=99ve only seen a single value stored but then somet= imes 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 timeco= de > Block at any case when it is not sequential. > Dave > > Same here actually, I've tried Control Room/Media Express/FCP and it's always striped. I'm sure there's some hidden option or different way of connecting the deck to the capture card to achieve this, but timecode jumps are always ignored on any capture I've seen, and the increment is applied to the starting timecode. Also i'd love to see your samples, Jerome. -Kieran. > > _______________________________________________ > > --001a114846183341cf054ab6442a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi

On Tue, Mar 14, 2017 at 7:45 PM, Dave Rice <dave@dericed.com><= /span> wrote:


OTOH I don=E2=80= =99t think I=E2=80=99ve ever seen a QuickTime timecode track that was non-s= tripped. 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 Bl= ock at any case when it is not sequential.
Dave


Same here actually, I've tried Control Room/Media Expr= ess/FCP and it's always striped. I'm sure there's some hidden o= ption or different way of connecting the deck to the capture card to achiev= e this, but timecode jumps are always ignored on any capture I've seen,= and the increment is applied to the starting timecode.
Also i= 9;d love to see your samples, Jerome.=C2=A0

-Kiera= n.=C2=A0
_______________________________________________


--001a114846183341cf054ab6442a-- From nobody Wed Mar 15 04:40:31 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 6DFC6129BD5 for ; Wed, 15 Mar 2017 04:40:29 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 YW-rilggt0Qa for ; Wed, 15 Mar 2017 04:40:25 -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 5BA6B129BF0 for ; Wed, 15 Mar 2017 04:40:25 -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, 15 Mar 2017 12:40:22 +0100 id 000000000000012A.0000000058C92826.00005B57 Message-ID: <58C92825.4020909@das-werkstatt.com> Date: Wed, 15 Mar 2017 12:40:21 +0100 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [Cellar] FFV1 in use at Sharjah Media Corporation (SMC) in UAE 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, 15 Mar 2017 11:40:29 -0000 Good news everyone :D According to the recent NOA newsletter [1] The Sharjah Media Corporation (SMC) (in United Arab Emirates) seems to have chosen FFV1 as their preservation format. Nice greetings, Pb == References: [1] http://www.noa-archive.com/news-and-events/news/installation-at-smc/ From nobody Wed Mar 15 20:25:30 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 0A030130A94 for ; Wed, 15 Mar 2017 20:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJ26K0fUKT9t for ; Wed, 15 Mar 2017 20:25:26 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 39B0E130141 for ; Wed, 15 Mar 2017 20:25:26 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id w124so1144417itb.0 for ; Wed, 15 Mar 2017 20:25:26 -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=16XhDvI/LvsB/sJ/u6ze3v2TsKuw3spFv8LLAccbGXo=; b=FOPigTEjLaybvNqjxLGeWTXYAHWQf1e0zlIuOxPmifsisMrsKrVbXm1okkH+uNE9ts QKWMOkC2KN9QFj7O3RUBNqEm/hWMOThQ9TRhHh3hWSnKqtMqO+Q0ZpdsKhVe9cCrj8iO S0wM2ZYWLTEvScpv2yZ3mHP1BkLSKOsT4h1KgPk70nWCvrD7vfanlxzm/VqWI2QQtMfw 2Ot/VYqh2dYRFX++GqtDHAXfJ+ToxoQ0m/5SpCBUrPOmE3j9xxJX894PJWjwe8QZRV27 5FZez/Kr1DvZhsk4rIDvZtWh8/B7IVerJKlYDM16rEG/ZgX+sOKAFvsSLubOTNqYo/5s eArQ== 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=16XhDvI/LvsB/sJ/u6ze3v2TsKuw3spFv8LLAccbGXo=; b=aXSbreV9t3/IPK/QMKm9SPRC4b62uJOkyDPgfg2RVCOcL8VVSBbiOjwIwEtSSfJD2Z ioLjGAovkxk4tJEttRrntt5AZLDztObGWZCr7SMn/2twWnVnRcWpO5c9Jw4e9wVDec8T eHd1FWdo+ttVKc+JbP00qsNgoltcgfYpnSBNuvSbuOx7gqKcg5pA/grDul/1LVds8OTn glGQ+b1WJ9P0tUkKM+TTehbF0xUwTCwTFKpcFuX4ScN5FQ//vt+MqbAsyVPFTpOrJE82 V9Peuf0ErKN4rZWvEx9c+7NeYn1o1VBtdlGuSF46JQwJL10H/tvDbopI37uADIeHSo1y 9PfA== X-Gm-Message-State: AFeK/H0rKP2lzn9WbYmHNzQWWs8xoOH2/rrcC9KOnOUndAOVrtwbmImV8aMUJxUyLwR34YPpyalpARU5OlxB6Q== X-Received: by 10.36.84.211 with SMTP id t202mr8032686ita.96.1489634725445; Wed, 15 Mar 2017 20:25:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.41.19 with HTTP; Wed, 15 Mar 2017 20:24:44 -0700 (PDT) In-Reply-To: <0B185EDE-66D4-4E83-B337-D359FCF0C5B0@dericed.com> References: <0B185EDE-66D4-4E83-B337-D359FCF0C5B0@dericed.com> From: Tessa Fallon Date: Wed, 15 Mar 2017 23:24:44 -0400 Message-ID: To: Dave Rice Cc: Steve Lhomme , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary=001a1139ad8ea7c802054ad09c8d Archived-At: Subject: Re: [Cellar] IETF current milestones: request for feedback 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, 16 Mar 2017 03:25:29 -0000 --001a1139ad8ea7c802054ad09c8d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable RE: Jul 2017 Submit specification for FFV1 video codec version 4 to IESG (Standards Track) Sep 2017 Submit specification for Matroska container format version 4 to IESG (Standards Track) Mar 2017 Submit informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication Mar 2017 Submit specification for EBML to IESG (Standards Track) May 2017 Submit informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication If these seem like reasonable dates to contributors, I will move to update milestones. RE: FLAC, backburner IMO until other milestones are on track. If there are folks who only want to work on FLAC and who are not actively working on other specs, I would ask them to speak up here to organize. I know there were some efforts a while ago, but I am not personally aware of any progress. Tessa On Sun, Feb 26, 2017 at 6:31 PM, Dave Rice wrote: > Hi Tessa, Steve, cellar, > > On Sep 18, 2016, at 3:44 AM, Steve Lhomme wrote: > > 2016-09-13 15:58 GMT+02:00 Tessa Fallon : > > At the CELLAR meeting in July, it was decided that working group mileston= es > would need to be revised. The current list is below. > > Would those working on FFV1, EBML, and Matroska weigh in on the state of > the > specifications and projected timelines for work to be completed? I note > that the most recent changes to EBML were submitted on Sunday 9/11. Wher= e > does this leave the document? > > > It's an on-going effort. There are currently 16 issues opened on the > EBML specs alone: > https://github.com/Matroska-Org/ebml-specification/issues > > > EBML is down to 7 issues now, though some are ideas/considerations rather > than issues. I propose that a milestone for submitting EBML to IESG is > reset to a date in the near-future (end of March), and nudge for more > comprehensive peer-reviews of the EBML specification. > > There are 5 on Matroska but that's because most of the effort has been > concentrated on EBML yet: > https://github.com/Matroska-Org/matroska-specification/issues > > > Matroska is now up to 19 issues since it=E2=80=99s been more active latel= y. It=E2=80=99s > certainly a large specification so perhaps we should set a new list of mo= re > granular milestones for the components of the specification: > > - attachments > - chapters / menu > - codec_specs > - cues > - diagram > - the EBML Schema of Matroska > - index / notes / order_guidelines / streaming > - subtitles > - tagging / metadata > > Volunteers to manage a review of the state of each component? > > With FFV1, there=E2=80=99s 6 open issues and half refer to future version > enhancements. Volunteers willing, I think it=E2=80=99s likely a version 0= , 1, 2, 3 > specification of FFV1 could be ready to submit to the IESG at the end of > March as well. > > However these depend on sufficient peer-reviews. Perhaps we could > collaborate with one of the other audiovisual working groups for a > cross-peer-review. > > Here=E2=80=99s a new draft of a milestone list, please comment/advice: > > ? Submit specification for FLAC audio codec to IESG (Standards Track) > Jul 2017 Submit specification for FFV1 video codec version 4 to > IESG (Standards Track) > Sep 2017 Submit specification for Matroska container format version 4 > to IESG (Standards Track) > Mar 2017 Submit informational specification for FFV1 video codec versions > 0, 1 and 3 to IESG for publication > Mar 2017 Submit specification for EBML to IESG (Standards Track) > May 2017 Submit informational specification for Matroska container > format versions 1, 2 and 3 to IESG for publication > > Although since Matroska version 4 has been in use for so longer, perhaps > the milestone to work on a future Matroska version should be changed to > =E2=80=98version 5=E2=80=99 rather than 4. > > Also FLAC? There=E2=80=99s been a few volunteer to get this started (self > included), but as far as I know, there=E2=80=99s no progress on this spec= ification. > > Thanks much, > Dave > > There are way more elements to defined in Matroska, various > interactions between them and all kinds of loopholes that we need to > iron out. > > Much thanks, > Tessa > > Date > Dec 2016 Submit specification for FLAC audio codec to IESG (Standards > Track) > Sep 2016 Submit specification for FFV1 video codec version 4 to IESG > (Standards Track) > Jul 2016 Submit specification for Matroska container format version 4 to > IESG (Standards Track) > Jul 2016 Submit informational specification for FFV1 video codec versions > 0, > 1 and 3 to IESG for publication > Jun 2016 Submit specification for EBML to IESG (Standards Track) > Jun 2016 Submit informational specification for Matroska container format > versions 1, 2 and 3 to IESG for publication > > _______________________________________________ > 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 > > > --001a1139ad8ea7c802054ad09c8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
RE:

Ju= l 2017 Submit specification for FFV1 video codec version 4 to IESG=C2=A0(St= andards Track)
Sep 2017 Submit specification for Matroska container format versi= on 4 to=C2=A0IESG (Standards Track)
Mar 2017 Submit informational specification = for FFV1 video codec versions 0,=C2=A01 and 3 to IESG for publication
Mar 2017 S= ubmit specification for EBML to IESG (Standards Track)
May 2017 Submit informati= onal specification for Matroska container format=C2=A0versions 1, 2 and 3 t= o IESG for publication

If these seem like= reasonable dates to contributors, I will move to update milestones.=

RE: FLAC, backburner IMO until other milestones are= on track.=C2=A0 If there are folks who only want to work on FLAC and who a= re not actively working on other specs, I would ask them to speak up here t= o organize.=C2=A0 I know there were some efforts a while ago, but I am not = personally aware of any progress.

Tessa

On S= un, Feb 26, 2017 at 6:31 PM, Dave Rice <dave@dericed.com> wro= te:
H= i Tessa, Steve, cellar,

On Sep 18, 2016, at 3:44 AM, Steve Lhomme <slhomme@matroska.org> wrote:<= /div>
= 2016-09-13 15:58 GMT+02:00 Tessa Fallon <tessa.fallon@gmail.com>:
At the CELLAR meeting in July, it was decided that working g= roup milestones
would need to be revised. =C2=A0=C2=A0The current list i= s below.

Would those working on FFV1, EBML, and Matroska weigh in on= the state of the
specifications and projected timelines for work to be = completed?=C2=A0 I note
that the most recent changes to EBML were submit= ted on Sunday 9/11.=C2=A0 Where
does this leave the document?

It's an on-going effort. There are currently 16 issues opened= on the
EBML specs alone:
https://github.com/Matroska-Org/ebml-specification/issues

<= /div>
EBML is down to 7 issues now, though some are ideas/consid= erations rather than issues. I propose that a milestone for submitting EBML= to IESG is reset to a date in the near-future (end of March), and nudge fo= r more comprehensive peer-reviews of the EBML specification.

There are 5 on Matroska but= that's because most of the effort has been
concentrated on EBML yet= :
https://github.com/Matroska-Org/matroska-specifi= cation/issues

Matroska is now up to 19 issues since it=E2=80=99s been more active late= ly. It=E2=80=99s certainly a large specification so perhaps we should set a= new list of more granular milestones for the components of the specificati= on:

- attachments
- chapters / menu
- codec_specs
- cues
- diagram
- the EB= ML Schema of Matroska
- index / notes / order_guidelines / stream= ing
- subtitles
- tagging / metadata

Volunteers to manage a review of the state of each component?
<= div>
With FFV1, there=E2=80=99s 6 open issues and half refer = to future version enhancements. Volunteers willing, I think it=E2=80=99s li= kely a version 0, 1, 2, 3 specification of FFV1 could be ready to submit to= the IESG at the end of March as well.

However the= se depend on sufficient peer-reviews. Perhaps we could collaborate with one= of the other audiovisual working groups for a cross-peer-review.

Here=E2=80=99s a new draft of a milestone list, please comm= ent/advice:

? Submit specification for FLAC audio = codec to IESG (Standards Track)
Jul 2017 Submit specification for= FFV1 video codec version 4 to IESG=C2=A0(Standards Track)
Sep 2017 Subm= it specification for Matroska container format version 4 to=C2=A0IESG (Stan= dards Track)
Mar 2017 Submit informational specification for FFV1 video = codec versions 0,=C2=A01 and 3 to IESG for publication
Mar 2017 Submit s= pecification for EBML to IESG (Standards Track)
May 2017 Submit informat= ional specification for Matroska container format=C2=A0versions 1, 2 and 3 = to IESG for publication

Although since Matroska ve= rsion 4 has been in use for so longer, perhaps the milestone to work on a f= uture Matroska version should be changed to =E2=80=98version 5=E2=80=99 rat= her than 4.

Also FLAC? There=E2=80=99s been a few = volunteer to get this started (self included), but as far as I know, there= =E2=80=99s no progress on this specification.

Than= ks much,
Dave

There are way more elements to defined in Matroska, variou= s
interactions between them and all kinds of loopholes that we need toiron out.

Much thanks,
Tessa

D= ate
Dec 2016 Submit specification for FLAC audio codec to IESG (Standard= s Track)
Sep 2016 Submit specification for FFV1 video codec version 4 to= IESG
(Standards Track)
Jul 2016 Submit specification for Matroska co= ntainer format version 4 to
IESG (Standards Track)
Jul 2016 Submit in= formational specification for FFV1 video codec versions 0,
1 and 3 to IE= SG for publication
Jun 2016 Submit specification for EBML to IESG (Stand= ards Track)
Jun 2016 Submit informational specification for Matroska con= tainer format
versions 1, 2 and 3 to IESG for publication

_______= ________________________________________
Cellar mailing list
Cellar@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/cellar



--
Steve Lhomme
Matroska association Chairman

______= _________________________________________
Cellar mailing list
Cellar@ietf.org
<= a href=3D"https://www.ietf.org/mailman/listinfo/cellar" target=3D"_blank">h= ttps://www.ietf.org/mailman/listinfo/cellar


--001a1139ad8ea7c802054ad09c8d-- From nobody Wed Mar 15 20:29:27 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 9D5AD131440 for ; Wed, 15 Mar 2017 20:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFcPNSxgPQ1j for ; Wed, 15 Mar 2017 20:29:23 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 55577130141 for ; Wed, 15 Mar 2017 20:29:23 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id b140so33969718iof.1 for ; Wed, 15 Mar 2017 20:29:23 -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=s+JT0TklvInm2+wwrLUlBXwx9B+1zYdlNsult4WYLFg=; b=Wt82+aKA8Nc05uMgNL8zfNerY07Lhxm2RRt9XNxx4Ezo2f9H7CvbLIs/x48aRjPRTR N0gDBGKIlV7jo//ToWYheTiPkyl/JtnSOMHL7RfUzcG4RH7B47TI2Qezgx68Dy7wIq9G cCK1VZgc84hlSwW0VFEwgAkyh+GhkkYq/pZlDUij2ooLS7iF8jTVCvZWMDIQsZw7mg+O MUNeP1sjRlL0oaPUxRfCK7BEOOZ26LT2zZ0rC3KU7TlUpQ5K+naT4K5V7ROHpVAMeC+0 xTlsiLUKw7uLUQR3NnWhBEpUG2uoLC9DlTZjONur3rdci1JFU+g+jvF227GjFGqbu2HJ PYXA== 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=s+JT0TklvInm2+wwrLUlBXwx9B+1zYdlNsult4WYLFg=; b=brqx/Hln7mdfXpRAvLaRO+6vHqRCzW+2czYNCarfx4iAxzjIc00srKqbEkw4aFNrz6 2Z9E+l+XS4LOX13rwVZ1nP1aKtOLXDYhzv5tIsw23MNl2U84Os8lHU9BbAHgjAPhsFsE CRHME4NkFQfKZNN+D/snJmFJ9THEPfqJ3T0OJwoxeTNpLKhxqfofLgCMohZkUYxZX/lD Vq/S6CAl6vGRzQZxgIsO1dONP8QJ+6MJXI0ZHaoFiSNJcQnbuNLEKXG4z6hpdGPjDri7 Ww47GT3Q5P+wybnpNHrGzeK4G+exBgJDGz8pLW1YfqzlZthSv36fQrS1v51Kaa53h9an u5Xg== X-Gm-Message-State: AFeK/H222OLxJlLx+wrt2XKs5+skwlgsaGpNjMVFisFDvmTClkFdgXcw7clk5BXpdzNMz6uw0IZRBN+V+M9PMg== X-Received: by 10.107.129.214 with SMTP id l83mr8123904ioi.168.1489634962696; Wed, 15 Mar 2017 20:29:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.41.19 with HTTP; Wed, 15 Mar 2017 20:28:42 -0700 (PDT) In-Reply-To: <18752B8C-73D0-4312-85DE-5566CC805AF5@dericed.com> References: <1888ECBC-8420-406C-B259-EB31B08D0952@dericed.com> <18752B8C-73D0-4312-85DE-5566CC805AF5@dericed.com> From: Tessa Fallon Date: Wed, 15 Mar 2017 23:28:42 -0400 Message-ID: To: Dave Rice Cc: Steve Lhomme , Nick.Drouin@live.com, Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary=001a113ecb9ccbf1a2054ad0aacd Archived-At: Subject: Re: [Cellar] adding VP8 and VP9 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, 16 Mar 2017 03:29:26 -0000 --001a113ecb9ccbf1a2054ad0aacd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Resurrecting this thread: was the intent to document use VP8 and VP9 in the Matroska specification? Was there any action on this? On Sat, Feb 4, 2017 at 9:56 AM, Dave Rice wrote: > The VP9 link is updated to http://www.webmproject.org/vp9. > https://github.com/Matroska-Org/matroska-specification/pull/91 should be > ready. > Dave > > > On Feb 4, 2017, at 9:50 AM, Dave Rice wrote: > > > > The VP9 format specification is still in draft form. We could use > https://storage.googleapis.com/downloads.webmproject.org/ > docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf as used on > http://www.webmproject.org/vp9/. This link is not hosted by IETF but is > more up to date. > > > > Is the IETF actively working on VP9? > > Dave > > > >> On Feb 4, 2017, at 8:14 AM, Steve Lhomme wrote: > >> > >> They definitely need to go in. The VP9 link should be changed to > >> something more stable and revent. Otherwise LGTM. > >> > >> 2017-02-01 23:57 GMT+01:00 Dave Rice : > >>> Hi cellar, > >>> > >>> Just before the cellar wg became active there was a proposal on > >>> matroska-devel to document use of VP8 and VP9 in Matroska, similar to > how > >>> they have been defined in webm. I started a pull request at > >>> https://github.com/Matroska-Org/matroska-specification/pull/91 to add > them. > >>> > >>> The original thread also proposes adding WEBVTT but it seems there=E2= =80=99s > some > >>> open questions there about how to do so. > >>> > >>> Dave Rice > >>> > >>> > >>> _______________________________________________ > >>> 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 > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --001a113ecb9ccbf1a2054ad0aacd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Resurrecting this thread: was the intent to document use V= P8 and VP9 in the Matroska specification? Was there any action on this?

On Sat, Feb 4, = 2017 at 9:56 AM, Dave Rice <dave@dericed.com> wrote:
The VP9 link is updated to http://www.webmpr= oject.org/vp9. https://github= .com/Matroska-Org/matroska-specification/pull/91 should be re= ady.
Dave

> On Feb 4, 2017, at 9:50 AM, Dave Rice <dave@dericed.com> wrote:
>
> The VP9 format specification is still in draft form. We could use https://storage.googleapis.com/downloads.webmproject.org/= docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf= as used on http://www.webmproject.org/vp9/. This link i= s not hosted by IETF but is more up to date.
>
> Is the IETF actively working on VP9?
> Dave
>
>> On Feb 4, 2017, at 8:14 AM, Steve Lhomme <slhomme@matroska.org> wrote:
>>
>> They definitely need to go in. The VP9 link should be changed to >> something more stable and revent. Otherwise LGTM.
>>
>> 2017-02-01 23:57 GMT+01:00 Dave Rice <dave@dericed.com>:
>>> Hi cellar,
>>>
>>> Just before the cellar wg became active there was a proposal o= n
>>> matroska-devel to document use of VP8 and VP9 in Matroska, sim= ilar to how
>>> they have been defined in webm. I started a pull request at >>> https://github.com/Matros= ka-Org/matroska-specification/pull/91 to add them.
>>>
>>> The original thread also proposes adding WEBVTT but it seems t= here=E2=80=99s some
>>> open questions there about how to do so.
>>>
>>> Dave Rice
>>>
>>>
>>> _______________________________________________
>>> Cellar mailing list
>>> Cellar@ietf.org
>>> https://www.ietf.org/mailman/listinf= o/cellar
>>>
>>
>>
>>
>> --
>> Steve Lhomme
>> Matroska association Chairman
>
> _______________________________________________
> 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

--001a113ecb9ccbf1a2054ad0aacd-- From nobody Wed Mar 15 21:42: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 0F57412025C for ; Wed, 15 Mar 2017 21:42:34 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 XlYXTllcm4Rc for ; Wed, 15 Mar 2017 21:42:32 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B15E120227 for ; Wed, 15 Mar 2017 21:42:32 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id EC98FC002824; Wed, 15 Mar 2017 21:42:31 -0700 (PDT) Received: from [10.0.1.31] (174-21-108-48.tukw.qwest.net [174.21.108.48]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: brian@madronalabs.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id 6D627C002821; Wed, 15 Mar 2017 21:42:31 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Brian Willoughby In-Reply-To: Date: Wed, 15 Mar 2017 21:42:31 -0700 Cc: Dave Rice , Codec Encoding for LossLess Archiving and Realtime transmission Content-Transfer-Encoding: quoted-printable Message-Id: References: <0B185EDE-66D4-4E83-B337-D359FCF0C5B0@dericed.com> To: Tessa Fallon X-Mailer: Apple Mail (2.1510) Archived-At: Subject: Re: [Cellar] IETF current milestones: request for feedback 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, 16 Mar 2017 04:42:34 -0000 Hello, I am one of the folks who joined this mailing list to contribute = regarding my experience with FLAC code development and end use of the = technology. So far, I've just been deleting Matroska messages as they = come through because I do not have the bandwidth to study the other = standards - so I'm clearly not working on other specs. If someone wants to organize a distinct FLAC list or group, please feel = free to contact me at the above email address and perhaps we can make = progress. My contribution would be to make sure that the original capabilities and = intents of FLAC are maintained as its spec is absorbed in others. If = Josh Coalson is available, he would certainly be the ultimate authority, = but I've been involved to an extent for quite a long time. Of course, I = would need a summary of the goals for the new specifications in order to = make sense of the situation. Brian Willoughby Sound Consulting On Mar 15, 2017, at 8:24 PM, Tessa Fallon = wrote: > RE: FLAC, backburner IMO until other milestones are on track. If = there are folks who only want to work on FLAC and who are not actively = working on other specs, I would ask them to speak up here to organize. = I know there were some efforts a while ago, but I am not personally = aware of any progress. >=20 > Tessa >=20 > On Sun, Feb 26, 2017 at 6:31 PM, Dave Rice wrote: >> Hi Tessa, Steve, cellar, >>=20 >>> On Sep 18, 2016, at 3:44 AM, Steve Lhomme = wrote: >>>=20 >>> 2016-09-13 15:58 GMT+02:00 Tessa Fallon : >>=20 >> Here=92s a new draft of a milestone list, please comment/advice: >>=20 >> ? Submit specification for FLAC audio codec to IESG (Standards Track) >>=20 >> Also FLAC? There=92s been a few volunteer to get this started (self = included), but as far as I know, there=92s no progress on this = specification. >>=20 >> Thanks much, >> Dave >>=20 >>>> Much thanks, >>>> Tessa >>>>=20 >>>> Date >>>> Dec 2016 Submit specification for FLAC audio codec to IESG = (Standards Track) >>=20 From nobody Wed Mar 15 21:51:16 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 A9F351201F8 for ; Wed, 15 Mar 2017 21:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSZuursUT-dg for ; Wed, 15 Mar 2017 21:51:12 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 6A4E612002E for ; Wed, 15 Mar 2017 21:51:12 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id n11so38100970wma.0 for ; Wed, 15 Mar 2017 21:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8KGzrnF53MocHog9qv9B4IMTusx56dyuGqq6QkDGA/0=; b=pE+rX9Fq4IJa284x6Zx/KPnAeAW28EHqI8mw1QECwLsFmPkeqZMAH0U2XA8iIG7axS lc+HcS31+pLenz+Tx/1H8a9G4hTe2iFQyY0cA4Mpj3fRiU9zqlb732YAHJBOnNHmnnJq NABFHiEhkBZ/7UdW4cXVqdxpY65+gKyMP9b1ybdT8/161vnZJ9aHI69s2OThmBDsDZBz m9lL/uajANbbxXJ6eWGTEacWBv8dhd9HjX5MTTnAR8wul/0M01qGmlyMAymNY3gTZU/d ZNEWvuTqjmFK4Qy4yMZknRTYvCinwpR9u8fyhWpPX4gbcew6QqibILS3DJDc86jLd1mB zdVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=8KGzrnF53MocHog9qv9B4IMTusx56dyuGqq6QkDGA/0=; b=AlBjo4yxlyS/kAFbcmla+30QmJLPh3haqcqk3JKbHbCZA9lAkNQCpFqY6S2G0ILy2K at26b9g4+wdis/IawXDZ3zsgp9y3lmzM4pne7F5TYReAL50N9Vc3GQDyGb8CbX7gotXP 7CL8zB2w41kIlJk/AACckm8bc1Dg/JBPmRHuUw19RLFVxOeU7czkCQ7ESOtWc0XTx1dN BC32FvMmbMNXS46tht8w3gqFUhLJgVRSgHZjYsluZxISgETs1omq9X0WKA3zkn1yJbZM 0lFj9xIofqeabDp2uvIalqlXwVFpcPFiIh5EQoS8Jz45ZMwD2DCEgroyx0xomyxp+zs+ EWeA== X-Gm-Message-State: AFeK/H1wuHL3vpQ7OuJifadSJpxM6IBvTLME1JCSMWPYDJJrPftb3IO42K243jfSFqr4eA== X-Received: by 10.28.111.151 with SMTP id c23mr22764195wmi.17.1489639870949; Wed, 15 Mar 2017 21:51:10 -0700 (PDT) Received: from [192.168.1.26] (144.128.152.78.rev.sfr.net. [78.152.128.144]) by smtp.gmail.com with ESMTPSA id i82sm1166917wmf.1.2017.03.15.21.51.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Mar 2017 21:51:10 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Pierre-Yves Thoulon X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Thu, 16 Mar 2017 05:51:09 +0100 Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Dave Rice Content-Transfer-Encoding: quoted-printable Message-Id: <733441AF-FD83-4ACA-B03C-CB507C6A4E21@gmail.com> References: <0B185EDE-66D4-4E83-B337-D359FCF0C5B0@dericed.com> To: Tessa Fallon Archived-At: Subject: Re: [Cellar] IETF current milestones: request for feedback 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, 16 Mar 2017 04:51:15 -0000 Same here. I have not been involved in the matroska effort as I have neither= the bandwidth nor the knowledge to do so, but I've been working extensively= these years with Flac. Unfortunately I don't have time to organize anything= on the matter, but I will make some to participate in the spec review.=20 Kind regards.=20 Pyt. > Le 16 mars 2017 =C3=A0 05:42, Brian Willoughby a= =C3=A9crit : >=20 > Hello, >=20 > I am one of the folks who joined this mailing list to contribute regarding= my experience with FLAC code development and end use of the technology. So f= ar, I've just been deleting Matroska messages as they come through because I= do not have the bandwidth to study the other standards - so I'm clearly not= working on other specs. >=20 > If someone wants to organize a distinct FLAC list or group, please feel fr= ee to contact me at the above email address and perhaps we can make progress= . >=20 > My contribution would be to make sure that the original capabilities and i= ntents of FLAC are maintained as its spec is absorbed in others. If Josh Coa= lson is available, he would certainly be the ultimate authority, but I've be= en involved to an extent for quite a long time. Of course, I would need a su= mmary of the goals for the new specifications in order to make sense of the s= ituation. >=20 > Brian Willoughby > Sound Consulting >=20 >=20 >> On Mar 15, 2017, at 8:24 PM, Tessa Fallon wrote:= >> RE: FLAC, backburner IMO until other milestones are on track. If there a= re folks who only want to work on FLAC and who are not actively working on o= ther specs, I would ask them to speak up here to organize. I know there wer= e some efforts a while ago, but I am not personally aware of any progress. >>=20 >> Tessa >>=20 >>> On Sun, Feb 26, 2017 at 6:31 PM, Dave Rice wrote: >>> Hi Tessa, Steve, cellar, >>>=20 >>>> On Sep 18, 2016, at 3:44 AM, Steve Lhomme wrote:= >>>>=20 >>>> 2016-09-13 15:58 GMT+02:00 Tessa Fallon : >>>=20 >>> Here=E2=80=99s a new draft of a milestone list, please comment/advice: >>>=20 >>> ? Submit specification for FLAC audio codec to IESG (Standards Track) >>>=20 >>> Also FLAC? There=E2=80=99s been a few volunteer to get this started (sel= f included), but as far as I know, there=E2=80=99s no progress on this speci= fication. >>>=20 >>> Thanks much, >>> Dave >>>=20 >>>>> Much thanks, >>>>> Tessa >>>>>=20 >>>>> Date >>>>> Dec 2016 Submit specification for FLAC audio codec to IESG (Standards T= rack) >>>=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Thu Mar 16 02:15: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 A8839127097 for ; Thu, 16 Mar 2017 02:15:06 -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, 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 pnvy4OVD8blU for ; Thu, 16 Mar 2017 02:15:05 -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 4B5AF126DD9 for ; Thu, 16 Mar 2017 02:15:04 -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, 16 Mar 2017 10:15:02 +0100 id 0000000000000078.0000000058CA5796.00001B35 Message-ID: <58CA5792.6070606@das-werkstatt.com> Date: Thu, 16 Mar 2017 10:14:58 +0100 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Codec Encoding for LossLess Archiving and Realtime transmission References: <0B185EDE-66D4-4E83-B337-D359FCF0C5B0@dericed.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] IETF current milestones: request for feedback 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, 16 Mar 2017 09:15:07 -0000 Hi everyone! :D On 03/16/2017 04:24 AM, Tessa Fallon wrote: > Jul 2017 Submit specification for FFV1 video codec version 4 to > IESG (Standards Track) > Sep 2017 Submit specification for Matroska container format version 4 > to IESG (Standards Track) Which new features are planned/desired to be in FFV1 version 4? So far I only know of plans for (film-grade) color-handling. Doi we have a consensus on whether which parts of it are gonna be in the codec and/or the container? Cheers, Pb From nobody Thu Mar 16 04:58:54 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 B31081292D3 for ; Thu, 16 Mar 2017 04:58:52 -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, 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] 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 n5WdgrH-32h5 for ; Thu, 16 Mar 2017 04:58:50 -0700 (PDT) Received: from 10.mo3.mail-out.ovh.net (10.mo3.mail-out.ovh.net [87.98.165.232]) (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 B46EF1270A3 for ; Thu, 16 Mar 2017 04:58:50 -0700 (PDT) Received: from player693.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id 891A0B977F for ; Thu, 16 Mar 2017 12:58:48 +0100 (CET) Received: from [192.168.2.101] (p5DDB5708.dip0.t-ipconnect.de [93.219.87.8]) (Authenticated sender: jerome@mediaarea.net) by player693.ha.ovh.net (Postfix) with ESMTPSA id 20CF9440071 for ; Thu, 16 Mar 2017 12:58:47 +0100 (CET) To: cellar@ietf.org References: <0B185EDE-66D4-4E83-B337-D359FCF0C5B0@dericed.com> From: Jerome Martinez Message-ID: <08e0533a-85a6-2751-a90a-13000f8dab4c@mediaarea.net> Date: Thu, 16 Mar 2017 12:58:46 +0100 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="------------5649A0AEA97538CD01EFE5FB" X-Ovh-Tracer-Id: 9077005051091685521 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelhedriedtgddutdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] IETF current milestones: request for feedback 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, 16 Mar 2017 11:58:52 -0000 This is a multi-part message in MIME format. --------------5649A0AEA97538CD01EFE5FB Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 16/03/2017 à 04:24, Tessa Fallon a écrit : > RE: > > Jul 2017 Submit specification for FFV1 video codec version 4 to > IESG (Standards Track) > Sep 2017 Submit specification for Matroska container format version 4 > to IESG (Standards Track) > Mar 2017 Submit informational specification for FFV1 video codec > versions 0, 1 and 3 to IESG for publication > Mar 2017 Submit specification for EBML to IESG (Standards Track) > May 2017 Submit informational specification for Matroska container > format versions 1, 2 and 3 to IESG for publication > > If these seem like reasonable dates to contributors, I will move to > update milestones. I would like to do a review of FFV1 specs, is it an issue if we put FFV1 in April? Or is it considered by others as enough reviewed? > > RE: FLAC, backburner IMO until other milestones are on track. If > there are folks who only want to work on FLAC and who are not actively > working on other specs, I would ask them to speak up here to > organize. I know there were some efforts a while ago, but I am not > personally aware of any progress. I started to review the current spec, I did not have the time to write "patches" about it. Definitely on my todo-list and I am happy to see that there is some people interested to join the effort, but on my side I'll focus on it only after EBML/Matroska/FFV1.0-3 is finished. --------------5649A0AEA97538CD01EFE5FB Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Le 16/03/2017 à 04:24, Tessa Fallon a écrit :
RE:

Jul 2017 Submit specification for FFV1 video codec version 4 to IESG (Standards Track)
Sep 2017 Submit specification for Matroska container format version 4 to IESG (Standards Track)
Mar 2017 Submit informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication
Mar 2017 Submit specification for EBML to IESG (Standards Track)
May 2017 Submit informational specification for Matroska container format versions 1, 2 and 3 to IESG for publication

If these seem like reasonable dates to contributors, I will move to update milestones.

I would like to do a review of FFV1 specs, is it an issue if we put FFV1 in April?
Or is it considered by others as enough reviewed?


RE: FLAC, backburner IMO until other milestones are on track.  If there are folks who only want to work on FLAC and who are not actively working on other specs, I would ask them to speak up here to organize.  I know there were some efforts a while ago, but I am not personally aware of any progress.

I started to review the current spec, I did not have the time to write "patches" about it. Definitely on my todo-list and I am happy to see that there is some people interested to join the effort,  but on my side I'll focus on it only after EBML/Matroska/FFV1.0-3 is finished. --------------5649A0AEA97538CD01EFE5FB-- From nobody Thu Mar 16 04:59:51 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 EEEDE129439 for ; Thu, 16 Mar 2017 04:59:49 -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, 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] 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 pOlFWykWXsXw for ; Thu, 16 Mar 2017 04:59:48 -0700 (PDT) Received: from 9.mo3.mail-out.ovh.net (9.mo3.mail-out.ovh.net [87.98.184.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8924112943A for ; Thu, 16 Mar 2017 04:59:48 -0700 (PDT) Received: from player693.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id B6384B9386 for ; Thu, 16 Mar 2017 12:59:46 +0100 (CET) Received: from [192.168.2.101] (p5DDB5708.dip0.t-ipconnect.de [93.219.87.8]) (Authenticated sender: jerome@mediaarea.net) by player693.ha.ovh.net (Postfix) with ESMTPSA id 99351440096 for ; Thu, 16 Mar 2017 12:59:46 +0100 (CET) To: cellar@ietf.org References: <0B185EDE-66D4-4E83-B337-D359FCF0C5B0@dericed.com> From: Jerome Martinez Message-ID: Date: Thu, 16 Mar 2017 12:59:44 +0100 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="------------1F09877BA241FAE6CD9E92CC" X-Ovh-Tracer-Id: 9093330600596934801 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelhedriedtgddutdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] IETF current milestones: request for feedback 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, 16 Mar 2017 11:59:50 -0000 This is a multi-part message in MIME format. --------------1F09877BA241FAE6CD9E92CC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Le 16/03/2017 à 04:24, Tessa Fallon a écrit : > > Jul 2017 Submit specification for FFV1 video codec version 4 to > IESG (Standards Track) From my point of view focus on FFV1 v4 should be done only after v3 is standardized. --------------1F09877BA241FAE6CD9E92CC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Le 16/03/2017 à 04:24, Tessa Fallon a écrit :

Jul 2017 Submit specification for FFV1 video codec version 4 to IESG (Standards Track)

From my point of view focus on FFV1 v4 should be done only after v3 is standardized.
--------------1F09877BA241FAE6CD9E92CC-- From nobody Thu Mar 16 06:58:15 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 EA139129517 for ; Thu, 16 Mar 2017 06:58:12 -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, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4aksZ9tV51Y for ; Thu, 16 Mar 2017 06:58:10 -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 5756D12951E for ; Thu, 16 Mar 2017 06:58:07 -0700 (PDT) Received: from [146.96.19.240] (port=28456 helo=[10.10.201.33]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1coVun-00032L-Gs; Thu, 16 Mar 2017 09:58:06 -0400 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_922A3071-45D7-4340-ADDD-FF32BDECE0F9" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Thu, 16 Mar 2017 09:58:03 -0400 In-Reply-To: Cc: Nick.Drouin@live.com, Codec Encoding for LossLess Archiving and Realtime transmission , Steve Lhomme To: Tessa Fallon References: <1888ECBC-8420-406C-B259-EB31B08D0952@dericed.com> <18752B8C-73D0-4312-85DE-5566CC805AF5@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] adding VP8 and VP9 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, 16 Mar 2017 13:58:13 -0000 --Apple-Mail=_922A3071-45D7-4340-ADDD-FF32BDECE0F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Tessa, It looks like Steve merged the patch into the codec_spec.md document = back on February 4th. See = https://github.com/Matroska-Org/matroska-specification/pull/91 = . VP8 = and VP9 had been in regular use in Matroska but the documentation on = this had never been finished in MKV, although it was in webm. The patch = resolved one of the discrepancies between mkv and webm. Dave > On Mar 15, 2017, at 11:28 PM, Tessa Fallon = wrote: >=20 > Resurrecting this thread: was the intent to document use VP8 and VP9 = in the Matroska specification? Was there any action on this? >=20 > On Sat, Feb 4, 2017 at 9:56 AM, Dave Rice > wrote: > The VP9 link is updated to http://www.webmproject.org/vp9 = . = https://github.com/Matroska-Org/matroska-specification/pull/91 = should = be ready. > Dave >=20 > > On Feb 4, 2017, at 9:50 AM, Dave Rice > wrote: > > > > The VP9 format specification is still in draft form. We could use = https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bits= tream-specification-v0.6-20160331-draft.pdf = as used on = http://www.webmproject.org/vp9/ . This = link is not hosted by IETF but is more up to date. > > > > Is the IETF actively working on VP9? > > Dave > > > >> On Feb 4, 2017, at 8:14 AM, Steve Lhomme > wrote: > >> > >> They definitely need to go in. The VP9 link should be changed to > >> something more stable and revent. Otherwise LGTM. > >> > >> 2017-02-01 23:57 GMT+01:00 Dave Rice >: > >>> Hi cellar, > >>> > >>> Just before the cellar wg became active there was a proposal on > >>> matroska-devel to document use of VP8 and VP9 in Matroska, similar = to how > >>> they have been defined in webm. I started a pull request at > >>> https://github.com/Matroska-Org/matroska-specification/pull/91 = to add = them. > >>> > >>> The original thread also proposes adding WEBVTT but it seems = there=E2=80=99s some > >>> open questions there about how to do so. > >>> > >>> Dave Rice > >>> > >>> > >>> _______________________________________________ > >>> 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 = >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar = >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_922A3071-45D7-4340-ADDD-FF32BDECE0F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Tessa,
It looks like = Steve merged the patch into the codec_spec.md document back on February = 4th. See https://github.com/Matroska-Org/matroska-specification/pull/91<= /a>. VP8 and VP9 had been in regular use in Matroska but the = documentation on this had never been finished in MKV, although it was in = webm. The patch resolved one of the discrepancies between mkv and = webm.
Dave


On Mar 15, 2017, at 11:28 PM, Tessa Fallon = <tessa.fallon@gmail.com> wrote:

Resurrecting this thread: was the intent to document use VP8 = and VP9 in the Matroska specification? Was there any action on = this?

On Sat, Feb 4, 2017 at 9:56 AM, Dave Rice <dave@dericed.com> wrote:
The VP9 link is = updated to http://www.webmproject.org/vp9. https://github.com/Matroska-Org/matroska-specification/pull/91 should = be ready.
Dave

> On Feb 4, 2017, at 9:50 AM, Dave Rice <dave@dericed.com> = wrote:
>
> The VP9 format specification is still in draft form. We could use = https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf as = used on http://www.webmproject.org/vp9/. This link is not hosted by IETF but is more up to = date.
>
> Is the IETF actively working on VP9?
> Dave
>
>> On Feb 4, 2017, at 8:14 AM, Steve Lhomme <slhomme@matroska.org> wrote:
>>
>> They definitely need to go in. The VP9 link should be changed = to
>> something more stable and revent. Otherwise LGTM.
>>
>> 2017-02-01 23:57 GMT+01:00 Dave Rice <dave@dericed.com>:
>>> Hi cellar,
>>>
>>> Just before the cellar wg became active there was a = proposal on
>>> matroska-devel to document use of VP8 and VP9 in Matroska, = similar to how
>>> they have been defined in webm. I started a pull request = at
>>> https://github.com/Matroska-Org/matroska-specification/pull/91 to add = them.
>>>
>>> The original thread also proposes adding WEBVTT but it = seems there=E2=80=99s some
>>> open questions there about how to do so.
>>>
>>> Dave Rice
>>>
>>>
>>> _______________________________________________
>>> 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

_______________________________________________
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

= --Apple-Mail=_922A3071-45D7-4340-ADDD-FF32BDECE0F9-- From nobody Sat Mar 18 05:07:04 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 1626112704A for ; Sat, 18 Mar 2017 05:07:03 -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, MIME_QP_LONG_LINE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgWaMykwGNKV for ; Sat, 18 Mar 2017 05:07:00 -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 A682C126579 for ; Sat, 18 Mar 2017 05:07:00 -0700 (PDT) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:43359 helo=[10.0.1.17]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cpD8L-0031ne-UB for cellar@ietf.org; Sat, 18 Mar 2017 08:07:00 -0400 From: Dave Rice Content-Type: multipart/alternative; boundary=Apple-Mail-7E77E9F5-86CE-48E5-8917-A817C3678714 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Sat, 18 Mar 2017 08:06:56 -0400 Message-Id: To: cellar@ietf.org X-Mailer: iPhone Mail (14B100) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] review of draft-niedermayer-cellar-ffv1-01 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, 18 Mar 2017 12:07:03 -0000 --Apple-Mail-7E77E9F5-86CE-48E5-8917-A817C3678714 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi all, I thought I'd provide feedback on the current state of the FFV1 specificatio= n as found at https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1= /. Please note this review isn't complete and there are still many parts of t= he specification that I don't completely understand. =3D=3D Introduction =3D=3D Overall this section could be expanded to provide more characteristics about= FFV1, what encoding technologies it is based upon, and how it may be used. I= think at this point the sentence "The latest version of this document is av= ailable..." could be removed. =3D=3D Definitions =3D=3D These definitions could be reordered to prevent a need for forward reference= . For instance "RCT" references "RGB" and "YCbCr" but "YCbCr" and "RGB" come= after "RCT". "VLC" explains the abbreviation, but does not offer an explanation of the me= aning as is done for the other defined terms. The term "symbol" is used within the Definitions section and throughout the d= ocument. I think "symbol" and perhaps "sample" could themselves use definiti= ons. =3D=3D Comparison operators =3D=3D I think there is a typo in the "a || b" section: "a || b" means Boolean lo= gical "or" of a and b. Perhaps this should be "a or b". In "!a" I suggest that the "not" should be changed to "not a". =3D=3D Mathematical functions =3D=3D The definition for "abs(a)" uses an undefined function "sign(a)". =3D=3D remaining_bits_in_bitstream =3D=3D I suggest using a variable value within "remaining_bits_in_bitstream( )" suc= h as "remaining_bits_in_bitstream( a )" and then using "a" within the defini= tion. Same with the next function "byte_aligned ( )". =3D=3D Border =3D=3D Some issues are already discussed at https://github.com/FFmpeg/FFV1/issues/4= 2, but the language could be more clear. =3D=3D Median predictor =3D=3D This section starts right away with what looks like a function. It could use= some context, for instance to start with "Three neighboring samples are use= d to create a median predictor:". =3D=3D Context =3D=3D The diagram could use an explanation for what "X" is, as well as to say that= 'tl' is 'top-left', 't' is 'top', etc. Although the diagram appears to use "= X" as a reference point, the "X" is not discussed or used within the equatio= n. The form of "Q_0[a-b]" is introduced here, but the meaning is not explained.= Are the pipes in the equation used to mean absolute value, as in "|Q_0|" is= the "absolute value of the zeroth quantization value"? Perhaps the Quantization section should preceed the Context section. Instead of "-context" it could say something like "the absolute value of con= text". =3D=3D Quantization =3D=3D In this equation " Q_{i}[a-b]=3DTable_{i}[(a-b)&255]" what do "a" and "b" s= ignify? I presume this would be from the list of sample differences, but it c= ould be more clear. =3D=3D JPEG2000-RCT =3D=3D=3D These equations are familiar but the section could use an introductory parag= raph to say what they are for. =3D=3D Coding of the sample difference =3D=3D The "(or n+1)" should be "(or n+1, in the case of RCT)" to clarify what the p= arenthetical is referring to. Alternatively the section could be divided int= o an explanation in the case of RCT and an explanation for non-RCT. =3D=3D Range coding mode =3D=3D Is the anecdote about early experimental versions of FFV1 needed? Does this d= ocument define those early experimental versions? If not perhaps the anecdot= e could be removed. =3D=3D=3D Range binary values =3D=3D Some values are defined in the introduction of this section but many are mis= sing. For instance what does r_i, R_i, l_i, L_i, and t_i mean? Left, right, t= op? Also in the equations what is "k" representing? Is it the same "k" as fr= om the Huffman coding mode section? S_{0,i} is defined as the i-th initial state, but why is there a "0," in the= subscript to express that? The first equation uses C_i within the subscript of S_i. Is that intention o= r are C_i and S_i intended to be at the same level? The second equation starts with S with "i+1,C_i" as a subscript. =46rom the i= ntroduction statement S with "0,i" means the i-th State. What is the "0" mea= ning here? And how is the comma read in words? So is the second equation imp= lying that it considers the C_i-th state? Also note that I've tried in https://github.com/FFmpeg/FFV1/pull/50 to expre= ss these equations in an RFC-friendly manner, but to represent the subscript= (particularly when there are subscripts and subscripts) is particularly cha= llenging. Is there a method to express the same without subscript? =3D=3D Range non binary values =3D=3D The introduction contains some think-out-loud style considerations about dat= a encoding, this language could be made more concise and direct. Noting that the backslashed comments included in the function break the barr= ier within the table. =3D=3D State transition table =3D=3D This section is equation-only. It could benefit from a introductory sentence= to give context. =3D=3D default state transition =3D=3D This section is only the table and no introduction. It should note that the c= oder_type MUST be set to '1' when using this table. =3D=3D alternative state transition table =3D=3D "has been build" -> "has been built" Note that here it's called the "alternative state transition table" but in t= he coder_type section it is called the "custom state transition table". Are t= hese phrases meaning the same thing, or does "custom" imply any user-customi= zed table? =3D=3D Prefix =3D=3D Does the table here imply that the Prefix of the VLC code MUST be between 1 a= nd 12 bits? There are likely some requirements of the prefix that could be s= tated here. =3D=3D Examples =3D=3D Based upon what I can gather from the Prefix and Suffix tables, I am not abl= e to fully comprehend what is communicated by the examples section. Some nar= rative could help. =3D=3D Mapping FFV1 into Containers =3D=3D This section is a large subsection of the "Bitstream" section. It may be out= of place and perhaps would be better places at the same sectional level as "= Bitstream". =3D=3D Frame =3D=3D Within the Frame structure is data called "Parameters" is this the same as t= he "Parameters" within the Configuration Record? If not, perhaps they should= use distinct terms. Also there is a lowercase "parameters" used throughout t= he document. If "parameters" uses a locally defined meaning then it should b= e in title case. =3D=3D slice_coding_mode =3D=3D This references a manner of slice coding via PCM but there is no other refer= ence to this mode. When would PCM encoding be used and not Range or VLC? =3D=3D error_status =3D=3D I'm not certain when error status would not equal zero. If the ffv1 encoder e= xpected to detect writing errors and record them here? What sorts of conditi= ons would trigger that? =3D=3D slice footer =3D=3D The footer contains the slice size which IIUC allows some bidirectional seek= ing and resilience. It may be worthwhile to say here how this works in the e= vent that some slices are corrupted. Best Regards, Dave Rice --Apple-Mail-7E77E9F5-86CE-48E5-8917-A817C3678714 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi all,

I thought I'd provide fee= dback on the current state of the FFV1 specification as found at https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1/. Plea= se note this review isn't complete and there are still many parts of the spe= cification that I don't completely understand.
<= span style=3D"background-color: rgba(255, 255, 255, 0);">
=3D=3D Introduction =3D=3D

Overal= l this section could be expanded to provide more characteristics about FFV1,= what encoding technologies it is based upon, and how it may be used. I thin= k at this point the sentence "The latest version of this document is availab= le..." could be removed.

=3D=3D Definiti= ons =3D=3D

These definitions could be re= ordered to prevent a need for forward reference. For instance "RCT" referenc= es "RGB" and "YCbCr" but "YCbCr" and "RGB" come after "RCT".

"VLC" explains the abbreviation, but does not offer an e= xplanation of the meaning as is done for the other defined terms.
=
The term "symbol" is used within the Definitions s= ection and throughout the document. I think "symbol" and perhaps "sample" co= uld themselves use definitions.

=3D=3D C= omparison operators =3D=3D

I think there i= s a typo in the "a || b" section:   "a || b" means Boolean logical "or"= of a and b.
Perhaps this should be "a or b".

In "!a" I suggest that the "not" should be changed to "not a".=

=3D=3D Mathematical functions =3D=3D

The definition for "abs(a)" uses an undefi= ned function "sign(a)".

=3D=3D rema= ining_bits_in_bitstream =3D=3D

I suggest= using a variable value within "remaining_bits_in_bitstream( )" such as "rem= aining_bits_in_bitstream( a )" and then using "a" within the definition. Sam= e with the next function "byte_aligned ( )".

=3D=3D Border =3D=3D

Some issues are= already discussed at https://github.com/FFmpeg/FFV1/issues/42, but the languag= e could be more clear.

=3D=3D Median pre= dictor =3D=3D

This section starts right a= way with what looks like a function. It could use some context, for instance= to start with "Three neighboring samples are used to create a median predic= tor:".

=3D=3D Context =3D=3D
<= br class=3D"">
The diagram could use an explanation for what "X" is= , as well as to say that 'tl' is 'top-left', 't' is 'top', etc. Although the= diagram appears to use "X" as a reference point, the "X" is not discussed o= r used within the equation.

The form of "= Q_0[a-b]" is introduced here, but the meaning is not explained. Are the pipe= s in the equation used to mean absolute value, as in "|Q_0|" is the "absolut= e value of the zeroth quantization value"?

<= /div>
Perhaps the Quantization section should preceed the Context section.

Instead of "-context" it could say something= like "the absolute value of context".

=3D= =3D Quantization =3D=3D

In this equation= "  Q_{i}[a-b]=3DTable_{i}[(a-b)&255]" what do "a" and "b" signify?= I presume this would be from the list of sample differences, but it could b= e more clear.

=3D=3D JPEG2000-RCT =3D=3D= =3D

These equations are familiar but the= section could use an introductory paragraph to say what they are for.

=3D=3D Coding of the sample difference =3D=3D<= /span>

The "(or n+1)" should be "(or n+1, in the= case of RCT)" to clarify what the parenthetical is referring to. Alternativ= ely the section could be divided into an explanation in the case of RCT and a= n explanation for non-RCT.

=3D=3D Range co= ding mode =3D=3D

Is the anecdote about e= arly experimental versions of FFV1 needed? Does this document define those e= arly experimental versions? If not perhaps the anecdote could be removed.

=3D=3D=3D Range binary values =3D=3D

Some values are defined in the introduction of= this section but many are missing. For instance what does r_i, R_i, l_i, L_= i, and t_i mean? Left, right, top? Also in the equations what is "k" represe= nting? Is it the same "k" as from the Huffman coding mode section?

S_{0,i} is defined as the i-th initial state, but= why is there a "0," in the subscript to express that?

The first equation uses C_i within the subscript of S_i. Is th= at intention or are C_i and S_i intended to be at the same level?
=
The second equation starts with S with "i+1,C_i" a= s a subscript. =46rom the introduction statement S with "0,i" means the i-th= State. What is the "0" meaning here? And how is the comma read in words? So= is the second equation implying that it considers the C_i-th state?<= /div>

Also note that I've tried in https://github.com/FFmpeg/FF= V1/pull/50 to express these equations in an RFC-friendly manner, bu= t to represent the subscript (particularly when there are subscripts and sub= scripts) is particularly challenging. Is there a method to express the same w= ithout subscript?

=3D=3D Range non binar= y values =3D=3D

The introduction contains= some think-out-loud style considerations about data encoding, this language= could be made more concise and direct.

= Noting that the backslashed comments included in the function break the barr= ier within the table.

= =3D=3D State trans= ition table =3D=3D

This section is equat= ion-only. It could benefit from a introductory sentence to give context.

=3D=3D default state transition =3D=3D

This section is only the table and no introd= uction. It should note that the coder_type MUST be set to '1' when using thi= s table.

=3D=3D alternative state transit= ion table =3D=3D

"has been build" -> "= has been built"

Note that here it's calle= d the "alternative state transition table" but in the coder_type section it i= s called the "custom state transition table". Are these phrases meaning the s= ame thing, or does "custom" imply any user-customized table?

=3D=3D Prefix =3D=3D

Does the table here imply that the Prefix of the VLC code MUST be between 1= and 12 bits? There are likely some requirements of the prefix that could be= stated here.

=3D=3D Examples =3D=3D

Based upon what I can gather from the Prefi= x and Suffix tables, I am not able to fully comprehend what is communicated b= y the examples section. Some narrative could help.

=
=3D=3D Mapping FFV1 into Containers =3D=3D

This section is a large subsection of the "Bitstream" section.= It may be out of place and perhaps would be better places at the same secti= onal level as "Bitstream".

=3D=3D Frame =3D= =3D

Within the Frame structure is data c= alled "Parameters" is this the same as the "Parameters" within the Configura= tion Record? If not, perhaps they should use distinct terms. Also there is a= lowercase "parameters" used throughout the document. If "parameters" uses a= locally defined meaning then it should be in title case.

=3D=3D slice_coding_mode =3D=3D

<= /span>
This references a manner of slice coding via PCM but there is no ot= her reference to this mode. When would PCM encoding be used and not Range or= VLC?

=3D=3D error_status =3D=3D<= /div>

I'm not certain when error status would not equ= al zero. If the ffv1 encoder expected to detect writing errors and record th= em here? What sorts of conditions would trigger that?

=3D=3D slice footer =3D=3D

The footer contains the slice size which IIUC a= llows some bidirectional seeking and resilience. It may be worthwhile to say= here how this works in the event that some slices are corrupted.

Best Regards,
Dave R= ice
= --Apple-Mail-7E77E9F5-86CE-48E5-8917-A817C3678714-- From nobody Sat Mar 18 10:25:41 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 1262E12896F for ; Sat, 18 Mar 2017 10:25:40 -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, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UffQGtVMMBI2 for ; Sat, 18 Mar 2017 10:25:36 -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 5006D128BE1 for ; Sat, 18 Mar 2017 10:25:36 -0700 (PDT) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:44848 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cpI6c-0040XK-18; Sat, 18 Mar 2017 13:25:33 -0400 From: Dave Rice Message-Id: <61FBB363-8FDE-49B3-8ECC-5A39A8AC7415@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_91DA78AF-0D70-43FB-81DE-BDD795E9A659" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Sat, 18 Mar 2017 13:25:27 -0400 In-Reply-To: <565FC9A9.1050604@xiph.org> Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Yaakov Stein To: "Timothy B. Terriberry" , Michael Niedermayer References: <565F46D9.90801@nostrum.com> <565F4C10.9040705@xiph.org> <565FC9A9.1050604@xiph.org> X-Mailer: Apple Mail (2.3259) 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] math in IETF specifications 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, 18 Mar 2017 17:25:40 -0000 --Apple-Mail=_91DA78AF-0D70-43FB-81DE-BDD795E9A659 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, > On Dec 2, 2015, at 11:48 PM, Timothy B. Terriberry = wrote: >=20 > Dave Rice wrote: >> Thanks, it=E2=80=99s good to see the options in action. Given what is = available in the timeline of the project it may be easiest to leave the = math in LaTeX form and cite the PDF version for reference. The ASCII Art = equations of RFC 6716 are impressive but I=E2=80=99d worry that in this = effort that it would compromise legibility. In the current FFV1 LaTeX = there are some examples with subscripts of subscripts of subscripts. >=20 > Yes, in 6716 we probably would have done that as C-style arrays (our = syntax closer to C than traditional mathematical notation, on the = whole). But doing that conversion for a bunch of existing equations = would be a lot of work. [=E2=80=A6] I=E2=80=99ve prepared a patch at https://github.com/FFmpeg/FFV1/pull/50 = . This adds a method to the = markdown draft to store alternatives of the same expression for use in = the current PDF output (a non-RFC output used by FFmpeg) and for use in = the RFC output. This is primarily because the PDF output supports LaTex = but the RFC output must be in much simpler ASCII. So the patch proposes = expressions such as: PDF:$$Q_{i}[a-b]=3DTable_{i}[(a-b)\&255]$$ =20 RFC:``` =20 RFC:Q_{i}[a =E2=88=92 b] =3D Table_{i}[(a =E2=88=92 b)&255] =20 RFC:``` And then the Makefile strips the prefixes (PDF: and RFC:) and uses the = appropriate lines for the appropriate output. This comment on the PR, = https://github.com/FFmpeg/FFV1/pull/50#issuecomment-287559570 = , = demonstrates what the most complex equations of the FFV1 specification = look like in the RFC output of this patch. It was a challenge to = replicate the PDF=E2=80=99s use of multi-level subscripting to depict = complex sequences within an RFC. In the PR I accommodate that in a = single-line expression using a locally defined syntax that is similar to = how subscripts are used in LaTeX. I also worked with text alignment in = the equations of the RFC to better imply line-wrapping since many of the = equations are far too long to fit on a single RFC line. a_{b} the b-th value of a sequence of a a_{b,c} the 'b,c'-th value of a sequence of a A fully rendered output of the PR is available at = https://gist.github.com/dericed/273ce52640b716d763d49bc955b4bead = . Comments? Best Regards, Dave Rice --Apple-Mail=_91DA78AF-0D70-43FB-81DE-BDD795E9A659 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi all,

On Dec 2, 2015, at 11:48 PM, = Timothy B. Terriberry <tterribe@xiph.org> wrote:

Dave = Rice wrote:
Thanks, = it=E2=80=99s good to see the options in action. Given what is available = in the timeline of the project it may be easiest to leave the math in = LaTeX form and cite the PDF version for reference. The ASCII Art = equations of RFC 6716 are impressive but I=E2=80=99d worry that in this = effort that it would compromise legibility. In the current FFV1 LaTeX = there are some examples with subscripts of subscripts of subscripts.

Yes, in 6716 we probably would = have done that as C-style arrays (our syntax closer to C than = traditional mathematical notation, on the whole). But doing that = conversion for a bunch of existing equations would be a lot of work.

[=E2=80=A6]

I=E2=80=99ve prepared a patch at https://github.com/FFmpeg/FFV1/pull/50. This adds a = method to the markdown draft to store alternatives of the same = expression for use in the current PDF output (a non-RFC output used by = FFmpeg) and for use in the RFC output. This is primarily because the PDF = output supports LaTex but the RFC output must be in much simpler ASCII. = So the patch proposes expressions such as:


PDF:$$Q_{i}[a-b]=3DTable_{i}[(a-b)\&255]$$   = ;   
RFC:```      
RFC:Q_{i}[a =E2=88=92 b] =3D Table_{i}[(a =E2=88=92 = b)&255]      
RFC:```

And then the Makefile = strips the prefixes (PDF: and RFC:) and uses the appropriate lines for = the appropriate output. This comment on the PR, https://github.com/FFmpeg/FFV1/pull/50#issuecomment-287559570, demonstrates what the most complex equations of the FFV1 = specification look like in the RFC output of this patch. It was a = challenge to replicate the PDF=E2=80=99s use of multi-level subscripting = to depict complex sequences within an RFC. In the PR I accommodate that = in a single-line expression using a locally defined syntax that is = similar to how subscripts are used in LaTeX. I also worked with text = alignment in the equations of the RFC to better imply line-wrapping = since many of the equations are far too long to fit on a single RFC = line.

   a_{b} the b-th value of a sequence of = a
   a_{b,c} the 'b,c'-th value of a = sequence of a

A fully rendered output of the PR is available at https://gist.github.com/dericed/273ce52640b716d763d49bc955b4bea= d.
Comments?

Best Regards,
Dave = Rice

= --Apple-Mail=_91DA78AF-0D70-43FB-81DE-BDD795E9A659-- From nobody Sat Mar 18 14:51:38 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 BAB4E126B7F for ; Sat, 18 Mar 2017 14:51:36 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uw-edu.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 g8V9yg4cI10A for ; Sat, 18 Mar 2017 14:51:34 -0700 (PDT) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 D54A8126C2F for ; Sat, 18 Mar 2017 14:51:34 -0700 (PDT) Received: by mail-ot0-x234.google.com with SMTP id x37so114547477ota.2 for ; Sat, 18 Mar 2017 14:51:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uw-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Kkpz7f3YDs3B40fdHAnXG+HOgEt2DDOlK+nVC10uJpg=; b=U6OSo8VE6Iu/sC0mMCvuV4q+MY/ybuh8i+HNq7KXqt0rUlODjsPINj+S3bdccrJAEL byMAPEdg/TSi0r4xUcYxkfa9yrxAeT+tztzyU/o4sA9cUNm4mTtMkNy5SFpts/MlmeLB xnvmoAGijwD7oE/MRhNon0RPygz3LILG15ILMZfO/+fcW0VG1YOHuhiQqG6XPtXLUKKa kRkbEWtKiHsqy90JSQHgaveRW6xoiBALAMXHblCJDYiG8852gzgFhd6uodjCz0TY5a7T z+w2b2CGJ0D04qkAJKO+DGrDijEfl+STTH5Xv5lLrLvvePgdBoROXatprUNeQ2OYcO5G dTbg== 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=Kkpz7f3YDs3B40fdHAnXG+HOgEt2DDOlK+nVC10uJpg=; b=SeCKwbcWVY0o3oRLVOfGwIQofmoh9gXxmXOaPPxRkHd7eh3/q+IbXJh2UMAydJ59Jt 7lXGBrrUsTU4rRdkw7HVq09i5WqrBsEy/lICdaVWtDIQ5oPMxxDZ3MRBmVbbVpYjqLWO C3X80Bhhwue33Xfruo+UBaJ8UNAZm+n9JtnHSkRIT4hOC8yq9RcWlesCqY/0NNrKBRCb pHxQzr8qKjVi8G6eRUXRL6QsQHvN2gMrPF4TnsMffJWvAfsDNLA3UKTvnCDZIm0bv+d3 Ve+Q7s66xaaqbo7eIklDAlPfqYA3jlXUVEDhepcK/HCJrb153h0YLrxE1kcMRlDdccg0 8TMg== X-Gm-Message-State: AFeK/H21OFf37MG4LhQVPS4XZro2rsrKHkHiuFRZohI9va9H96K+yCHnr90WYRk95cVQmt8RuEtftKeWdIbq7jBg X-Received: by 10.157.63.118 with SMTP id m109mr10022228otc.270.1489873893776; Sat, 18 Mar 2017 14:51:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.218.99 with HTTP; Sat, 18 Mar 2017 14:51:33 -0700 (PDT) In-Reply-To: References: <0B185EDE-66D4-4E83-B337-D359FCF0C5B0@dericed.com> From: Andrew James Weaver Date: Sat, 18 Mar 2017 14:51:33 -0700 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=001a11472aec32f326054b084cc7 Archived-At: Subject: Re: [Cellar] IETF current milestones: request for feedback 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, 18 Mar 2017 21:51:37 -0000 --001a11472aec32f326054b084cc7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I would be interested in helping out with some of the FLAC efforts as well. I am happy to participate in some of the nitty gritty such as helping to convert the spec into markdown etc. Best, Andrew On Thu, Mar 16, 2017 at 4:59 AM, Jerome Martinez wrote: > Le 16/03/2017 =C3=A0 04:24, Tessa Fallon a =C3=A9crit : > > > Jul 2017 Submit specification for FFV1 video codec version 4 to > IESG (Standards Track) > > > From my point of view focus on FFV1 v4 should be done only after v3 is > standardized. > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > --=20 Andrew Weaver, MLIS American Archive of Public Broadcasting National Digital Stewardship Resident @ CUNY TV weevz@uw.edu --001a11472aec32f326054b084cc7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I would be interested in helping out = with some of the FLAC efforts as well. I am happy to participate in some of= the nitty gritty such as helping to convert the spec into markdown etc.

Best,
Andrew

On Thu, Mar 16, 2017 at 4:5= 9 AM, Jerome Martinez <jerome@mediaarea.net> wrote:
=20 =20 =20
Le 16/03/2017 =C3= =A0 04:24, Tessa Fallon a =C3=A9crit=C2=A0:

Jul 2017 Submit specification for FFV1 video codec version 4 to IESG=C2=A0(Standards Track)

 From my point of view focus on FFV1 v4 should be done only after v3 is standardized.

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



--
=
Andrew= Weaver, MLIS
American Archi= ve of Public Broadcasting
National= Digital Stewardship Resident @ CUNY TV
weevz@uw.edu
--001a11472aec32f326054b084cc7-- From nobody Mon Mar 20 13:37:10 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 D332B12706D for ; Mon, 20 Mar 2017 13:37:07 -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 Lnos2-26DsjO for ; Mon, 20 Mar 2017 13:37:06 -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 0B610126C0F for ; Mon, 20 Mar 2017 13:37:06 -0700 (PDT) Received: from [146.96.19.240] (port=20575 helo=[10.10.201.33]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cq436-002skc-9d; Mon, 20 Mar 2017 16:37:05 -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: <43056655-cf09-9d54-6552-4ed4b655e74f@mediaarea.net> Date: Mon, 20 Mar 2017 16:37:02 -0400 Cc: cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <34CA7943-497F-449A-81DA-3237CB87BDD7@dericed.com> 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> 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] 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: Mon, 20 Mar 2017 20:37:08 -0000 > On Mar 14, 2017, at 3:57 PM, Jerome Martinez = wrote: >=20 > Le 14/03/2017 =C3=A0 20:45, Dave Rice a =C3=A9crit : >> [...] >>=20 >>> Time code may be stripped (only the first time code is stored and = other time code must be computed from it + header metadata), and there = is no way to know it in Matroska : QuickTime has the list of blocks in = the track header so the player knows if the the time code is stripped (1 = block of 4 bytes) or not (more than 1 block), this is not the case with = Matroska. >>> How could we indicate to the player that the time code is stripped = (=3Donly one value stored, then player should compute value of other = time code frames)? >>=20 >>=20 >> Since the update proposal defines a new media type (timecode) it is = possible to define a Timecode Master element (as similar done with Audio = and Video) to store needed context. >>=20 >> OTOH I don=E2=80=99t think I=E2=80=99ve ever seen a QuickTime = timecode track that was non-stripped. >=20 > OK, I need to check my files but I am pretty sure I have some. >=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? Isn't the seeking similar to QuickTime. 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 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. 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. Dave Rice= From nobody Mon Mar 20 14:07:38 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 2202E1293EE for ; Mon, 20 Mar 2017 14:07:37 -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 o6MHZLAH48KI for ; Mon, 20 Mar 2017 14:07:34 -0700 (PDT) Received: from 7.mo179.mail-out.ovh.net (7.mo179.mail-out.ovh.net [46.105.61.94]) (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 68D441293E3 for ; Mon, 20 Mar 2017 14:07:33 -0700 (PDT) Received: from player794.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id 434C9304D4 for ; Mon, 20 Mar 2017 22:07:31 +0100 (CET) Received: from [192.168.2.101] (p5DDB5708.dip0.t-ipconnect.de [93.219.87.8]) (Authenticated sender: jerome@mediaarea.net) by player794.ha.ovh.net (Postfix) with ESMTPSA id A6AF514007D for ; Mon, 20 Mar 2017 22:07:31 +0100 (CET) To: cellar@ietf.org 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> From: Jerome Martinez Message-ID: <1db0fb80-2441-a4f0-729e-bc5b5cfd1a84@mediaarea.net> Date: Mon, 20 Mar 2017 22:07:29 +0100 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: <34CA7943-497F-449A-81DA-3237CB87BDD7@dericed.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 4941293218207436945 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelhedrieejgddugeehucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc 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: Mon, 20 Mar 2017 21:07:37 -0000 Le 20/03/2017 à 21:37, Dave Rice a écrit : > [...] >>> I’ve 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. >> 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 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. > 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. 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 = 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 = 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 = 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). 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.