From nobody Thu Nov 1 07:03:51 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A2F1277BB for ; Thu, 1 Nov 2018 07:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykuTcS5YosnE for ; Thu, 1 Nov 2018 07:03:48 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D158124D68 for ; Thu, 1 Nov 2018 07:03:48 -0700 (PDT) Received: from [146.96.19.240] (port=35663 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gIDZY-0032d0-Oe for cellar@ietf.org; Thu, 01 Nov 2018 10:03:46 -0400 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_6C13AD63-EB5E-48AB-BDC0-61EF352CE3FD" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> Date: Thu, 1 Nov 2018 10:03:44 -0400 To: Cellar list X-Mailer: Apple Mail (2.3273) 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] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2018 14:03:50 -0000 --Apple-Mail=_6C13AD63-EB5E-48AB-BDC0-61EF352CE3FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I=E2=80=99m looking for thoughts on pull request = https://github.com/Matroska-Org/matroska-specification/pull/276 = for = Matroska which addresses an issue described at = https://github.com/Matroska-Org/matroska-specification/issues/270 = . = This would add a new Master Element called =E2=80=9CMetadata=E2=80=9D = within BlockGroup and the Metadata Element would contain a MetadataName = which labels the content of either a MetadataString or MetadataBinary = Element (this is a bit similar to the TagName/TagString/TagBinary set of = elements). These elements would allow information to be associated = directly with the contents of the Block. I also considered Michael Niedermayer=E2=80=99s work in the nut = specification at http://ffmpeg.org/~michael/nut.txt = where a structure is defined to = store side metadata per frame, see the section on "sm_data / side_data / = meta_data=E2=80=9D. Here are a few use cases where I think this structure could be helpful: =3D=3D=3D timecode We=E2=80=99ve made many starts and stops at defining how to store = timecode in Matroska but haven=E2=80=99t found consensus or resolution = on those attempts. With the Metadata Element I think a timecode value = could be stored such as Cluster/ Timestamp=3D01:00:00.000 BlockGroup/ Block/ ... Metadata/ MetadataName=3D=E2=80=9Ctimecode" MetadataString=3D"01:23:45;12=E2=80=9D The Metadata Element would here would be encoded as = 0xD297D38874696D65636F6465D48B30313A32333A34353B3132 which adds 25 bytes = per frame (about 2MB per hour for PAL). Currently the decklink input device in libavdevice can pass along = timecode as frame side metadata (see = https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/0946c0ec177dc48ef0677f890a= a42d95e667c417 = ) but Matroska offers no method to store such side data. =3D=3D=3D DPX -> MKV -> DPX lossless remuxing When converting a DPX image sequence to FFV1/MKV the image data is = losslessly stored but the DPX headers contain lots of information = specific to DPX which is lost. The RawCooked project has an approach = where that DPX header data is stored in Matroska attachments and then = recalled and used when RawCooked is reverting from Matroska back to DPX = (so the resulting DPX bitstream is identical as the input, similar to = how flac can do this with wav->flac->wav. With this proposal the DPX = header data could be stored within the Metadata Elements of the block = group, such as: Cluster/ Timestamp=3D01:00:00.000 BlockGroup/ Block/ ... Metadata/ MetadataName=3D=E2=80=9Cdpx_header" MetadataBinary=3D0x58504453=E2=80=A6 Comments welcome. Dave Rice= --Apple-Mail=_6C13AD63-EB5E-48AB-BDC0-61EF352CE3FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

I=E2=80=99m looking for = thoughts on pull request https://github.com/Matroska-Org/matroska-specification/pull/276=  for Matroska which addresses an issue described at https://github.com/Matroska-Org/matroska-specification/issues/2= 70. This would add a new Master Element called =E2=80=9CMetadata=E2=80= =9D within BlockGroup and the Metadata Element would contain a = MetadataName which labels the content of either a MetadataString or = MetadataBinary Element (this is a bit similar to the = TagName/TagString/TagBinary set of elements). These elements would allow = information to be associated directly with the contents of the = Block.

I = also considered Michael Niedermayer=E2=80=99s work in the nut = specification at http://ffmpeg.org/~michael/nut.txt where a structure = is defined to store side metadata per frame, see the section on "sm_data = / side_data / meta_data=E2=80=9D.

Here are a few use cases where I think = this structure could be helpful:

=3D=3D=3D timecode
We=E2=80=99ve made many starts and stops at defining how to = store timecode in Matroska but haven=E2=80=99t found consensus or = resolution on those attempts. With the Metadata Element I think a = timecode value could be stored such as

Cluster/
= Timestamp=3D01:00:00.000
= BlockGroup/
Block/
= ...
Metadata/
= MetadataName=3D=E2=80=9Ctimecode"
= MetadataString=3D"01:23:45;12=E2=80=9D

The Metadata Element = would here would be encoded as = 0xD297D38874696D65636F6465D48B30313A32333A34353B3132 which adds 25 bytes = per frame (about 2MB per hour for PAL).

Currently the decklink input device in = libavdevice can pass along timecode as frame side metadata (see https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/0946c0ec177dc48= ef0677f890aa42d95e667c417) but Matroska offers no method to store = such side data.

=3D=3D=3D DPX -> MKV -> DPX lossless remuxing
When converting a DPX image sequence to FFV1/MKV the image = data is losslessly stored but the DPX headers contain lots of = information specific to DPX which is lost. The RawCooked project has an = approach where that DPX header data is stored in Matroska attachments = and then recalled and used when RawCooked is reverting from Matroska = back to DPX (so the resulting DPX bitstream is identical as the input, = similar to how flac can do this with wav->flac->wav. With this = proposal the DPX header data could be stored within the Metadata = Elements of the block group, such as:

Cluster/
= Timestamp=3D01:00:00.000
= BlockGroup/
Block/
= ...
Metadata/
= MetadataName=3D=E2=80=9Cdpx_header"
= MetadataBinary=3D0x58504453=E2=80=A6

Comments = welcome.
Dave Rice
= --Apple-Mail=_6C13AD63-EB5E-48AB-BDC0-61EF352CE3FD-- From nobody Fri Nov 2 02:31:58 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64FD012F1A6 for ; Fri, 2 Nov 2018 02:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, 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 B_2UQwRFDvLq for ; Fri, 2 Nov 2018 02:31:53 -0700 (PDT) Received: from mx01.mail.netstorage.at (mx01.mail.netstorage.at [IPv6:2a02:2410:b000:101:3000::c]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E20D12F1A5 for ; Fri, 2 Nov 2018 02:31:52 -0700 (PDT) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx01.mail.netstorage.at (Postfix) with ESMTPS id D003BA46A8 for ; Fri, 2 Nov 2018 10:31:48 +0100 (CET) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 4945C8004E for ; Fri, 2 Nov 2018 10:31:48 +0100 (CET) Received: from [127.0.0.1] (HSI-KBW-46-237-252-214.hsi.kabel-badenwuerttemberg.de [46.237.252.214]) by mailix with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128) ; Fri, 2 Nov 2018 10:31:47 +0100 To: cellar@ietf.org References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> From: Tobias Rapp Organization: NOA GmbH Message-ID: <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> Date: Fri, 2 Nov 2018 10:31:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20181102093148.25477.28864@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 02 Nov 2018 09:31:57 -0000 Hi Dave, On 01.11.2018 15:03, Dave Rice wrote: > [...] > > Here are a few use cases where I think this structure could be helpful: > > === timecode > We’ve made many starts and stops at defining how to store timecode in > Matroska but haven’t found consensus or resolution on those attempts. > With the Metadata Element I think a timecode value could be stored such as > > Cluster/ > Timestamp=01:00:00.000 > BlockGroup/ > Block/ > ... > Metadata/ > MetadataName=“timecode" > MetadataString="01:23:45;12” while I think that frame side data can be useful for the DPX scenario mentioned later, I see problems with storing timecode information that way. Shall timecode be attached to the video or audio track? Shall there be some sub-classification for VITC/LTC/other timecode sources? Also I would prefer the timecode value to be stored as a number instead of a string representation, for the same reason that the Cluster Timestamp element uses a numerical representation: It makes processing a lot easier. Best regards, Tobias From nobody Sat Nov 3 16:43:33 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3F8128766 for ; Sat, 3 Nov 2018 16:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHLEv0gn1YBT for ; Sat, 3 Nov 2018 16:43:31 -0700 (PDT) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD53127598 for ; Sat, 3 Nov 2018 16:43:31 -0700 (PDT) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:40327 helo=[10.0.1.17]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gJ5Zf-000aXq-3J; Sat, 03 Nov 2018 19:43:28 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Dave Rice In-Reply-To: <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> Date: Sat, 3 Nov 2018 19:43:25 -0400 Cc: cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> To: Tobias Rapp X-Mailer: Apple Mail (2.3445.100.39) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Nov 2018 23:43:32 -0000 > On Nov 2, 2018, at 5:31 AM, Tobias Rapp = wrote: >=20 > Hi Dave, >=20 > On 01.11.2018 15:03, Dave Rice wrote: >> [...] >> Here are a few use cases where I think this structure could be = helpful: >> =3D=3D=3D timecode >> We=E2=80=99ve made many starts and stops at defining how to store = timecode in Matroska but haven=E2=80=99t found consensus or resolution = on those attempts. With the Metadata Element I think a timecode value = could be stored such as >> Cluster/ >> Timestamp=3D01:00:00.000 >> BlockGroup/ >> Block/ >> ... >> Metadata/ >> MetadataName=3D=E2=80=9Ctimecode" >> MetadataString=3D"01:23:45;12=E2=80=9D >=20 > while I think that frame side data can be useful for the DPX scenario = mentioned later, I see problems with storing timecode information that = way. Shall timecode be attached to the video or audio track? Shall there = be some sub-classification for VITC/LTC/other timecode sources? >=20 > Also I would prefer the timecode value to be stored as a number = instead of a string representation, for the same reason that the Cluster = Timestamp element uses a numerical representation: It makes processing a = lot easier. If the structure is sufficient then perhaps is better discussed in how = to define the MetadataName values. For instance, we could define: MetadataName=3D=E2=80=9Ctimecode.s314m=E2=80=9D where MetadataBinary is set to a binary value as defined by SMPTE ST = 314M-2005 Sec 4.4.2.2.1 "Time code pack (TC)=E2=80=9D. In other thoughts on this suggestion, I think it could make it difficult = to easily understand if a file has a particular type of side data. For = instance if only a few Clusters somewhere in the Segment contain a = certain type of side data, it would require parsing every Cluster to = know what types of side data are available. This uncertainly wouldn=E2=80=99= t be the same issue if the side data was itself a Track. Dave From nobody Mon Nov 5 01:07:21 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C15112EB11 for ; Mon, 5 Nov 2018 01:07:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Hb_p3oUieSwL for ; Mon, 5 Nov 2018 01:07:17 -0800 (PST) Received: from mx01.mail.netstorage.at (mx01.mail.netstorage.at [89.207.144.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09FE2128CFD for ; Mon, 5 Nov 2018 01:07:16 -0800 (PST) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx01.mail.netstorage.at (Postfix) with ESMTPS id 8A495A03B0 for ; Mon, 5 Nov 2018 10:07:12 +0100 (CET) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 01D278176E for ; Mon, 5 Nov 2018 10:07:11 +0100 (CET) Received: from [127.0.0.1] (HSI-KBW-46-237-252-214.hsi.kabel-badenwuerttemberg.de [46.237.252.214]) by mailix with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128) ; Mon, 5 Nov 2018 10:07:12 +0100 To: cellar@ietf.org References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> From: Tobias Rapp Organization: NOA GmbH Message-ID: <83069618-2f88-eb00-4479-83fee6a564ab@noa-archive.com> Date: Mon, 5 Nov 2018 10:07:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20181105090712.15149.51864@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 09:07:20 -0000 On 04.11.2018 00:43, Dave Rice wrote: > >> On Nov 2, 2018, at 5:31 AM, Tobias Rapp wrote: >> >> [...] >> >> while I think that frame side data can be useful for the DPX scenario mentioned later, I see problems with storing timecode information that way. Shall timecode be attached to the video or audio track? Shall there be some sub-classification for VITC/LTC/other timecode sources? >> >> Also I would prefer the timecode value to be stored as a number instead of a string representation, for the same reason that the Cluster Timestamp element uses a numerical representation: It makes processing a lot easier. > > If the structure is sufficient then perhaps is better discussed in how to define the MetadataName values. For instance, we could define: > MetadataName=“timecode.s314m” > where MetadataBinary is set to a binary value as defined by SMPTE ST 314M-2005 Sec 4.4.2.2.1 "Time code pack (TC)”. I should clarify: Storing the timecode value as a _single_ number makes processing a lot easier. For example when you export a sub-range of your archived video file and have to shift timecode offset in the output file. Or when you change the video frame-rate for some reason. Both, the "01:23:45;12" timecode string and its binary representation are using some display-oriented format with mixed timebases (hours/minutes/seconds use a fixed timebase, framecount uses another timebase depending on the media). In our ingest system we use a separate XML file to store VITC/LTC values and first tried to store the SMPTE TC string but then switched to storing a microseconds number together with some hint for presentation "these values shall be rendered at 29.97 fps with drop-frame counting". > In other thoughts on this suggestion, I think it could make it difficult to easily understand if a file has a particular type of side data. For instance if only a few Clusters somewhere in the Segment contain a certain type of side data, it would require parsing every Cluster to know what types of side data are available. This uncertainly wouldn’t be the same issue if the side data was itself a Track. I would agree here. Best regards, Tobias From nobody Mon Nov 5 01:29:25 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52551277BB for ; Mon, 5 Nov 2018 01:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFWq_uDhhRVX for ; Mon, 5 Nov 2018 01:29:22 -0800 (PST) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (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 3FD701274D0 for ; Mon, 5 Nov 2018 01:29:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2018100901; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:In-reply-to:Subject:Cc:To:From:References; bh=aDe7HUiy182PjVwdfNvoj/MyXy23YRzQXhDIPDIoXYY=; b=tzHnF+emphpJqblE2/cMVw+5Lc78a6A7yS9SjfEk4S3/DWTd5WYQzf7K7o7hcHFICsgvba+R2M+Rzv6QQVlosfuXQVlfU2Gzi4W7AsinwtC2CT22MkL3ouwviflQqBWhF5EXI9zdVl1puemVJv0D5ZBb7oz/NGoLa0v9SvaQQBo=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:42112) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1gJbC1-0004G2-1j; Mon, 05 Nov 2018 10:29:09 +0100 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id E5948654000D; Mon, 5 Nov 2018 10:29:02 +0100 (CET) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 2613A4DC4D87; Mon, 5 Nov 2018 10:29:02 +0100 (CET) References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> User-agent: mu4e 1.0; emacs 26.1 From: Moritz Bunkus To: Dave Rice Cc: Tobias Rapp , cellar@ietf.org In-reply-to: <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> Date: Mon, 05 Nov 2018 10:29:02 +0100 Message-ID: <87r2fz7u01.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 09:29:24 -0000 Hey, > In other thoughts on this suggestion, I think it could make it difficult > to easily understand if a file has a particular type of side data. For > instance if only a few Clusters somewhere in the Segment contain a > certain type of side data, it would require parsing every Cluster to know > what types of side data are available. This uncertainly wouldn=E2=80=99t = be the > same issue if the side data was itself a Track. It's not entirely necessary to use a full track for side data. We can simply signal the presence of side data in the track headers and refer to it from the side data in the block groups. This would also mean we only have to store the string identifying the side data type once (in the track headers) instead of in each block. (I'll use "BlockMetadata" as the basis for all element names here. Initially I proposed "FrameMetadata", but "BlockMetadata" is fine with me, too.) For example: Tracks +- TrackEntry +- TrackBlockMetadata (Master) +- TrackBlockMetadataType (String, required) +- TrackBlockMetadataID (Unsigned Integer, required) =E2=80=A6 Cluster +- BlockGroup +- BlockMetadata (Master) +- BlockMetadataID (Unsigned Integer, required, refers to existing TrackBlockMetadataID in track headers) +- BlockMetadataString (Unicode String, optional) +- BlockMetadataBinary (Binary, optional) +- BlockMetadataUInteger (Unsigned Integer, optional) +- BlockMetadataSInteger (Signed Integer, optional) +- BlockMetadataFloat (Float, optional) with the restriction that exactly one of (BlockMetadataString, BlockMetadataBinary, BlockMetadataUInteger, BlockMetadataSInteger, BlockMetadataFloat) must exist. Advantages as I see them: =E2=80=A2 Less overhead (no repeated string parsing required) =E2=80=A2 Quicker parsing (no repeated string parsing required) =E2=80=A2 Presence of meta data is known upfront =E2=80=A2 Not using a full-blown track for meta data would alleviate the ne= ed to specify how all those track and block features (e.g. BlockDuration, TrackDefaultDuration=E2=80=A6) apply to a "meta data track". Kind regards, mosu From nobody Mon Nov 5 03:10:24 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AC8128DFD for ; Mon, 5 Nov 2018 03:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 5z3a_TE3lPfb for ; Mon, 5 Nov 2018 03:10:19 -0800 (PST) Received: from 3.mo178.mail-out.ovh.net (3.mo178.mail-out.ovh.net [46.105.44.197]) (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 B235712EB11 for ; Mon, 5 Nov 2018 03:10:19 -0800 (PST) Received: from player157.ha.ovh.net (unknown [10.109.146.1]) by mo178.mail-out.ovh.net (Postfix) with ESMTP id E36AB3CD92 for ; Mon, 5 Nov 2018 12:10:16 +0100 (CET) Received: from mediaarea.net (p3EE2DA4D.dip0.t-ipconnect.de [62.226.218.77]) (Authenticated sender: jerome@mediaarea.net) by player157.ha.ovh.net (Postfix) with ESMTPSA id 2CCD4100086 for ; Mon, 5 Nov 2018 12:10:15 +0100 (CET) To: cellar@ietf.org References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> <83069618-2f88-eb00-4479-83fee6a564ab@noa-archive.com> From: Jerome Martinez Message-ID: Date: Mon, 5 Nov 2018 12:10:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <83069618-2f88-eb00-4479-83fee6a564ab@noa-archive.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Ovh-Tracer-Id: 2672886379757441169 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrjeehgddvhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecu Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 11:10:22 -0000 On 05/11/2018 10:07, Tobias Rapp wrote: > I should clarify: Storing the timecode value as a _single_ number > makes processing a lot easier. [...] It adds another complexity: you need to transport somewhere else the configuration of this time code value (DP/NDP, frame rate). which is not always available, if I do e.g. realtime transcoding from SDI and catch SMPTE ST 12, I don't have immediately the frame rate (I need to wait for frame number going back to 0) so I would have to wait up to 1 second before writing the Matroska header if frame rate info is in track header. For reference MP4/MOV or MXF time codes use numbered values, SMPTE ST 12, SDTI in MXF or GXF use a format which is more like a string time code. strict conversion between time code format (especially keeping the user bytes) is not always doable. In my opinion we should not debate here of the best time code format (it would be in a metadata format registry, and both string time code and numbered time code may exist), just permit any of them so I like the proposal from Moritz, especially because I would use it too for RAWcooked the same way as with time code configuration in the track header for DP/NDP and frame rate info (if I store some RAWcooked configuration in the track header, I can improve a lot the comrpession of RAWcooked metadata). From nobody Mon Nov 5 03:20:15 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 683CC128DFD for ; Mon, 5 Nov 2018 03:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1zGcxLdUFqi for ; Mon, 5 Nov 2018 03:20:11 -0800 (PST) Received: from 18.mo3.mail-out.ovh.net (18.mo3.mail-out.ovh.net [87.98.172.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F660127133 for ; Mon, 5 Nov 2018 03:20:11 -0800 (PST) Received: from player798.ha.ovh.net (unknown [10.109.160.12]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id 9EBB31E70F4 for ; Mon, 5 Nov 2018 12:20:09 +0100 (CET) Received: from mediaarea.net (p3EE2DA4D.dip0.t-ipconnect.de [62.226.218.77]) (Authenticated sender: jerome@mediaarea.net) by player798.ha.ovh.net (Postfix) with ESMTPSA id 60E045400AA for ; Mon, 5 Nov 2018 12:20:08 +0100 (CET) To: cellar@ietf.org References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> <87r2fz7u01.fsf@bunkus.org> From: Jerome Martinez Message-ID: <2c9da243-26b0-6ae5-1fb8-0f0448e8728d@mediaarea.net> Date: Mon, 5 Nov 2018 12:20:09 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <87r2fz7u01.fsf@bunkus.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 2839801043706908817 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtkedrjeehgddvkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecu Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 11:20:13 -0000 On 05/11/2018 10:29, Moritz Bunkus wrote: > Hey, > >> In other thoughts on this suggestion, I think it could make it difficult >> to easily understand if a file has a particular type of side data. For >> instance if only a few Clusters somewhere in the Segment contain a >> certain type of side data, it would require parsing every Cluster to know >> what types of side data are available. This uncertainly wouldn’t be the >> same issue if the side data was itself a Track. > It's not entirely necessary to use a full track for side data. We can simply > signal the presence of side data in the track headers and refer to it from > the side data in the block groups. This would also mean we only have to > store the string identifying the side data type once (in the track headers) > instead of in each block. It would permit more efficient storage, but IMO it should be optional only, because if we do real time transcoding to MKV we don't have always all sidecar info. I have in mind some A/V content with ancillary data coming only after few minutes, without any change in A/V part. > > (I'll use "BlockMetadata" as the basis for all element names > here. Initially I proposed "FrameMetadata", but "BlockMetadata" is fine > with me, too.) I prefer also "BlockMetadata" due to here is located the element. > > For example: > > Tracks > +- TrackEntry > +- TrackBlockMetadata (Master) > +- TrackBlockMetadataType (String, required) > +- TrackBlockMetadataID (Unsigned Integer, required) Please add:  +- TrackBlockMetadataPrivate (Binary, optional) Would have the same usage as CodecPrivate but for metadata. > > … > > Cluster > +- BlockGroup > +- BlockMetadata (Master) > +- BlockMetadataID (Unsigned Integer, required, refers to existing > TrackBlockMetadataID in track headers) Here I suggest to keep something like current PR "BlockMetadataName" and the restriction that  that exactly one of (BlockMetadataID , BlockMetadataName) must exist. This would be even more complex but IMO more versatile. > [...] From nobody Mon Nov 5 03:30:25 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0260127133 for ; Mon, 5 Nov 2018 03:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bunkus.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sueRJb_EZzwD for ; Mon, 5 Nov 2018 03:30:21 -0800 (PST) Received: from adara.bunkus.org (adara.bunkus.org [144.76.6.84]) (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 A310E12958B for ; Mon, 5 Nov 2018 03:30:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bunkus.org; s=mail2018100901; h=Content-Type:MIME-Version:Message-ID:Date:In-reply-to:Subject:Cc:To:From:References; bh=hdpDpYQY2zkSEHnQAbYWmboqMRU+XaPk603k0LhR47Y=; b=Sh7CowgBU+rW6z6zUjkFkWyNbUAhpCIeMstxxy8FdFZmRQvJ3NgMyT9pS9y0y+bjrp90R3/mm3na3DT4S4IM8oM/xwgi9XNtYxbIywOOZMVNGHEnNsIRg2oP4h75SOC7plc+PYQgSGJixembzpNh7wkaryxG/PAKSy0tI5w75Wc=; Received: from liselle.bunkus.org ([2a01:4f8:190:8147::105:1]:44944) by adara.bunkus.org with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1gJd59-00075Q-1x; Mon, 05 Nov 2018 12:30:11 +0100 Received: from sweet-chili.local (unknown [192.168.191.4]) by liselle.bunkus.org (Postfix) with ESMTPS id 1F1D16540017; Mon, 5 Nov 2018 12:30:04 +0100 (CET) Received: from sweet-chili (localhost [IPv6:::1]) by sweet-chili.local (Postfix) with ESMTP id 0D3F24DC624A; Mon, 5 Nov 2018 12:30:03 +0100 (CET) References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> <87r2fz7u01.fsf@bunkus.org> <2c9da243-26b0-6ae5-1fb8-0f0448e8728d@mediaarea.net> User-agent: mu4e 1.0; emacs 26.1 From: Moritz Bunkus To: Jerome Martinez Cc: cellar@ietf.org In-reply-to: <2c9da243-26b0-6ae5-1fb8-0f0448e8728d@mediaarea.net> Date: Mon, 05 Nov 2018 12:30:03 +0100 Message-ID: <87pnvj7oec.fsf@bunkus.org> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 11:30:24 -0000 Hey, > Please add: > +- TrackBlockMetadataPrivate (Binary, optional) Sure, that's useful. > Here I suggest to keep something like current PR "BlockMetadataName" and > the restriction that that exactly one of (BlockMetadataID , > BlockMetadataName) must exist. Sure. I wasn't trying to write down the full specs; just enough to have something to discuss. That restriction is already present in Dave's PR, and I'm all for keeping it. Kind regards, mosu From nobody Mon Nov 5 07:41:28 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82E26130DF2 for ; Mon, 5 Nov 2018 07:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 VROKDksR5tgK for ; Mon, 5 Nov 2018 07:41:23 -0800 (PST) Received: from mx01.mail.netstorage.at (mx01.mail.netstorage.at [IPv6:2a02:2410:b000:101:3000::c]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A88C4130DE6 for ; Mon, 5 Nov 2018 07:41:22 -0800 (PST) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) by mx01.mail.netstorage.at (Postfix) with ESMTPS id 4A026A044F for ; Mon, 5 Nov 2018 16:41:17 +0100 (CET) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id C9F2D816A3 for ; Mon, 5 Nov 2018 16:41:16 +0100 (CET) Received: from [192.168.0.103] (HSI-KBW-46-237-252-214.hsi.kabel-badenwuerttemberg.de [46.237.252.214]) by mailix with ESMTPSA (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128) ; Mon, 5 Nov 2018 16:41:16 +0100 To: cellar@ietf.org References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> <83069618-2f88-eb00-4479-83fee6a564ab@noa-archive.com> From: Tobias Rapp Organization: NOA GmbH Message-ID: Date: Mon, 5 Nov 2018 16:41:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20181105154117.8787.1041@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2018 15:41:27 -0000 On 05.11.2018 12:10, Jerome Martinez wrote: > On 05/11/2018 10:07, Tobias Rapp wrote: >> I should clarify: Storing the timecode value as a _single_ number >> makes processing a lot easier. [...] > > It adds another complexity: you need to transport somewhere else the > configuration of this time code value (DP/NDP, frame rate). I would say that the complexity is just shifted from read to write side. It depends on the assumed balance of write and read (archive vs. reuse, ingest vs. outgest) whether to see this as adding or removing complexity. > which is not always available, if I do e.g. realtime transcoding from > SDI and catch SMPTE ST 12, I don't have immediately the frame rate (I > need to wait for frame number going back to 0) so I would have to wait > up to 1 second before writing the Matroska header if frame rate info is > in track header. You could reserve some space in the header to write the frame-rate information later. > For reference MP4/MOV or MXF time codes use numbered values, SMPTE ST > 12, SDTI in MXF or GXF use a format which is more like a string time > code. strict conversion between time code format (especially keeping the > user bytes) is not always doable. > > In my opinion we should not debate here of the best time code format (it > would be in a metadata format registry, and both string time code and > numbered time code may exist), just permit any of them so I like the > proposal from Moritz, especially because I would use it too for > RAWcooked the same way as with time code configuration in the track > header for DP/NDP and frame rate info (if I store some RAWcooked > configuration in the track header, I can improve a lot the comrpession > of RAWcooked metadata). > Indeed the timecode format is of second interest (even though implementation of multiple formats also adds complexity). The idea of adding general metadata for each frame is nice, and storing DPX tags into it is fine. But I wouldn't store timecode that way, regardless of the serialization format. When you want to seek to a specific timecode position you have to read all frame metadata in advance. If timecode is stored separately, possibly as an own track, it allows you to do the mapping from timecode to timestamp first and then use the cue table to perform the locate operation efficiently. Regards, Tobias From nobody Thu Nov 8 07:07:43 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1D3128CE4 for ; Thu, 8 Nov 2018 07:07:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.87 X-Spam-Level: X-Spam-Status: No, score=0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHZjWR07UMvY for ; Thu, 8 Nov 2018 07:07:40 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17BE8128CF2 for ; Thu, 8 Nov 2018 07:07:40 -0800 (PST) Received: from [146.96.19.240] (port=50200 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gKluD-000YW1-1j for cellar@ietf.org; Thu, 08 Nov 2018 10:07:39 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_AFB9DF4F-0EAB-4510-8DB9-3D7EA95AEDC6" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Thu, 8 Nov 2018 10:07:33 -0500 To: Cellar list X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-0.4 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] WIP FFV1 upgrade from xml2rfc v2 to v3 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2018 15:07:42 -0000 --Apple-Mail=_AFB9DF4F-0EAB-4510-8DB9-3D7EA95AEDC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I drafted a pull request at https://github.com/FFmpeg/FFV1/pull/135 = which upgrades from the use of = xml2rfc version 2 (with mmark and xml2rfc) to xml2rfc version 3. The = pull request addresses some changes to accommodate this while preserving = the semantics as some markdown features we used are no longer supported = in the new xml2rfc. Version 3 also supports svg images for = representation of mathematical formula. Thus the Makefile requires some = new dependencies in pdfcrop and pdf2svg in order to produce embeddable = svg images. A representation of the HTML RFC output is available at = https://htmlpreview.github.io/?https://gist.githubusercontent.com/dericed/= 5ce9c949eeec9042a4ac5e2b222f1cc0/raw/b315b8d3f5c4b06ecf656fc1fb7e9ad9bd6fd= 88c/draft-ietf-cellar-ffv1-06.html = . I haven=E2=80=99t seen rfc2xml = version 3 much used in IETF yet though so am uncertain of how this = impacts or will impact the document management process. Comments welcome. Dave Rice --Apple-Mail=_AFB9DF4F-0EAB-4510-8DB9-3D7EA95AEDC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

I = drafted a pull request at https://github.com/FFmpeg/FFV1/pull/135 which = upgrades from the use of xml2rfc version 2 (with mmark and xml2rfc) to = xml2rfc version 3. The pull request addresses some changes to = accommodate this while preserving the semantics as some markdown = features we used are no longer supported in the new xml2rfc. Version 3 = also supports svg images for representation of mathematical formula. = Thus the Makefile requires some new dependencies in pdfcrop and pdf2svg = in order to produce embeddable svg images.

A representation of the HTML RFC output = is available at https://htmlpreview.github.io/?https://gist.githubusercontent.c= om/dericed/5ce9c949eeec9042a4ac5e2b222f1cc0/raw/b315b8d3f5c4b06ecf656fc1fb= 7e9ad9bd6fd88c/draft-ietf-cellar-ffv1-06.html. I haven=E2=80=99t = seen rfc2xml version 3 much used in IETF yet though so am uncertain of = how this impacts or will impact the document management = process.

Comments welcome.

Dave Rice

= --Apple-Mail=_AFB9DF4F-0EAB-4510-8DB9-3D7EA95AEDC6-- From nobody Sun Nov 11 07:07:11 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F8112785F for ; Sun, 11 Nov 2018 07:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF_-cCJQOcD2 for ; Sun, 11 Nov 2018 07:07:08 -0800 (PST) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 C038D12777C for ; Sun, 11 Nov 2018 07:07:08 -0800 (PST) Received: by mail-pl1-x62e.google.com with SMTP id b5-v6so3078285pla.6 for ; Sun, 11 Nov 2018 07:07:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=27ZgOGtepLA7lzBWb60cdN/YSxAg4NJIZCSucK71EjY=; b=Zc7f/JQiuNjX5OaS/eTC7D0u+GKPDn8tiF3ZP4+K8W2ZReGOlUWQW2sST9ynXvRRI1 1QBdT8W2dowSB976EB9w8hUTT0rXjJB9hDrboUcjhnKs1QO/a7J9vAgEe32RHwt6gqTq fMItQGLew48ww8Vi6UIDC6i1uvSi99+A1dF/X31D0AgezhsZmnznpgtb1JeU36Sy/Mg/ D4ZeJFLrHEJpUEARgHFV8gIG0OXcTFHVMb1cr++XsCukH9YsjSJGGuo/EOEoMwVypYbt /0Ymx0kn9e2vWU197HKLiks3wOEtJhsiBafwq14fGXDZYbboG3938vj4ysykNk1QyWAL KAjg== 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=27ZgOGtepLA7lzBWb60cdN/YSxAg4NJIZCSucK71EjY=; b=WNbjr1YYk2/Z2ZmX7CdZ8iL+1CbV4HUqACgqr13PtV35Xk6ULf6X6Sonkeu4COL6y1 +c1PPlC2wkZ4IkpMSD+/Uiqv09fdQ5qsRX2fzwTSMnh4vxdeX0baKzOLyvEHU1gxmnIA 7Y1L7+hVJSDFoM4IibMxQUaT7YfRZHqjgOvZHkrTwe8waApW+4gE32ZtQFDzPBj9lLz5 4tbAgJuDNDS3QNO80Q/JSbsmOoYV+NxsvamngkBAoTkUP231VFwGRpniSgbn8IleS7y3 4R7rXRhpiYguxpX5JUikftejImfBH3jz6BkYe0dSZkd9mnvtZdnlKAMzI4zYXgcK0sBu hmwQ== X-Gm-Message-State: AGRZ1gKVPlFAcvZJCPG61iiV4h5nwmI3eabbTpUR0eN2tU88GYVfy4E+ lJUBl/YNjRFTtrgX8pIh7/R9ya3Fu/QSNk2p4Y3V8BazRpk= X-Google-Smtp-Source: AJdET5emtbHHJV/X29sz0PJ8/MKkAOuXLimA3blR3mfQ5g1srtE3KqKiHfa9xtqo/Bk+gctqoLd+j9OmqxmUezp3HOE= X-Received: by 2002:a17:902:544:: with SMTP id 62-v6mr15699629plf.73.1541948828136; Sun, 11 Nov 2018 07:07:08 -0800 (PST) MIME-Version: 1.0 From: Steve Lhomme Date: Sun, 11 Nov 2018 16:06:57 +0100 Message-ID: To: Matroska Devel , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cellar] Spec update X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 11 Nov 2018 15:07:10 -0000 Recently I updated the specs on matroska.org. I updated the spectools found in github to use the ebml_matroska.xml instead of a local source file that we used until now. So now the specs on matroska.org can be keep in sync with the CELLAR version. I used the opportunity to reformat things more cleanly, especially regarding to enums. The reason I did this is because a lot of people are still looking there for Matroska information. And so it's better to reflect the recent changes and additions. I also noticed the links to the DivX extensions spec are now dead and nowhere to be found... So we should probably remove them for good. -- Steve Lhomme Matroska association Chairman From nobody Sun Nov 11 07:40:53 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CD87128CB7 for ; Sun, 11 Nov 2018 07:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-_WqQL1asiB for ; Sun, 11 Nov 2018 07:40:49 -0800 (PST) Received: from mail-pg1-x542.google.com (mail-pg1-x542.google.com [IPv6:2607:f8b0:4864:20::542]) (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 0C4A812785F for ; Sun, 11 Nov 2018 07:40:48 -0800 (PST) Received: by mail-pg1-x542.google.com with SMTP id f8-v6so2908352pgq.5 for ; Sun, 11 Nov 2018 07:40:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=1YQFKK025+s9nTkgeTPPpVwirtXrnx1Yb945I7N/0J4=; b=eVlXFWuSCVGB4BAuDIwwetP1pDuPfGc2XwlTwAXNC/yl2gTi2/XTUZscZ0L5DmKGno I4RR58c0yMTD/suTvUlDC6Gk1JohgcCB53At/pD6KMvsEdB4eLGHaihKVvXBDu8nb0g4 SdYOg6QObRU767hebIQMnYH3IiKcV79UbV9JuMCc3BF3qMBiYzCp1Lcw8wOaWsd1ETBl KqIYBP1Q8TGNqHcBzQWGz3jg7wkfpLgZvXjCt0szFufRk42IRH59FVm4Q5ApS3/pbhIS cVIC1J+biPxYx58SGqRNTy+xj/ysOD5qrXx6D7yyugDqyTcY17DHDn3+nlTiFfhYNn+l ozuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=1YQFKK025+s9nTkgeTPPpVwirtXrnx1Yb945I7N/0J4=; b=Nn9yn99FUlgzTOwhjmLRsONTJQDAyMIBMvlqXiwT/U7Tt6ggHsuaTdCUKSojkJp9Q5 CeQynN1jBTcnoHOl75HBhjX8cpINn/AFN++x60C61Ilu++ffWZCKOY3bFZibDz3WhK+M bmxPFtxHrHRWfR4sNzHCVoMofH9BDiVUjiRuRRetZk19mdP5Turku2jERQs4Lq1Vr8cE NSqiPuFKhs221m/dmiqG0WG2WtRH3D3gMWel+h/MD1LuAuChpxLoQoOTSMCKbOHvSrM2 WDj+KrvAi06BA82iDFtOb+EeuVfiDckmNTCLVOdIGy2m6EegamKrTCStu+LJZw5KwW7N RVEg== X-Gm-Message-State: AGRZ1gKcCGMRiCeeRXuboU14O0SP3PeB9LhlUJH/zN6bVm5wzh6y5c+2 fzbVd7UkjhB7dbnkVgKg8y7JJtu71og3m+bdZQ8VQpWoZsGHFQ== X-Google-Smtp-Source: AJdET5elxvUIS2MlKyIoWfJBFvj2ZjukrtLOP/mR9PHuY3xOfEMEOs1esExR+AUo/mjl05aPc0sXpy476l1ogBkbT5M= X-Received: by 2002:aa7:818a:: with SMTP id g10-v6mr16622087pfi.153.1541950848307; Sun, 11 Nov 2018 07:40:48 -0800 (PST) MIME-Version: 1.0 References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> <87r2fz7u01.fsf@bunkus.org> In-Reply-To: <87r2fz7u01.fsf@bunkus.org> From: Steve Lhomme Date: Sun, 11 Nov 2018 16:40:36 +0100 Message-ID: To: Moritz Bunkus Cc: Dave Rice , Codec Encoding for LossLess Archiving and Realtime transmission , Tobias Rapp Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 11 Nov 2018 15:40:53 -0000 I would go with the Track way as well. Primarily because storing a string (which pretty much never changes) in each Block is a huge waste. Add extra data per Block is already supported using BlockAdditions. There's already BlockAddID which correspond to Moritz' BlockMetadataID and BlockAdditional which correspond to BlockMetadataString / BlockMetadataBinary / BlockMetadataUInteger / BlockMetadataSInteger / BlockMetadataFloat. It's like a codec where the CodecID defines how the data in the binary blob should be interpreted. The current system states that the additions are left to interpretation to the codec. It was originally designed to hold the lossless complement to lossy versions of Musepack. So in that case it's really meant to be passed to the codec. I think we can expand this system with keeping this default behaviour by default (albeit not used anywhere) and have different ones on demand. There's also an AlphaMode that also uses BlockAdditions to store the alpha track. Which pretty much no info on how to do it.... As noted timecode may be a separate track (as originally intended) if it is not related to the video frames (ie the timestamps doesn't match). This would look like this: - Musepack lossless complement: Segment\Tracks\TrackEntry\MaxBlockAdditionID: 1 Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 1 (same as BlockAddID) (default) Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: "complement" (default) Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: 0 (Codec Complement data) (default) Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 1 Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: lossless part interpreted by the codec - Alpha layer: Segment\Tracks\TrackEntry\MaxBlockAdditionID: 2 Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 2 (same as BlockAddID) Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: "alpha" Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: 1 (Alpha layer data) Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 2 Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: alpha mask to apply on the video track - RawCooked DPX data Segment\Tracks\TrackEntry\MaxBlockAdditionID: 3 Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 3 (same as BlockAddID) Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: "rawcooked" Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: 0x1234567 (rawcooked identifier) Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 3 Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: DPX data defined by RawCooked - Timecode storing Segment\Tracks\TrackEntry\MaxBlockAdditionID: 3 Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 3 (same as BlockAddID) Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: "timecode" Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: 0x890ABCD (SMPTE TC identifier, can be another ID for different kind of timecode) Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 3 Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: Timecode storage That means the alpha mode would not be backward compatible with existing files, because it requires non default values. But I don't think anyone ever used this improperly defined feature. The value of MaxBlockAdditionID is kept low on purpose. BlockAddID 1 was always for codec complement and thus 2 for the AlphaMode. But we don't need to go much higher that than now that we have a mapping. If there are Timecode AND Rawcooked it would be like this: Segment\Tracks\TrackEntry\MaxBlockAdditionID: 4 Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 3 Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: "rawcooked" Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: 0x1234567 (rawcooked identifier) Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 4 Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: "timecode" Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: 0x890ABCD (SMPTE TC identifier, can be another ID for different kind of timecode) Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 3 Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: DPX data defined by RawCooked Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 4 Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: Timecode storage Le lun. 5 nov. 2018 =C3=A0 10:29, Moritz Bunkus a =C3=A9crit : > > Hey, > > > In other thoughts on this suggestion, I think it could make it difficul= t > > to easily understand if a file has a particular type of side data. For > > instance if only a few Clusters somewhere in the Segment contain a > > certain type of side data, it would require parsing every Cluster to kn= ow > > what types of side data are available. This uncertainly wouldn=E2=80=99= t be the > > same issue if the side data was itself a Track. > > It's not entirely necessary to use a full track for side data. We can sim= ply > signal the presence of side data in the track headers and refer to it fro= m > the side data in the block groups. This would also mean we only have to > store the string identifying the side data type once (in the track header= s) > instead of in each block. > > (I'll use "BlockMetadata" as the basis for all element names > here. Initially I proposed "FrameMetadata", but "BlockMetadata" is fine > with me, too.) > > For example: > > Tracks > +- TrackEntry > +- TrackBlockMetadata (Master) > +- TrackBlockMetadataType (String, required) > +- TrackBlockMetadataID (Unsigned Integer, required) > > =E2=80=A6 > > Cluster > +- BlockGroup > +- BlockMetadata (Master) > +- BlockMetadataID (Unsigned Integer, required, refers to existing > TrackBlockMetadataID in track headers) > +- BlockMetadataString (Unicode String, optional) > +- BlockMetadataBinary (Binary, optional) > +- BlockMetadataUInteger (Unsigned Integer, optional) > +- BlockMetadataSInteger (Signed Integer, optional) > +- BlockMetadataFloat (Float, optional) > > with the restriction that exactly one of (BlockMetadataString, > BlockMetadataBinary, BlockMetadataUInteger, BlockMetadataSInteger, > BlockMetadataFloat) must exist. > > Advantages as I see them: > > =E2=80=A2 Less overhead (no repeated string parsing required) > =E2=80=A2 Quicker parsing (no repeated string parsing required) > =E2=80=A2 Presence of meta data is known upfront > =E2=80=A2 Not using a full-blown track for meta data would alleviate the = need to > specify how all those track and block features (e.g. BlockDuration, > TrackDefaultDuration=E2=80=A6) apply to a "meta data track". > > Kind regards, > mosu > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Nov 11 15:15:42 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA36F130DD1 for ; Sun, 11 Nov 2018 15:15: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 C6Gg9K2kUrQL for ; Sun, 11 Nov 2018 15:15:38 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDCF1128CE4 for ; Sun, 11 Nov 2018 15:15:38 -0800 (PST) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:45189 helo=[10.0.1.17]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gLyx1-001o75-OC; Sun, 11 Nov 2018 18:15:35 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Dave Rice In-Reply-To: Date: Sun, 11 Nov 2018 18:15:30 -0500 Cc: Moritz Bunkus , Codec Encoding for LossLess Archiving and Realtime transmission , Tobias Rapp Content-Transfer-Encoding: quoted-printable Message-Id: <69462008-FABB-476E-8032-EEE21A832A9B@dericed.com> References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> <87r2fz7u01.fsf@bunkus.org> To: Steve Lhomme X-Mailer: Apple Mail (2.3445.100.39) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 11 Nov 2018 23:15:41 -0000 Hi Steve, Initially I looked at the BlockAdditions Element as a possibility to = store side data, but the definition didn=E2=80=99t seem to allow it. = Since the specification defers to the encoding ("Interpreted by the = codec as it wishes=E2=80=9D) there doesn=E2=80=99t seem to be any way = for the Matroska specification to define a BlockAdditionalID value = (except for 0 which is reserved as a reference to the main block).=20 However, this approach works for me if others accept the break in = reverse compatibility. Several other definitions would require updates. Currently we have: BlockAdditions: "Contain additional blocks to complete the main one. An = EBML parser that has no knowledge of the Block structure could still see = and use/skip these data.=E2=80=9D BlockAddID: "An ID to identify the BlockAdditional level.=E2=80=9D=20 BlockAdditional: "Interpreted by the codec as it wishes (using the = BlockAddID)." AlphaMode: "Alpha Video Mode. Presence of this Element indicates that = the BlockAdditional Element could contain Alpha data.=E2=80=9D Notes about what definition updates would be needed: BlockAdditions=E2=80=99s definition would have to be rewritten as the = data wouldn=E2=80=99t necessarily =E2=80=9Ccomplete=E2=80=9D the main = block but might alternatively supplement it or describe it. BlockAddID should include an enumerated list of integers and reference a = registry on what each value means. BlockAdditional=E2=80=99s definition would have to be updated, since = only in some cases would the BlockAddition content be interpreted by the = codec. AlphaMode=E2=80=99s definition seems to imply that one of the = BlockAdditional Elements contains alpha but gives no way to identify = which one, so this is the largest reverse compatibility issue. Are there = Matroska demuxers which would try to use timecode or rawcooked data as = if it was alpha data? So IIUC BlockAddID=3D1 is reserved for the context of the associated = codec mapping (as done in A_WAVPACK4). Then we reserve BlockAddID=3D2 = for alpha and 0 is reserved since BlockAdditionID uses 0 to reference = the main block. Then any other type of data for storage in = BlockAdditional would use the next available unsigned integer from 3 and = would require an BlockAdditionMapping. I suggest that BlockAddId =3D 0, = 1 and 2 would not require a BlockAdditionMapping since the specification = would reserve them for particular purpose. But if we already define BlockAddId for 0, 1, and 2 in the specification = then why not continue and reserve 3 for rawcooked and 4 for timecode and = so on. That would avoid the need for storing that data in = BlockAdditionMapping, eliminate the need for new BlockAdditionMapping = elements, and then demuxers could understand if they can use that data = by simply checking the BlockAddId rather than looking up the = corresponding value in BlockAddIDName. Also what is the need for MaxBlockAdditionID? And what is the reason to = keep BlockAdditionID low, simply to keep it to a single byte? Dave > On Nov 11, 2018, at 10:40 AM, Steve Lhomme = wrote: >=20 > I would go with the Track way as well. Primarily because storing a > string (which pretty much never changes) in each Block is a huge > waste. >=20 > Add extra data per Block is already supported using BlockAdditions. > There's already BlockAddID which correspond to Moritz' BlockMetadataID > and BlockAdditional which correspond to BlockMetadataString / > BlockMetadataBinary / BlockMetadataUInteger / BlockMetadataSInteger / > BlockMetadataFloat. It's like a codec where the CodecID defines how > the data in the binary blob should be interpreted. >=20 > The current system states that the additions are left to > interpretation to the codec. It was originally designed to hold the > lossless complement to lossy versions of Musepack. So in that case > it's really meant to be passed to the codec. I think we can expand > this system with keeping this default behaviour by default (albeit not > used anywhere) and have different ones on demand. > There's also an AlphaMode that also uses BlockAdditions to store the > alpha track. Which pretty much no info on how to do it.... >=20 > As noted timecode may be a separate track (as originally intended) if > it is not related to the video frames (ie the timestamps doesn't > match). >=20 > This would look like this: > - Musepack lossless complement: > Segment\Tracks\TrackEntry\MaxBlockAdditionID: 1 > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 1 > (same as BlockAddID) (default) > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: > "complement" (default) > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: 0 > (Codec Complement data) (default) > Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 1 > Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: > lossless part interpreted by the codec >=20 > - Alpha layer: > Segment\Tracks\TrackEntry\MaxBlockAdditionID: 2 > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 2 > (same as BlockAddID) > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: "alpha" > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: 1 > (Alpha layer data) > Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 2 > Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: > alpha mask to apply on the video track >=20 > - RawCooked DPX data > Segment\Tracks\TrackEntry\MaxBlockAdditionID: 3 > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 3 > (same as BlockAddID) > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: = "rawcooked" > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: > 0x1234567 (rawcooked identifier) > Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 3 > Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: > DPX data defined by RawCooked >=20 > - Timecode storing > Segment\Tracks\TrackEntry\MaxBlockAdditionID: 3 > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 3 > (same as BlockAddID) > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: = "timecode" > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: > 0x890ABCD (SMPTE TC identifier, can be another ID for different kind > of timecode) > Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 3 > Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: > Timecode storage >=20 > That means the alpha mode would not be backward compatible with > existing files, because it requires non default values. But I don't > think anyone ever used this improperly defined feature. >=20 > The value of MaxBlockAdditionID is kept low on purpose. BlockAddID 1 > was always for codec complement and thus 2 for the AlphaMode. But we > don't need to go much higher that than now that we have a mapping. If > there are Timecode AND Rawcooked it would be like this: > Segment\Tracks\TrackEntry\MaxBlockAdditionID: 4 > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 3 > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: = "rawcooked" > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: > 0x1234567 (rawcooked identifier) > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 4 > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: = "timecode" > Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: > 0x890ABCD (SMPTE TC identifier, can be another ID for different kind > of timecode) > Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 3 > Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: > DPX data defined by RawCooked > Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 4 > Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: > Timecode storage >=20 > Le lun. 5 nov. 2018 =C3=A0 10:29, Moritz Bunkus > a =C3=A9crit : >>=20 >> Hey, >>=20 >>> In other thoughts on this suggestion, I think it could make it = difficult >>> to easily understand if a file has a particular type of side data. = For >>> instance if only a few Clusters somewhere in the Segment contain a >>> certain type of side data, it would require parsing every Cluster to = know >>> what types of side data are available. This uncertainly wouldn=E2=80=99= t be the >>> same issue if the side data was itself a Track. >>=20 >> It's not entirely necessary to use a full track for side data. We can = simply >> signal the presence of side data in the track headers and refer to it = from >> the side data in the block groups. This would also mean we only have = to >> store the string identifying the side data type once (in the track = headers) >> instead of in each block. >>=20 >> (I'll use "BlockMetadata" as the basis for all element names >> here. Initially I proposed "FrameMetadata", but "BlockMetadata" is = fine >> with me, too.) >>=20 >> For example: >>=20 >> Tracks >> +- TrackEntry >> +- TrackBlockMetadata (Master) >> +- TrackBlockMetadataType (String, required) >> +- TrackBlockMetadataID (Unsigned Integer, required) >>=20 >> =E2=80=A6 >>=20 >> Cluster >> +- BlockGroup >> +- BlockMetadata (Master) >> +- BlockMetadataID (Unsigned Integer, required, refers to existing >> TrackBlockMetadataID in track headers) >> +- BlockMetadataString (Unicode String, optional) >> +- BlockMetadataBinary (Binary, optional) >> +- BlockMetadataUInteger (Unsigned Integer, optional) >> +- BlockMetadataSInteger (Signed Integer, optional) >> +- BlockMetadataFloat (Float, optional) >>=20 >> with the restriction that exactly one of (BlockMetadataString, >> BlockMetadataBinary, BlockMetadataUInteger, BlockMetadataSInteger, >> BlockMetadataFloat) must exist. >>=20 >> Advantages as I see them: >>=20 >> =E2=80=A2 Less overhead (no repeated string parsing required) >> =E2=80=A2 Quicker parsing (no repeated string parsing required) >> =E2=80=A2 Presence of meta data is known upfront >> =E2=80=A2 Not using a full-blown track for meta data would alleviate = the need to >> specify how all those track and block features (e.g. BlockDuration, >> TrackDefaultDuration=E2=80=A6) apply to a "meta data track". >>=20 >> Kind regards, >> mosu >>=20 >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman From nobody Mon Nov 12 07:38:25 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB141130E47 for ; Mon, 12 Nov 2018 07:38:23 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BLLalDIaBKd for ; Mon, 12 Nov 2018 07:38:21 -0800 (PST) Received: from mail-wm1-x341.google.com (mail-wm1-x341.google.com [IPv6:2a00:1450:4864:20::341]) (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 7C2BA12D4E8 for ; Mon, 12 Nov 2018 07:38:20 -0800 (PST) Received: by mail-wm1-x341.google.com with SMTP id z8-v6so2388578wma.5 for ; Mon, 12 Nov 2018 07:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=fS72Kaj/o66gWuKbCTyRaxS5b5NEJBkxpkv+X9TH80Q=; b=Zf5RFXWcQnsECxyvAOsuaqHx2LYXgWRvESaPLiRQ2keNW0Wa4NBGZ2GieCZZj8bzoO n6lEqljc2njTpuK5khmC1qSZF4jlrgj0/2ESYG6LMRBGm2vd5tflVnILKy+wdTN+ZT/q se1HD49CLvTA4/tR0RvmVulXtKdzDmBaAll6c5wmZZYb1MVMn/Ab8TuRBebRR9+7Q6pR SfVJD6UszaoaS557U15F6cF8N2QDb58Hw84MaUuunnjkvTlnH7YmSlVMR42hNy3ait5N g/KMJm518FygPJ+6lN127Iqb9aZ7e7Se0ZO8I/1bZQI8S4oEi8BjVmzlFK7zWajkpCQ0 A1iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=fS72Kaj/o66gWuKbCTyRaxS5b5NEJBkxpkv+X9TH80Q=; b=U8Y9iCGwX7qtCzH/sGC/kqRqnjCuySvC1Wpviy8sJUqIgIxcsuaVMc4e80RzQs+7Sr Nb4i7V1lvweVkL6FY2JiSERemLFNqV6EY/JLLCvOmkrAEc5QwWTH2CMxlT5Q+QaDjw+k 5hP0Xi3oy/90qxzTwuunGWdrhNUcfd2DEh28KkpEG4tzV09oTYFfT3g0G7NBbnDxxoMj ESacWEsGmFxcyf/PwC2/hL8jphhDglr0qc0K2Jx3iaEBe8eAJKOUXlgbI5zP3YKrEfy9 Yl24mpOE1e0b513CF3ZkmaLrNt3zClvy4rbM60Thh5owOmIkX2nvoJxhyjxzN9x/nCPX IpHw== X-Gm-Message-State: AGRZ1gIb+WuhhSiE4FTD1aS5Q5D9o0Ko0H/98DcaJQLnc8bcNWpPNAf1 8NS5WmoC3hJgkYdHQuYIQ/vJU6kTpi8vPg== X-Google-Smtp-Source: AJdET5cymFqpaTkFm1trDUfmfmX7k48Nz+kA4oZECxRDrD1ut0DI/NG9a8n3VEvhioIJOSJ7/0yBdg== X-Received: by 2002:a1c:c46:: with SMTP id 67-v6mr138715wmm.6.1542037098442; Mon, 12 Nov 2018 07:38:18 -0800 (PST) Received: from [192.168.3.19] (229.74.9.109.rev.sfr.net. [109.9.74.229]) by smtp.gmail.com with ESMTPSA id 66-v6sm9641798wmp.28.2018.11.12.07.38.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Nov 2018 07:38:16 -0800 (PST) To: cellar@ietf.org Cc: Tobias Rapp References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> <87r2fz7u01.fsf@bunkus.org> <69462008-FABB-476E-8032-EEE21A832A9B@dericed.com> From: Steve Lhomme Message-ID: <40cfae4a-fff9-8153-7116-08a2f59aef75@matroska.org> Date: Mon, 12 Nov 2018 16:38:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <69462008-FABB-476E-8032-EEE21A832A9B@dericed.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 15:38:24 -0000 Just as I double check this, it turns out WebM has support for the AlphaMode and all the BlockAddition that goes with it. https://www.webmproject.org/docs/container/ I have no idea how this can even work, except it must be tied to VP8 and VP9 internals. So it is also extra data added per frame. I'd be interested in a sample making use of that. They don't even support MaxBlockAdditionID, so technically the value is 0 for them. I just hope they don't use BlockAddId 0, it is a forbidden value. If not it's probably a value of 1 but not 2. I found this sample which uses a value of 1 https://examples.phaser.io/assets/video/alpha-webm.webm So we can assume 1 is really for "codec interpreted data" and all the other are freely interpreted. In addition of Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName and Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType we may also add a Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDExtraData which could hold extra information for the given type. For example the type of timecode format for the given format. MaxBlockAdditionID is there to signal that there will be extra data in the header of the file, since there was no other way of knowing. It's not used in WebM but they have AlphaMode (which we will need to keep as well). As for hardcoding BlockAddIDType in the specs we can do it. But we need to allow more values anyway. On 12/11/2018 00:15, Dave Rice wrote: > Hi Steve, > > Initially I looked at the BlockAdditions Element as a possibility to store side data, but the definition didn’t seem to allow it. Since the specification defers to the encoding ("Interpreted by the codec as it wishes”) there doesn’t seem to be any way for the Matroska specification to define a BlockAdditionalID value (except for 0 which is reserved as a reference to the main block). > > However, this approach works for me if others accept the break in reverse compatibility. > > Several other definitions would require updates. Currently we have: > BlockAdditions: "Contain additional blocks to complete the main one. An EBML parser that has no knowledge of the Block structure could still see and use/skip these data.” > BlockAddID: "An ID to identify the BlockAdditional level.” > BlockAdditional: "Interpreted by the codec as it wishes (using the BlockAddID)." > AlphaMode: "Alpha Video Mode. Presence of this Element indicates that the BlockAdditional Element could contain Alpha data.” > > Notes about what definition updates would be needed: > BlockAdditions’s definition would have to be rewritten as the data wouldn’t necessarily “complete” the main block but might alternatively supplement it or describe it. > BlockAddID should include an enumerated list of integers and reference a registry on what each value means. > BlockAdditional’s definition would have to be updated, since only in some cases would the BlockAddition content be interpreted by the codec. > AlphaMode’s definition seems to imply that one of the BlockAdditional Elements contains alpha but gives no way to identify which one, so this is the largest reverse compatibility issue. Are there Matroska demuxers which would try to use timecode or rawcooked data as if it was alpha data? > > So IIUC BlockAddID=1 is reserved for the context of the associated codec mapping (as done in A_WAVPACK4). Then we reserve BlockAddID=2 for alpha and 0 is reserved since BlockAdditionID uses 0 to reference the main block. Then any other type of data for storage in BlockAdditional would use the next available unsigned integer from 3 and would require an BlockAdditionMapping. I suggest that BlockAddId = 0, 1 and 2 would not require a BlockAdditionMapping since the specification would reserve them for particular purpose. > > But if we already define BlockAddId for 0, 1, and 2 in the specification then why not continue and reserve 3 for rawcooked and 4 for timecode and so on. That would avoid the need for storing that data in BlockAdditionMapping, eliminate the need for new BlockAdditionMapping elements, and then demuxers could understand if they can use that data by simply checking the BlockAddId rather than looking up the corresponding value in BlockAddIDName. > > Also what is the need for MaxBlockAdditionID? And what is the reason to keep BlockAdditionID low, simply to keep it to a single byte? > > Dave > >> On Nov 11, 2018, at 10:40 AM, Steve Lhomme wrote: >> >> I would go with the Track way as well. Primarily because storing a >> string (which pretty much never changes) in each Block is a huge >> waste. >> >> Add extra data per Block is already supported using BlockAdditions. >> There's already BlockAddID which correspond to Moritz' BlockMetadataID >> and BlockAdditional which correspond to BlockMetadataString / >> BlockMetadataBinary / BlockMetadataUInteger / BlockMetadataSInteger / >> BlockMetadataFloat. It's like a codec where the CodecID defines how >> the data in the binary blob should be interpreted. >> >> The current system states that the additions are left to >> interpretation to the codec. It was originally designed to hold the >> lossless complement to lossy versions of Musepack. So in that case >> it's really meant to be passed to the codec. I think we can expand >> this system with keeping this default behaviour by default (albeit not >> used anywhere) and have different ones on demand. >> There's also an AlphaMode that also uses BlockAdditions to store the >> alpha track. Which pretty much no info on how to do it.... >> >> As noted timecode may be a separate track (as originally intended) if >> it is not related to the video frames (ie the timestamps doesn't >> match). >> >> This would look like this: >> - Musepack lossless complement: >> Segment\Tracks\TrackEntry\MaxBlockAdditionID: 1 >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 1 >> (same as BlockAddID) (default) >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: >> "complement" (default) >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: 0 >> (Codec Complement data) (default) >> Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 1 >> Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: >> lossless part interpreted by the codec >> >> - Alpha layer: >> Segment\Tracks\TrackEntry\MaxBlockAdditionID: 2 >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 2 >> (same as BlockAddID) >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: "alpha" >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: 1 >> (Alpha layer data) >> Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 2 >> Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: >> alpha mask to apply on the video track >> >> - RawCooked DPX data >> Segment\Tracks\TrackEntry\MaxBlockAdditionID: 3 >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 3 >> (same as BlockAddID) >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: "rawcooked" >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: >> 0x1234567 (rawcooked identifier) >> Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 3 >> Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: >> DPX data defined by RawCooked >> >> - Timecode storing >> Segment\Tracks\TrackEntry\MaxBlockAdditionID: 3 >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 3 >> (same as BlockAddID) >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: "timecode" >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: >> 0x890ABCD (SMPTE TC identifier, can be another ID for different kind >> of timecode) >> Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 3 >> Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: >> Timecode storage >> >> That means the alpha mode would not be backward compatible with >> existing files, because it requires non default values. But I don't >> think anyone ever used this improperly defined feature. >> >> The value of MaxBlockAdditionID is kept low on purpose. BlockAddID 1 >> was always for codec complement and thus 2 for the AlphaMode. But we >> don't need to go much higher that than now that we have a mapping. If >> there are Timecode AND Rawcooked it would be like this: >> Segment\Tracks\TrackEntry\MaxBlockAdditionID: 4 >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 3 >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: "rawcooked" >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: >> 0x1234567 (rawcooked identifier) >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDValue: 4 >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDName: "timecode" >> Segment\Tracks\TrackEntry\BlockAdditionMapping\BlockAddIDType: >> 0x890ABCD (SMPTE TC identifier, can be another ID for different kind >> of timecode) >> Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 3 >> Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: >> DPX data defined by RawCooked >> Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAddID: 4 >> Segment\Cluster\BlockGroup\BlockAdditions\BlockMore\BlockAdditional: >> Timecode storage >> >> Le lun. 5 nov. 2018 à 10:29, Moritz Bunkus >> a écrit : >>> Hey, >>> >>>> In other thoughts on this suggestion, I think it could make it difficult >>>> to easily understand if a file has a particular type of side data. For >>>> instance if only a few Clusters somewhere in the Segment contain a >>>> certain type of side data, it would require parsing every Cluster to know >>>> what types of side data are available. This uncertainly wouldn’t be the >>>> same issue if the side data was itself a Track. >>> It's not entirely necessary to use a full track for side data. We can simply >>> signal the presence of side data in the track headers and refer to it from >>> the side data in the block groups. This would also mean we only have to >>> store the string identifying the side data type once (in the track headers) >>> instead of in each block. >>> >>> (I'll use "BlockMetadata" as the basis for all element names >>> here. Initially I proposed "FrameMetadata", but "BlockMetadata" is fine >>> with me, too.) >>> >>> For example: >>> >>> Tracks >>> +- TrackEntry >>> +- TrackBlockMetadata (Master) >>> +- TrackBlockMetadataType (String, required) >>> +- TrackBlockMetadataID (Unsigned Integer, required) >>> >>> … >>> >>> Cluster >>> +- BlockGroup >>> +- BlockMetadata (Master) >>> +- BlockMetadataID (Unsigned Integer, required, refers to existing >>> TrackBlockMetadataID in track headers) >>> +- BlockMetadataString (Unicode String, optional) >>> +- BlockMetadataBinary (Binary, optional) >>> +- BlockMetadataUInteger (Unsigned Integer, optional) >>> +- BlockMetadataSInteger (Signed Integer, optional) >>> +- BlockMetadataFloat (Float, optional) >>> >>> with the restriction that exactly one of (BlockMetadataString, >>> BlockMetadataBinary, BlockMetadataUInteger, BlockMetadataSInteger, >>> BlockMetadataFloat) must exist. >>> >>> Advantages as I see them: >>> >>> • Less overhead (no repeated string parsing required) >>> • Quicker parsing (no repeated string parsing required) >>> • Presence of meta data is known upfront >>> • Not using a full-blown track for meta data would alleviate the need to >>> specify how all those track and block features (e.g. BlockDuration, >>> TrackDefaultDuration…) apply to a "meta data track". >>> >>> Kind regards, >>> mosu >>> >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >> >> >> -- >> Steve Lhomme >> Matroska association Chairman From nobody Mon Nov 12 09:21:48 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305D412777C for ; Mon, 12 Nov 2018 09:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6U1-4HsPmLpc for ; Mon, 12 Nov 2018 09:21:45 -0800 (PST) Received: from smtp.gentoo.org (woodpecker.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4094212896A for ; Mon, 12 Nov 2018 09:21:44 -0800 (PST) Received: from eris.local (dynamic-adsl-84-221-124-174.clienti.tiscali.it [84.221.124.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: lu_zero) by smtp.gentoo.org (Postfix) with ESMTPSA id 97562335CEC for ; Mon, 12 Nov 2018 17:21:43 +0000 (UTC) To: cellar@ietf.org References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> <87r2fz7u01.fsf@bunkus.org> <2c9da243-26b0-6ae5-1fb8-0f0448e8728d@mediaarea.net> From: Luca Barbato Message-ID: Date: Mon, 12 Nov 2018 18:21:39 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:64.0) Gecko/20100101 Thunderbird/64.0 MIME-Version: 1.0 In-Reply-To: <2c9da243-26b0-6ae5-1fb8-0f0448e8728d@mediaarea.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 17:21:47 -0000 On 05/11/2018 12:20, Jerome Martinez wrote: > On 05/11/2018 10:29, Moritz Bunkus wrote: >> Hey, >> >>> In other thoughts on this suggestion, I think it could make it difficult >>> to easily understand if a file has a particular type of side data. For >>> instance if only a few Clusters somewhere in the Segment contain a >>> certain type of side data, it would require parsing every Cluster to >>> know >>> what types of side data are available. This uncertainly wouldn’t be the >>> same issue if the side data was itself a Track. >> It's not entirely necessary to use a full track for side data. We can >> simply >> signal the presence of side data in the track headers and refer to it >> from >> the side data in the block groups. This would also mean we only have to >> store the string identifying the side data type once (in the track >> headers) >> instead of in each block. > > > It would permit more efficient storage, but IMO it should be optional > only, because if we do real time transcoding to MKV we don't have always > all sidecar info. I have in mind some A/V content with ancillary data > coming only after few minutes, without any change in A/V part. > This should warrant for a stand alone track maybe? lu From nobody Mon Nov 12 09:49:42 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67580130DE2 for ; Mon, 12 Nov 2018 09:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VH4PTW13FPmF for ; Mon, 12 Nov 2018 09:49:36 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C79128CB7 for ; Mon, 12 Nov 2018 09:49:36 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DFE562008C; Mon, 12 Nov 2018 12:49:31 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id C659DCA1; Mon, 12 Nov 2018 12:49:35 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C433B9DB; Mon, 12 Nov 2018 12:49:35 -0500 (EST) From: Michael Richardson To: Steve Lhomme cc: cellar@ietf.org, Tobias Rapp In-Reply-To: <40cfae4a-fff9-8153-7116-08a2f59aef75@matroska.org> References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> <87r2fz7u01.fsf@bunkus.org> <69462008-FABB-476E-8032-EEE21A832A9B@dericed.com> <40cfae4a-fff9-8153-7116-08a2f59aef75@matroska.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Content-Transfer-Encoding: quoted-printable Date: Mon, 12 Nov 2018 12:49:35 -0500 Message-ID: <16963.1542044975@localhost> Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 17:49:39 -0000 Steve Lhomme wrote: > Just as I double check this, it turns out WebM has support for the > AlphaMode and all the BlockAddition that goes with it. > https://www.webmproject.org/docs/container/ Is there some implication for Matroska? = btw: IANA (Michelle) and I had some discussion about how to reserve DocTyp= e names for WebM properly, and I think we have a solution. -- = ] Never tell me the odds! | ipv6 mesh networ= ks [ = ] Michael Richardson, Sandelman Software Works | network architec= t [ = ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ = = From nobody Sun Nov 18 04:07:41 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39835130DC6 for ; Sun, 18 Nov 2018 04:07:39 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTuWi9za1esZ for ; Sun, 18 Nov 2018 04:07:37 -0800 (PST) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (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 41E4112F295 for ; Sun, 18 Nov 2018 04:07:37 -0800 (PST) Received: by mail-pl1-x62a.google.com with SMTP id x21-v6so10522235pln.9 for ; Sun, 18 Nov 2018 04:07:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=mFxC1A2a8gFhMj2FQ63yo1woFkkEHSMISmmJSNA8K7A=; b=wALwMhAL44P1uLrviZ8Tq61IYwkN/MjEewErjMDTCW3BycrVnuvEd8YHURkZ2ONJSn BcvWLBrMGBBrp8L4bDSXWr1siUazYwaFQ74DDdPK467tBoS12z9QV6WdyG5Q0i1XzlWt wzXZFvXqeeahROYcFbFrEj8RFU2Qz+pK1ZN0PU5wxlGJ/B87f/QtDtUVHB3XaoYV7X4Y avEaG7jERWuhz91/511031ZRoZY2+QdmufvJ4EraoEb45+RqzQtGy9xvsnbcwKAPW2Km Vh8TqWaJqv5r6nEXiQSJ5ThLsPnZGJxXol+9E1UI5Ljd+9mhoy5KGdzxbrZeVmEnSOZ/ +yLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=mFxC1A2a8gFhMj2FQ63yo1woFkkEHSMISmmJSNA8K7A=; b=NokgPFv7TZnXxmW1S4g8j/AgF33FAg3xnWxVTSNOhf30XqEAaeD7EYuceuM/WdRsPp A8sdp4YoYaxPfi+yKTwWll+5I5EUT+7tNTjUwMWs2xZRVFdULbkw1nFGazm/URdEksLy m66UbR2lIWS2zxvno1gxgEBubqB92+Y/t33P5RIf71Vj71oTuJiMzY+eCk5mpskbiBh3 ZMYEtwXAVotZ0wGlVZRJ/S7tFahPtF7/082y3OxBRopj7zqpqLzOMTNV45R0/lOcuAmy 4r7CgP0kbgqedUtRPCHIHvHWRsbCvZF4AaaKvcoWUMUdn4MOdT+ZKop0jFovuOKc4k6e vOGw== X-Gm-Message-State: AGRZ1gKcYcL+4uA56axmPcnPqWaoCNotvMI2PHsLU6mKJUaEop0EegTA GC5tc55MWWRyLRgbNaJPMNc+SCtCsPxwFB4Xg4332b9p3mvkQQ== X-Google-Smtp-Source: AJdET5cmdI/1+lurLpc51VWWz1cHthGGHg/xh54QV17PqtO6jBfkzwpOynfzQOZVITqjZXleHHaTzIqqreqpMbX33pY= X-Received: by 2002:a17:902:544:: with SMTP id 62-v6mr17419428plf.73.1542542855552; Sun, 18 Nov 2018 04:07:35 -0800 (PST) MIME-Version: 1.0 References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> <87r2fz7u01.fsf@bunkus.org> <69462008-FABB-476E-8032-EEE21A832A9B@dericed.com> <40cfae4a-fff9-8153-7116-08a2f59aef75@matroska.org> <16963.1542044975@localhost> In-Reply-To: <16963.1542044975@localhost> From: Steve Lhomme Date: Sun, 18 Nov 2018 13:07:24 +0100 Message-ID: To: mcr@sandelman.ca Cc: Codec Encoding for LossLess Archiving and Realtime transmission , Tobias Rapp Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 18 Nov 2018 12:07:39 -0000 Le lun. 12 nov. 2018 =C3=A0 18:49, Michael Richardson a = =C3=A9crit : > > Steve Lhomme wrote: > > Just as I double check this, it turns out WebM has support for the > > AlphaMode and all the BlockAddition that goes with it. > > https://www.webmproject.org/docs/container/ > > Is there some implication for Matroska? That means at least we can't deprecate it and we have to make sure what we do in the future is compatible with that. We don't want to separate the specs. From a "container" perspective it's just a pity that it's can't be "contained" in a BlockAdditionMapping. But that's the only issue. > btw: IANA (Michelle) and I had some discussion about how to reserve DocTy= pe > names for WebM properly, and I think we have a solution. OK, feel free to share it ;) > -- > ] Never tell me the odds! | ipv6 mesh netwo= rks [ > ] Michael Richardson, Sandelman Software Works | network archite= ct [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails= [ > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Nov 18 06:03:29 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6515B130E1D for ; Sun, 18 Nov 2018 06:03:27 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=matroska-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6utxUB5X1d0 for ; Sun, 18 Nov 2018 06:03:25 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 3E229130DD7 for ; Sun, 18 Nov 2018 06:03:25 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id z10so12635708pgp.7 for ; Sun, 18 Nov 2018 06:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-transfer-encoding; bh=vP9i5YJvemcr9K82CjCPC9Wg/EkTXVYeQTWKZcGb1HA=; b=oByzm2d54+mpfICMwQhNy2uAPIGQWoAy2vcE1qhOosHpcaTDi5WvZsiMhIHLj3LYYm i5LPe9SsSfZxR5fZ/yyaA8PDcEjt+pzE9G6goJPFnpwbHfByQEZVLXVdQz5s+erk2KwQ AI5eA2foc6R1t1gjAxeWvlCZv7quONXTJoKx2SAwXOuyvBy9DPoATQguWbTbapmlA38k rA40+IAQJ6Kjqhsh8TLN7SeTWgmhjtHww79PtGpJDy72lRS48sAy24db/NdyWdHCe1cS BOsvcCN1ZBs7F/2k6JBnntl44j4QcrW0aKkXyr32ODlHa6OdoSZdU/xPognxafxTxHb4 WKcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-transfer-encoding; bh=vP9i5YJvemcr9K82CjCPC9Wg/EkTXVYeQTWKZcGb1HA=; b=QMhHXrb20HJFsKYfZrypPchxVKUlMb7poz+EupAfXDLxgNsWGDn+OVbqDy5sKZfEHc SJB0msrwZMuOVJSF7yx4vOuBWk/D574bKeqwZT5QW9MzBoyNfvfC0nHpri38/G9JG6LA 1HxBHgz7wuA8pBu2NAWzNTEakHGkP2GBLrtLD73jgBm++dwRQ2v5NMJN/+UkDWfJhzyn X+o+2f/zNoOvCZpvTRFbAEnyNjN8Y+YGVdqGcAZdnh97sRhr4Z6TXBOw3EsC0hLzJ0KA FKF84pbJ1S48PGG2Y4bQX995X63yw/07KNxarCid9djfM3a3cW18JUvVpEauEJum913A sitA== X-Gm-Message-State: AGRZ1gKFZVNKT2DaKB1kgqiSQOhTd0CDuQEZLwxr9+U4Fp/xuaU8S/fY KF5Wdd7xTH9vj5qkMdH4ACMAc3YtcXTorXuag+rZ+polGlYCjQ== X-Google-Smtp-Source: AJdET5d5vAWBQRTQf8Ati7bwFoMVXYGGnex1skLamT1Gu3jbNgTX54lN+lcrCjtK5dDYVJG7om5iWqya+2OxHGGx9no= X-Received: by 2002:aa7:818a:: with SMTP id g10-v6mr18946959pfi.153.1542549804443; Sun, 18 Nov 2018 06:03:24 -0800 (PST) MIME-Version: 1.0 References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> <87r2fz7u01.fsf@bunkus.org> <69462008-FABB-476E-8032-EEE21A832A9B@dericed.com> <40cfae4a-fff9-8153-7116-08a2f59aef75@matroska.org> <16963.1542044975@localhost> In-Reply-To: From: Steve Lhomme Date: Sun, 18 Nov 2018 15:03:13 +0100 Message-ID: To: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 18 Nov 2018 14:03:27 -0000 I did a Pull Request with my proposed additions to handle BlockAdditional data in a meaningful way: https://github.com/Matroska-Org/matroska-specification/pull/287 I added Timecode and RAWCooked values but IMO they should be in a separate document (since the binary extra data will evolve over time, independently of the Matroska specs). We will need a IANA registry for each BlockAddIDType value. The value 0 (Codec Complement) may be explained further. Le dim. 18 nov. 2018 =C3=A0 13:07, Steve Lhomme a = =C3=A9crit : > > Le lun. 12 nov. 2018 =C3=A0 18:49, Michael Richardson = a =C3=A9crit : > > > > Steve Lhomme wrote: > > > Just as I double check this, it turns out WebM has support for th= e > > > AlphaMode and all the BlockAddition that goes with it. > > > https://www.webmproject.org/docs/container/ > > > > Is there some implication for Matroska? > > That means at least we can't deprecate it and we have to make sure > what we do in the future is compatible with that. We don't want to > separate the specs. From a "container" perspective it's just a pity > that it's can't be "contained" in a BlockAdditionMapping. But that's > the only issue. > > > btw: IANA (Michelle) and I had some discussion about how to reserve Doc= Type > > names for WebM properly, and I think we have a solution. > > OK, feel free to share it ;) > > > -- > > ] Never tell me the odds! | ipv6 mesh net= works [ > > ] Michael Richardson, Sandelman Software Works | network archi= tect [ > > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rai= ls [ > > > > > -- > Steve Lhomme > Matroska association Chairman --=20 Steve Lhomme Matroska association Chairman From nobody Sun Nov 18 11:59:01 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6897912DD85 for ; Sun, 18 Nov 2018 11:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFRU1FUGpo3P for ; Sun, 18 Nov 2018 11:58:55 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEEB512D4E7 for ; Sun, 18 Nov 2018 11:58:54 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id F053320072; Sun, 18 Nov 2018 14:58:49 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 33611CEB; Sun, 18 Nov 2018 14:58:54 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 306DFCEA; Sun, 18 Nov 2018 14:58:54 -0500 (EST) From: Michael Richardson To: iana-issues@iana.org cc: Codec Encoding for LossLess Archiving and Realtime transmission , Tobias Rapp In-Reply-To: References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> <87r2fz7u01.fsf@bunkus.org> <69462008-FABB-476E-8032-EEE21A832A9B@dericed.com> <40cfae4a-fff9-8153-7116-08a2f59aef75@matroska.org> <16963.1542044975@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] IANA considerations text to reserve WebM/Matroska in EBML document X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 18 Nov 2018 19:58:59 -0000 --=-=-= Content-Type: text/plain Steve Lhomme wrote: >> btw: IANA (Michelle) and I had some discussion about how to reserve DocType >> names for WebM properly, and I think we have a solution. > OK, feel free to share it ;) Michelle was going to propose the right text so that the EBML document would correctly reserve the DocType "WebM" and "Matroska" names in the First Come First Served DocType Registry. Both are to be entered into the Registry under IESG ownership/control. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlvxxH0ACgkQgItw+93Q 3WU6/wf/cC2siTfl8Bgm3QloEZlswODm6HS4zScmFxjjhLtUMxdpxdNWxjdrCBNo Zet12VM00t3JbeI+Q+IAW7FDV61EWJKWtcalb3pwsEfrRZGpk5AC50ImqMFrelS6 C3J5EnTjlgRskBymSNCXI24BFH/ayWP7kReUmGtGkNzT++8WiMQUa2hyyUFiO6sF QTQm3DkxAEkkbx/WgqcCm8eTxHa6/SSYVZYKAi7kpMz/Z1wNgf43SxGZ1DvImhsR fY+CscgusYi3b7OjTh62U/1MpbV+qa3aEBAgfqXRWJnDCH9A3pOAgN46IJOj6KLw eTyH7LwEx2kc3BGnQCZGQDZ/YgNXRQ== =zGX8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 19 10:47:28 2018 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE51130DF9; Mon, 19 Nov 2018 10:47:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org, cellar-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154265324108.5281.11179661480653275341.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2018 10:47:21 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Interim Meeting Cancelled (was 2018-10-30) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 18:47:21 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) virtual interim meeting for 2018-10-30 from 20:00 to 21:00 UTC has been cancelled. From nobody Mon Nov 19 14:30:36 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA1951252B7 for ; Mon, 19 Nov 2018 14:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f8NzQuX32fcf for ; Mon, 19 Nov 2018 14:30:33 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06BD1126CC7 for ; Mon, 19 Nov 2018 14:30:33 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D751220089; Mon, 19 Nov 2018 17:30:27 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 2D705D8B; Mon, 19 Nov 2018 17:30:32 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2A216D85; Mon, 19 Nov 2018 17:30:32 -0500 (EST) From: Michael Richardson To: cellar@ietf.org CC: iana-issues@ietf.org In-Reply-To: References: <5484.1533072262@localhost> <26302.1537376440@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Cellar] [IANA #1124191] Re: reserving a value for in-the-field X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2018 22:30:35 -0000 --=-=-= Content-Type: text/plain Michelle Cotton via RT wrote: > Hello Michael, > Great seeing you in Bangkok. > As promised, here is some suggested text for the document regarding > those 2 reservations. > Let me know what you think. Happy to discuss more and feel free to > wordsmith. This is just an idea to get us going on the language > changes. > The use of ASCII corresponds to the types and code already in use, > the value is not meant to be visible to the user. > DocType string values of "matroska" and "webm" are reserved to the IETF > for future use. > These can be assigned via IESG Approval or RFC Required. ... the text is even simpler than I would have thought. Wonderful. > The idea for this suggested text changes for draft-ietf-cellar-ebml was > that those could be reserved and then when the appropriate parties want > them designated they can either write an RFC or the IESG can > designate. > Thanks, > Michelle I pasted the text in to the markdown and sent a pull request (#195). -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlvzOYcACgkQgItw+93Q 3WUlHgf9HaXvUE9gofuHmfLXVknoUyDIKrTHCQJtZyHtICI7izH96Q/zEDC/qWKG DxfYC1sa815X1Cd7BwD9Okww9U3g9SYmD3Z7PGzNzrPpu7QOoNlKARSYlrIb1u2P u2x4zCqrpwfkVqMP8vn/XNReGOMbZLnwEI+KeIeegx3a95/yv2VlJ3QbeS8cNgkk gJ/EypYFPzw5jLo/GvDgcxMN/2gkUJE6iP9NlBta8AHrvqHUYoUMTTtW1sr1X57L 5Mp4Fa7sgu0vJDxhwQuYpsaz1vvbwhz/9P13vA8YiTfhlW76NhdZVPdY1MHDebO2 YcIi3UbqLnbZTk4X8s+66rvLgXfmCQ== =4QGG -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 19 16:53:19 2018 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 918CC128CFD; Mon, 19 Nov 2018 16:53:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org, cellar-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154267519255.26657.3544391128387307515.idtracker@ietfa.amsl.com> Date: Mon, 19 Nov 2018 16:53:12 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Interim Meeting Cancelled (was 2018-11-27) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 00:53:12 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) virtual interim meeting for 2018-11-27 from 20:00 to 21:00 UTC has been cancelled. From nobody Mon Nov 19 16:54:49 2018 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E665B124C04; Mon, 19 Nov 2018 16:54:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154267528289.26560.9855214436522996423@ietfa.amsl.com> Date: Mon, 19 Nov 2018 16:54:42 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2018-12-18 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 00:54:43 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2018-12-18 from 15:00 to 16:00 America/Toronto. Agenda: Agenda to be uploaded 10 days beforehand. Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=me21026faa14be85507cdef66b860014e mtg number: 313 505 170 From nobody Mon Nov 19 16:55:07 2018 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 849A1130E5F; Mon, 19 Nov 2018 16:55:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154267530149.26661.2899262779148386208@ietfa.amsl.com> Date: Mon, 19 Nov 2018 16:55:01 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-01-29 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 00:55:05 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2019-01-29 from 15:00 to 16:00 America/Toronto. Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=me21026faa14be85507cdef66b860014e mtg number: 313 505 170 From nobody Mon Nov 19 16:55:35 2018 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 240B8130E13; Mon, 19 Nov 2018 16:55:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154267532409.26570.15847192855335941357@ietfa.amsl.com> Date: Mon, 19 Nov 2018 16:55:24 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-02-26 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 00:55:29 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2019-02-26 from 15:00 to 16:00 America/Toronto. Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=me21026faa14be85507cdef66b860014e mtg number: 313 505 170 From nobody Mon Nov 19 18:16:31 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAACE128CFD for ; Mon, 19 Nov 2018 18:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5diH5kJ1SCr1 for ; Mon, 19 Nov 2018 18:16:27 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFBC5124BE5 for ; Mon, 19 Nov 2018 18:16:27 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id D160120089 for ; Mon, 19 Nov 2018 21:16:20 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 2A963D8B; Mon, 19 Nov 2018 21:16:25 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2754DD85 for ; Mon, 19 Nov 2018 21:16:25 -0500 (EST) From: Michael Richardson To: cellar@ietf.org In-Reply-To: <154267519255.26657.3544391128387307515.idtracker@ietfa.amsl.com> References: <154267519255.26657.3544391128387307515.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Cellar] virtual interim meeting schedule X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 02:16:30 -0000 --=-=-= Content-Type: text/plain I have cancelled the Nov. 27 meeting, as I can not chair it. I have schedule a meeting for Dec. 18, and I hope that being off the schedule by a week is acceptable. The other meetings are: Jan. 29, Feb. 26, and March 26. I expect to push EBML up to the IESG by Dec. 1, once the Shepherd write up is done. I know many were available Nov. 6 for a meeting to replace Oct. 30, but unfortunately, we aren't supposed to reschedule official meetings without reasonable notice. [Of course, *design teams* can meet anytime they like. That's among the team of people working on the document] -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlvzbngACgkQgItw+93Q 3WXQHwgAvKDGI6DtldfLQiQ283dFi9Gge7LHLbZ6jmt04TgCW87CTV0RF0eHfeqv CEi4f/9DIupjxaxoF451KLErlT+W1qH7my8s/iSGrhM+w+KnwEwEW0KoW8MVOPS0 RYH/T7AefZc/mkTUBe6+Bomyz2ZvF0DeMEyjmdkxXGUn56G5eDu0+OC3KetaY9ok rTEh/wiL5kGwhIGFyvne7WwrxNaEOyEt1EfmI2gzFK6wnPuGJP6Lkm7NfkF3IB4A jaIOvvGs9ecjkYLG+CSfXEBeaDFZ43EmHkWyEAd6sr4T9VouoLq4ycTwcWEQ27Si 77ywaGfNaph9LTrI+YEW+4Eywpgz1A== =w3CW -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 20 09:20:49 2018 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C0C012896A; Tue, 20 Nov 2018 09:20:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.88.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154273443904.18530.767244481082368984@ietfa.amsl.com> Date: Tue, 20 Nov 2018 09:20:39 -0800 Archived-At: Subject: [Cellar] Codec Encoding for LossLess Archiving and Realtime transmission (cellar) WG Virtual Meeting: 2019-03-26 X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 17:20:39 -0000 The Codec Encoding for LossLess Archiving and Realtime transmission (cellar) Working Group will hold a virtual interim meeting on 2019-03-26 from 15:00 to 16:00 America/Toronto. Agenda: (No agenda submitted) Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=me21026faa14be85507cdef66b860014e mtg number: 313 505 170 From nobody Tue Nov 20 11:10:47 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B40A61277BB for ; Tue, 20 Nov 2018 11:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 iS8rH2zPHKCy for ; Tue, 20 Nov 2018 11:10:44 -0800 (PST) Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) (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 27CCF1286E3 for ; Tue, 20 Nov 2018 11:10:44 -0800 (PST) Received: by mail-wm1-x335.google.com with SMTP id u13-v6so3402848wmc.4 for ; Tue, 20 Nov 2018 11:10:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LxgcjHGIj6mMRvF+FPLeGa8GsD4aqRrb2ROIg6SumZ8=; b=r+eAtwrug0+1CX2yTxyCcU//JZb4/T2iBGLsxQiiE8ijPpJis4AgWMD79FP/nuzPyY lxDVNZJABi5MEnFb9HeugX9bjsePKTHJmnC9SodmxiuVvDDVDI+GVmbZHGr2aYscZlMQ tIJqMIMppGJZCSTUek9fhVysEtvFiHTsiblHhB/XH0io5ChjVrOSA2nZL2jI1zT0OdbF WKu2WIfaZSd3WkpqW0CCdhlrEQAZP0in4KjpPFMrXa9MNMmstjAqKm2BDdWMgFg0s4nQ uNPyym9cHN7zMcpknwjMRSbcGlWRE5NXgHnTK+4FV7WmZEa+O3O9IS+pw3DwZWtvugjD wiIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LxgcjHGIj6mMRvF+FPLeGa8GsD4aqRrb2ROIg6SumZ8=; b=gpdRT6Pe7S5a9ZVc6Npi/LP1ptMbHc88ZOnLUJlao9blt+5h7sIG++rN9bXGsT6s/6 jvZSti12ZCy5ZL8Vd7CkgXkYPZDfqy5AfEA6CXgk5XbKOYajqzfrhrBc65RcexWTaxm2 cSANKg6BlSp5jxaiAbdMwqGUUlvqssSgfS5Zdo6HWj744/iyQy+DZj6xipD/387IPLEo WvEPQDM37RujRepUweA2T/DmRr5chEIOITvgwptaqfeGnkHN4Cgl2CKYy4rTgeW5fKFF AgrIeMpjtTITafqjqFlgcARTKSWlfXUASGvA089QJ7CZT9RtkRV7gFB+lBet0UnQVRym AndA== X-Gm-Message-State: AA+aEWaehAbSQ2IEv6ehURSB1HgxEHhn3xmC7SXGNskHzpL9CJv9GDnu FjrzhomN1PyxWas0CXwNiWvs6uHyUAIhfJE7Z934gseli/4= X-Google-Smtp-Source: AFSGD/XfUPOpDMrNudC3hWf0JjKjP3KVcaylQBpROVRfn3h4FmoBKdqvMG0PPknULGyRcbhCXvcskDBjgVrrBZZKqbc= X-Received: by 2002:a1c:1d0:: with SMTP id 199mr3359828wmb.115.1542741042191; Tue, 20 Nov 2018 11:10:42 -0800 (PST) MIME-Version: 1.0 References: <24ED459F-2375-4934-9156-E64BB1A8AC05@dericed.com> <62624df3-77e8-3234-8496-30354570abee@noa-archive.com> <1E9938AC-B503-42A4-B1A9-43345F81B30F@dericed.com> <87r2fz7u01.fsf@bunkus.org> <69462008-FABB-476E-8032-EEE21A832A9B@dericed.com> <40cfae4a-fff9-8153-7116-08a2f59aef75@matroska.org> In-Reply-To: <40cfae4a-fff9-8153-7116-08a2f59aef75@matroska.org> From: Michael Bradshaw Date: Tue, 20 Nov 2018 11:10:30 -0800 Message-ID: To: slhomme@matroska.org Cc: cellar@ietf.org Content-Type: multipart/alternative; boundary="000000000000cd6a08057b1d6303" Archived-At: Subject: Re: [Cellar] Matroska Elements to support frame side data X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 20 Nov 2018 19:10:46 -0000 --000000000000cd6a08057b1d6303 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 12, 2018 at 7:38 AM Steve Lhomme wrote: > They don't even support MaxBlockAdditionID, so technically the value is > 0 for them. I just hope they don't use BlockAddId 0, it is a forbidden > value. If not it's probably a value of 1 but not 2. > Good catch that MaxBlockAdditionID is unsupported in WebM. I'll try to rectify that. To clarify, alpha in WebM uses BlockAddID==1. It would be nice to standardize that within CELLAR. If I can help in any way, please let me know. --000000000000cd6a08057b1d6303 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --000000000000cd6a08057b1d6303-- From nobody Fri Nov 23 01:56:55 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE73130E0F for ; Fri, 23 Nov 2018 01:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_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 ClpQsTCaBk2Z for ; Fri, 23 Nov 2018 01:56:50 -0800 (PST) Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (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 36FCF130DFC for ; Fri, 23 Nov 2018 01:56:50 -0800 (PST) Received: by mail-wm1-x32d.google.com with SMTP id r11-v6so11272522wmb.2 for ; Fri, 23 Nov 2018 01:56:50 -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=He5EUxHgjPRI5+TZZ531s5h7ilihnUY/3t0kncLyxl4=; b=TgO07OsTXJNFBV7mOWBQsz3/nWOh9V3K/0dQSHudwphPJZqdEQNc8qJGCTTNk0wCf6 CbofBqZn6fqymgP7BOTjCX0xlTk3HgALPqnhWB2lxglXDlGwfONSzQzpdQjh1ZsgNome y8R9PBFnIaNAD77DAWCoqjWU7xfMZkU8lPG/C+q/EttO3M8rxmdfNi9dnMDTatdYz886 oWIxyXVNNc8BEteX51ya9gTpkA2o67IltFafbbSzNklNQi+nY7y7t66w5yo9kmQPthl5 0U090GFNoSiK+TOEs+hwJNRMrBaAFuO2LP9LE3gtKMdfd70EJwKDzUtxASwuTqkync45 QqMQ== 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=He5EUxHgjPRI5+TZZ531s5h7ilihnUY/3t0kncLyxl4=; b=NSwS/sDJQ7La57uDQ6mGbK6hJwOc/L8G6aJtcLHBflkSDfrbbrjb6YtW8VXDcNLaAa cpDLEH0ss+5HwVaqPuWaUiDBeX6O5Kg3arDyEC/eXcpGaZjNoRHlCiEfvDrVtuDrfmEN 6T+h2t3lAznZYfzNEHJY4sPzLrf/Pb6+7QAb/WODFi0kdK0CniHmt6TKHm9w22dpJHhY KpfZIeMKBko1GS0jdCX1gHfGW8BSvw7FLDid4cHwXyuwDDhaj6JMw5y44S2h/yDctALv KNbRh7biDb5Ek40icrEV4FNF8dklO+YaZthxCQQ9ZSAbjMjW6DTcUMFrWcc3iPfVm4YA kQcw== X-Gm-Message-State: AGRZ1gLgTMO78mJ6NNBfoRFinuzkgNv34poR15UEJa9umQ9nUwi5nhti MwBab+TZRNQ9w45AzYDsR5JoedQ+p2dKz2VrUmbyKqw= X-Google-Smtp-Source: AJdET5fcPfQX8U/2TpZmKpG8bpLfNv03Dd/nUwNM6fmRFXB5E93GWVC7pcaPKaqZgAX+ya1JZx/TYMfTzJR9o8NG96w= X-Received: by 2002:a7b:c5d1:: with SMTP id n17mr13024295wmk.152.1542967008165; Fri, 23 Nov 2018 01:56:48 -0800 (PST) MIME-Version: 1.0 From: Kieran O Leary Date: Fri, 23 Nov 2018 09:56:36 +0000 Message-ID: To: cellar@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Cellar] Mapping of MOV clean aperture values to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 23 Nov 2018 09:56:54 -0000 Hi, Would I be correct in saying that ideally, Clean Aperture values in a MOV/MPEG-4 file should map to the PixelCrop element in Matroska? I'm asking about this in regards to this ffmpeg ticket - https://trac.ffmpeg.org/ticket/7437 As it appears that FFmpeg does not currently read the values in the clap atom and it also does not map them to Matorksa files when remuxing. It seems to make the most sense to map them to PixelCrop, but I'd like to hear it from folks more knowledgable than me. Another associated issue with the display of these kinds of values is with VLC as it appears that 1) PixelCrop values in Matroska are not supported by VLC at the moment - https://trac.videolan.org/vlc/ticket/21192 2) Clean aperture values are not supported by VLC at the moment https://trac.videolan.org/vlc/ticket/21179 Best, Kieran O'Leary Irish Film Institute From nobody Sun Nov 25 12:20:07 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3AE1292AD for ; Sun, 25 Nov 2018 12:20:06 -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 VDbLzmfpWFXH for ; Sun, 25 Nov 2018 12:20:04 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 416641288EB for ; Sun, 25 Nov 2018 12:20:04 -0800 (PST) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:40598 helo=[10.0.1.17]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gR0sp-003FWR-P3; Sun, 25 Nov 2018 15:20:03 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Dave Rice In-Reply-To: Date: Sun, 25 Nov 2018 15:19:58 -0500 Cc: cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <353D4CFD-370C-4509-B7BE-3D572EC2DEFB@dericed.com> References: To: Kieran O Leary X-Mailer: Apple Mail (2.3445.100.39) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Mapping of MOV clean aperture values to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 25 Nov 2018 20:20:07 -0000 Hi Kieran, > On Nov 23, 2018, at 4:56 AM, Kieran O Leary = wrote: >=20 > Hi, >=20 > Would I be correct in saying that ideally, Clean Aperture values in a > MOV/MPEG-4 file should map to the PixelCrop element in Matroska? Yes, they conceptually do the same thing but I=E2=80=99m a little = confused about how to use the vert/horiz offset fractions of the clap = atom to convert to the pixel crop atom. I tried in both QuickTime 7 and = X, and while QuickTime X uses the cleanAperature w/h fractions to = present a cropped image, QuickTime 7 doesn=E2=80=99t but appears to = adjust the aspect ratio according to those values. QuickTime X does seem = impacted by non-zero offset values not in a way that I consider = coherent. Do you have any examples of un-centered aperatures? I was = hoping that IMX files would, does the ones I have don=E2=80=99t use any = aperature. > I'm asking about this in regards to this ffmpeg ticket - > https://trac.ffmpeg.org/ticket/7437 > As it appears that FFmpeg does not currently read the values in the > clap atom and it also does not map them to Matorksa files when > remuxing. It seems to make the most sense to map them to PixelCrop, > but I'd like to hear it from folks more knowledgable than me. Seems reasonable to me, but I=E2=80=99m not exactly certain what the = mapping would be. > Another associated issue with the display of these kinds of values is > with VLC as it appears that >=20 > 1) PixelCrop values in Matroska are not supported by VLC at the moment > - https://trac.videolan.org/vlc/ticket/21192 > 2) Clean aperture values are not supported by VLC at the moment > https://trac.videolan.org/vlc/ticket/21179 Sounds like these tickets are in my priority order as well. Dave Rice From nobody Sun Nov 25 12:37:05 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5437D1277C8 for ; Sun, 25 Nov 2018 12:37:04 -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 EiHpTBcYoSUq for ; Sun, 25 Nov 2018 12:37:03 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69DEC1274D0 for ; Sun, 25 Nov 2018 12:37:03 -0800 (PST) Received: from cpe-104-162-94-162.nyc.res.rr.com ([104.162.94.162]:42220 helo=[10.0.1.17]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gR19J-003hlc-2g; Sun, 25 Nov 2018 15:37:02 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) From: Dave Rice In-Reply-To: <15400.1542680185@localhost> Date: Sun, 25 Nov 2018 15:36:59 -0500 Cc: cellar@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154267519255.26657.3544391128387307515.idtracker@ietfa.amsl.com> <15400.1542680185@localhost> To: Michael Richardson X-Mailer: Apple Mail (2.3445.100.39) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] virtual interim meeting schedule X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 25 Nov 2018 20:37:04 -0000 Hi Michael, > On Nov 19, 2018, at 9:16 PM, Michael Richardson = wrote: >=20 >=20 > I have cancelled the Nov. 27 meeting, as I can not chair it. > I have schedule a meeting for Dec. 18, and I hope that being off > the schedule by a week is acceptable. >=20 > The other meetings are: > Jan. 29, Feb. 26, and March 26. >=20 > I expect to push EBML up to the IESG by Dec. 1, once the Shepherd = write up is > done. Do you recommend any timing for a new version of an EBML draft? I see we = have recent commits from yourself and Steve that are not yet represented = in the current draft. [=E2=80=A6] Dave Rice= From nobody Sun Nov 25 20:42:40 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1370130EF5 for ; Sun, 25 Nov 2018 20:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.435 X-Spam-Level: * X-Spam-Status: No, score=1.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_3qEIGzUqs0 for ; Sun, 25 Nov 2018 20:42:38 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71FC812872C for ; Sun, 25 Nov 2018 20:42:38 -0800 (PST) Received: from dooku.sandelman.ca (unknown [38.98.37.141]) by relay.sandelman.ca (Postfix) with ESMTPS id 808211F8BD; Mon, 26 Nov 2018 04:42:35 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 655071A82; Sun, 25 Nov 2018 23:41:59 -0500 (EST) From: Michael Richardson To: Dave Rice cc: cellar@ietf.org In-reply-to: References: <154267519255.26657.3544391128387307515.idtracker@ietfa.amsl.com> <15400.1542680185@localhost> Comments: In-reply-to Dave Rice message dated "Sun, 25 Nov 2018 15:36:59 -0500." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sun, 25 Nov 2018 23:41:59 -0500 Message-ID: <1020.1543207319@dooku.sandelman.ca> Archived-At: Subject: Re: [Cellar] virtual interim meeting schedule X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 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, 26 Nov 2018 04:42:40 -0000 --=-=-= Content-Type: text/plain Dave Rice wrote: >> I have cancelled the Nov. 27 meeting, as I can not chair it. I have >> schedule a meeting for Dec. 18, and I hope that being off the schedule >> by a week is acceptable. >> >> The other meetings are: Jan. 29, Feb. 26, and March 26. >> >> I expect to push EBML up to the IESG by Dec. 1, once the Shepherd >> write up is done. > Do you recommend any timing for a new version of an EBML draft? I see > we have recent commits from yourself and Steve that are not yet > represented in the current draft. The Shepherd write-up should be done this week (right...), so we need a new revision so that I can send the document up to the IESG. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlv7eZcACgkQlUzhVv38 QpAGSwgAnCtp3oR58qxl1Fw6vdlfLpMnfnpq3kGV/1waxiLdH5ezGbSndsKnFXwa Ow00pxFNIEPzQiYhjWNNZkkS+MyKpnARvyx+syxQzP0b9Tu38xjkYf2uyWOVw5V5 0sixnyzBRSFQJbQl0AmD3BZmFCnVjQaZ0gGKCiEnA6OkVqUCVzzJVgFGbG7QCrDj 8dP8hyJQi2GSVEIP14pnrfV2n/i1stw60jcfAxJ7BknBDsXR0UnKEf5QaXi8IM0c c+Vq30UBBFPzX5va4WqFW7x1JH/tE6CeQy3xKPkeAt+BzFUvZJmRLHKZvXNZ6KTc LQaApZfLgLxWL5VRXCbdjhZBGhxmkA== =Hgns -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Nov 27 08:36:59 2018 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 167A8130DE3; Tue, 27 Nov 2018 08:36:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.89.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <154333661006.21338.6583445060295740002@ietfa.amsl.com> Date: Tue, 27 Nov 2018 08:36:50 -0800 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ebml-08.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 16:36:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : Extensible Binary Meta Language Authors : Steve Lhomme Dave Rice Moritz Bunkus Filename : draft-ietf-cellar-ebml-08.txt Pages : 42 Date : 2018-11-27 Abstract: This document defines the Extensible Binary Meta Language (EBML) format as a generalized file format for any type of data in a hierarchical form. EBML is designed as a binary equivalent to XML and uses a storage-efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ebml/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cellar-ebml-08 https://datatracker.ietf.org/doc/html/draft-ietf-cellar-ebml-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ebml-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 27 08:39:04 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C9FB130DE3 for ; Tue, 27 Nov 2018 08:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxPtghNz-kvR for ; Tue, 27 Nov 2018 08:39:01 -0800 (PST) Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D91B130DDA for ; Tue, 27 Nov 2018 08:39:01 -0800 (PST) Received: from [146.96.19.240] (port=40430 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1gRgO3-001RYC-FN; Tue, 27 Nov 2018 11:39:00 -0500 From: Dave Rice Message-Id: <72B285B3-535A-4B6C-9E03-4D73DC0F02F7@dericed.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_E4CDB880-C357-4675-80FA-74FD9471D459" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 27 Nov 2018 11:38:58 -0500 In-Reply-To: <1020.1543207319@dooku.sandelman.ca> Cc: cellar@ietf.org To: Michael Richardson References: <154267519255.26657.3544391128387307515.idtracker@ietfa.amsl.com> <15400.1542680185@localhost> <1020.1543207319@dooku.sandelman.ca> X-Mailer: Apple Mail (2.3273) X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] virtual interim meeting schedule X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 16:39:03 -0000 --Apple-Mail=_E4CDB880-C357-4675-80FA-74FD9471D459 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Nov 25, 2018, at 11:41 PM, Michael Richardson = wrote: >=20 >=20 > Dave Rice wrote: >>> I have cancelled the Nov. 27 meeting, as I can not chair it. I have >>> schedule a meeting for Dec. 18, and I hope that being off the = schedule >>> by a week is acceptable. >>>=20 >>> The other meetings are: Jan. 29, Feb. 26, and March 26. >>>=20 >>> I expect to push EBML up to the IESG by Dec. 1, once the Shepherd >>> write up is done. >=20 >> Do you recommend any timing for a new version of an EBML draft? I see >> we have recent commits from yourself and Steve that are not yet >> represented in the current draft. >=20 > The Shepherd write-up should be done this week (right...), so we need = a new > revision so that I can send the document up to the IESG. OK, version 8 of the EBML draft is now posted at = https://datatracker.ietf.org/wg/cellar/documents/ = to reflect recent = work. Let me know if further changes are needed prior to IESG = submission. Dave= --Apple-Mail=_E4CDB880-C357-4675-80FA-74FD9471D459 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Nov 25, 2018, at 11:41 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Dave Rice <dave@dericed.com> wrote:
I have = cancelled the Nov. 27 meeting, as I can not chair it.  I have
schedule a meeting for Dec. 18, and I hope that being off the = schedule
by a week is acceptable.

The other meetings are: Jan. 29, Feb. 26, and March 26.

I expect to push EBML up to the IESG by Dec. = 1, once the Shepherd
write up is done.

Do you recommend any timing for a new version = of an EBML draft? I see
we have recent commits from = yourself and Steve that are not yet
represented in the = current draft.

The Shepherd = write-up should be done this week (right...), so we need a new
revision so that I can send the document up to the IESG.

OK, version 8 of the EBML draft is now posted at https://datatracker.ietf.org/wg/cellar/documents/ to = reflect recent work. Let me know if further changes are needed prior to = IESG submission.
Dave
= --Apple-Mail=_E4CDB880-C357-4675-80FA-74FD9471D459-- From nobody Tue Nov 27 09:44:18 2018 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AF94130E99 for ; Tue, 27 Nov 2018 09:44:09 -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 A9TSxws1rrmn for ; Tue, 27 Nov 2018 09:44:06 -0800 (PST) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 778AC130E9A for ; Tue, 27 Nov 2018 09:44:06 -0800 (PST) Received: by mail-wr1-x429.google.com with SMTP id t27so15646341wra.6 for ; Tue, 27 Nov 2018 09:44:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4s16wD0XYjDVOvDz43bE2VM8Bcw6yxdKjFUOuXZ4X80=; b=kKUUocSjwcW/SHjE6OJnPnZqCw9rK7SyoW0wdUELfAZwRRX00Rn5ejSD5fNmRM7lLH PDf3M7YBRjXukLXne/Cwib6urFC9fH0IF/vBzwkaDr7R8CBrAScRfqDnsTIPbSqYLg9X RV8Xr9FORLCwy0wahy0mEmV2yq2IwBu1R2nNx1NzHdf3Rt1Bfxf/ifR7J7kpKIUDuFWH gipCPaprht2z8k2xUjqtUySOY+/Z6aK9Wc3G36S2OOck0obrTnCyzroN0GruqeQ4Y78l YhPe3/rKcrmVxGuN9FQBRyS6l2+8kAu2lXaB0Fu7plUC7BvyMA2yFVY43qVwbIT7Di7K 5Ayw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4s16wD0XYjDVOvDz43bE2VM8Bcw6yxdKjFUOuXZ4X80=; b=HNmamFj4PcbQzdKB1exKcyJoJwAnkyPWRuiDFdEP4eiiTO7F/EptC5NqAe93m+ZIPv tPWFZww8hEEWcyo8N35MgFucPsohCFPEc1pgxjnVKsPi0GyWk/iGijeMxct/soGOITON A5Oczlk9JuRIAVJLAuEyfEFu3dQkDvurgzKf4r+JeL0FotzNpM+VblGxmSPZtGD8+qZx 0iw0qRQGQKyjiKrB3qeQf+Bcc5hKHGiGv9rDYUgb6lwcYLxzJSKnu0LgQup2Iy8liaMd 9ViqoL7m7KWKmhV0g9+jDJwq63qLKqWbHeLVIfyu/NZExtYQnh3cHGbpd+0jNooJoG5G wxhQ== X-Gm-Message-State: AA+aEWb4KETGLxHS/Ucifxe224G/kcQQj4N5SLmH8NEHpQoz+H4hxsBI 6QQthQbfCu1w0QFy73nH2wUiuOzLSpnr1vvFxg== X-Google-Smtp-Source: AFSGD/Uprd4m33OkvUYgV+6qrFDVa0CKaRyMmhDL93ZxJx/V925wXkLCameeEzZOXyXznkneT7EmUYU7kNqtdhGF2U4= X-Received: by 2002:a5d:4382:: with SMTP id i2mr3711444wrq.172.1543340644790; Tue, 27 Nov 2018 09:44:04 -0800 (PST) MIME-Version: 1.0 References: <353D4CFD-370C-4509-B7BE-3D572EC2DEFB@dericed.com> In-Reply-To: <353D4CFD-370C-4509-B7BE-3D572EC2DEFB@dericed.com> From: Kieran O Leary Date: Tue, 27 Nov 2018 17:43:51 +0000 Message-ID: To: Dave Rice Cc: cellar@ietf.org Content-Type: multipart/alternative; boundary="000000000000e67740057ba8fe16" Archived-At: Subject: Re: [Cellar] Mapping of MOV clean aperture values to Matroska X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2018 17:44:18 -0000 --000000000000e67740057ba8fe16 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hey, Thanks for replying: On Sun, 25 Nov 2018, 20:20 Dave Rice Hi Kieran, > > > On Nov 23, 2018, at 4:56 AM, Kieran O Leary > wrote: > > > > Hi, > > > > Would I be correct in saying that ideally, Clean Aperture values in a > > MOV/MPEG-4 file should map to the PixelCrop element in Matroska? > > Yes, they conceptually do the same thing but I=E2=80=99m a little confuse= d about > how to use the vert/horiz offset fractions of the clap atom to convert to > the pixel crop atom. I tried in both QuickTime 7 and X, and while QuickTi= me > X uses the cleanAperature w/h fractions to present a cropped image, > QuickTime 7 doesn=E2=80=99t but appears to adjust the aspect ratio accord= ing to > those values. QuickTime X does seem impacted by non-zero offset values no= t > in a way that I consider coherent. Do you have any examples of un-centere= d > aperatures? I was hoping that IMX files would, does the ones I have don= =E2=80=99t > use any aperature. > I don't think I've ever seen non-centered.. but it sounds like Matroska is capable of a mapping,but the actual quicktime implementation sounds inconsistent? I guess this could be specified explicitly by an archivist who will hopefully be able to determine the intended rendering of the original QuickTime file.. Also it looks like here's yet another related ticket: https://trac.ffmpeg.org/ticket/4489 > > I'm asking about this in regards to this ffmpeg ticket - > > https://trac.ffmpeg.org/ticket/7437 > > As it appears that FFmpeg does not currently read the values in the > > clap atom and it also does not map them to Matorksa files when > > remuxing. It seems to make the most sense to map them to PixelCrop, > > but I'd like to hear it from folks more knowledgable than me. > > Seems reasonable to me, but I=E2=80=99m not exactly certain what the mapp= ing would > be. > I was considering doing some experiments with some common PAL scenarios ( crop to 703x576 with a PAR of 59:54, or crop to 704x576 with PAR of 12:11) and using mkvpropedit to insert the metadata. I'll have to look beyond VLC to other players that can display these crops and aspect ratio conversions for the moment. > > Another associated issue with the display of these kinds of values is > > with VLC as it appears that > > > > 1) PixelCrop values in Matroska are not supported by VLC at the moment > > - https://trac.videolan.org/vlc/ticket/21192 > > 2) Clean aperture values are not supported by VLC at the moment > > https://trac.videolan.org/vlc/ticket/21179 > > Sounds like these tickets are in my priority order as well. > Cheers, Kieran O'Leary, Irish Film Institute > Dave Rice > > --000000000000e67740057ba8fe16 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey,

Thanks for replying:

On Sun, 25 Nov 2018, 20:20 Dave Rice <dave@dericed.com wrote:
Hi Kieran,

> On Nov 23, 2018, at 4:56 AM, Kieran O Leary <kieran.o.leary@g= mail.com> wrote:
>
> Hi,
>
> Would I be correct in saying that ideally, Clean Aperture values in a<= br> > MOV/MPEG-4 file should map to the PixelCrop element in Matroska?

Yes, they conceptually do the same thing but I=E2=80=99m a little confused = about how to use the vert/horiz offset fractions of the clap atom to conver= t to the pixel crop atom. I tried in both QuickTime 7 and X, and while Quic= kTime X uses the cleanAperature w/h fractions to present a cropped image, Q= uickTime 7 doesn=E2=80=99t but appears to adjust the aspect ratio according= to those values. QuickTime X does seem impacted by non-zero offset values = not in a way that I consider coherent. Do you have any examples of un-cente= red aperatures? I was hoping that IMX files would, does the ones I have don= =E2=80=99t use any aperature.

I don't think I've ever seen non-cente= red.. but it sounds like Matroska is capable of a mapping,but the actual qu= icktime implementation sounds inconsistent? I guess this could be specified= explicitly by an archivist who will hopefully be able to determine the int= ended rendering of the original QuickTime file..
Als= o it looks like here's yet another related ticket:=C2=A0


> I'm asking about this in regards to this ffmpeg ticket -
> https://trac.ffmpeg.org/ticket/7437
> As it appears that FFmpeg does not currently read the values in the > clap atom and it also does not map them to Matorksa files when
> remuxing. It seems to make the most sense to map them to PixelCrop, > but I'd like to hear it from folks more knowledgable than me.

Seems reasonable to me, but I=E2=80=99m not exactly certain what the mappin= g would be.

I was considering=C2=A0 doing some experiments with some common = PAL scenarios ( crop to 703x576 with a PAR of 59:54, or crop to 704x576 wit= h PAR of 12:11) and using mkvpropedit to insert the metadata. I'll have= to look beyond VLC to other players that can display these crops and aspec= t ratio conversions for the moment.


> Another associated issue with the display of these kinds of values is<= br> > with VLC as it appears that
>
> 1) PixelCrop values in Matroska are not supported by VLC at the moment=
> - https://trac.videolan.org/vlc/ticket/211= 92
> 2) Clean aperture values are not supported by VLC at the moment
> https://trac.videolan.org/vlc/ticket/21179=

Sounds like these tickets are in my priority order as well.

Cheers,

Kieran O'Leary,

Irish Film Institute
Dave Rice

--000000000000e67740057ba8fe16--