From nobody Mon Jan 2 08:03:48 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 682251296A1 for ; Mon, 2 Jan 2017 08:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4bo8vy_Aw4pw for ; Mon, 2 Jan 2017 08:03:45 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489451296A9 for ; Mon, 2 Jan 2017 08:03:42 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:47568 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1cO55I-0027mt-SR for cellar@ietf.org; Mon, 02 Jan 2017 11:03:41 -0500 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 2 Jan 2017 11:03:39 -0500 To: Codec Encoding for LossLess Archiving and Realtime transmission Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] the next FFV1 draft X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jan 2017 16:03:46 -0000 Hi all, I notice that the current draft of the FFV1 specification [1] expires in = less than a week (January 8, 2017). I suggest that we submit a new = revision before that expiration. Currently the GitHub repo for FFV1=E2=80=99= s specification [2] has over 20 commits since the current -00 draft so = it=E2=80=99s timely anyhow to post a new version. There=E2=80=99s two pull requests that are works in progress and could = use review: https://github.com/FFmpeg/FFV1/pull/31/files includes expanded = documentation on the colorspaces used in FFV1 https://github.com/FFmpeg/FFV1/pull/29 is an attempt to add a narrative = explanation to accompany information about FFV1=E2=80=99s structural = components that are currently documented in codeblocks without = narratives. Here=E2=80=99s some of my suggestions on what small efforts we could = take to improve the document for the next version: Review spacing and formatting in the codeblocks. There=E2=80=99s some = discussion on this in a related pull request at = https://github.com/FFmpeg/FFV1/pull/25. Note and integrate forward-references into the document. There=E2=80=99s = several places where an FFV1 term is introduced and used before it is = defined. We now have section headers throughout the document so it = should be easier to add forward-references. Review capitalization of terms. I started some of this in = https://github.com/FFmpeg/FFV1/pull/32/commits, but there=E2=80=99s = other terms used in the document which have inconsistent capitalization, = such as 'frame' vs 'Frame'. Identify terms that are used though undefined and should have local = definitions. Suggestions on short-term goals? Volunteers? Also I see that RFC7996 [3] was published last month which defines how = to use SVG within RFCs. Could this be a reasonable method for handling = the complex math of the FFV1 specification (currently in LaTeX) within = an RFC? There are some LaTeX to SVG convertors available online. Best Regards, Dave Rice [1] https://tools.ietf.org/html/draft-niedermayer-cellar-ffv1-00 [2] https://github.com/FFmpeg/FFV1/commits/master [3] https://tools.ietf.org/html/rfc7996= From nobody Tue Jan 3 08:23:45 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED97A12966C for ; Tue, 3 Jan 2017 08:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6gkpknThd7a for ; Tue, 3 Jan 2017 08:23:41 -0800 (PST) Received: from 6.mo1.mail-out.ovh.net (6.mo1.mail-out.ovh.net [46.105.43.205]) (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 A94D6129579 for ; Tue, 3 Jan 2017 08:23:41 -0800 (PST) Received: from player691.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo1.mail-out.ovh.net (Postfix) with ESMTP id 9D39434A79 for ; Tue, 3 Jan 2017 17:23:38 +0100 (CET) Received: from [192.168.2.101] (p5DDB67BC.dip0.t-ipconnect.de [93.219.103.188]) (Authenticated sender: jerome@francoallemand.eu) by player691.ha.ovh.net (Postfix) with ESMTPSA id 59EBD26008F for ; Tue, 3 Jan 2017 17:23:37 +0100 (CET) To: cellar@ietf.org References: From: Jerome Martinez Message-ID: Date: Tue, 3 Jan 2017 17:23:38 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 14990794309825269905 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelgedrudefgdekhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] the next FFV1 draft X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 16:23:44 -0000 Le 02/01/2017 à 17:03, Dave Rice a écrit : > [...] > There’s two pull requests that are works in progress and could use review: > https://github.com/FFmpeg/FFV1/pull/31/files includes expanded documentation on the colorspaces used in FFV1 From my point of view this is slightly redundant with the "General" section. I like the way it is put in the spec with this PR but I think that the redundant content should be removed from the General section. I added some other less significant comments in the PR directly. > https://github.com/FFmpeg/FFV1/pull/29 is an attempt to add a narrative explanation to accompany information about FFV1’s structural components that are currently documented in codeblocks without narratives. I am not convinced that it is useful, I think that the "C like" approach is enough, and if there is a need of more detail for a "block" it should be in the corresponding paragraph. "A `Slice` is a spatially distinct region of a `Frame` that is encoded separately from any other region of that `Frame`." is a good introduction, at the right place. "A `Slice` is comprised the following four components in this storage order: (...)" is redundant with the "C-like" code, and there is a risk of error when we update. better to have only one place for a piece of information. > > Here’s some of my suggestions on what small efforts we could take to improve the document for the next version: > > Review spacing and formatting in the codeblocks. There’s some discussion on this in a related pull request at https://github.com/FFmpeg/FFV1/pull/25. > > Note and integrate forward-references into the document. There’s several places where an FFV1 term is introduced and used before it is defined. We now have section headers throughout the document so it should be easier to add forward-references. > > Review capitalization of terms. I started some of this in https://github.com/FFmpeg/FFV1/pull/32/commits, but there’s other terms used in the document which have inconsistent capitalization, such as 'frame' vs 'Frame'. +1 > > Identify terms that are used though undefined and should have local definitions. > > Suggestions on short-term goals? Volunteers? I see less and less things to add to the specs. I plan to do another review code vs specs this week and see what is missing, and beside what you suggest I would like to have comments from others about what is considered as missing. > > Also I see that RFC7996 [3] was published last month which defines how to use SVG within RFCs. Could this be a reasonable method for handling the complex math of the FFV1 specification (currently in LaTeX) within an RFC? There are some LaTeX to SVG convertors available online. I don't see a better method until MathML is accepted and supported by tools, so +1. Jérôme From nobody Tue Jan 3 09:32:13 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C811296C2 for ; Tue, 3 Jan 2017 09:32:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aVXPnZereOW for ; Tue, 3 Jan 2017 09:32:09 -0800 (PST) Received: from 4.mo1.mail-out.ovh.net (4.mo1.mail-out.ovh.net [46.105.76.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D2101294B6 for ; Tue, 3 Jan 2017 09:32:08 -0800 (PST) Received: from player691.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo1.mail-out.ovh.net (Postfix) with ESMTP id 337DC30DAC for ; Tue, 3 Jan 2017 18:32:06 +0100 (CET) Received: from [192.168.2.101] (p5DDB67BC.dip0.t-ipconnect.de [93.219.103.188]) (Authenticated sender: jerome@francoallemand.eu) by player691.ha.ovh.net (Postfix) with ESMTPSA id 083B0260079 for ; Tue, 3 Jan 2017 18:32:05 +0100 (CET) To: cellar@ietf.org References: <006693EE-3D14-44E3-A2F5-A3F18CF4020F@dericed.com> From: Jerome Martinez Message-ID: Date: Tue, 3 Jan 2017 18:32:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <006693EE-3D14-44E3-A2F5-A3F18CF4020F@dericed.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 16147093515812343953 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelgedrudefgddutddtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] defining how to define codec support X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 17:32:11 -0000 Le 31/12/2016 à 20:53, dave@dericed.com a écrit : > Hi all, > > From comments on the recent subtitle definition, I drafted a pull request [1] to better document how to define codec support in Matroska. Mostly this adds a new section called “Defining Matroska Codec Support” which is reviewable at GitHub in rendered form [2]. I started to document how to construct a Codec ID and broke it down into the concepts of a Prefix, Major ID, Minor ID, Micro ID, and Delimiter. If any ABNF authors want to volunteer, it may be useful to rework the Codec ID definition in ABNF. I added some comments in the PR, the most important one being that I think the proposal is too limitative, and we should let each ID free to define what is after "/". I suggest: "Codec ID Prefix"_"Major Codec ID"/ "Codec ID Specific" (the "/" + right part being optional) > I also divided the vague concept of Codec Description into three parts Description, Citation (we should reference the specification of the codec), and Initialization (to specifically define the data to be stored in CodecPrivate or CodecState). > > Once the above revisions are supported, we can rework the existing codec specs into this form. > > Also I notice that in many places the word “Codec” is used when it seems that “Encoding” is intended. For instance if many Codecs all encode the same encoding, then the Codec ID for each it the same although the Codecs are different. Should this be the Encoding ID? "Codec" wording was from the beginning of the digital world a bad confusion between a format and a Coder/Decoder, and nowadays it is difficult to "fix" that. I have mixed feeling between "Codec ID" being the most used word so easy to understand for people despite it is wrong vs the correct "Encoding ID3 being not classic despite it is the right word. Jérôme From nobody Sat Jan 7 08:57:26 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 4DE9A129522 for ; Sat, 7 Jan 2017 08:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[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 xlS0txZCL4qR for ; Sat, 7 Jan 2017 08:57:22 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45A1D1294BC for ; Sat, 7 Jan 2017 08:57:22 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:41882 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1cPuIx-0033Bv-Pg; Sat, 07 Jan 2017 11:57:21 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave Rice In-Reply-To: <2651a6f3-9c9a-6f76-2ee7-4d5c23b1ce57@mediaarea.net> Date: Sat, 7 Jan 2017 11:57:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2651a6f3-9c9a-6f76-2ee7-4d5c23b1ce57@mediaarea.net> To: Jerome Martinez X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Ancillary data in Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 16:57:24 -0000 Hi all, > On Dec 27, 2016, at 3:22 PM, Jerome Martinez = wrote: >=20 > We need additional codec to be supported in Matroska in order to be = able to transwrap in a lossless manner content from older containers to = Matroska, especially time codes (all the codecs defined in the patch can = contain 1 or more time codes) > The global idea is to be able to transwrap e.g. MOV (from Apple), MXF = (from SMPTE), GXF (from Grass Valley, also known as SMPTE ST 360 and = SMPTE RDD 14, found in some broadcaster archives), LXF (from = Leitch/Harris, found in some broadcaster archives) without losing = metadata in some sidecar non visible streams. I think this is an interesting approach and it=E2=80=99s probably better = than yet again defined another timecode containment system. > After agreeing on the format, we will have to update tools e.g. FFmpeg = in order to support such lossless transwrap. >=20 >=20 > I added an "Ancillary" section with several mappings in the attached = patch, please comment. >=20 >=20 > Comments: >=20 > The frequent remark is "Why do you need so many time code formats, = choose one and stop using the others": in the real world, people = consider that one format is the best one, but not the same format as = others, and they use only this time code for their work and don't plan = to switch. You can have 10+ time codes in a file and each one is = important for someone, as well as the sidecar information transported at = the same time (never same between each format). There is no consensus = about that for years, and I don't think we could achieve a consensus = from the different actors (lot of them are not interested by our work at = IETF) so the idea here is to be able to move from one container to = another one without losing any metadata, absolutely not deciding about a = reference time code (and other metadata) format, as Matroska does for = e.g. video (Matroska does not say that VP9 should be used instead of = AVC, it supports both). Agreed. > "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. > VBI and ANC: used to transport time codes (LTC, VITC, ATC...), = Recording Information, bar and pan/scan data, captions (North American = CEA-608, CEA-708, European and Australian WSS/Teletext, Japanese ARIB = B37...), camera acquisition dynamic metadata, Audio Metadata, Film = Transfer and Video Production Information (in theory, I never saw it)... > The "perfect" solution would be to decode VBI and ANC, and put each = format in its own specification, but it would be an huge task and we = still would have to store opaque content (content is present in the = VBI/ANC but we ignore all from it right now), so it is better to start = by the beginning and we consider all opaque without trying to decode the = data, as do other containers. I agree to store and consider it as opaque or to leave within the video = but use the PixelCrop elements to note that the lines of the VBI data = aren=E2=80=99t intended in presentation.=20 > +**Codec ID:** N_VBI =20 > +**Codec Name:** Vertical Blanking Interval =20 > +**Description:** used in SDTV, see = https://en.wikipedia.org/wiki/Vertical_blanking_interval for more = information. Each Matroska block contains a SMPTE ST 436 VBI Frame = Element. =20 OK in the patch you reference storage of VBI as smpte 436m frame = elements (example attached to https://trac.ffmpeg.org/ticket/726). Is = the N_ prefix still relevant as the encoding would contain captioning = data as well? =E2=80=9CS_=E2=80=9D? > N_STRIPPEDTIMECODE: the Cluster part will contain no data, but despite = of that it must be a complete standalone track, with Track Id ans so on, = as it is a standalone track in the source container. Do you mean that there would be an N_STRIPPEDTIMECODE but it would = reference no Clusters, or that the N_STRIPPEDTIMECODE track would = reference Clusters that contain no SimpleBlock and no BlockGroup? If the = latter where would the value of the timecode be stored? > +**Codec ID:** N_STRIPPEDTIMECODE =20 > +**Codec Name:** Stripped time code =20 > +**Description:** track containing no data in the Cluster elements, as = all is in the track header: the CodecPrivate element contains, in big = endian: 4 bytes Rate numerator, 4 bytes rate denominator, 4 bytes count = of consecutive time codes / frames (the "duration", 0 if unknown), 1 = byte time code drop frame flag (0 is no, 1 is yes, others are reserved), = 4 byte the start time code (in frames). Note: this permits to map a MXF = time code track or a GXF stripped time code track to Matroska. =20 =E2=80=9Cno data in the Cluster elements=E2=80=9D is not clear enough. = The structure of CodecPrivate would not note flags such as if the = timecode is limited to 24 hours or not. If that=E2=80=99s similar to the = MXF and GXF limitations then I guess it=E2=80=99s fine. Any reference to = the CodecPrivate structure? =46rom the writing it=E2=80=99s not clear if = this is a new structure or copied from some other timecode storage form. I suggest throughout the patch we are consistent on capitalization = (Frame vs frame) and spacing (timecode vs time code). Also I=E2=80=99m worried about the confusion to be created between the = Matroska Timecode* Elements and the concept of timecode (copies to = external reference systems from source objects). An earlier discussion = suggested calling the focus of this patch as Reference Timecode to = distinguish it from Matroska=E2=80=99s own Timecode. I see that SMPTE is = starting to reference timecode as =E2=80=9CTime Label=E2=80=9D which may = also be appropriate here. > N_SDTICP: nearly 1:1 copy of SMPTE ST 385 elements. In order to have = all data and being able to have only 1 Matroska block for all STDI-CP = elements, I kept also the 2 last bytes of the KLV "Key" and the KLV = "Length" in addition of the KLV "Value". Note that something weird, this = is a standalone track in source container but the difference with other = tracks (including ANC or VBI) is that this stream has no track header so = no track number, and Matroska specs makes TrackNumber mandatory, I = wonder what should be used during transwrap (fake number?) Not familiar with this type of timecode. Would max-TrackNumber + 1 = suffice? Dave Rice= From nobody Sat Jan 7 12:31: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 CD4D6129627 for ; Sat, 7 Jan 2017 12:31:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kcuXhDZCdBG for ; Sat, 7 Jan 2017 12:31:39 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E51F12960F for ; Sat, 7 Jan 2017 12:31:39 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:39807 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1cPxeI-000Boc-2m; Sat, 07 Jan 2017 15:31:38 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave Rice In-Reply-To: Date: Sat, 7 Jan 2017 15:31:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <85043622-069B-4050-807B-7027A25B1250@dericed.com> References: To: Jerome Martinez X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] the next FFV1 draft X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 20:31:41 -0000 > On Jan 3, 2017, at 11:23 AM, Jerome Martinez = wrote: >=20 > Le 02/01/2017 =C3=A0 17:03, Dave Rice a =C3=A9crit : >> [...] >> There=E2=80=99s two pull requests that are works in progress and = could use review: >> https://github.com/FFmpeg/FFV1/pull/31/files includes expanded = documentation on the colorspaces used in FFV1 >=20 > =46rom my point of view this is slightly redundant with the "General" = section. > I like the way it is put in the spec with this PR but I think that the = redundant content should be removed from the General section. > I added some other less significant comments in the PR directly. The redundancy is removed and the pull request on colorspace definitions = is updated at https://github.com/FFmpeg/FFV1/pull/31. >> https://github.com/FFmpeg/FFV1/pull/29 is an attempt to add a = narrative explanation to accompany information about FFV1=E2=80=99s = structural components that are currently documented in codeblocks = without narratives. >=20 > I am not convinced that it is useful, I think that the "C like" = approach is enough, and if there is a need of more detail for a "block" = it should be in the corresponding paragraph. > "A `Slice` is a spatially distinct region of a `Frame` that is encoded = separately from any other region of that `Frame`." is a good = introduction, at the right place. > "A `Slice` is comprised the following four components in this storage = order: (...)" is redundant with the "C-like" code, and there is a risk = of error when we update. better to have only one place for a piece of = information. This PR is closed and a new issue is opened at = https://github.com/FFmpeg/FFV1/issues/35 to give a paragraph to describe = how FFV1 structures are defined in codeblocks. >> Here=E2=80=99s some of my suggestions on what small efforts we could = take to improve the document for the next version: >>=20 >> Review spacing and formatting in the codeblocks. There=E2=80=99s some = discussion on this in a related pull request at = https://github.com/FFmpeg/FFV1/pull/25. >>=20 >> Note and integrate forward-references into the document. There=E2=80=99= s several places where an FFV1 term is introduced and used before it is = defined. We now have section headers throughout the document so it = should be easier to add forward-references. >>=20 >> Review capitalization of terms. I started some of this in = https://github.com/FFmpeg/FFV1/pull/32/commits, but there=E2=80=99s = other terms used in the document which have inconsistent capitalization, = such as 'frame' vs 'Frame'. >=20 > +1 +1 though still needs a volunteer. >> Identify terms that are used though undefined and should have local = definitions. >>=20 >> Suggestions on short-term goals? Volunteers? >=20 > I see less and less things to add to the specs. I plan to do another = review code vs specs this week and see what is missing, and beside what = you suggest I would like to have comments from others about what is = considered as missing. New pull requests are here for review: = https://github.com/FFmpeg/FFV1/pulls. These: - add definitions for several functions within the document - add a few more citations - describe assignment operators a bit more verbosely - define the NumBytes value Along the way I opened a few more issues at = https://github.com/FFmpeg/FFV1/issues where a few things aren=E2=80=99t = defined or cited. >> Also I see that RFC7996 [3] was published last month which defines = how to use SVG within RFCs. Could this be a reasonable method for = handling the complex math of the FFV1 specification (currently in LaTeX) = within an RFC? There are some LaTeX to SVG convertors available online. >=20 > I don't see a better method until MathML is accepted and supported by = tools, so +1. Adjusting the mmark and xml2rfc process to incorporate SVG equations = seems harder than I hoped. Currently mmark produces xml2rfc version 2 = but we=E2=80=99ll have to update to xml2rfc version 3 to use the recent = SVG parts of RFC7996. My attempts here did not work well. I get the = impression that although xml2rfc version 3 is now officially defined, = there aren=E2=80=99t yet updates to the xml2rfc tools to allow those new = features to be used. Any advice? Dave Rice= From nobody Sun Jan 8 12:06:19 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 8E3DB129411 for ; Sun, 8 Jan 2017 12:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 7VBdulLgp1IE for ; Sun, 8 Jan 2017 12:06:16 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 626841295B7 for ; Sun, 8 Jan 2017 12:06:16 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:37934 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1cQJjH-000yHe-V4; Sun, 08 Jan 2017 15:06:15 -0500 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sun, 8 Jan 2017 15:05:42 -0500 Message-Id: <4BA8D34B-E7FA-4BEC-A467-24258A413B81@dericed.com> To: Codec Encoding for LossLess Archiving and Realtime transmission Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Tessa Fallon , "Timothy B. Terriberry" Subject: [Cellar] proposal for draft-niedermayer-cellar-ffv1-01 as WG Document X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 20:06:17 -0000 Hi all, I've submitted draft-niedermayer-cellar-ffv1-01.xml to the RFC tracker = [1] as of = https://github.com/FFmpeg/FFV1/commit/210958c09df80ed93e75ae8ea263ca51db94= 8a98. As this document is actively developed, I propose that the document is = considered for WG Document status. Best Regards, Dave Rice [1] = https://datatracker.ietf.org/submit/status/83631/8d4bf7420df9a663542842a77= fea5144/= From nobody Fri Jan 13 13:21: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 1751E129CE3 for ; Fri, 13 Jan 2017 13:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IIU1uWLINUVo for ; Fri, 13 Jan 2017 13:21:38 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26E97129B60 for ; Fri, 13 Jan 2017 13:21:38 -0800 (PST) Received: from [146.96.19.240] (port=17018 helo=[10.10.201.55]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cS9I0-001fAu-8Y for cellar@ietf.org; Fri, 13 Jan 2017 16:21:37 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_C600C399-1E64-40BC-BDB7-FADFD321CD00" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Message-Id: <9D9D0A4C-46B3-46B3-8A4F-4E948A301F8D@dericed.com> Date: Fri, 13 Jan 2017 16:21:34 -0500 To: Codec Encoding for LossLess Archiving and Realtime transmission X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] draft-niedermayer-cellar-ffv1-01 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 21:21:40 -0000 --Apple-Mail=_C600C399-1E64-40BC-BDB7-FADFD321CD00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, A new version of the FFV1 draft is available at = https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1/ = . Reviews welcome. Best Regards, Dave Rice= --Apple-Mail=_C600C399-1E64-40BC-BDB7-FADFD321CD00 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
Hi all,

A new version of the FFV1 draft is available at https://datatracker.ietf.org/doc/draft-niedermayer-cellar-ffv1/.
Reviews welcome.

Best Regards,
Dave Rice
--Apple-Mail=_C600C399-1E64-40BC-BDB7-FADFD321CD00-- From nobody Sat Jan 14 13:09:37 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49572129511 for ; Sat, 14 Jan 2017 13:09:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeM0N5s9kszx for ; Sat, 14 Jan 2017 13:09:34 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B457D129DDD for ; Sat, 14 Jan 2017 13:09:34 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:39340 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1cSVZt-0027QR-4M for cellar@ietf.org; Sat, 14 Jan 2017 16:09:34 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_57D1A61A-30AE-4D81-AB34-957E737AC744" Message-Id: Date: Sat, 14 Jan 2017 16:09:27 -0500 To: Codec Encoding for LossLess Archiving and Realtime transmission Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] deprecating TrackTimecodeScale X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 21:09:36 -0000 --Apple-Mail=_57D1A61A-30AE-4D81-AB34-957E737AC744 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all, At one point in Matroska history there was a TrackTimecodeScale which = was intended for cases as having a video track from a film along with an = audio track from NTSC and a audio track from PAL (in PAL it is typical = to speed up the film from 24 to 25 fps whereas NTSC slows down the film = from 24 to 24000/1001 fps). There was some discussion on = https://lists.matroska.org/pipermail/matroska-devel/2010-May/003646.html = = and in 2012 it was deprecated here: = https://github.com/Matroska-Org/foundation-source/commit/ca8263bfbbcd2a3ce= 69369465aaa1ebe0c3c779e = . Although it is deprecated there is still a large section of = documentation about it in = https://github.com/Matroska-Org/matroska-specification/blob/dff36b4e01b6b1= 921e5bbdafa020e6485064dfd4/notes.md#tracktimecodescale = . Should this documentation be removed altogether from the RFC draft? Or = should that documentation be marked with a caveat that it is = documentation of a deprecated Element? Dave Rice= --Apple-Mail=_57D1A61A-30AE-4D81-AB34-957E737AC744 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi all,

At one point in Matroska history there = was a TrackTimecodeScale which was intended for cases as having a video = track from a film along with an audio track from NTSC and a audio track = from PAL (in PAL it is typical to speed up the film from 24 to 25 fps = whereas NTSC slows down the film from 24 to 24000/1001 fps). There was = some discussion on https://lists.matroska.org/pipermail/matroska-devel/2010-May/00= 3646.html and in 2012 it was deprecated here: https://github.com/Matroska-Org/foundation-source/commit/ca8263= bfbbcd2a3ce69369465aaa1ebe0c3c779e.

Although it is deprecated there is = still a large section of documentation about it in https://github.com/Matroska-Org/matroska-specification/blob/dff= 36b4e01b6b1921e5bbdafa020e6485064dfd4/notes.md#tracktimecodescale.

Should this = documentation be removed altogether from the RFC draft? Or should that = documentation be marked with a caveat that it is documentation of a = deprecated Element?

Dave Rice
= --Apple-Mail=_57D1A61A-30AE-4D81-AB34-957E737AC744-- From nobody Sun Jan 15 08:24:29 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 89C5B1293E3 for ; Sun, 15 Jan 2017 08:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.652 X-Spam-Level: X-Spam-Status: No, score=0.652 tagged_above=-999 required=5 tests=[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 ZWYPL742pBDL for ; Sun, 15 Jan 2017 08:24:26 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03D321293D9 for ; Sun, 15 Jan 2017 08:24:26 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:47435 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1cSnbT-001KHr-Tq; Sun, 15 Jan 2017 11:24:25 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave Rice In-Reply-To: Date: Sun, 15 Jan 2017 11:24:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> References: <3363d485-83af-d46b-3bca-3b0359ca9bb2@mediaarea.net> To: Steve Lhomme X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Jerome Martinez , cellar@ietf.org Subject: Re: [Cellar] Rationale Numbers for timestamps X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 16:24:27 -0000 Hi Jerome, Steve, > On Jul 27, 2016, at 3:28 PM, Steve Lhomme = wrote: >=20 > 2016-07-27 6:13 GMT+02:00 Jerome Martinez : >> On 27/07/2016 04:35, Steve Lhomme wrote: >>>=20 >>> As the topic often resurfaces maybe it's time we discuss it in the >>> context of CELLAR. >>>=20 >>> There have been talks about ways to do it in the Matroska mailing >>> before in this thread: >>>=20 >>> = https://lists.matroska.org/pipermail/matroska-devel/2012-October/004294.ht= ml >>>=20 >>> = https://lists.matroska.org/pipermail/matroska-devel/2012-October/004295.ht= ml >>>=20 >>> = https://lists.matroska.org/pipermail/matroska-devel/2012-October/004296.ht= ml >>>=20 >>> = https://lists.matroska.org/pipermail/matroska-devel/2012-October/004299.ht= ml >>>=20 >>> An element to handle it was added (still in specdata.xml but = commented) >>>=20 >>> = https://lists.matroska.org/pipermail/matroska-devel/2012-September/004289.= html >>> and later removed >>>=20 >>> = https://lists.matroska.org/pipermail/matroska-devel/2012-December/004317.h= tml >>>=20 >>> So far there was nothing conclusive but it seems it's not possible = to >>> do it properly in a backward compatible way. >>>=20 >>> The constraints are simple: >>> - backward compatible, so the 16 bits timestamp value in the >>> (Simple)Block must remain unchanged. This value is multiplied by the >>> scale (global and/or per track) to get the actual timestamp. >>> - There could be some acceptable rounding between the two coexisting >>> systems. >>> - The rounding should happen in the current system, the rationale >>> should always be exact (provided the source is exact) >>> - A lot of Matroska elements are based on the timestamp scales. So >>> they may be adjusted accordingly >>> - We must minimize the elements where the same information is found >>> twice. Basically only scale elements should be added. Maybe some >>> elements for the Cluster timestamp might be added as well if >>> necessary. >>> - because of the 16 bits range per Cluster differences between a >>> rationale system and the ns system must be tight. >>> - we still want Clusters to be 4-5s long to minimize the scope of >>> errors and buffering before playback. It may also correspond to some >>> GOP values. >>> - sample accuracy for audio would be good. >>>=20 >>> Let the math begin. >>=20 >>=20 >> Rationale Numbers for timestamps are usually for US style fixed = framerate, >> so I think my answer in a previous email still applies. >> = https://mailarchive.ietf.org/arch/msg/cellar/WQCExNvAZy4goibE3_chnFB1w0c >> Please comment about which need would not be fulfilled with this = proposal. >>=20 >> Copy/paste: >>=20 >> I don't like the idea to have an incompatible change with such = feature, >> because this is not a "must have" for 99% of people, and Matroska = "v5" >> will not be adopted with that. >> I think that we can have a workaround for having additional 0.99% = happy >> without the need of a break in compatibility: >> - lot of people want to know the exact frame rate of a fixed frame = rate >> stream, people muxing from tapes know that the frame rate is fixed >> (hardware limitation) so can set this element in the header. >=20 > Let's rewind a decade or more. The timestamps were originally using > floating points on purpose. At the time all sources were analog (film > or video tape). And in the analog world the clock is never perfect. > You cannot expect to have 30000/1001 frames per second and 48000 > samples a second for hours without some drift. And I'd rather have the > timing as accurate as the analog source rather than clean it for the > digital world. It=E2=80=99s true that analog format frame rates are more analogous to = floating points. A video tape may stretch unevenly from use so that = frames don=E2=80=99t start with exact precision. However these = discrepancies complicate digitization and most videotape digitization = will use a hardware time base corrector to buffer analog video in order = to transmit it accordingly to a more precise clock, so that the = resulting digital file will have already had it=E2=80=99s frame rate = =E2=80=98cleaned=E2=80=99. To Jerome, by "set this element in the header=E2=80=9D do you mean = within the Info Element similar to how it contains a nominal Duration = Element? Or do you mean to set this within the associated Track Element? = I=E2=80=99m assuming per track. > In the context of digitizing for archivists I don't know if that's > something that's taken in account. Dave ? For example how is that > solved for movies from the early days where a guy would have to turn a > handle to advance the film. It's definitely not a very precise/clean > clock. For videotapes that are stretched or shrunken to affect the presentation = timing, these deviations are not the intent of the recording, so using a = time base corrector fixes the frame rate. Also in the case of film = shrinkage the projector should still present at 24 fps although damage = is more likely. So I think following the intent of the format whether = 30000/1001 or 24 fps is correct. For hand cranked silent film, the film prints would usually be = distributed with recommended frame rates, so that the projectionist is = =E2=80=98trying=E2=80=99 to crank in order to present at 18 fps (or as = directed). If that film is digitization to a Matroska file then I think = that the Matroska should also be labelled for an 18 fps projection just = as the film print would have been. If there=E2=80=99s desire to = replicate the unperfect cranking of a human operator than that could be = accomplished by the player and not the file itself. Should I file a = ticket for VLC to accept input from a USB-attached hand crank? >> putting >> frame rate info in the header with numerator and denominator is = enough >> for doing the difference between 30000/1001 and 29970/1000, and the >> current millisecond timestamp is enough (a demuxer aware of the >> framerate element can "correct" the timecode from e.g. 0.033s to >> 1001/30000 second; an old player just play the file with 1 ms >> precision). We could add some rules in case a timecode does not fit = the >> frame rate (e.g. if timecode is 0.031, frame rate info is considered = not >> applicable) >=20 > In video the issue is not too big. But if we want sample precision for > audio, the fraction is a lot bigger (up to 192000 fps with modern pro > hardware). And with a timestamp scale shared among tracks that could > be problematic. If we want sample precision for audio and video we > could end up we'd lose a big range of the 16 bits available per > Cluster. Each of the 65536 Block timestamp would be 1/192,000s > (0.0052ms) giving a max Cluster duration of 0.341333s (65536/192000). > If we want to precision for a 1001/30000 track and a 1/192000 track we > would need a fraction of 1001/(30000*192000) (0.000173ms) resulting in > a Cluster max duration of 0.011s. Yes, this approach is not scalable. One could have 24000/1001 video, = 30000/1001 video, 44100 hz audio, and 192000 hz audio in the same file. > If the muxer knows that a track will always pack samples by an amount > X (1152 in MP3 for example) we can regain some duration. But that's > not always the case. Some codecs like Vorbis pack only a small amount > of samples per frame and the amount can vary between frames (In Vorbis > I, legal frame sizes are powers of two from 64 to 8192 samples). The > worst case scenario (I know of) of Vorbis at 192 KHz, frame precision > of the timestamp means we can only have a Cluster duration of 21.84s > (65536*64/192000). Mixed with NTSC video that's > 65536*64*1001/30000*192000 =3D 0.72s max duration for sample precision > per frame (not sample but it's close enough). That's still 21 video > frames in that Cluster. Not too bad. >=20 >> - people having variable frame rate with very precise timestamp need = to >> know it before starting the muxing and can use a Timecodescale = element >> of 1 (so precision of 1 nanosecond, usually enough when there is no >> fixed frame rate). >=20 > I can think of 3 different variable frame rate use cases: >=20 > - mixing video (25/29fps) and film sources (24fps) into one final = video > - a camera dropping some frames or only storing images when they > change. In this case there's likely a stable main clock like in > constant frame rate. > - a camera that would work like the eye. When there's > adrenaline/danger you capture images faster. In this case there's no > real clock. The timestamps can happen at anytime. I understand the issues of adding a frame rate numerator and denominator = to the track header as multiple timestamps could round to the same = increment of the frame rate. However what if the rounding to the nearest = increment of the frame rate is enabled by one of the reserved flag bits = of the Block Header (such as bit 1 of flags =3D Enable TimeScale = Alignment)? Thus if the frame rate of the track header is 120000/1001, then If Matroska timecode is 4 and Enable TimeScale Alignment is 0, than it = is at 4 / (1000000000 / TimecodeScale ). If Matroska timecode is 4 and Enable TimeScale Alignment is 1, than it = is at 0 / 1200000 (nearest increment of the rationale frame rate). If Matroska timecode is 17 and Enable TimeScale Alignment is 0, than it = is at 17 / (1000000000 / TimecodeScale ). If Matroska timecode is 17 and Enable TimeScale Alignment is 1, than it = is at 2002 / 1200000 (nearest increment of the rationale frame rate). Ignoring the rationale frame rate and the Enable TimeScale Alignment bit = would still decode to the accuracy supported by the TimecodeScale; = however a player that uses the rationale frame rate and Enable TimeScale = Alignment could round the timecode to the nearest increment of the frame = rate. Such a feature would not be useful for mixed timebase content = (documentary that mixes 24000/1001 and 30000/1001 framerates together). >> Which real life scenario can not deal with such workaround? >=20 > The question is: why do we want rationale number if we're going to > allow some form of rounding between the tracks that match the > timestamp scale precisely and the one that don't. IMO if there's > rounding let's just keep what we have. >=20 >> Compared to the concerns in: >> = https://lists.matroska.org/pipermail/matroska-devel/2012-October/004294.ht= ml >> It is per track so it resolves most concern >> For PCM, the corresponding video framerate is sometimes used and it = would >> not be resolved correctly, right (i.e. at 30000/1001 fps, there are >> sometimes 1601 samples and sometimes 1602 samples and it is not = possible to >> do the difference with the 16-bit timestamp having the millisecond >> precision) >> Note that my proposal is similar to the one in the mail having = criticism >> about TimecodeScaleDenominator (proposal of TrackTimeBaseNumerator = and >> TrackTimeBaseDenominator) [=E2=80=A6] Best Regards, Dave Rice From nobody Sun Jan 15 08:56:44 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABC0129605 for ; Sun, 15 Jan 2017 08:56:42 -0800 (PST) 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 OqQr78_SsJig for ; Sun, 15 Jan 2017 08:56:40 -0800 (PST) Received: from 2.mo2.mail-out.ovh.net (2.mo2.mail-out.ovh.net [188.165.53.149]) (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 94DE81295FD for ; Sun, 15 Jan 2017 08:56:39 -0800 (PST) Received: from player728.ha.ovh.net (b7.ovh.net [213.186.33.57]) by mo2.mail-out.ovh.net (Postfix) with ESMTP id 0737115959 for ; Sun, 15 Jan 2017 17:56:36 +0100 (CET) Received: from [192.168.2.101] (p5DDB67BC.dip0.t-ipconnect.de [93.219.103.188]) (Authenticated sender: jerome@francoallemand.eu) by player728.ha.ovh.net (Postfix) with ESMTPSA id 6B3A4540078; Sun, 15 Jan 2017 17:56:34 +0100 (CET) To: Dave Rice , Steve Lhomme References: <3363d485-83af-d46b-3bca-3b0359ca9bb2@mediaarea.net> <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> From: Jerome Martinez Message-ID: Date: Sun, 15 Jan 2017 17:56:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 12232902489875550353 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeelgedrfeeggddukeduucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Rationale Numbers for timestamps X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 16:56:42 -0000 Hi, Le 15/01/2017 à 17:24, Dave Rice a écrit : > [...] > To Jerome, by "set this element in the header” do you mean within the Info Element similar to how it contains a nominal Duration Element? Or do you mean to set this within the associated Track Element? I’m assuming per track. Per track, right. > [...] > I understand the issues of adding a frame rate numerator and denominator to the track header as multiple timestamps could round to the same increment of the frame rate. However what if the rounding to the nearest increment of the frame rate is enabled by one of the reserved flag bits of the Block Header (such as bit 1 of flags = Enable TimeScale Alignment)? > > Thus if the frame rate of the track header is 120000/1001, then > > If Matroska timecode is 4 and Enable TimeScale Alignment is 0, than it is at 4 / (1000000000 / TimecodeScale ). > If Matroska timecode is 4 and Enable TimeScale Alignment is 1, than it is at 0 / 1200000 (nearest increment of the rationale frame rate). > > If Matroska timecode is 17 and Enable TimeScale Alignment is 0, than it is at 17 / (1000000000 / TimecodeScale ). > If Matroska timecode is 17 and Enable TimeScale Alignment is 1, than it is at 2002 / 1200000 (nearest increment of the rationale frame rate). > > Ignoring the rationale frame rate and the Enable TimeScale Alignment bit would still decode to the accuracy supported by the TimecodeScale; however a player that uses the rationale frame rate and Enable TimeScale Alignment could round the timecode to the nearest increment of the frame rate. +1. I think that with this flag, we resolve all concerns (especially the fact we can "disable" the feature per frame so being as without the feature, we don't remove something, we just add a possibility and if this possibility is not usable, nothing changes because we set the flag for saying "do as TimeScale Alignment does not exist"). > Such a feature would not be useful for mixed timebase content (documentary that mixes 24000/1001 and 30000/1001 framerates together). Actually it is, with 120 fps hack (120/24 and 120/30 are integers, and this is the "frame rate" used in e.g. AVI for having mixed content, with "no op" frames when there is no frame to display). but maybe "frame rate numerator and denominator" should be named "TimeScale Alignment numerator and denominator" in order to be explicit about the fact it is used for TimeScale Alignment and is not a frame rate, so mixed timebase content is not an hack in Matroska but something officially doable. For example, for mixed content 24000/1001 and 30000/1001, TimeScale Alignment numerator is 1001, TimeScale Alignment denominator is 120000, and TimecodeScale default 1000000. - if 24000/1001 content, timecode is 0, 42, 83, 125... "aligned" to 0/120000, 5005/120000, 10010/120000, 15015/120000... - if 30000/1001 content, timecode is 0, 33, 67, 100... "aligned" to 0/120000, to 4004/120000, 8008/120000, 12012/120000... - if 2 frames at 24000/1001 then 2 frames at 30000/1000, timecode is 0, 42, 83, 117... "aligned" to 0/120000, 5005/120000, 10010/120000, 14014/120000... > [...] Jérôme From nobody Sun Jan 15 09:12:29 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 AF81C129624 for ; Sun, 15 Jan 2017 09:12:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.857 X-Spam-Level: X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.156, 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 VMuyWaukaNNA for ; Sun, 15 Jan 2017 09:12:23 -0800 (PST) Received: from smtp-sh.infomaniak.ch (smtp-sh.infomaniak.ch [128.65.195.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA0A12960D for ; Sun, 15 Jan 2017 09:12:23 -0800 (PST) Received: from smtp5.infomaniak.ch (smtp5.infomaniak.ch [83.166.132.18]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v0FHCKrI025307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Sun, 15 Jan 2017 18:12:20 +0100 Received: from Castor.local (77-56-128-186.dclient.hispeed.ch [77.56.128.186]) (authenticated bits=0) by smtp5.infomaniak.ch (8.14.5/8.14.5) with ESMTP id v0FHCJwZ019323 for ; Sun, 15 Jan 2017 18:12:20 +0100 Date: Sun, 15 Jan 2017 18:12:20 +0100 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 In-Reply-To: <34FB7CEC-68BF-47C7-AC12-BD27191C034F@dericed.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] Rationale Numbers for timestamps X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 17:12:26 -0000 Dave Rice wrote: >For hand cranked silent film, the film prints would usually >be distributed with recommended frame rates, so that the >projectionist is =E2=80=98trying=E2=80=99 to crank in order to present at >18 fps (or as directed). If that film is digitization to a >Matroska file then I think that the Matroska should also be >labelled for an 18 fps projection just as the film print >would have been. If there=E2=80=99s desire to replicate the >unperfect cranking of a human operator than that could be >accomplished by the player and not the file itself. Should >I file a ticket for VLC to accept input from a USB-attached >hand crank? +1 There is not only the operator's "imperfect hand-cranking", but also the films themselves that may have different projection speeds between reels and also inside a single reel. Many instruction sheets for the operator as well as for the conductor are known. Best regards, Reto From nobody Sun Jan 15 15:38: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 DE8CC1294F9 for ; Sun, 15 Jan 2017 15:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-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 jo6sfLareIHK for ; Sun, 15 Jan 2017 15:38:24 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9281E129509 for ; Sun, 15 Jan 2017 15:38:24 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:35578 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1cSuNP-0048hh-Jg; Sun, 15 Jan 2017 18:38:23 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Dave Rice In-Reply-To: Date: Sun, 15 Jan 2017 18:38:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <32BBAA33-1B23-4D46-B6A9-EC62D4358253@dericed.com> References: <05793BC1-EA9A-4FA1-A75A-A52611648253@dericed.com> <61c511fd-cd2e-ee0e-195d-e75aef7e20be@mediaarea.net> To: Steve Lhomme X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Jerome Martinez , Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] Matroska EncryptedBlock Structure and Virtual Block X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 23:38:26 -0000 > On Oct 16, 2016, at 9:53 AM, Steve Lhomme = wrote: >=20 > 2016-10-06 11:15 GMT+02:00 Jerome Martinez : >> Le 06/10/2016 =C3=A0 06:19, Dave Rice a =C3=A9crit : >>>=20 >>> What is the status of the Matroska documentation on "EncryptedBlock >>> Structure=E2=80=9D and =E2=80=9CVirtual Block=E2=80=9D? >>=20 >>=20 >> I understood that it is outdated, not really used, and should be = removed >> from the standard >=20 > Yes they should be removed. I removed the documentation on EncryptedBlock and VirtualBlock in = https://github.com/Matroska-Org/matroska-specification/pull/82. I also = dropped the reference to BlockVirtual from the definition of BlockGroup. Dave Rice= From nobody Sun Jan 22 06:15:13 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAC212962A for ; Sun, 22 Jan 2017 06:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32t_EPXVBoIJ for ; Sun, 22 Jan 2017 06:15:10 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DC87129607 for ; Sun, 22 Jan 2017 06:15:10 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id u68so82688449ywg.0 for ; Sun, 22 Jan 2017 06:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xub2l5tm25MlynAusbSw3XlZxUun0Yd3hcfErV8m9NE=; b=16Q6zd/cyELFHTuLKd6mwS/1QNvZNozQ7ZODLRHNTO45RTaeQX3OJJeDwU362iy9TD 8zArMH2APgUe704yccD8jtlBaLUtgKLca5HiJYSqnuTdlNs2zrNPheNTb91g5MpL5vaX ZXZG6P3szhVb/xjEojL+P9JLweBOIKtKj1f96+hD6hhCWDKJTUuVCQzY+h30cwAxraer +0PkebVk6MYUYw9Nbd5YS90XTqlEJmnVsvTkU2ZbCNHhkeSXXNkoljVP0xXVS13WUAiU CYzVTgiS9YiZZ2j48r8uVnVdtc0FW+XZh38aAOHJmz1HXejscYhVQfOjB+Q84aKClH/Q uwnQ== 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=xub2l5tm25MlynAusbSw3XlZxUun0Yd3hcfErV8m9NE=; b=pmY74iU1TWJ+X2H3Cl4YTQ3/ylbJS8BiAKf3CvwiHrC9bn762PjvEefXnyCTKc+uaq d3MeH6J8gUO8xBdHaPjR92wAINVbgm12qv3+zitNhRRdjZcI91qtZS7TktImPsl9DUbh 7y/RlmBYRZWjhAOOjPatKwiBU98LKYmNVH5e5j9CKCDWroveRV5AJOCU388rlLJwa6PK M9qCsIjQAUb99IDNgML0a3omYvO3uO9fxBUGJ0d984crNbpxOeO5uOC0Le2+VCcAlnc0 huov7l6uZ0oQnPb00jncFXNUBibJ9UzH4PWFfIOwqBqEywoewCjvzxu6iTPnTN1P0YTO c/wg== X-Gm-Message-State: AIkVDXKKtTuxHaQvjYFhpYhI6wq9MNaNW8UaaIxJQBzscE3iOxGiBg5VPQdvBtgZN/YRX/iIxIDwxQ1jG8hj5Q== X-Received: by 10.13.239.129 with SMTP id y123mr20400702ywe.131.1485094509334; Sun, 22 Jan 2017 06:15:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.46.203 with HTTP; Sun, 22 Jan 2017 06:15:08 -0800 (PST) In-Reply-To: References: From: Steve Lhomme Date: Sun, 22 Jan 2017 15:15:09 +0100 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] deprecating TrackTimecodeScale X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 14:15:12 -0000 Hi, In the current "official" specs it says that it's deprecated in newer versions, compared to other deprecated elements considered as not used in any version of Matroska. On top of that it was mandatory so some muxers may have written the value, likely to the default value. I don't see think we can ignore the elements in the current RFC. I created a PR to fix the XML specification as the minver/maxver should be 1 and 3, rather than 0 and 0. https://github.com/Matroska-Org/matroska-specification/pull/86 I just noticed that will finishing my parser to generate the libxml(2) code from the specs, which is now done even though the code is very dirty. I noticed another issue in the XML file, the MasteringMetadata parent was set incorrectly. 2017-01-14 22:09 GMT+01:00 Dave Rice : > Hi all, > > At one point in Matroska history there was a TrackTimecodeScale which was > intended for cases as having a video track from a film along with an audio > track from NTSC and a audio track from PAL (in PAL it is typical to speed up > the film from 24 to 25 fps whereas NTSC slows down the film from 24 to > 24000/1001 fps). There was some discussion on > https://lists.matroska.org/pipermail/matroska-devel/2010-May/003646.html and > in 2012 it was deprecated here: > https://github.com/Matroska-Org/foundation-source/commit/ca8263bfbbcd2a3ce69369465aaa1ebe0c3c779e. > > Although it is deprecated there is still a large section of documentation > about it in > https://github.com/Matroska-Org/matroska-specification/blob/dff36b4e01b6b1921e5bbdafa020e6485064dfd4/notes.md#tracktimecodescale. > > Should this documentation be removed altogether from the RFC draft? Or > should that documentation be marked with a caveat that it is documentation > of a deprecated Element? > > Dave Rice > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > -- Steve Lhomme Matroska association Chairman From nobody Sun Jan 22 07:46:56 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 3D3851295C7 for ; Sun, 22 Jan 2017 07:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lja1J1uw87o3 for ; Sun, 22 Jan 2017 07:46:54 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF66C1295C6 for ; Sun, 22 Jan 2017 07:46:53 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id u68so83369682ywg.0 for ; Sun, 22 Jan 2017 07:46:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6r8s9G3zx9+CqMPtq+Q2VHWDSwN8DAk8MUBnkGotvHA=; b=zy6f5SEq4TcyvNEpb/GOe0AV5vldQuY16bbXOn/jqd0YMIhdhjEzg8Fpsy9V2ZZ2OF xH66JXB9LtMhIlcn9n4RPpMpW3RpvXZ+xrMRZ7enA6qCFcD3NFCk2Fa+JBicGShd287L G9qndkRGKHg4LciwnHgdE2CebD3mAOnX5JR6vCQvGHsZ19C4IgfAEVAT0WWtWp+AGChn q8fyBTowbX2dVW2eK7xHtvh1LdvfhgfitHjgEKX3ix67YGxT2oFTgrUcK8Kak1iURqVj /edBusw3/69P8+Pc6GQ4NcscZ8N7qDNFo71vakKDWq6BGxqazrSHU9xUbR+zC0ttyOrE sK3g== 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=6r8s9G3zx9+CqMPtq+Q2VHWDSwN8DAk8MUBnkGotvHA=; b=M5oyP7QI7GViOMz1Ot/I4icvlWX/E0Ni3kadJuBQRXeLne1nAxXzLNVJ3y67AQxq39 YrpONmLqMig7vx+URDXRpi/RdcOEcyZhOQwSuU/N+4YgEBlIsEIsh1imW+je2O5IwqD2 QRrkoAJVwmV6XInELtb1mpDEtB9Q9orWH0u+RXr3rqfppBE58HwFCfwpCGOQMNDXl6rn Vh2wvtIBYA+vlxQaWw13+esd9MFgitk7J67yL9lSRZx1kyAcLreRFyUHuzCrJqa+JBnr KgPZgcVo9A3AwVwj+KCcjddHyfJQfMTHcQ/OO2Afw0q+ocTafKRHFt5zlYQjn4nFCfKV Y7bQ== X-Gm-Message-State: AIkVDXJc3KfXZV+3FpEzBFr+i8Yl5v2+zy4PuBb//NAeOjRvd2YOjde31htwltPKxtOuT0JI+sCQVDQoBjV7cw== X-Received: by 10.13.198.2 with SMTP id i2mr18588403ywd.201.1485100013170; Sun, 22 Jan 2017 07:46:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.83.46.203 with HTTP; Sun, 22 Jan 2017 07:46:52 -0800 (PST) In-Reply-To: References: From: Steve Lhomme Date: Sun, 22 Jan 2017 16:46:52 +0100 Message-ID: To: Dave Rice Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Codec Encoding for LossLess Archiving and Realtime transmission Subject: Re: [Cellar] deprecating TrackTimecodeScale X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 15:46:55 -0000 2017-01-22 15:15 GMT+01:00 Steve Lhomme : > Hi, > > In the current "official" specs it says that it's deprecated in newer > versions, compared to other deprecated elements considered as not used > in any version of Matroska. On top of that it was mandatory so some > muxers may have written the value, likely to the default value. I > don't see think we can ignore the elements in the current RFC. > > I created a PR to fix the XML specification as the minver/maxver > should be 1 and 3, rather than 0 and 0. > https://github.com/Matroska-Org/matroska-specification/pull/86 > > I just noticed that will finishing my parser to generate the libxml(2) > code from the specs, which is now done even though the code is very > dirty. I noticed another issue in the XML file, the MasteringMetadata > parent was set incorrectly. Turns out I spoke too fast. I finished libmatroska2 but not libmatroska. The Projection sub-elements had the wrong parent. I updated the ebml_specification.xml file accordingly. > 2017-01-14 22:09 GMT+01:00 Dave Rice : >> Hi all, >> >> At one point in Matroska history there was a TrackTimecodeScale which was >> intended for cases as having a video track from a film along with an audio >> track from NTSC and a audio track from PAL (in PAL it is typical to speed up >> the film from 24 to 25 fps whereas NTSC slows down the film from 24 to >> 24000/1001 fps). There was some discussion on >> https://lists.matroska.org/pipermail/matroska-devel/2010-May/003646.html and >> in 2012 it was deprecated here: >> https://github.com/Matroska-Org/foundation-source/commit/ca8263bfbbcd2a3ce69369465aaa1ebe0c3c779e. >> >> Although it is deprecated there is still a large section of documentation >> about it in >> https://github.com/Matroska-Org/matroska-specification/blob/dff36b4e01b6b1921e5bbdafa020e6485064dfd4/notes.md#tracktimecodescale. >> >> Should this documentation be removed altogether from the RFC draft? Or >> should that documentation be marked with a caveat that it is documentation >> of a deprecated Element? >> >> Dave Rice >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> > > > > -- > Steve Lhomme > Matroska association Chairman -- Steve Lhomme Matroska association Chairman From nobody Mon Jan 23 17:32:33 2017 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5F612951D for ; Mon, 23 Jan 2017 17:32:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USlA2_20jpvU for ; Mon, 23 Jan 2017 17:32:31 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BFA5129518 for ; Mon, 23 Jan 2017 17:32:31 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id i68so123614226uad.0 for ; Mon, 23 Jan 2017 17:32:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=reNfsqfBQB/8BaMWCsdSqyfPEiHSdYX5dkAG7v6ypFw=; b=pOvakztWNmQAeVBE3lAAca1mFWTFrHtCv0wvEp4AnxM9Sx2/xbHn7QnHNx+ydaxwDG 9BI6bJNVaPn761BGCljQck+rLQLtQilQLN4vwLYwlfGbSfSgbog59qUnrmPd8xdrP0Lm CM74Bzwzc3VQP3k6dTFLrhESVDUrMht6OJzU+D1kK0/do/bI78j5IPsOV0iiS/vPI4+f M6V4oXaEeVNVyDx63EvjOVmNSiBtPFLDcNH6YVHJX/uUhzVpA6a9QuFKvpg60Xm6fFkc DoAcJfoeD0r2m6kinfau5MbWJ9dNZY5pmvU8DVY6JFX9NYPK7hL/5Kap6dYif1TvVw4g MWrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=reNfsqfBQB/8BaMWCsdSqyfPEiHSdYX5dkAG7v6ypFw=; b=jwiQN3hrW7bSjV13lGdcR2IxGOclVrzsJoFHh6MIg9S0d3VQ/Rk3PCwiFIqfICq2LY dUJMCd5vaX4SPfKZyuyni4xXJocrJMbrM3ROmUMq4GRshviip7ABaLQ3bnVHUxDlr7Ht jPST1Y7/zEoaPl3doISu67zjJDTbtPbMTR9HyAA3wRYhP7Ywk8rtk+EN2E3CuGenWnV1 39TMgtVy4MABjfgv4WVym6ip0VZb303Lcm9WGqnGR1vlc0GsBaZrfIXjfSqTMqVJfCpq Ueou03YrDksZHnTkJ7w7XHmnqManH0qSkBs4eMJwCzFBEPN9ar0EfNdLGI4hwAgevT7m cOqQ== X-Gm-Message-State: AIkVDXIWrZ2MXF73b/A1zBE1EhnGoeJGIXvTFaN+a+haZPPIMNo1L6yFs+WhywFFYikCjFS+kKxk7A6+RKQRfQ== X-Received: by 10.176.23.3 with SMTP id j3mr13284356uaf.78.1485221550282; Mon, 23 Jan 2017 17:32:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.5.4 with HTTP; Mon, 23 Jan 2017 17:32:29 -0800 (PST) From: Matt Gruenke Date: Mon, 23 Jan 2017 20:32:29 -0500 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=f40304361f38eadf860546cd16f2 Archived-At: Subject: [Cellar] TrackTypes for non-standard data formats X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 01:32:32 -0000 --f40304361f38eadf860546cd16f2 Content-Type: text/plain; charset=UTF-8 Hello, I have a use case for Matroska files/streams I'd like to discuss, and was referred to this list. I need to multiplex a video stream, possibly an audio stream, and one or more streams of time-stamped, non-standard binary data. In considering which TrackType to use, I am concerned that using audio or video might break compatibility with standard players (i.e. for the *actual* audio/video tracks contained in these files). I saw recent discussion of adding a track type specifically for ancillary data, but it seems to me that it might also be worth considering reserving a small block of TrackType values for non-standard, application-specific uses. As I try to imagine the different kinds of structures & uses tracks might have, within a family of applications, I think this block should consist of somewhere between 4 and 8 values. Thank you for considering my suggestion. Matt --f40304361f38eadf860546cd16f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

I have a use case= for Matroska files/streams I'd like to discuss, and was referred to th= is list.

I need to multiplex a video stream, possibly a= n audio stream, and one or more streams of time-stamped, non-standard binar= y data.=C2=A0 In considering which TrackType to use, I am concerned that us= ing audio or video might break compatibility with standard players (i.e. fo= r the actual audio/video tracks contained in these files).

<= /div>
I saw recent discussion of adding a track type specifically for a= ncillary data, but it seems to me that it might also be worth considering r= eserving a small block of TrackType values for non-standard, application-sp= ecific uses.=C2=A0 As I try to imagine the different kinds of structures &a= mp; uses tracks might have, within a family of applications, I think this b= lock should consist of somewhere between 4 and 8 values.

Thank you for considering my suggestion.


Matt

--f40304361f38eadf860546cd16f2-- From nobody Mon Jan 23 19:23:03 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 AA73212955F for ; Mon, 23 Jan 2017 19:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.12 X-Spam-Level: X-Spam-Status: No, score=-0.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779, UC_GIBBERISH_OBFU=1] 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 X8ByVek-IPIc for ; Mon, 23 Jan 2017 19:23:01 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBCD7129559 for ; Mon, 23 Jan 2017 19:23:00 -0800 (PST) Received: from cpe-104-162-86-103.nyc.res.rr.com ([104.162.86.103]:35302 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:ECDHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1cVrhD-003GIF-A2 for cellar@ietf.org; Mon, 23 Jan 2017 22:23:00 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_4E8DAB77-1CD0-432B-975F-B425180486ED" Message-Id: <8E74E6A0-83BB-46DD-A5D2-F732C7ABDA6A@dericed.com> Date: Mon, 23 Jan 2017 22:22:56 -0500 To: Codec Encoding for LossLess Archiving and Realtime transmission Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: [Cellar] re-formatting the Matroska Codec Mappings X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 03:23:03 -0000 --Apple-Mail=_4E8DAB77-1CD0-432B-975F-B425180486ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, The documentation on how to document a Codec Mapping in Matroska has = been integrated into the GitHub repo. Now here's a attempt to update the = Codec Mapping page to use the new form: = https://github.com/Matroska-Org/matroska-specification/pull/88. Some = notes about the update: There are many informal questions left within the codec_specs document, = usually listed with a =E2=80=9C???=E2=80=9D. Steve, Moritz, are these = notes to self? Can we resolve or remove them? For example = V_MS/VFW/FOURCC contains "Where is the Huffman table stored in HuffYUV, = not AVISTREAMINFO ??? And the FourCC, not in AVISTREAMINFO.fccHandler = ???=E2=80=9D Also the definition for A_AC3 seems to question if there is = any Private Data for that encoding "The private data is void ???=E2=80=9D.= In some cases the original list of codec mappings was nested, I = flattened it which increases clarify but also increases redundancy. The description for V_MPEG1, V_MPEG2, A_MPC, and S_TEXT/USF seem to = imply that they are not yet defined, though their definitions are in = early states. The pull request updates the form of the Codec Mappings, but isn=E2=80=99t= intended to update or clarify all of the language (there=E2=80=99s = still a lot to do there). And some questions: Should we define a structure to detail Private Data? For instance = Private Data for V_MS/VFW/FOURCC contains a BITMAPINFOHEADER and for = V_REAL contains a real_video_props_t. These structures are defined in = linked references but is it worthwhile to define the structure within = the Codec Mapping? There is a method for defining bitstream data already = in the FFV1 specification (example = ) which = we could adapt. The definition for A_AAC/?????/??? implies that it applies to all = A_AAC/* Codec Mappings and its description says "AAC audio always uses = wFormatTag 0xFF=E2=80=9D which implies that WAVEFORMATEX is used in the = Private Data; however each definition for A_AAC/* says that the Private = Data is void. So why does it need to be said that "AAC audio always uses = wFormatTag 0xFF=E2=80=9D? The A_PCM Codec Mappings reference wFormatTag = as well. V_Uncompressed references a KaxCodecColourSpace element but there = isn=E2=80=99t such a thing. Is it intended to refer to the ColourSpace = Element? A_PCM/* references a KaxAudioBitDepth element. Is this meant to be the = BitDepth Element? The specs list A_QUICKTIME/QDMC and A_QUICKTIME/QDM2 as deprecated and = superseded by A_QUICKTIME. However we note deprecation with a date in = the =E2=80=9CDeprecation Date=E2=80=9D value, but I=E2=80=99m unable to = determine when that date was. Suggestions on a date to use or an = alternate expression to note Codec deprecation? Best Regards, Dave Rice --Apple-Mail=_4E8DAB77-1CD0-432B-975F-B425180486ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi all,

The documentation on how to document a = Codec Mapping in Matroska has been integrated into the GitHub repo. Now = here's a attempt to update the Codec Mapping page to use the new form: = https://github.com/Matroska-Org/matroska-specification/pull/88<= /a>. Some notes about the update:

There are many informal questions left = within the codec_specs document, usually listed with a =E2=80=9C???=E2=80=9D= . Steve, Moritz, are these notes to self? Can we resolve or remove them? = For example V_MS/VFW/FOURCC contains "Where is the Huffman table stored = in HuffYUV, not AVISTREAMINFO ??? And the FourCC, not in AVISTREAMINFO.fccHandler ???=E2=80=9D = Also the definition for A_AC3 seems to question if there is any Private = Data for that encoding "The private data is void ???=E2=80=9D.

In some cases the = original list of codec mappings was nested, I flattened it which = increases clarify but also increases redundancy.

The description for V_MPEG1, V_MPEG2, = A_MPC, and S_TEXT/USF seem to imply that they are not yet defined, = though their definitions are in early states.

The pull request updates the form of = the Codec Mappings, but isn=E2=80=99t intended to update or clarify all = of the language (there=E2=80=99s still a lot to do there).

And some = questions:

Should we define a structure to detail Private Data? For = instance Private Data for V_MS/VFW/FOURCC contains a BITMAPINFOHEADER = and for V_REAL contains a real_video_props_t. These structures are = defined in linked references but is it worthwhile to define the = structure within the Codec Mapping? There is a method for defining = bitstream data already in the FFV1 specification (example) which we could adapt.

The definition for A_AAC/?????/??? = implies that it applies to all A_AAC/* Codec Mappings and its = description says "AAC audio always uses wFormatTag 0xFF=E2=80=9D which = implies that WAVEFORMATEX is used in the Private Data; however each = definition for A_AAC/* says that the Private Data is void. So why does = it need to be said that "AAC audio always uses wFormatTag 0xFF=E2=80=9D? = The A_PCM Codec Mappings reference wFormatTag as well.

V_Uncompressed = references a KaxCodecColourSpace element but there isn=E2=80=99t = such a thing. Is it intended to refer to the ColourSpace = Element?

A_PCM/*= references a KaxAudioBitDepth element. Is this meant to be the = BitDepth Element?

The specs list A_QUICKTIME/QDMC = and A_QUICKTIME/QDM2 as deprecated and superseded = by A_QUICKTIME. However we note deprecation with a date in the = =E2=80=9CDeprecation Date=E2=80=9D value, but I=E2=80=99m unable to = determine when that date was. Suggestions on a date to use or an = alternate expression to note Codec deprecation?

Best Regards,
Dave = Rice

= --Apple-Mail=_4E8DAB77-1CD0-432B-975F-B425180486ED-- From nobody Tue Jan 24 07:24:34 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 C8A0B129A56 for ; Tue, 24 Jan 2017 07:24:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 4PA4kRX7OunC for ; Tue, 24 Jan 2017 07:24:32 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86416129A55 for ; Tue, 24 Jan 2017 07:24:32 -0800 (PST) Received: from [146.96.19.240] (port=11665 helo=[10.10.201.55]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1cW2xQ-0008Wl-BJ; Tue, 24 Jan 2017 10:24:32 -0500 From: Dave Rice Message-Id: <90625ABD-48AE-41CC-AFE1-24BD57A62415@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_45B3E4B2-612B-4AC2-AAF7-96F1D957ECA3" Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\)) Date: Tue, 24 Jan 2017 10:24:26 -0500 In-Reply-To: To: Matt Gruenke References: X-Mailer: Apple Mail (2.3226) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] TrackTypes for non-standard data formats X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 15:24:34 -0000 --Apple-Mail=_45B3E4B2-612B-4AC2-AAF7-96F1D957ECA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 23, 2017, at 8:32 PM, Matt Gruenke = wrote: >=20 > Hello, >=20 > I have a use case for Matroska files/streams I'd like to discuss, and = was referred to this list. >=20 > I need to multiplex a video stream, possibly an audio stream, and one = or more streams of time-stamped, non-standard binary data. In = considering which TrackType to use, I am concerned that using audio or = video might break compatibility with standard players (i.e. for the = actual audio/video tracks contained in these files). >=20 > I saw recent discussion of adding a track type specifically for = ancillary data, but it seems to me that it might also be worth = considering reserving a small block of TrackType values for = non-standard, application-specific uses. As I try to imagine the = different kinds of structures & uses tracks might have, within a family = of applications, I think this block should consist of somewhere between = 4 and 8 values. IIRC the proposal for ancillary tracks was to have Codec_IDs prefixed = with "N_". If your binary data stream is wholly private with contents = that are not intended to be known by the Matroska specification then = perhaps a private Codec ID prefix (such a "X_") would be worthwhile to = define. On the other hand, if you could be more transparent you could = also consider defining your codec openly, perhaps the application = specific use could have wider interest. Or could OggKate store the values you need? Perhaps it's worthwhile to = define storage for a time-based metadata track such as this. Dave Rice= --Apple-Mail=_45B3E4B2-612B-4AC2-AAF7-96F1D957ECA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jan 23, 2017, at 8:32 PM, Matt Gruenke <matt.gruenke@gmail.com> wrote:

Hello,

I have a use case for Matroska = files/streams I'd like to discuss, and was referred to this = list.

I need to multiplex a = video stream, possibly an audio stream, and one or more streams of = time-stamped, non-standard binary data.  In considering which = TrackType to use, I am concerned that using audio or video might break = compatibility with standard players (i.e. for the actual= audio/video tracks contained in these files).

I saw recent discussion of adding a = track type specifically for ancillary data, but it seems to me that it = might also be worth considering reserving a small block of TrackType = values for non-standard, application-specific uses.  As I try to = imagine the different kinds of structures & uses tracks might have, = within a family of applications, I think this block should consist of = somewhere between 4 and 8 values.

IIRC the proposal for ancillary tracks was to have = Codec_IDs prefixed with "N_". If your binary data stream is wholly = private with contents that are not intended to be known by the Matroska = specification then perhaps a private Codec ID prefix (such a "X_") would = be worthwhile to define. On the other hand, if you could be more = transparent you could also consider defining your codec openly, perhaps = the application specific use could have wider interest.

Or could OggKate store the values you need? = Perhaps it's worthwhile to define storage for a time-based metadata = track such as this.

Dave = Rice
= --Apple-Mail=_45B3E4B2-612B-4AC2-AAF7-96F1D957ECA3-- From nobody Tue Jan 24 20:39: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 43B2B1296EA for ; Tue, 24 Jan 2017 20:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-fKHGUvc5F1 for ; Tue, 24 Jan 2017 20:39:12 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 77F301296E7 for ; Tue, 24 Jan 2017 20:39:12 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id 96so150713236uaq.3 for ; Tue, 24 Jan 2017 20:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TdbT7ao4zNt9FJExf1YY32McneIUydwiqI4MVEnJQHs=; b=gLCBvwZaYUXMyvKRtOu9RsI12BMl2hZu8OciscQ+st/gF9y5i7dc0k67Zavu4YXbg8 w4p1hYIGKzf8YBbl6aJ4Ljd8GUa7kbJJ6Jd4eRC7br7cBAH29bi0COF1ixgGiRyxymil q2SpbHH5DLAeMCliHH32+6cYzZHuK/RyQtcZ3y4DS4nYibzet6ZuWYTGT0iC8PgJHjvO WOLirU1P2+XkEwrVxjC7nSvHGYr2MoNU7fwiowDRRtrxJ0xZ5vbPV5ufZAYmxIukDDcw IlDC4ERHWTtkuI7vl9gJo4cDrwBXaqfmryWmetfwmqwJz1qsBSd9UXjYDHlBur78LhEf yxJw== 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=TdbT7ao4zNt9FJExf1YY32McneIUydwiqI4MVEnJQHs=; b=qr/GjLUxlChBFIvkDe4p5+SaBWJGW5BiQ1jciHdYUPc8ioD171q2WEfZ5s+zuZIFaR SmkQqEBR+YNORV/bwUx2xEgbbHBv87I6e4a7XgpF9W/tKFVoEtVjH13CNr1tPYB78x6R jPnRZr9WqAlRX0enyE9rrNjKmU0/JaiE0ask2ptdl1NOrA2fwy/iU1bn62EmaIgeplEp r+oyAYDYAt4smUX4QnH4iG7AZKhmGM9DUJbVEq/GewcZbZ4Nwrm8vlZfwTA+J2Ti1ymL /Q4W9rkx/sexV7DLBSVRsTmKIKMmNx2PubtKXlfoYZPKQfAJGbzG5tFDT4vOBziT262f 0Fyw== X-Gm-Message-State: AIkVDXKfnSEL3cEhy+XKOKHk0+S+Vsg6mAtIly1C9ksaHFf1iFZyMtrOwCZ62UVLhv3CotPSWj2FU+Kfi+jQBw== X-Received: by 10.176.64.169 with SMTP id i38mr16685488uad.7.1485319151539; Tue, 24 Jan 2017 20:39:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.5.4 with HTTP; Tue, 24 Jan 2017 20:39:11 -0800 (PST) In-Reply-To: <90625ABD-48AE-41CC-AFE1-24BD57A62415@dericed.com> References: <90625ABD-48AE-41CC-AFE1-24BD57A62415@dericed.com> From: Matt Gruenke Date: Tue, 24 Jan 2017 23:39:11 -0500 Message-ID: To: Dave Rice Content-Type: multipart/alternative; boundary=94eb2c12458867dca80546e3d00b Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] TrackTypes for non-standard data formats X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 04:39:14 -0000 --94eb2c12458867dca80546e3d00b Content-Type: text/plain; charset=UTF-8 If it'd help to deal with specifics, some examples I have in mind are scene geometry (e.g. point clouds, polygonal meshes, Z-buffer), camera pose (e.g. position & orientation as vector & quaternion pairs, GPS coordinates, compass readings), and various telemetry data (plenty of examples at https://en.wikipedia.org/wiki/Telemetry ). Although nothing specific comes to mind that wouldn't have a stream-like structure, one might allow for more such things as menus and button tracks. Perhaps a game streaming application might use a track for player information and statistics. In considering the utility & possible necessity of multiple, application-defined TrackTypes, perhaps it's worth reviewing the purposes they serve. One function of TrackType is certainly to simplify semantic mapping of the available tracks. To this end, it can prove more reliable than CodecID, since it's certainly possible to use the same encoding for tracks with different semantics. Of course, TrackType also dictates the content model of TrackEntry. Though, I don't know enough about EBML to have a sense of whether it's practical and reasonable for applications to extend the schema to allow for custom track metadata. I guess I'd ask why *not* allow ancillary data to have one of ~8 TrackTypes? At the very least, I'd suggest using somewhere near the top of the range. Then, more values for ancillary data could be added, subsequently, while keeping the range contiguous. Matt On Tue, Jan 24, 2017 at 10:24 AM, Dave Rice wrote: > > IIRC the proposal for ancillary tracks was to have Codec_IDs prefixed with > "N_". If your binary data stream is wholly private with contents that are > not intended to be known by the Matroska specification then perhaps a > private Codec ID prefix (such a "X_") would be worthwhile to define. On the > other hand, if you could be more transparent you could also consider > defining your codec openly, perhaps the application specific use could have > wider interest. > > Or could OggKate store the values you need? Perhaps it's worthwhile to > define storage for a time-based metadata track such as this. > > Dave Rice > --94eb2c12458867dca80546e3d00b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If it'd help to deal with specifics, some examples I h= ave in mind are scene geometry (e.g. point clouds, polygonal meshes, Z-buff= er), camera pose (e.g. position & orientation as vector & quaternio= n pairs, GPS coordinates, compass readings), and various telemetry data (pl= enty of examples at htt= ps://en.wikipedia.org/wiki/Telemetry ).

Although not= hing specific comes to mind that wouldn't have a stream-like structure,= one might allow for more such things as menus and button tracks.=C2=A0 Per= haps a game streaming application might use a track for player information = and statistics.

In considering the utility &a= mp; possible necessity of multiple, application-defined TrackTypes, perhaps= it's worth reviewing the purposes they serve.=C2=A0 One function of Tr= ackType is certainly to simplify semantic mapping of the available tracks.= =C2=A0 To this end, it can prove more reliable than CodecID, since it's= certainly possible to use the same encoding for tracks with different sema= ntics.

Of course, TrackType also dictates the cont= ent model of TrackEntry.=C2=A0 Though, I don't know enough about EBML t= o have a sense of whether it's practical and reasonable for application= s to extend the schema to allow for custom track metadata.

I guess I'd ask w= hy *not* allow ancillary data to have one of ~8 TrackTypes?=C2=A0 At the ve= ry least, I'd suggest using somewhere near the top of the range.=C2=A0 = Then, more values for ancillary data could be added, subsequently, while ke= eping the range contiguous.


Matt


On Tue, Jan 24, 2017 at 10:24 AM, Dave Rice <dave@dericed.com= > wrote:

IIRC = the proposal for ancillary tracks was to have Codec_IDs prefixed with "= ;N_". If your binary data stream is wholly private with contents that = are not intended to be known by the Matroska specification then perhaps a p= rivate Codec ID prefix (such a "X_") would be worthwhile to defin= e. On the other hand, if you could be more transparent you could also consi= der defining your codec openly, perhaps the application specific use could = have wider interest.

Or could OggKate store the va= lues you need? Perhaps it's worthwhile to define storage for a time-bas= ed metadata track such as this.

Dave Rice

--94eb2c12458867dca80546e3d00b-- From nobody Fri Jan 27 09:11:14 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 EF0DA12969D for ; Fri, 27 Jan 2017 09:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.939 X-Spam-Level: X-Spam-Status: No, score=-4.939 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 LCkvLQMgVVz5 for ; Fri, 27 Jan 2017 09:11:12 -0800 (PST) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDAB12969C for ; Fri, 27 Jan 2017 09:11:12 -0800 (PST) Received: by mail-yb0-x234.google.com with SMTP id j82so69454014ybg.1 for ; Fri, 27 Jan 2017 09:11:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=IIG5Y/y7S69kHHcUDHqqIZEfXiNePjcMrNMQ1b3rLDg=; b=MmPUzE7xzloWRL7ZSaI4lLMGjtEuxNu1mF6e8TcpXs04KyibnOJyxvtis7gKyJTIN3 5DK6tIabQ1tgK22NBIufP224izVymxos5PBH9VfFXXcRZ8v/0OM1BNJX0CMdUnpVBIH9 lqlmpwrKiE6P08K+lZ+Qchk4biZ3nc8duEsASmzFphOyZziGT7FJM1d/1nmXjvVRiIsY r3ulCxhDfVjtV8el34BbHr4FJL+DsF0ClLzG3DKx3NgGvbf1m2fTgAG478FW7c/jrSQm hkoMRQByHfhyywo5A42veh+egmfW8lWJszE9wT7bOocp6w6duGqac7T22toXthCqZgCD cX9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IIG5Y/y7S69kHHcUDHqqIZEfXiNePjcMrNMQ1b3rLDg=; b=sFDFKe4eIEBxxAUjSXviDrq+EZf0RdmLazMfkPRhWaU5yonkJE/SD1SpFeGdi1iqdI rbkGbxoFMViYQxXb9YCYKKmZf4IqXWsuCaOzFcMFKAw6XpXiFkEyo1sp6xy9jOSH3UYz /rr9SjmZ7wYBSN8YhLra/SaQzMMNqrnQFLh0nr0429RJvKfVJpDfcU4g2ZjR3zSlS/IY nCpbgB1TY9WoQTQ+bbws+vpPeLbIfy2umqOYxyjEpVL18OWLMSobKqw61KF3zHk66UlA IJ57LvaGFsR7Eu/9kzJHueqEWiU3BFYQZqF7rdIzs1WfzswDrzSLOPAAiHf/bEZh2DRp 0RQw== X-Gm-Message-State: AIkVDXK3womMYFMii60Gs+tuNtdmyt4C8HvgZ9Vcyt/nezUda/7AAL1TmIKeb34lDx6oHLYSxhQ3DZGhaRG/5MNY X-Received: by 10.37.216.18 with SMTP id p18mr2302764ybg.42.1485537071354; Fri, 27 Jan 2017 09:11:11 -0800 (PST) MIME-Version: 1.0 From: Aaron Colwell Date: Fri, 27 Jan 2017 17:11:00 +0000 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary=94eb2c05e14270b8bc0547168dfe Archived-At: Subject: [Cellar] Adding a new stereo mode for 360 mesh projections X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 17:11:14 -0000 --94eb2c05e14270b8bc0547168dfe Content-Type: text/plain; charset=UTF-8 Hi, I work on the Spherical Video V2 spec and I'm working on this patch to update the semantics for stereo content that uses a different projection mesh for each eye. I wanted to get some feedback from folks here about adding a new StereoMode enum value that essentially signals that the (u,v) mappings for each eye are specified elsewhere. In my case they are specified in the per-eye meshes, but I could also imagine other descriptions for non-360 content. The intent here is to still be able to have the stereo mode indicate the content is stereoscopic, but the actual layout of the pixels for each eye is freeform and does not fall into the usual left-right or top-bottom forms. Would folks here be supportive of adding a new enum value for this use case? Thanks, Aaron --94eb2c05e14270b8bc0547168dfe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I work on the=C2=A0Spherical Video V2 spec=C2=A0and I'm working o= n=C2=A0this patch=C2=A0to update the semantics for stereo content = that uses a different projection mesh for each eye. I wanted to get some fe= edback from folks here about adding a new StereoMode enum value that essent= ially signals that the (u,v) mappings for each eye are specified elsewhere.= In my case they are specified in the per-eye meshes, but I could also imag= ine other descriptions for non-360 content. The intent here is to still be = able to have the stereo mode indicate the content is stereoscopic, but the = actual layout of the pixels for each eye is freeform and does not fall into= the usual left-right or top-bottom forms.

Would f= olks here be supportive of adding a new enum value for this use case?
=

Thanks,
Aaron


--94eb2c05e14270b8bc0547168dfe--