From nobody Tue Feb 2 11:51:10 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22391B3031 for ; Tue, 2 Feb 2016 11:51:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 NXNtMsJMPoPb for ; Tue, 2 Feb 2016 11:51:07 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E551B1B3030 for ; Tue, 2 Feb 2016 11:51:06 -0800 (PST) Received: from [146.96.19.240] (port=32142 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aQgye-002YfC-68; Tue, 02 Feb 2016 14:51:06 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_69E840C2-E0E1-4E07-9F38-4020BE0C4D3F" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Dave Rice In-Reply-To: <56A8DA3D.8050902@wanadoo.fr> Date: Tue, 2 Feb 2016 14:51:04 -0500 Message-Id: <2D0464C5-53AD-45C1-8541-8DCB7A1DA17C@dericed.com> References: <56A43AD8.7000904@wanadoo.fr> <56A8DA3D.8050902@wanadoo.fr> To: Pierre Choffet , "Questions, help, instructions, talk about Matroska" , cellar@ietf.org X-Mailer: Apple Mail (2.1990.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Steve Lhomme Subject: Re: [Cellar] [Matroska-users] [RFC] Documentary presenter tagging X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 02 Feb 2016 19:51:08 -0000 --Apple-Mail=_69E840C2-E0E1-4E07-9F38-4020BE0C4D3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 27, 2016, at 9:54 AM, Pierre Choffet via Matroska-users = wrote: >=20 > Le 26/01/2016 05:25, Steve Lhomme a =C3=A9crit : >> I agree with the additions, although we're in the process of formally >> standardizing Matroska at the IETF and tags will likely be discussed. >> So I'd refrain making such changes until we reach that part in the >> process.=20 > Hi Steve, thanks for your answer >=20 > Sounds good to me, I'll resubmit this request once the standardization > process has ended. In standardizing the metadata for the roles of contributions, it may = make sense to adopt an external authority. For instance PBCore manages a = vocabulary called contributorRole: = http://metadataregistry.org/concept/list/vocabulary_id/127.html = = http://v1.pbcore.org/PBCore/picklists/picklist_contributorRole.html = . = Adopting such a list may be more effective than okaying the values one = by one as requested. Dave Rice= --Apple-Mail=_69E840C2-E0E1-4E07-9F38-4020BE0C4D3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan 27, 2016, at 9:54 AM, Pierre Choffet via = Matroska-users <matroska-users@lists.matroska.org> wrote:

Le 26/01/2016 05:25, = Steve Lhomme a =C3=A9crit :
I agree with the additions, although we're in the process of = formally
standardizing Matroska at the IETF and tags will = likely be discussed.
So I'd refrain making such changes = until we reach that part in the
process.
Hi Steve, thanks for your answer
Sounds good to me, I'll resubmit this request once the = standardization
process has ended.

In = standardizing the metadata for the roles of contributions, it may make = sense to adopt an external authority. For instance PBCore manages a = vocabulary called contributorRole: http://metadataregistry.org/concept/list/vocabulary_id/127.html=  http://v1.pbcore.org/PBCore/picklists/picklist_contributorRole.= html. Adopting such a list may be more effective than okaying the = values one by one as requested.
Dave = Rice
= --Apple-Mail=_69E840C2-E0E1-4E07-9F38-4020BE0C4D3F-- From nobody Tue Feb 2 22:25:44 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84AE91A6F04 for ; Tue, 2 Feb 2016 22:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 MsAPkFvLGCMX for ; Tue, 2 Feb 2016 22:25:36 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CD6F1A6EF4 for ; Tue, 2 Feb 2016 22:25:36 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:44960 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aQqsa-003B1l-Jy; Wed, 03 Feb 2016 01:25:36 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_A38E5183-485D-4122-B9C1-837D324AEB17" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Date: Wed, 3 Feb 2016 01:25:26 -0500 References: <568C3CA0.8040300@mediaarea.net> To: Frank Galligan , cellar@ietf.org, Discussion about the current and future development of Matroska In-Reply-To: X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 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-devel] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 06:25:41 -0000 --Apple-Mail=_A38E5183-485D-4122-B9C1-837D324AEB17 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 22, 2016, at 5:54 PM, Frank Galligan via Matroska-devel = wrote: >=20 > On Thu, Jan 14, 2016 at 4:04 AM, Steve Lhomme > wrote: > 2016-01-06 23:30 GMT+01:00 Frank Galligan >: > > > > > > On Tue, Jan 5, 2016 at 1:58 PM, Jerome Martinez = > > > wrote: > >> > >> Thanks for your detailed proposal. > >> It is a lot of items, I am not expert in all domains but I have = some > >> comments: > > > > Neither am I, but I figured we might as well start from a proposal = and > > iterate from there. > > > >> > >> Name: MatrixCoefficients (or Matrix. You don't use "Colour" with > >> "Primaries" element, so I would not use it here too) > > > > Sounds good to me. > > > >> > >> > >> > >> > >> > >> Element Name: BitsPerChannel > >> Level: 5 > >> ID: [55][A2] > >> Mandatory: ma > >> Multiple: - > >> Default: 8 > >> Type: u > >> Description: Number of bits per channel. This number may be less = for > >> specific > >> channels depending on the ColourFormat and > >> ChromaSubsampling. > >> > >> > >> > >> BitsPerChannel is misleading, used to be the technical count of = bits. > >> I propose QuantizationBits or ValidBitsPerChannel > >> Not mandatory, not default (this value is often unknown) > > > > When authoring the video, I'm not sure why the software would not = know the > > bits per channel. Can you describe a use case where the this is = unknown? >=20 > When remuxing an older file. Either from Matroska source or AVI or = other. >=20 > Now if elements are mandatory with a default value to "unknown" it's = fine. >=20 > > I really think we should make this mandatory and have authoring = software > > populate the element (or default) vs software thinking this was > > non-mandatory and not populating this element because the developer = didn't > > think it was needed. > >> > >> > >> > >> > >> Element Name: ChromaSubsampling > >> Level: 5 > >> ID: [55][A3] > >> Mandatory: ma > >> Multiple: - > >> Default: 0 > >> Type: u > >> Description: (0: 4:2:0, 2: 4:2:2, 4: 4:4:4) > >> > >> > >> FFV1, for example, permits "weird" chroma values, more = possibilities. > >> And the following chroma values were seen at least once in some = specs: > >> 4:4:4 > >> 4:2:2 > >> 4:2:1 > >> 4:1:1 > >> 4:2:0 > >> 4:1:0 > >> 3:1:1 > >> > >> So having a list is maybe not the solution. > >> I like the way it is done in FFV1, except the power of 2 (so 3 can = not be > >> expressed). > >> I propose to find a way for describing Chroma subsampling (e.g. > >> h_chroma_subsample and v_chroma_subsample; a ratio per plane with = any number > >> of plane, think to alpha channel with a subsampling). > > > > I'm fine with coming up with a more extensible solution (Micheal = asked for > > that as well). > >> > >> > >> > >> > >> > >> > >> Element Name: ColourRange > >> Level: 5 > >> ID: [55][A4] > >> Mandatory: ma > >> Multiple: - > >> Default: 1 > >> Type: u > >> Description: (0: Unspecified, 1: Defined by > >> ColourMatrix/TransferFunction, > >> 2: Full range) > >> > >> > >> I don't understand the 1 value. > >> in at least AVC and HEVC, range is orthogonal to > >> ColourMatrix/TransferFunction. > >> I propose 0: unspecified 1: Broadcast range 1: Full range > >> and Default:0 > > > > I thought someone mentioned to me before that the range could change = based > > on the matrix and transfer function. I'm fine with your proposal. > > > >> > >> > >> > >> I got requests for having information about "Capture Gamma = Equation" (or > >> "Tone Curve"), e.g. "same as transfer characteristic", Scene = Linear, S-Log, > >> Cine-Log, Log-C... > >> I am not an expert of this domain, but looks like it is sometimes > >> important. > > > > Someone who knows more about this should propose something to this = list to > > be included. > > > >> > >> there are also other colour ideas with e.g. EBU Tech 3349. > > > > If this is important to people, then we could add this as well. > >> > >> > >> > >> > >> > >> > >> I can post a link to a formatted document if that would be easier. = For > >> Matrix, Range, and Primaries, I'm pretty much using values that map = directly > >> to values defined in FFmpeg. > >> > >> > >> I don't like the idea to use the source code of a piece of software = for > >> lists. Too much subjective, may have historical flaws. > >> Lists from FFmpeg are nearly same as the ones in H.26x, I think I = prefer > >> we base our list on their list (I don't think there are copyright = issues > >> with such list) directly. > > > > I don't know the H.26x list. I started with my own, but then = switched to > > FFmpeg as they already had an extensive list and assumed they have = seen a > > lot of the video already. > > > > If deciding between H.26x and FFmpeg, my guess is that FFmpeg would = be > > better as it handles a lot more video than H.26x. > > > >> > >> Or that we have a prefix with the origin of the list (e.g. ARIB = STD-B67, > >> from Japan, is not in ITU/ISO list, a 18 will be used in the future = for > >> something in ITU/ISO) > > > > Yeah HLG is relatively new, but has been requested by a few people. > > > > > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar = > > >=20 >=20 >=20 > -- > Steve Lhomme > Matroska association Chairman >=20 > So I updated my original proposal based on comments from this list. >=20 > Changes: > - Added more common ChromaSubsampling values > - ColourMatrix renamed to Matrix > - Added a default value of 0 to BitsPerChannel to signify = "unspecified". > - Added "decoded" to BitsPerChannel note. > - Added ChromaSittingHorz and ChromaSittingVert elements. In this case, I think the intended term is =E2=80=98siting=E2=80=99 = rather than =E2=80=98sitting=E2=80=99. > - Added Broadcast range to Range element. > - Removed mandatory flag for elements with unspecified defaults. > - Updated element IDs. >=20 >=20 > - I kept "Defined by Matrix/TransferFunction" in Range element because = there are ranges that fall outside of Broadcast and Full depending on = the TF. E.g. xvYCC (61966-2-4) > - Does someone want to propose something better for ChromaSubsampling? > - I know some people expressed that they don't think starting from = FFmpeg for the TransferFunction is a good idea as they might have got = something wrong or too subjective. But I just used it as a starting = point for a list. I can reorder the list however we want. I also don't = think following another list, so we will be compatible with future = additions, will give us what we want as that list most likely will be = incomplete with something that is defined only in a different list. So = should we just start with a list, re-order it (so we are not explicitly = following it), then add what is currently missing? Then in the future if = someone needs to add something to the list it can be brought up here? I think Jerome=E2=80=99s main point was that FFmpeg=E2=80=99s list = themselves were based on something else, so we should follow the source = for a vocabulary authority. For instance, see ITU Recommendation H.264 = at https://www.itu.int/rec/T-REC-H.264-201402-I/en, article E 39577. = Pages 387 (pdf page 409) gives a table of color primaries, page 388 has = transfer characteristics, and 392 has Matrix coefficients. The = information in the ITU docs provides a lot more context than FFmpeg = source code. > This is what I currently have: >=20 > The parent element would be Video [E0]. >=20 >=20 > Element Name: Colour > Level: 4 > ID: [55][A0] > Mandatory: - > Multiple: - > Default: - > Type: m > Description: Settings describing the colour format. >=20 >=20 > Element Name: Matrix > Level: 5 > ID: [55][A1] > Mandatory: - > Multiple: - > Default: 2 > Type: u > Description: Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB), 1: = BT709, > 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: = SMPTE 170M, > 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant = Luminance, > 10: BT2020 Constant Luminance)=20 I suggest referencing a specific ITU document for these values and their = meaning. > Element Name: BitsPerChannel > Level: 5 > ID: [55][A2] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: Number of decoded bits per channel. This number may be = less for=20 > specific channels depending on the Matrix and = ChromaSubsampling. A > value of 0 is unspecified. >=20 >=20 > Element Name: ChromaSubsampling > Level: 5 > ID: [55][A3] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1, = 5: 4:2:0, =20 > 6: 4:1:1, 7: 4:1:0, 8: 3:1:1) >=20 > Element Name: ChromaSittingHorz Siting > Level: 5 > ID: [55][A4] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: How Chroma is subsampled horizontally. (0: Unspecified, = 1: Left=20 > collocated , 2: Half) >=20 > Element Name: ChromaSittingVert Siting > Level: 5 > ID: [55][A5] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: How Chroma is subsampled vertically. (0: Unspecified, 1: = Top > collocated , 2: Half) >=20 >=20 > Element Name: Range > Level: 5 > ID: [55][A6] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: (0: Unspecified, 1: Broadcast range, 2: Full range, 3: = Defined by=20 > Matrix/TransferFunction) I think a description (beyond the list) is needed. > Element Name: TransferFunction > Level: 5 > ID: [55][A7] > Mandatory: - > Multiple: - > Default: 2 > Type: u > Description: Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified, > 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, > 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, > 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut, > 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, > 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, > 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) Consider referencing ITU document as an external authority for the = vocabulary.=20 > Element Name: Primaries > Level: 5 > Mandatory: - > Multiple: - > ID: [55][A8] > Default: 2 > Description: (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R = BT.470M, > 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: = FILM, > 9: ITU-R BT.2020, 10: SMPTE ST 428-1) Consider reference to ITU document. Needs a description besides list. > Element Name: MaxCLL > Level: 5 > ID: [55][A9] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: Maximum brightness of a single pixel in candelas per = square > meter (cd/m=C2=B2). >=20 >=20 > Element Name: MaxFALL > Level: 5 > ID: [55][AA] [55][AA] is already in use as FlagForced. > Mandatory: - > Multiple: - > Default: - > Type: u > Description: Maximum brightness of a single full frame in candelas = per square > meter (cd/m=C2=B2). >=20 >=20 > Element Name: MasteringMetadata > Level: 5 > ID: [55][D0] > Mandatory: - > Multiple: - > Default: - > Type: m > Description: SMPTE 2086 mastering data. I=E2=80=99m not well experienced in MasteringMetadata but wouldn=E2=80=99t= this data need to change from scene to scene rather than be stored = within the Tracks element where the same values would apply to all = scenes? > Element Name: PrimaryRChromaticityX > Level: 6 > ID: [55][D1] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Valid value is in the range 0 <=3D f <=3D 1. The description is actually a range. When we initially drafted = information on expressing ranges in EBML definitions, I ignored float, = see = https://github.com/Matroska-Org/ebml-specification/blob/master/specificati= on.markdown#expression-of-range. I can update this definition to include = floats and greater-than-or-equal values. But the description for this = and the following elements should be moved to range (suggested = formatting as "0-1=E2=80=9D). Then these elements need actual = descriptions. > Element Name: PrimaryRChromaticityY > Level: 6 > ID: [55][D2] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Valid value is in the range 0 <=3D f <=3D 1. >=20 >=20 > Element Name: PrimaryGChromaticityX > Level: 6 > ID: [55][D3] > Mandatory: - > Multiple: - > Default: - > f > Description: Valid value is in the range 0 <=3D f <=3D 1. >=20 >=20 > Element Name: PrimaryGChromaticityY > Level: 6 > ID: [55][D4] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Valid value is in the range 0 <=3D f <=3D 1. >=20 >=20 > Element Name: PrimaryBChromaticityX > Level: 6 > ID: [55][D5] > Mandatory: - > Multiple: - > Default: - > f > Description: Valid value is in the range 0 <=3D f <=3D 1. >=20 >=20 > Element Name: PrimaryBChromaticityY > Level: 6 > ID: [55][D6] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Valid value is in the range 0 <=3D f <=3D 1. >=20 >=20 > Element Name: WhitePointChromaticityX > Level: 6 > ID: [55][D7] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Valid value is in the range 0 <=3D f <=3D 1. >=20 >=20 > Element Name: WhitePointChromaticityY > Level: 6 > ID: [55][D8] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Valid value is in the range 0 <=3D f <=3D 1. >=20 >=20 > Element Name: LuminanceMax > Level: 6 > ID: [55][D9] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Maximum luminance. Shall be represented in candelas per = square > meter (cd/m=C2=B2). Valid value is in the range 0 <=3D f = <=3D 9999.99 Add a Range value and split the Description and Range. > Element Name: LuminanceMin > Level: 6 > ID: [55][DA] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Minimum luminance. Shall be represented in candelas per = square > meter (cd/m=C2=B2). Valid value is in the range 0 <=3D f = <=3D 999.9999 Add a Range value and split the Description and Range. Best Regards, Dave Rice --Apple-Mail=_A38E5183-485D-4122-B9C1-837D324AEB17 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 22, 2016, at 5:54 PM, = Frank Galligan via Matroska-devel <matroska-devel@lists.matroska.org> wrote:

On Thu, Jan 14, 2016 at = 4:04 AM, Steve Lhomme <slhomme@matroska.org> wrote:
2016-01-06 23:30 GMT+01:00 Frank Galligan <frankgalligan@gmail.com>:
>
>
> On Tue, Jan 5, 2016 at 1:58 PM, Jerome Martinez <jerome@mediaarea.net>
> wrote:
>>
>> Thanks for your detailed proposal.
>> It is a lot of items, I am not expert in all domains but I have = some
>> comments:
>
> Neither am I, but I figured we might as well start from a proposal = and
> iterate from there.
>
>>
>> Name: MatrixCoefficients (or Matrix. You don't use "Colour" = with
>> "Primaries" element, so I would not use it here too)
>
>  Sounds good to me.
>
>>
>>
>>
>>
>>
>> Element Name: BitsPerChannel
>> Level:        5
>> ID:           [55][A2]
>> Mandatory:    ma
>> Multiple:     -
>> Default:      8
>> Type:         u
>> Description:  Number of bits per channel. This number may = be less for
>> specific
>>               channels = depending on the ColourFormat and
>> ChromaSubsampling.
>>
>>
>>
>> BitsPerChannel is misleading, used to be the technical count of = bits.
>> I propose QuantizationBits or ValidBitsPerChannel
>> Not mandatory, not default (this value is often unknown)
>
> When authoring the video, I'm not sure why the software would not = know the
> bits per channel. Can you describe a use case where the this is = unknown?

When remuxing an older file. Either from Matroska source or = AVI or other.

Now if elements are mandatory with a default value to "unknown" it's = fine.

> I really think we should make this mandatory and have authoring = software
> populate the element (or default) vs software thinking this was
> non-mandatory and not populating this element because the developer = didn't
> think it was needed.
>>
>>
>>
>>
>> Element Name: ChromaSubsampling
>> Level:        5
>> ID:           [55][A3]
>> Mandatory:    ma
>> Multiple:     -
>> Default:      0
>> Type:         u
>> Description:  (0: 4:2:0, 2: 4:2:2, 4: 4:4:4)
>>
>>
>> FFV1, for example, permits "weird" chroma values, more = possibilities.
>> And the following chroma values were seen at least once in some = specs:
>> 4:4:4
>> 4:2:2
>> 4:2:1
>> 4:1:1
>> 4:2:0
>> 4:1:0
>> 3:1:1
>>
>> So having a list is maybe not the solution.
>> I like the way it is done in FFV1, except the power of 2 (so 3 = can not be
>> expressed).
>> I propose to find a way for describing Chroma subsampling = (e.g.
>> h_chroma_subsample and v_chroma_subsample; a ratio per plane = with any number
>> of plane, think to alpha channel with a subsampling).
>
> I'm fine with coming up with a more extensible solution (Micheal = asked for
> that as well).
>>
>>
>>
>>
>>
>>
>> Element Name: ColourRange
>> Level:        5
>> ID:           [55][A4]
>> Mandatory:    ma
>> Multiple:     -
>> Default:      1
>> Type:         u
>> Description:  (0: Unspecified, 1: Defined by
>> ColourMatrix/TransferFunction,
>>               2: Full = range)
>>
>>
>> I don't understand the 1 value.
>> in at least AVC and HEVC, range is orthogonal to
>> ColourMatrix/TransferFunction.
>> I propose 0: unspecified 1: Broadcast range 1: Full range
>> and Default:0
>
> I thought someone mentioned to me before that the range could = change based
> on the matrix and transfer function. I'm fine with your = proposal.
>
>>
>>
>>
>> I got requests for having information about "Capture Gamma = Equation" (or
>> "Tone Curve"), e.g. "same as transfer characteristic", Scene = Linear, S-Log,
>> Cine-Log, Log-C...
>> I am not an expert of this domain, but looks like it is = sometimes
>> important.
>
> Someone who knows more about  this should propose something to = this list to
> be included.
>
>>
>> there are also other colour ideas with e.g. EBU Tech 3349.
>
> If this is important to people, then we could add this as well.
>>
>>
>>
>>
>>
>>
>> I can post a link to a formatted document if that would be = easier. For
>> Matrix, Range, and Primaries, I'm pretty much using values that = map directly
>> to values defined in FFmpeg.
>>
>>
>> I don't like the idea to use the source code of a piece of = software for
>> lists. Too much subjective, may have historical flaws.
>> Lists from FFmpeg are nearly same as the ones in H.26x, I think = I prefer
>> we base our list on their list (I don't think there are = copyright issues
>> with such list) directly.
>
> I don't know the H.26x list. I started with my own, but then = switched to
> FFmpeg as they already had an extensive list and assumed they have = seen a
> lot of the video already.
>
> If deciding between H.26x and FFmpeg, my guess is that FFmpeg would = be
> better as it handles a lot more video than H.26x.
>
>>
>> Or that we have a prefix with the origin of the list (e.g. ARIB = STD-B67,
>> from Japan, is not in ITU/ISO list, a 18 will be used in the = future for
>> something in ITU/ISO)
>
> Yeah HLG is relatively new, but has been requested by a few = people.
>
>
>
> = _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar
= >



--
Steve Lhomme
Matroska association Chairman

So I updated my original proposal based = on comments from this list.

Changes:
- Added more common = ChromaSubsampling values
- ColourMatrix renamed to = Matrix
- Added a default value of 0 to = BitsPerChannel to signify "unspecified".
- Added = "decoded" to BitsPerChannel note.
- Added = ChromaSittingHorz and ChromaSittingVert = elements.

In this case, I think the intended term is = =E2=80=98siting=E2=80=99 rather than =E2=80=98sitting=E2=80=99.

- Added Broadcast range to Range = element.
- Removed mandatory flag for elements with = unspecified defaults.
- Updated element = IDs.


- I kept "Defined by Matrix/TransferFunction" in Range element because = there are ranges that fall outside of Broadcast and Full depending on = the TF. E.g. xvYCC (61966-2-4)
- Does someone want = to propose something better for ChromaSubsampling?
- = I know some people expressed that they don't think starting from FFmpeg = for the TransferFunction is a good idea as they might have got something = wrong or too subjective. But I just used it as a starting point for a = list. I can reorder the list however we want. I also don't think = following another list, so we will be compatible with future additions, = will give us what we want as that list most likely will be incomplete = with something that is defined only in a different list. So should we = just start with a list, re-order it (so we are not explicitly following = it), then add what is currently missing? Then in the future if someone = needs to add something to the list it can be brought up = here?

I think Jerome=E2=80=99s main point was that = FFmpeg=E2=80=99s list themselves were based on something else, so we = should follow the source for a vocabulary authority. For instance, see = ITU Recommendation H.264 at https://www.itu.int/rec/T-REC-H.264-201402-I/en, article = E 39577. Pages 387 (pdf page 409) gives a table of color primaries, page = 388 has transfer characteristics, and 392 has Matrix coefficients. The = information in the ITU docs provides a lot more context than FFmpeg = source code.

This is what I currently = have:

The parent = element would be Video [E0].


Element = Name: Colour
Level: =        4
ID: =           [55][A0]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         m
Description:=  Settings describing the colour format.


Element = Name: Matrix
Level: =        5
ID: =           [55][A1]
Mandatory: =    -
Multiple: =     -
Default: =      2
Type: =         u
Description:=  Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB), 1: = BT709,
=             &n= bsp;2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE = 170M,
=             &n= bsp;7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant = Luminance,
=             &n= bsp;10: BT2020 Constant Luminance) =

I suggest referencing a specific ITU document for = these values and their meaning.

Element = Name: BitsPerChannel
Level: =        5
ID: =           [55][A2]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:=  Number of decoded bits per channel. This number may be less for =
=             &n= bsp;specific channels depending on the Matrix and ChromaSubsampling. = A
=             &n= bsp;value of 0 is unspecified.


Element = Name: ChromaSubsampling
Level: =        5
ID: =           [55][A3]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:=  (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1, 5: = 4:2:0, =             
=             &n= bsp;6: 4:1:1, 7: 4:1:0, 8: 3:1:1)

Element = Name: = ChromaSittingHorz

Siting

Level: =        5
ID: =           [55][A4]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:=  How Chroma is subsampled horizontally. (0: Unspecified, 1: Left =
=             &n= bsp;collocated , 2: Half)

Element = Name: = ChromaSittingVert

Siting

Level: =        5
ID: =           [55][A5]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:=  How Chroma is subsampled vertically. (0: Unspecified, 1: = Top
=             &n= bsp;collocated , 2: Half)


Element = Name: Range
Level: =        5
ID: =           [55][A6]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:=  (0: Unspecified, 1: Broadcast range, 2: Full range, 3: Defined by =
=             &n= bsp;Matrix/TransferFunction)

I think a description = (beyond the list) is needed.

Element = Name: TransferFunction
Level: =        5
ID: =           [55][A7]
Mandatory: =    -
Multiple: =     -
Default: =      2
Type: =         u
Description:=  Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified,
=             &n= bsp;4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE = 170M,
=             &n= bsp;7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt,
=             &n= bsp;11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut,
=             &n= bsp;13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit,
=             &n= bsp;15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084,
=             &n= bsp;17: SMPTE ST 428-1 18: ARIB STD-B67 = (HLG))
=
Consider referencing ITU document as an = external authority for the vocabulary. 

Element = Name: Primaries
Level: =        5
Mandatory: =    -
Multiple: =     -
ID: =           [55][A8]
Default: =      2
Description:=  (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R = BT.470M,
=             &n= bsp; 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: = FILM,
=             &n= bsp; 9: ITU-R BT.2020, 10: SMPTE ST = 428-1)
=
Consider reference to ITU document. Needs a = description besides list.

Element = Name: MaxCLL
Level: =        5
ID: =           [55][A9]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:=  Maximum brightness of a single pixel in candelas per = square
=             &n= bsp;meter (cd/m=C2=B2).


Element = Name: MaxFALL
Level: =        5
ID: =           [55][AA]

[55][AA] is already in use as FlagForced.

Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:=  Maximum brightness of a single full frame in candelas per = square
=             &n= bsp;meter (cd/m=C2=B2).


Element = Name: MasteringMetadata
Level: =        5
ID: =           [55][D0]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         m
Description:=  SMPTE 2086 mastering = data.
<= br class=3D"">
I=E2=80=99m not well experienced in = MasteringMetadata but wouldn=E2=80=99t this data need to change from = scene to scene rather than be stored within the Tracks element where the = same values would apply to all scenes?

Element = Name: PrimaryRChromaticityX
Level: =        6
ID: =           [55][D1]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         f
Description:=  Valid value is in the range 0 <=3D f <=3D = 1.

The description is actually a range. When we = initially drafted information on expressing ranges in EBML definitions, = I ignored float, see https://github.com/Matroska-Org/ebml-specification/blob/master/= specification.markdown#expression-of-range. I can update this = definition to include floats and greater-than-or-equal values. But the = description for this and the following elements should be moved to range = (suggested formatting as "0-1=E2=80=9D). Then these elements need actual = descriptions.

Element = Name: PrimaryRChromaticityY
Level: =        6
ID: =           [55][D2]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         f
Description:=  Valid value is in the range 0 <=3D f <=3D = 1.


Element = Name: PrimaryGChromaticityX
Level: =        6
ID: =           [55][D3]
Mandatory: =    -
Multiple: =     -
Default: =      -
f
Description:=  Valid value is in the range 0 <=3D f <=3D = 1.


Element = Name: PrimaryGChromaticityY
Level: =        6
ID: =           [55][D4]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         f
Description:=  Valid value is in the range 0 <=3D f <=3D = 1.


Element = Name: PrimaryBChromaticityX
Level: =        6
ID: =           [55][D5]
Mandatory: =    -
Multiple: =     -
Default: =      -
f
Description:=  Valid value is in the range 0 <=3D f <=3D = 1.


Element = Name: PrimaryBChromaticityY
Level: =        6
ID: =           [55][D6]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         f
Description:=  Valid value is in the range 0 <=3D f <=3D = 1.


Element = Name: WhitePointChromaticityX
Level: =        6
ID: =           [55][D7]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         f
Description:=  Valid value is in the range 0 <=3D f <=3D = 1.


Element = Name: WhitePointChromaticityY
Level: =        6
ID: =           [55][D8]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         f
Description:=  Valid value is in the range 0 <=3D f <=3D = 1.


Element = Name: LuminanceMax
Level: =        6
ID: =           [55][D9]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         f
Description:=  Maximum luminance. Shall be represented in candelas per = square
=             &n= bsp;meter (cd/m=C2=B2). Valid value is in the range 0 <=3D f <=3D = 9999.99

Add a Range value and split the Description = and Range.

Element = Name: LuminanceMin
Level: =        6
ID: =           [55][DA]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         f
Description:=  Minimum luminance. Shall be represented in candelas per = square
=             &n= bsp;meter (cd/m=C2=B2). Valid value is in the range 0 <=3D f <=3D = 999.9999

Add a Range value and split the Description and = Range.

Best Regards,
Dave = Rice

= --Apple-Mail=_A38E5183-485D-4122-B9C1-837D324AEB17-- From nobody Tue Feb 2 22:26:06 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233A61A6F0B for ; Tue, 2 Feb 2016 22:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.416 X-Spam-Level: *** X-Spam-Status: No, score=3.416 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=1.836, SPF_NEUTRAL=0.779] autolearn=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 QF1zZJfKqowq for ; Tue, 2 Feb 2016 22:25:50 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94F5B1A6EF4 for ; Tue, 2 Feb 2016 22:25:50 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:44960 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aQqsl-003B1l-Vk for cellar@ietf.org; Wed, 03 Feb 2016 01:25:50 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_2E51B7EC-5600-41B6-B537-8451096DAA66" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Date: Wed, 3 Feb 2016 01:25:39 -0500 References: <21E28D45-E45F-4CBE-AC3D-6E41DCE172B9@dericed.com> <20150828065002.GH3813@bunkus.org> <5606B89B-FCF0-4C75-BAB8-FB1E212F8D82@dericed.com> <5EDBE9D2-3E2F-4865-ACF9-497706E0CA07@dericed.com> <87110F5D-3199-4CF5-887E-D5B8C7A08C6C@dericed.com> To: cellar@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=1.5 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] EBML Schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 06:25:58 -0000 --Apple-Mail=_2E51B7EC-5600-41B6-B537-8451096DAA66 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 23, 2016, at 2:49 PM, Dave Rice wrote: >=20 >=20 >> On Jan 17, 2016, at 8:05 AM, Steve Lhomme > wrote: >>=20 >> 2016-01-15 16:35 GMT+01:00 Dave Rice >: >>>=20 >>>> On Jan 15, 2016, at 7:44 AM, Steve Lhomme > wrote: >>>>=20 >>>> 2016-01-15 7:27 GMT+01:00 Dave Rice >: >>>>>=20 >>>>> On Dec 1, 2015, at 10:40 AM, Dave Rice > wrote: >>>>>=20 >>>>> On Nov 9, 2015, at 1:19 PM, Dave Rice > wrote: >>>>>=20 >>>>> On Oct 3, 2015, at 9:46 AM, Steve Lhomme > wrote: >>>>>=20 >>>>> On Aug 28, 2015 17:00, "Dave Rice" > wrote: >>>>>=20 >>>>>>> On Aug 28, 2015, at 2:50 AM, Moritz Bunkus > wrote: >>>>>>>=20 >>>>>>> Hey, >>>>>>>=20 >>>>>>> I have no objections, however I don't know a lot about XML = schemas in >>>>>>> the first place (neither about DTDs, to be honest). >>>>>>=20 >>>>>>=20 >>>>>> Honestly, I know a lot more about XML Schemas than I do about = DTDs. As >>>>>> wikipedia mentions at >>>>>> https://en.wikipedia.org/wiki/Document_type_definition = , DTDs have = largely >>>>>> been superseded by XML Schemas. And at this point I think that = XML Schemas >>>>>> may be a more familiar analogy to use. >>>>>>=20 >>>>>> I think XML Schemas also share more in common with specdata.xml = than DTDs >>>>>> do. Schemas use the node and have maxOccurs and = minOccurs >>>>>> attributes (specdata has semantically the same thing with = mandatory and >>>>>> multiple), they both have a similar declaration of element type, = element >>>>>> name and element description. Actually I think a semantically = equivalent >>>>>> version of specdata.xml could be written as an XML Schema. >>>>>>=20 >>>>>> XML Schemas also offer a few advantages for machine readable = expressions; >>>>>> for instance XML Schemas can mandate a particular pattern or = regex for a >>>>>> value. >>>>>>=20 >>>>>>>> I propose the specdata.xml file here >>>>>>>>=20 >>>>>>>> = https://github.com/Matroska-Org/foundation-source/blob/master/spectool/spe= cdata.xml = >>>>>>>>=20 >>>>>>>> = >>>>>>>> is a good basis for the consideration of an EBML Schema. =46rom = what I >>>>>>>> can see, specdata.xml is an expression of the EBML + Matroska >>>>>>>> specifications to support automated creation of documentation, = but the >>>>>>>> structure of this already shares a lot of similarity to XML = Schemas. >>>>>>>=20 >>>>>>>=20 >>>>>>> For both documentation (e.g. the table on the matroska.org = specs page is >>>>>>> generated from this file) and code (libMatroska's class = hierarchy is >>>>>>> generated automatically from this file) actually. >>>>>>=20 >>>>>>=20 >>>>>> Does specdata.xml play a role in mkvalidate? I'm thinking of the = potential >>>>>> to have an ebmlvalidator where you can provide the EBML Schema to = validate >>>>>> particular EBML docType. >>>>>=20 >>>>> Well the parsing code is generated from the XML file, so in a way, = yes. But >>>>> it's not parsed "live". >>>>>=20 >>>>>>>> Is there a preference in handling the standardization of = Matroska: >>>>>>>> documenting it in a similar fashion to our work in the EBML = spec or to >>>>>>>> define what an EBML Schema is and consider matroska an = expression of >>>>>>>> it? >>>>>>>=20 >>>>>>>=20 >>>>>>> I'm not sure whether or not I understand the implications. But = my gut >>>>>>> feeling is that having a definition for an EBML Schema would = benefit >>>>>>> other formats than Matroska, too, therefore the latter seems the = way to >>>>>>> go. >>>>>>=20 >>>>>>=20 >>>>>> I have the same feeling: >>>>>> - document EBML as a specification that includes rules for = defining a >>>>>> docType in the form of an EBML Schema >>>>>> - write an EBML Schema (updated specdata.xml) for Matroska and = maybe webM >>>>>>=20 >>>>>>>> Are some changes to specdata.xml acceptable? Such as a filename = change >>>>>>>> or changing the name of the element of some attributes? >>>>>>>=20 >>>>>>>=20 >>>>>>> Well, like I said above the specdata.xml is used for generating = both >>>>>>> documentation and code. Both should stay viable. If changes to = it are >>>>>>> made then the accompanying tools must be updated as well. >>>>>>>=20 >>>>>>>> Neither the current EBML specs nor the specdata.xml = specifically refer >>>>>>>> to the hierarchical arrangement of the elements, but this could = be >>>>>>>> presumed by their ordering. For instance, could any level 3 = element be >>>>>>>> a child of any level 2 Master-element? I presume not, but I = don't >>>>>>>> think it's clear anywhere what parent-child relationships are >>>>>>>> feasible. Possibly specdata.xml and/or the EBML Schema = Definition >>>>>>>> could define the relationship between levels of related = elements >>>>>>>> similar to how an XML Schema (XSD) does. >>>>>>>=20 >>>>>>>=20 >>>>>>> So far it is understood that an element not marked as a global = element >>>>>>> must only occur as a child of its parent. Its parent is the last = element >>>>>>> located before the child element in the specdata file with a = lower level >>>>>>> than the child element. Or something like that. >>>>>>=20 >>>>>>=20 >>>>>> This will need some documentation. That's how I've understood the = mkv spec >>>>>> as well but the definition for how an EBML Schema works should be = explicit >>>>>> about this. >>>>>=20 >>>>> Any more opinion about how to go about (or if to go about) = modifying >>>>> specdata.xml towards becoming an expression of a to-be-defined = EBML Schema >>>>> for matroska and webm? As a summary of proposed changes to = specdata.xml >>>>>=20 >>>>> - change to XML Schema conventions where relevant: >>>>> - use maxOccurs attribute instead of the current Multiple = attribute. >>>>> - use minOccurs attribute instead of the current Mandatory = attribute. >>>>> - move documentation of elements to a sub-element (allows for = possible >>>>> internationalization in the schema and better semantics) >>>>> - arrange elements in hierarchical form to indicate parent-child >>>>> relationships (rather than the current practices where all = elements are >>>>> defined at the same level, and you have to parse back in elements = to the one >>>>> with the lower-numbered level attribute to find the parent) >>>>>=20 >>>>> A draft of specdata.xml with these changes is at >>>>> https://gist.github.com/dericed/f0a4bb0e7dc635ed1347 = . I can continue = to work >>>>> on this and send back changes for advice/approval but if I do so = is there >>>>> someone who could later update the tools that use specdata.xml so = that >>>>> newly-defined EBML Schemas may later to be into use? >>>>>=20 >>>>>=20 >>>>> I=E2=80=99m preparing a pull request on specdata.xml but want to = update the >>>>> utilities in spectool at the same time so that spec2data, = data2lib, and >>>>> data2spec still function properly. I=E2=80=99m having trouble = getting the spectool >>>>> utilities to build properly so that I can test them. I was able to = build >>>>> coremake but not sure where to go from here. I=E2=80=99ve read = spec2data and have an >>>>> idea of how it works and am thinking that I could reproduce the = spec2data >>>>> workflow with xsl and then we could have a make file which uses = xsltproc to >>>>> convert an EBML Schema into the Drupal table and library files as = needed. >>>>> Any advice on which route to take: continue trying with getting = spectool >>>>> utilities to build or redo the utilities in xsl? >>>>>=20 >>>>>=20 >>>>> I=E2=80=99d like to revive this thread to propose some changes in = the definition of >>>>> the EBML Schema. The EBML Schema is intended to be a = machine-readible >>>>> document that details the semantics and structure of an EBML = Document Type. >>>>> The EBML Schema for a Document Type is essential for understanding = the >>>>> semantics and validating an EBML Document. This proposal builds = upon an >>>>> earlier conversation started last year on matroska-devel, >>>>> = http://lists.matroska.org/pipermail/matroska-devel/2015-August/004765.html= = , >>>>> = http://lists.matroska.org/pipermail/matroska-devel/2015-October/004807.htm= l = . >>>>>=20 >>>>> I=E2=80=99m open to other solutions or approaches, but since = Matroska is based on >>>>> EBML which itself is becoming well-defined. I think there is = utility in >>>>> documenting how to create a machine-readible document that = describes an EBML >>>>> Document Type. I think the concept of the XML Schema and XML = Document is >>>>> analogous to EBML Schema and EBML Document and that adopting from = the XML >>>>> community for documenting form may be beneficial. >>>>>=20 >>>>> Thus far we have this section >>>>> = https://github.com/Matroska-Org/ebml-specification/blob/3b30502d2adb6a22c6= 0294c1e7ea68f703e07e50/specification.markdown#ebml-schema = >>>>> which introduces the concept for the EBML Schema and then provides = a list of >>>>> attributes for defining Elements that make up a specific EBML = Document Type >>>>> = https://github.com/Matroska-Org/ebml-specification/blob/3b30502d2adb6a22c6= 0294c1e7ea68f703e07e50/specification.markdown#ebml-schema-element-attribut= es. >>>>> This documentation currently reflects the specdata.xml file of the = Matroska >>>>> foundation-source repo, which is here >>>>> = https://github.com/Matroska-Org/foundation-source/blob/master/spectool/spe= cdata.xml. >>>>> The specdata.xml file is used to create the HTML table of elements = on >>>>> http://matroska.org/technical/specs/index.html and libraries used = by >>>>> mkvalidate and other files. After drafting the EBML Schema and = Attribute >>>>> documentation I found >>>>> http://matroska.org/technical/specs/notes.html#Table_Columns which = covers >>>>> similar concepts. >>>>>=20 >>>>> I=E2=80=99d like to propose the following changes to the = definition of EBML Schema: >>>>>=20 >>>>> - Replace
with . >>>>>=20 >>>>> The node
makes sense in the context of the HTML table on >>>>> matroska.org but if there will be greater machine-readible usage I = think a >>>>> rename would clarify. >>>>>=20 >>>>> - Add an XML NameSpace attribute to . >>>>>=20 >>>>> This would add something like >>>>> = xmlns=3D=E2=80=9Chttp://official_url_of_EBML_Schema_definition.org/EBMLSch= ema.xsd=E2=80=9D. >>>>> The EBMLSchema.xsd file would be an XML Schema that defines the = EBMLSchema >>>>> document itself. Yes, this uses an XML Schema to define the EBML = Schema, but >>>>> this gives a way to validate the EBML Schemas and docType = definitions made >>>>> by others. >>>>>=20 >>>>> - Add a =E2=80=9CdocType=E2=80=9D attribute to >>>>>=20 >>>>> This would clarify what the EBMLSchema is documenting, thus it = would start >>>>> with >>>>>=20 >>>>> - Add =E2=80=9Cversion=E2=80=9D attribute to >>>>>=20 >>>>> This would note the highest version number of the docType = officially >>>>> documented by the EBML Schema, so the EBML Schema would be = inferred to >>>>> document the noted docType from version 0 up to the version value = listed >>>>> here. >>>>=20 >>>> Maybe we need something to say it's the final version or a draft. >>>=20 >>> With XML Schemas this is done by having an entirely separate = document per version. We could have separate files such as: >>>=20 >>> matroska_v1.xml >>> matroska_v2.xml >>> matroska_v3.xml >>> matroska_v4.xml >>> matroska_v5RC.xml >>> webm_v1.xml >>>=20 >>> Or we could add an attribute called something like "unofficial" so = that we may have an EBML Schema with non-standardized elements for = testing. >>>=20 >>> Any preference at which tactic? An advantage of having versioned = EBML Schemas (one doc per version) is that the deprecated elements are = simply removed rather than an eternal lingering presence. It may accept = complexity in use though since you'd have to use the proper schema that = matches both the docType and docTypeVersion. >>=20 >> That makes omission by mistake a possibility, involves more proof >> reading and it becomes harder to know which elements changed between >> what versions. It's also harder to process to generate code. Also >> should the documentation we currently have be duplicated on each >> document ? I'd rather keep a single document. >>=20 >>>>> - Rename =E2=80=9Cmandatory=E2=80=9D as =E2=80=9CminOccurs=E2=80=9D = and rename =E2=80=9Cmultiple=E2=80=9D as =E2=80=9CmaxOccurs=E2=80=9D >>>>=20 >>>> That may be odd when we add "repeatable" elements that must be = maxOccurs =3D 1. >>>=20 >>> With maxOccurs it is usually set via numbers, however 'unbounded' is = an accepted maxOccurs value to say that the element may repeat for an = infinite amount of times. In addition to "unbounded" we could also add a = value "identical" which would mean the same as "unbounded" with the = added constraint that every copy be identical. >>=20 >> That sounds good, yes. >>=20 >>>>> This is to match the meaning of minOccurs and maxOccurs in XML = Schema, >>>>> https://www.w3.org/TR/xmlschema-0/#ref6 = . >>>>> mandatory=3D=E2=80=9C0=E2=80=9D would be equivalent to = minOccurs=3D=E2=80=9C0" >>>>> mandatory=3D=E2=80=9C1=E2=80=9D would be equivalent to = minOccurs=3D=E2=80=9C1=E2=80=9D >>>>> no mandatory attribute would be equivalent of no minOccurs = attribute which >>>>> is equivalent to minOccurs=3D=E2=80=9C1=E2=80=9D (as is true with = minOccurs within an XML >>>>> Schema) >>>>>=20 >>>>> multiple=3D=E2=80=9C0=E2=80=9D would be equivalent to maxOccurs = =3D=E2=80=9C1" >>>>> multiple =3D=E2=80=9C1=E2=80=9D would be equivalent to maxOccurs = =3D=E2=80=9Cunbounded=E2=80=9D >>>>> no multiple attribute would be equivalent of no maxOccurs = attribute which is >>>>> equivalent to maxOccurs =3D=E2=80=9C1=E2=80=9D (as is true with = maxOccurs within an XML >>>>> Schema) >>>>>=20 >>>>> Moving from mandatory/multiple to minOccurs/maxOccurs can be done = with no >>>>> semantic differences, but we=E2=80=99d have to advantage of = allowing for constraints >>>>> to the number of usage that are not 0, 1, and infinite. For = instance, I >>>>> understand the logic to have 2 SeekHead Elements, but is there a = scenario >>>>> for 3 or more SeekHeads at the same Level within the same EBML = Document? >>>>=20 >>>> Limiting the amount of redirection might be a good thing indeed. >>>=20 >>> Are there other elements currently listed as multiple=3D"1" where = they are intended for use greater than 1 and less than unbounded. = SeekHead was the only one coming to mind. >>=20 >> Not from the top of my mind. >>=20 >>>>> - Store nodes hierarchically rather than all at the same = level. >>>>>=20 >>>>> Currently with in the specdata.xml file it is difficult to = ascertain the >>>>> parent of a given element. It can be done by seeking to the = previous element >>>>> where the level of the element is one value lower, but there are = exceptions >>>>> for global elements. I suggest that a structure of >>>>> >>>>> ... >>>>> ... >>>>> >>>>> is more clear than all elements at the same level. I made an = example draft >>>>> of specdata.xml with nested implementing here: >>>>> https://gist.github.com/dericed/f0a4bb0e7dc635ed1347 = . >>>>>=20 >>>>> I can provide a patch to the current EBML Schema and EBML Schema = Attributes >>>>> as well as incorporate a sample EBML Schema into the = specification, but >>>>> wanted to nudge for comments before proceeding. >>>>=20 >>>> The current flat hierarchy is not good anyway. I will need a bit of >>>> time to update the spec tools accordingly. But the change is OK for >>>> me. >>>=20 >>> Thanks. Should I cross-post this to webm lists? >>=20 >> No idea if they use the document but it's worth a try. >=20 > Here are some changes made to the definition of EBML Schema. I placed = them into a pull request in github, = https://github.com/Matroska-Org/ebml-specification/pull/51/files = , and = will summarize the changes here. >=20 > I removed the attributes for mandatory, multiple, and identical and = replaced them with minOccurs and maxOccurs (see in context at = https://github.com/MediaArea/ebml-specification/blob/ebml-schema-refactor/= specification.markdown#ebml-schema-element-attributes = ) >=20 > minOccurs: > An integer to express the minimal number of occurrences that the EBML = Element MUST occur within its Parent Element if its Parent Element is = used. If the minOccurs attribute is not expressed for that Element then = that Element shall be considered to have a minOccurs value of 0. This = value of minOccurs MUST be a positive integer. The semantic meaning of = minOccurs within an EBML Schema is considered analogous to the meaning = of minOccurs within an [XML = Schema](https://www.w3.org/TR/xmlschema-0/#ref6 = ). >=20 > maxOccurs > A value to express the maximum number of occurrences that the EBML = Element MUST occur within its Parent Element if its Parent Element is = used. This value may be either a positive integer or the term = `unbounded` to indicate there is no maximum number of occurrences or the = term `identical` to indicate that the Element is an = Identically-Recurring Element. If the maxOccurs attribute is not = expressed for that Element then that Element shall be considered to have = a maxOccurs value of 1. The semantic meaning of maxOccurs within an EBML = Schema is considered analogous to the meaning of minOccurs within an = [XML Schema](https://www.w3.org/TR/xmlschema-0/#ref6 = ), with EBML Schema adding the = concept of Identically-Recurring Elements. >=20 > I also added a section called "Identically-Recurring Elements" to = define them since they are enabled by setting maxOccurs to "enabled". = See in context at = https://github.com/MediaArea/ebml-specification/blob/ebml-schema-refactor/= specification.markdown#identically-recurring-elements = . >=20 > An Identically-Recurring Element is an Element that may occur within = its Parent Element more than once but that each recurrence within that = Parent Element MUST be identical both in storage and semantics. = Identically-Recurring Elements are permitted to be stored multiple times = within the same Parent Element in order to increase data resilience and = optimize the use of EBML in transmission. Identically-Recurring Elements = SHOULD include a CRC-32 Element as a Child Element; this is especially = recommended when EBML is used for long-term storage or transmission. If = a Parent Element contains more than one copy of an Identically-Recurring = Element which includes a CRC-32 Child Element then the first instance of = the Identically-Recurring Element with a valid CRC-32 value should be = used for interpretation. If a Parent Element contains more than one copy = of an Identically-Recurring Element which does not contain a CRC-32 = Child Element or if CRC-32 Child Elements are present but none are valid = then the first instance of the Identically-Recurring Element should be = used for interpretation. >=20 >=20 > I also drafted a new section called "EBML Schema example" as a = demonstration of an EBML Schema. This example EBML Schema is simply the = EBML Header with some structure to store files (somewhat based on the = Attachments Element of Matroska). The section can be seen in a GitHub = branch here: = https://github.com/MediaArea/ebml-specification/blob/ebml-schema-refactor/= specification.markdown#ebml-schema-example = or is pasted here. Compared = to the existing implementation of specdata.xml, this uses hierarchical = arrangement and the changes mentioned above. > > > > Set the EBML characteristics of the = data to follow. Each EBML Document has to start with = this. > > The version of EBML parser used to = create the EBML Document. > > > The minimum EBML version a parser has = to support to read this EBML Document. > > > The EBMLMaxIDLength is the maximum = length in octets of the Element IDs to be found within the EBML Body. An = EBMLMaxIDLength value of four is recommended, though larger values are = allowed. > > > The EBMLMaxSizeLength is the maximum = length in octets of the expression of all Element Data Sizes to be found = within the EBML Body. To be clear EBMLMaxSizeLength documents the = maximum 'length' of all Element Data Size expressions within the EBML = Body and not the maximum 'value' of all Element Data Size expressions = within the EBML Body. Elements that have a Element Data Size expression = which is larger in octets than what is expressed by EBMLMaxSizeLength = SHALL be considered invalid. > > > A string that describes and = identifies the content of the EBML Body that follows this EBML = Header. > > > The version of DocType interpreter = used to create the EBML Document. > > > The minimum DocType version an = interpreter has to support to read this EBML Document. > > > > Used to void damaged data, to avoid = unexpected behaviors when using damaged data. The content is discarded. = Also used to reserve space in a sub-element for later = use. > > > The CRC is computed on all the data = from the last CRC element (or start of the upper level element), up to = the CRC element, including other previous CRC elements. All level 1 = elements SHOULD include a CRC-32. > > > Container of data and attributes = representing one or many files. > > An attached file. > > Filename of the attached = file. > > > MIME type of the = file. > > > Modification timestamp of the = file. > > > The data of the = file. > > > > >=20 > If this approach seems agreeable for defining machine-readable = documents of EBML DocTypes then can next create versions of them = according to Matroska and webm. Bumping this thread. The corresponding pull request is open here: = https://github.com/Matroska-Org/ebml-specification/pull/51/files. Dave Rice --Apple-Mail=_2E51B7EC-5600-41B6-B537-8451096DAA66 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jan 23, 2016, at 2:49 PM, Dave Rice <dave@dericed.com> = wrote:


On Jan 17, 2016, at 8:05 AM, Steve Lhomme <slhomme@matroska.org> wrote:

2016-01-15 16:35 = GMT+01:00 Dave Rice <dave@dericed.com>:

On Jan 15, 2016, at 7:44 AM, Steve Lhomme <slhomme@matroska.org> wrote:

2016-01-15 7:27 GMT+01:00 Dave Rice <dave@dericed.com>:

On Dec 1, = 2015, at 10:40 AM, Dave Rice <dave@dericed.com> wrote:

On= Nov 9, 2015, at 1:19 PM, Dave Rice <dave@dericed.com> = wrote:

On Oct 3, 2015, at 9:46 AM, Steve = Lhomme <slhomme@matroska.org> wrote:

On Aug 28, 2015 17:00, "Dave Rice" <dave@dericed.com> = wrote:

On Aug 28, 2015, at 2:50 = AM, Moritz Bunkus <moritz@bunkus.org> wrote:

Hey,

I have no objections, = however I don't know a lot about XML schemas in
the first = place (neither about DTDs, to be honest).


Honestly, I know a lot more about XML Schemas = than I do about DTDs. As
wikipedia mentions at
https://en.wikipedia.org/wiki/Document_type_definition, = DTDs have largely
been superseded by XML Schemas. And at = this point I think that XML Schemas
may be a more familiar = analogy to use.

I think XML Schemas also = share more in common with specdata.xml than DTDs
do. = Schemas use the <element> node and have maxOccurs and minOccurs
attributes (specdata has semantically the same thing with = mandatory and
multiple), they both have a similar = declaration of element type, element
name and element = description. Actually I think a semantically equivalent
version of specdata.xml could be written as an XML Schema.

XML Schemas also offer a few advantages for = machine readable expressions;
for instance XML Schemas can = mandate a particular pattern or regex for a
value.

I propose the specdata.xml file here

https://github.com/Matroska-Org/foundation-source/blob/master/s= pectool/specdata.xml

<https://github.com/Matroska-Org/foundation-source/blob/master/s= pectool/specdata.xml>
is a good basis for the = consideration of an EBML Schema. =46rom what I
can see, = specdata.xml is an expression of the EBML + Matroska
specifications to support automated creation of = documentation, but the
structure of this already shares a = lot of similarity to XML Schemas.


For both documentation (e.g. the table on the = matroska.org specs page = is
generated from this file) and code (libMatroska's class = hierarchy is
generated automatically from this file) = actually.


Does = specdata.xml play a role in mkvalidate? I'm thinking of the potential
to have an ebmlvalidator where you can provide the EBML = Schema to validate
particular EBML docType.

Well the parsing code is = generated from the XML file, so in a way, yes. But
it's = not parsed "live".

Is there a preference in handling the standardization of = Matroska:
documenting it in a similar fashion to our work = in the EBML spec or to
define what an EBML Schema is and = consider matroska an expression of
it?


I'm not sure = whether or not I understand the implications. But my gut
feeling is that having a definition for an EBML Schema would = benefit
other formats than Matroska, too, therefore the = latter seems the way to
go.


I have the same feeling:
- = document EBML as a specification that includes rules for defining a
docType in the form of an EBML Schema
- write = an EBML Schema (updated specdata.xml) for Matroska and maybe webM

Are some changes to specdata.xml acceptable? = Such as a filename change
or changing the name of the = <table> element of some attributes?


Well, like I said above the specdata.xml is = used for generating both
documentation and code. Both = should stay viable. If changes to it are
made then the = accompanying tools must be updated as well.

Neither the current EBML = specs nor the specdata.xml specifically refer
to the = hierarchical arrangement of the elements, but this could be
presumed by their ordering. For instance, could any level 3 = element be
a child of any level 2 Master-element? I = presume not, but I don't
think it's clear anywhere what = parent-child relationships are
feasible. Possibly = specdata.xml and/or the EBML Schema Definition
could = define the relationship between levels of related elements
similar to how an XML Schema (XSD) does.


So far it is = understood that an element not marked as a global element
must only occur as a child of its parent. Its parent is the = last element
located before the child element in the = specdata file with a lower level
than the child element. = Or something like that.


This will need some documentation. That's how I've understood = the mkv spec
as well but the definition for how an EBML = Schema works should be explicit
about this.

Any more opinion about how to go = about (or if to go about) modifying
specdata.xml towards = becoming an expression of a to-be-defined EBML Schema
for = matroska and webm? As a summary of proposed changes to specdata.xml

- change to XML Schema conventions where = relevant:
- use maxOccurs attribute instead of the current = Multiple attribute.
- use minOccurs attribute instead of = the current Mandatory attribute.
- move documentation of = elements to a sub-element (allows for possible
internationalization in the schema and better semantics)
- arrange elements in hierarchical form to indicate = parent-child
relationships (rather than the current = practices where all elements are
defined at the same = level, and you have to parse back in elements to the one
with the lower-numbered level attribute to find the = parent)

A draft of specdata.xml with these = changes is at
https://gist.github.com/dericed/f0a4bb0e7dc635ed1347. I = can continue to work
on this and send back changes for = advice/approval but if I do so is there
someone who could = later update the tools that use specdata.xml so that
newly-defined EBML Schemas may later to be into use?


I=E2=80=99m preparing a pull = request on specdata.xml but want to update the
utilities = in spectool at the same time so that spec2data, data2lib, and
data2spec still function properly. I=E2=80=99m having trouble = getting the spectool
utilities to build properly so that I = can test them. I was able to build
coremake but not sure = where to go from here. I=E2=80=99ve read spec2data and have an
idea of how it works and am thinking that I could reproduce = the spec2data
workflow with xsl and then we could have a = make file which uses xsltproc to
convert an EBML Schema = into the Drupal table and library files as needed.
Any = advice on which route to take: continue trying with getting spectool
utilities to build or redo the utilities in xsl?


I=E2=80=99d like to revive this = thread to propose some changes in the definition of
the = EBML Schema. The EBML Schema is intended to be a machine-readible
document that details the semantics and structure of an EBML = Document Type.
The EBML Schema for a Document Type is = essential for understanding the
semantics and validating = an EBML Document. This proposal builds upon an
earlier = conversation started last year on matroska-devel,
http://lists.matroska.org/pipermail/matroska-devel/2015-August/= 004765.html,
http://lists.matroska.org/pipermail/matroska-devel/2015-October= /004807.html.

I=E2=80=99m open to other = solutions or approaches, but since Matroska is based on
EBML= which itself is becoming well-defined. I think there is utility in
documenting how to create a machine-readible document that = describes an EBML
Document Type. I think the concept of = the XML Schema and XML Document is
analogous to EBML = Schema and EBML Document and that adopting from the XML
community for documenting form may be beneficial.

Thus far we have this section
https://github.com/Matroska-Org/ebml-specification/blob/3b30502= d2adb6a22c60294c1e7ea68f703e07e50/specification.markdown#ebml-schemawhich introduces the concept for the EBML Schema and then = provides a list of
attributes for defining Elements that = make up a specific EBML Document Type
https://github.com/Matroska-Org/ebml-specification/blob/3b30502= d2adb6a22c60294c1e7ea68f703e07e50/specification.markdown#ebml-schema-eleme= nt-attributes.
This documentation currently reflects = the specdata.xml file of the Matroska
foundation-source = repo, which is here
https://github.com/Matroska-Org/foundation-source/blob/master/s= pectool/specdata.xml.
The specdata.xml file is used to = create the HTML table of elements on
http://matroska.org/technical/specs/index.html and = libraries used by
mkvalidate and other files. After = drafting the EBML Schema and Attribute
documentation I = found
http://matroska.org/technical/specs/notes.html#Table_Columns which covers
similar concepts.

I=E2=80=99d like to propose the following changes to the = definition of EBML Schema:

- Replace = <table> with <EBMLSchema>.

The = node <table> makes sense in the context of the HTML table on
matroska.org = but if there will be greater machine-readible usage I think a
rename would clarify.

- Add an = XML NameSpace attribute to <EBMLSchema>.

This would add something like
xmlns=3D=E2=80=9Chttp://official_url_of_EBML_Schema_definition.org/EBMLSchema.xs= d=E2=80=9D.
The EBMLSchema.xsd file would be an XML = Schema that defines the EBMLSchema
document itself. Yes, = this uses an XML Schema to define the EBML Schema, but
this = gives a way to validate the EBML Schemas and docType definitions made
by others.

- Add a =E2=80=9CdocTyp= e=E2=80=9D attribute to <EBMLSchema>

This would clarify what the EBMLSchema is documenting, thus = it would start
with <EBMLSchema = docType=3D=E2=80=9Cmatroska=E2=80=9D>

- = Add =E2=80=9Cversion=E2=80=9D attribute to <EBMLSchema>

This would note the highest version number of = the docType officially
documented by the EBML Schema, so = the EBML Schema would be inferred to
document the noted = docType from version 0 up to the version value listed
here.

Maybe we need = something to say it's the final version or a draft.

With XML Schemas this is done by = having an entirely separate document per version. We could have separate = files such as:

matroska_v1.xml
matroska_v2.xml
matroska_v3.xml
matroska_v4.xml
matroska_v5RC.xml
webm_v1.xml

Or we could add an = attribute called something like "unofficial" so that we may have an EBML = Schema with non-standardized elements for testing.

Any preference at which tactic? An advantage of having = versioned EBML Schemas (one doc per version) is that the deprecated = elements are simply removed rather than an eternal lingering presence. = It may accept complexity in use though since you'd have to use the = proper schema that matches both the docType and docTypeVersion.

That makes omission by mistake a = possibility, involves more proof
reading and it becomes = harder to know which elements changed between
what = versions. It's also harder to process to generate code. Also
should the documentation we currently have be duplicated on = each
document ? I'd rather keep a single document.

- Rename = =E2=80=9Cmandatory=E2=80=9D as =E2=80=9CminOccurs=E2=80=9D and rename = =E2=80=9Cmultiple=E2=80=9D as =E2=80=9CmaxOccurs=E2=80=9D

That may be odd when we add = "repeatable" elements that must be maxOccurs =3D 1.

With maxOccurs it is usually set = via numbers, however 'unbounded' is an accepted maxOccurs value to say = that the element may repeat for an infinite amount of times. In addition = to "unbounded" we could also add a value "identical" which would mean = the same as "unbounded" with the added constraint that every copy be = identical.

That sounds good, = yes.

This is to match the meaning of minOccurs and maxOccurs in = XML Schema,
https://www.w3.org/TR/xmlschema-0/#ref6.
mandatory=3D=E2=80=9C0=E2=80=9D would be equivalent to = minOccurs=3D=E2=80=9C0"
mandatory=3D=E2=80=9C1=E2=80=9D = would be equivalent to minOccurs=3D=E2=80=9C1=E2=80=9D
no = mandatory attribute would be equivalent of no minOccurs attribute = which
is equivalent to minOccurs=3D=E2=80=9C1=E2=80=9D (as = is true with minOccurs within an XML
Schema)

multiple=3D=E2=80=9C0=E2=80=9D would be = equivalent to maxOccurs =3D=E2=80=9C1"
multiple =3D=E2=80=9C= 1=E2=80=9D would be equivalent to maxOccurs =3D=E2=80=9Cunbounded=E2=80=9D=
no multiple attribute would be equivalent of no maxOccurs = attribute which is
equivalent to maxOccurs =3D=E2=80=9C1=E2=80= =9D (as is true with maxOccurs within an XML
Schema)

Moving from mandatory/multiple to = minOccurs/maxOccurs can be done with no
semantic = differences, but we=E2=80=99d have to advantage of allowing for = constraints
to the number of usage that are not 0, 1, and = infinite. For instance, I
understand the logic to have 2 = SeekHead Elements, but is there a scenario
for 3 or more = SeekHeads at the same Level within the same EBML Document?

Limiting the amount of = redirection might be a good thing indeed.

Are there other elements currently listed as multiple=3D"1" = where they are intended for use greater than 1 and less than unbounded. = SeekHead was the only one coming to mind.

Not from the top of my mind.

- Store <element> = nodes hierarchically rather than all at the same level.

Currently with in the specdata.xml file it is difficult to = ascertain the
parent of a given element. It can be done by = seeking to the previous element
where the level of the = element is one value lower, but there are exceptions
for = global elements. I suggest that a structure of
<element>
<element>...</element>
<element>...</element>
</element>
is more clear than all = elements at the same level. I made an example draft
of = specdata.xml with nested implementing here:
https://gist.github.com/dericed/f0a4bb0e7dc635ed1347.

I can provide a patch to the current EBML = Schema and EBML Schema Attributes
as well as incorporate a = sample EBML Schema into the specification, but
wanted to = nudge for comments before proceeding.

The current flat hierarchy is not good anyway. I will need a = bit of
time to update the spec tools accordingly. But the = change is OK for
me.

Thanks. Should I cross-post this to webm lists?

No idea if they use the document = but it's worth a try.

Here are some changes made to the definition = of EBML Schema. I placed them into a pull request in github, https://github.com/Matroska-Org/ebml-specification/pull/51/file= s, and will summarize the changes here.

I removed the attributes for mandatory, = multiple, and identical and replaced them with minOccurs and maxOccurs = (see in context at https://github.com/MediaArea/ebml-specification/blob/ebml-schem= a-refactor/specification.markdown#ebml-schema-element-attributes)

minOccurs:
An integer to express the minimal number of occurrences that = the EBML Element MUST occur within its Parent Element if its Parent = Element is used. If the minOccurs attribute is not expressed for = that Element then that Element shall be considered to have a minOccurs = value of 0. This value of minOccurs MUST be a positive integer. The = semantic meaning of minOccurs within an EBML Schema is considered = analogous to the meaning of minOccurs within an [XML Schema](https://www.w3.org/TR/xmlschema-0/#ref6).
maxOccurs
A value = to express the maximum number of occurrences that the EBML Element MUST = occur within its Parent Element if its Parent Element is used. This = value may be either a positive integer or the term `unbounded` to = indicate there is no maximum number of occurrences or the term = `identical` to indicate that the Element is an Identically-Recurring = Element. If the maxOccurs attribute is not expressed for that = Element then that Element shall be considered to have a maxOccurs value = of 1. The semantic meaning of maxOccurs within an EBML Schema is = considered analogous to the meaning of minOccurs within an = [XML Schema](https://www.w3.org/TR/xmlschema-0/#ref6), with EBML = Schema adding the concept of Identically-Recurring Elements.

I also added a section = called "Identically-Recurring Elements" to define them since they are = enabled by setting maxOccurs to "enabled". See in context at https://github.com/MediaArea/ebml-specification/blob/ebml-schem= a-refactor/specification.markdown#identically-recurring-elements.

An = Identically-Recurring Element is an Element that may occur within its = Parent Element more than once but that each recurrence within that = Parent Element MUST be identical both in storage and semantics. = Identically-Recurring Elements are permitted to be stored multiple = times within the same Parent Element in order to increase data = resilience and optimize the use of EBML in transmission. = Identically-Recurring Elements SHOULD include a CRC-32 Element as a = Child Element; this is especially recommended when EBML is used for = long-term storage or transmission. If a Parent Element contains more = than one copy of an Identically-Recurring Element which includes a = CRC-32 Child Element then the first instance of the = Identically-Recurring Element with a valid CRC-32 value should be = used for interpretation. If a Parent Element contains more than one copy = of an Identically-Recurring Element which does not contain a CRC-32 = Child Element or if CRC-32 Child Elements are present but none are valid = then the first instance of the Identically-Recurring Element should = be used for interpretation.


I also drafted a new = section called "EBML Schema example" as a demonstration of an EBML = Schema. This example EBML Schema is simply the EBML Header with some = structure to store files (somewhat based on the Attachments Element of = Matroska). The section can be seen in a GitHub branch here: https://github.com/MediaArea/ebml-specification/blob/ebml-schem= a-refactor/specification.markdown#ebml-schema-example or is = pasted here. Compared to the existing implementation of specdata.xml, = this uses hierarchical arrangement and the changes mentioned = above.
<?xml version=3D"1.0" =
encoding=3D"utf-8"?>
<EBMLSchema docType=3D"files-in-ebml-demo">
  <element name=3D"EBML" =
level=3D"0" id=3D"0x1A45DFA3" =
type=3D"master" =
minOccurs=3D"1" maxOccurs=3D"1" minver=3D"1">
    <documentation lang=3D"en">Set =
the EBML characteristics of the data to follow. Each EBML Document has =
to start with this.</documentation>
    <element name=3D"EBMLVersion"=
 level=3D"1" id=3D"0x4286" =
type=3D"uinteger" =
minOccurs=3D"1" default=3D"1" minver=3D"1">
      <documentation lang=3D"en">The =
version of EBML parser used to create the EBML Document.</documentation>
    </element>
    <element name=3D"EBMLReadVersion" level=3D"1" id=3D"0x42F7" type=3D"uinteger" minOccurs=3D"1" default=3D"1" minver=3D"1">
      <documentation lang=3D"en">The =
minimum EBML version a parser has to support to read this EBML =
Document.</documentation>
    </element>
    <element name=3D"EBMLMaxIDLength" level=3D"1" id=3D"0x42F2" type=3D"uinteger" minOccurs=3D"1" default=3D"4" minver=3D"1">
      <documentation lang=3D"en">The =
EBMLMaxIDLength is the maximum length in octets of the Element IDs to be =
found within the EBML Body. An EBMLMaxIDLength value of four is =
recommended, though larger values are allowed.</documentation>
    </element>
    <element name=3D"EBMLMaxSizeLength" level=3D"1" id=3D"0x42F3" type=3D"uinteger" minOccurs=3D"1" default=3D"8" minver=3D"1">
      <documentation lang=3D"en">The =
EBMLMaxSizeLength is the maximum length in octets of the expression of =
all Element Data Sizes to be found within the EBML Body. To be clear =
EBMLMaxSizeLength documents the maximum 'length' of all Element Data =
Size expressions within the EBML Body and not the maximum 'value' of all =
Element Data Size expressions within the EBML Body. Elements that have a =
Element Data Size expression which is larger in octets than what is =
expressed by EBMLMaxSizeLength SHALL be considered invalid.</documentation>
    </element>
    <element name=3D"DocType" =
level=3D"1" id=3D"0x4282" =
type=3D"string" =
minOccurs=3D"1" default=3D"matroska" =
minver=3D"1">
      <documentation lang=3D"en">A =
string that describes and identifies the content of the EBML Body that =
follows this EBML Header.</documentation>
    </element>
    <element name=3D"DocTypeVersion" level=3D"1" id=3D"0x4287" type=3D"uinteger" minOccurs=3D"1" default=3D"1" minver=3D"1">
      <documentation lang=3D"en">The =
version of DocType interpreter used to create the EBML =
Document.</documentation>
    </element>
    <element name=3D"DocTypeReadVersion" level=3D"1" id=3D"0x4285" type=3D"uinteger" minOccurs=3D"1" default=3D"1" minver=3D"1">
      <documentation lang=3D"en">The =
minimum DocType version an interpreter has to support to read this EBML =
Document.</documentation>
    </element>
  </element>
  <element name=3D"Void" =
global=3D"1" level=3D"0+" id=3D"0xEC" =
type=3D"binary" =
minver=3D"1">
    <documentation lang=3D"en">Used =
to void damaged data, to avoid unexpected behaviors when using damaged =
data. The content is discarded. Also used to reserve space in a =
sub-element for later use.</documentation>
  </element>
  <element name=3D"CRC-32" =
global=3D"1" level=3D"1+" id=3D"0xBF" =
type=3D"binary" =
minver=3D"1">
    <documentation lang=3D"en">The =
CRC is computed on all the data from the last CRC element (or start of =
the upper level element), up to the CRC element, including other =
previous CRC elements. All level 1 elements SHOULD include a =
CRC-32.</documentation>
  </element>
  <element name=3D"Files" =
level=3D"0" id=3D"0x1946696C" =
type=3D"master" =
minver=3D"1">
    <documentation lang=3D"en">Container of data and attributes =
representing one or many files.</documentation>
    <element name=3D"File" =
level=3D"1" id=3D"0x6146" =
type=3D"master" =
minOccurs=3D"1" maxOccurs=3D"unbounded" =
minver=3D"1">
      <documentation lang=3D"en">An =
attached file.</documentation>
      <element name=3D"FileName" =
level=3D"2" id=3D"0x614E" =
type=3D"utf-8" =
minOccurs=3D"1">
        <documentation lang=3D"en">Filename of the attached =
file.</documentation>
      </element>
      <element name=3D"MimeType" =
level=3D"2" id=3D"0x464D" =
type=3D"string" =
minOccurs=3D"1">
        <documentation lang=3D"en">MIME =
type of the file.</documentation>
      </element>
      <element name=3D"ModificationTimestamp" level=3D"2" id=3D"0x4654" type=3D"date" minOccurs=3D"1">
        <documentation lang=3D"en">Modification timestamp of the =
file.</documentation>
      </element>
      <element name=3D"Data" =
level=3D"2" id=3D"0x4664" =
type=3D"binary" =
minOccurs=3D"1">
        <documentation lang=3D"en">The =
data of the file.</documentation>
      </element>
    </element>
  </element>
</EBMLSchema>
If this approach seems agreeable for = defining machine-readable documents of EBML DocTypes then can next = create versions of them according to Matroska and = webm.

Bumping this thread. The corresponding pull = request is open here: https://github.com/Matroska-Org/ebml-specification/pull/51/file= s.
Dave Rice

= --Apple-Mail=_2E51B7EC-5600-41B6-B537-8451096DAA66-- From nobody Tue Feb 2 23:46:44 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2371D1B2E25 for ; Tue, 2 Feb 2016 23:46:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.122 X-Spam-Level: X-Spam-Status: No, score=0.122 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 WfEVDFQ8ZxnE for ; Tue, 2 Feb 2016 23:46:40 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 A2E151B3190 for ; Tue, 2 Feb 2016 23:46:39 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id e6so8277135vkh.2 for ; Tue, 02 Feb 2016 23:46:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=HXNav8PUy/B4gd7bbcA6ITDN/N8/VJk89bd1YAvSmy4=; b=QFwUrSBHevMtPbs6pS9Kzxd2/zd0/5JF9t6P3brsWPPYrQ7MJd+0UV4VVbwWPCZEUY 4aQ2vwahX9xNPMCXh2KFBhBYpS1+88vE3aqZjIEeX8nBxAWBY+J7uVu5p0pcXzEKTpBU BybhT0kOzwam+4Ymk6IIoDWPNBbKeFdjjbON8+gkLXj6tbbFqEnWYmvDQKjhXxMeQYVg nTlLV84reb2ZZi7wboUKHOAK3dJyjl0wybpOJ0wKG4ZPGmYyOczlZC5IAqkPg9AxpDco oiamDenSN6Hz+6hcYFiZYTAaO9Oopuql9J7pjTT10lzqXDRwpzSqKySxUyDNkF5x7mic V9QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HXNav8PUy/B4gd7bbcA6ITDN/N8/VJk89bd1YAvSmy4=; b=Y0lusgf9RX1gdpePizg2JKPh179vSpnjmUZFWIJeWaEsilLVhCqnngaLTTQ3u9GrOT 2G7fXxsBcKlb59BOP7o2+zoFzIZi43LJVi7wC+xOCxgP5oBvBYkyqJcYe8WaR7TMgmna fQoonToeCKhG7izXnhK7dak7JJqiZeIfyghCWdKrkjBmCZbDGxypf26DqvruilI7K8IQ fb4Xg/wX5VYjgVoOuF9m7q0Y17HH7kPfYnSS/FW81cCvXRaEMiZfxsNbTbK1sgq4LCLj aziV1G1AAZW+npZHpm+4kL6AGRQTsVjgpxm0lnDIFcn3Th8G1W9W8cq/4+0j/vPedqfm qoww== X-Gm-Message-State: AG10YORsylLhGx0qp5O+1c7zDAlnLcpw6sqVW71ol1Hpc7BGM+aA3NCd5EME4LOymacogJ28IMzWcdgdliCp3A== MIME-Version: 1.0 X-Received: by 10.31.5.71 with SMTP id 68mr39690vkf.157.1454485598742; Tue, 02 Feb 2016 23:46:38 -0800 (PST) Received: by 10.31.165.151 with HTTP; Tue, 2 Feb 2016 23:46:38 -0800 (PST) In-Reply-To: <2D0464C5-53AD-45C1-8541-8DCB7A1DA17C@dericed.com> References: <56A43AD8.7000904@wanadoo.fr> <56A8DA3D.8050902@wanadoo.fr> <2D0464C5-53AD-45C1-8541-8DCB7A1DA17C@dericed.com> Date: Wed, 3 Feb 2016 08:46:38 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org, Pierre Choffet , "Questions, help, instructions, talk about Matroska" Subject: Re: [Cellar] [Matroska-users] [RFC] Documentary presenter tagging X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 07:46:41 -0000 2016-02-02 20:51 GMT+01:00 Dave Rice : > > On Jan 27, 2016, at 9:54 AM, Pierre Choffet via Matroska-users > wrote: > > Le 26/01/2016 05:25, Steve Lhomme a =C3=A9crit : > > I agree with the additions, although we're in the process of formally > standardizing Matroska at the IETF and tags will likely be discussed. > So I'd refrain making such changes until we reach that part in the > process. > > Hi Steve, thanks for your answer > > Sounds good to me, I'll resubmit this request once the standardization > process has ended. > > > In standardizing the metadata for the roles of contributions, it may make > sense to adopt an external authority. For instance PBCore manages a > vocabulary called contributorRole: > http://metadataregistry.org/concept/list/vocabulary_id/127.html > http://v1.pbcore.org/PBCore/picklists/picklist_contributorRole.html. > Adopting such a list may be more effective than okaying the values one by > one as requested. Interoperability of tags is definitely a good thing. The question is, what's the best basis to start from ? Matroska is certainly not the one. We did this mapping a long time ago. https://matroska.org/technical/specs/tagging/othertagsystems/comparetable.h= tml > Dave Rice --=20 Steve Lhomme Matroska association Chairman From nobody Wed Feb 3 01:30:53 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB321A711A for ; Wed, 3 Feb 2016 01:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 IR-hd8SVButi for ; Wed, 3 Feb 2016 01:30:49 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E91151A70FE for ; Wed, 3 Feb 2016 01:30:48 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id e64so9830455vkg.0 for ; Wed, 03 Feb 2016 01:30:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=hSS/nxFzfz38xkI6dZaRTnLXKuXaairCjP4sKbstgo0=; b=UsPH1GdOEOgBjCD5Est+NgLgACW9CDfz5Tu0UsoeWF0h31oiRkTc5aIEZhBtJb9bta cUqYNpPkGkW23ywpEkRxcDzs4La2y4B+5dBWlk6Q9zPK0Z70UoYGtq1TH7W0D/smo6pk cWTEVhx+Lg9gb/pIfwdRoIa3J6pQbdDboJmntzCBx8x4L2Z2X5p5C03DPuE2+eh/VPHm km/ZnjnmDxu1QPdCLl0V3hwuTtBHlCR6qgU/r39l+aL6uRoKWM3tbb5cPPFhtyx+iyQ/ oiFiyIdR9tWDaKr+vvqQO0wlkU1ZywHOigODvmhTk1Yyy9PfySIE+CL3hUjMOy6Cwt0a R04A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=hSS/nxFzfz38xkI6dZaRTnLXKuXaairCjP4sKbstgo0=; b=j2biM4xZ4BZld6X2AytyvbBNiDLThKLE4OSQtgL09D+angZp2gmV0FR8oUVGR65+oP 1+xAxlpNB3ye/X4SA+a1cbBi6qJnfdi8CX4ft/GL1WPIjIhPriO1EjuXTPOLeAXuyc5x 4D/FJNdHBQGHtmraRA4MBZfXF3S0FvUtURoudsh6eOnWc92CMHjfpXxI/+XN9r97PI5j LOQYo4v9lMGTYesZJCiDJOaJc/PIkML6JLj/VRvbq8stNgv+cZaX6AK3kYUMl/8h/9iH e6fhHoFprRap3mruIqtaARjldevjn684rcpzs6DOEMDxcO8M9rKtMLu4PEOqAmlkg5Cn LU2w== X-Gm-Message-State: AG10YOQvxx78d4lqsIetDXo7+4UEJ5Fe5GDc9WDlnS4juw8YprymHXPqUD40LJOXzD1lRXw+PKDUNl6p/7xWkA== MIME-Version: 1.0 X-Received: by 10.31.168.76 with SMTP id r73mr317482vke.117.1454491847781; Wed, 03 Feb 2016 01:30:47 -0800 (PST) Received: by 10.31.165.151 with HTTP; Wed, 3 Feb 2016 01:30:47 -0800 (PST) In-Reply-To: References: <568C3CA0.8040300@mediaarea.net> Date: Wed, 3 Feb 2016 10:30:47 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Discussion about the current and future development of Matroska , cellar@ietf.org, Frank Galligan Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 09:30:52 -0000 2016-02-03 7:25 GMT+01:00 Dave Rice : > > On Jan 22, 2016, at 5:54 PM, Frank Galligan via Matroska-devel > wrote: > > On Thu, Jan 14, 2016 at 4:04 AM, Steve Lhomme wrot= e: >> >> 2016-01-06 23:30 GMT+01:00 Frank Galligan : >> > >> > >> > On Tue, Jan 5, 2016 at 1:58 PM, Jerome Martinez >> > wrote: >> >> >> >> Thanks for your detailed proposal. >> >> It is a lot of items, I am not expert in all domains but I have some >> >> comments: >> > >> > Neither am I, but I figured we might as well start from a proposal and >> > iterate from there. >> > >> >> >> >> Name: MatrixCoefficients (or Matrix. You don't use "Colour" with >> >> "Primaries" element, so I would not use it here too) >> > >> > Sounds good to me. >> > >> >> >> >> >> >> >> >> >> >> >> >> Element Name: BitsPerChannel >> >> Level: 5 >> >> ID: [55][A2] >> >> Mandatory: ma >> >> Multiple: - >> >> Default: 8 >> >> Type: u >> >> Description: Number of bits per channel. This number may be less for >> >> specific >> >> channels depending on the ColourFormat and >> >> ChromaSubsampling. >> >> >> >> >> >> >> >> BitsPerChannel is misleading, used to be the technical count of bits. >> >> I propose QuantizationBits or ValidBitsPerChannel >> >> Not mandatory, not default (this value is often unknown) >> > >> > When authoring the video, I'm not sure why the software would not know >> > the >> > bits per channel. Can you describe a use case where the this is unknow= n? >> >> When remuxing an older file. Either from Matroska source or AVI or other= . >> >> Now if elements are mandatory with a default value to "unknown" it's fin= e. >> >> > I really think we should make this mandatory and have authoring softwa= re >> > populate the element (or default) vs software thinking this was >> > non-mandatory and not populating this element because the developer >> > didn't >> > think it was needed. >> >> >> >> >> >> >> >> >> >> Element Name: ChromaSubsampling >> >> Level: 5 >> >> ID: [55][A3] >> >> Mandatory: ma >> >> Multiple: - >> >> Default: 0 >> >> Type: u >> >> Description: (0: 4:2:0, 2: 4:2:2, 4: 4:4:4) >> >> >> >> >> >> FFV1, for example, permits "weird" chroma values, more possibilities. >> >> And the following chroma values were seen at least once in some specs= : >> >> 4:4:4 >> >> 4:2:2 >> >> 4:2:1 >> >> 4:1:1 >> >> 4:2:0 >> >> 4:1:0 >> >> 3:1:1 >> >> >> >> So having a list is maybe not the solution. >> >> I like the way it is done in FFV1, except the power of 2 (so 3 can no= t >> >> be >> >> expressed). >> >> I propose to find a way for describing Chroma subsampling (e.g. >> >> h_chroma_subsample and v_chroma_subsample; a ratio per plane with any >> >> number >> >> of plane, think to alpha channel with a subsampling). >> > >> > I'm fine with coming up with a more extensible solution (Micheal asked >> > for >> > that as well). >> >> >> >> >> >> >> >> >> >> >> >> >> >> Element Name: ColourRange >> >> Level: 5 >> >> ID: [55][A4] >> >> Mandatory: ma >> >> Multiple: - >> >> Default: 1 >> >> Type: u >> >> Description: (0: Unspecified, 1: Defined by >> >> ColourMatrix/TransferFunction, >> >> 2: Full range) >> >> >> >> >> >> I don't understand the 1 value. >> >> in at least AVC and HEVC, range is orthogonal to >> >> ColourMatrix/TransferFunction. >> >> I propose 0: unspecified 1: Broadcast range 1: Full range >> >> and Default:0 >> > >> > I thought someone mentioned to me before that the range could change >> > based >> > on the matrix and transfer function. I'm fine with your proposal. >> > >> >> >> >> >> >> >> >> I got requests for having information about "Capture Gamma Equation" >> >> (or >> >> "Tone Curve"), e.g. "same as transfer characteristic", Scene Linear, >> >> S-Log, >> >> Cine-Log, Log-C... >> >> I am not an expert of this domain, but looks like it is sometimes >> >> important. >> > >> > Someone who knows more about this should propose something to this li= st >> > to >> > be included. >> > >> >> >> >> there are also other colour ideas with e.g. EBU Tech 3349. >> > >> > If this is important to people, then we could add this as well. >> >> >> >> >> >> >> >> >> >> >> >> >> >> I can post a link to a formatted document if that would be easier. Fo= r >> >> Matrix, Range, and Primaries, I'm pretty much using values that map >> >> directly >> >> to values defined in FFmpeg. >> >> >> >> >> >> I don't like the idea to use the source code of a piece of software f= or >> >> lists. Too much subjective, may have historical flaws. >> >> Lists from FFmpeg are nearly same as the ones in H.26x, I think I >> >> prefer >> >> we base our list on their list (I don't think there are copyright >> >> issues >> >> with such list) directly. >> > >> > I don't know the H.26x list. I started with my own, but then switched = to >> > FFmpeg as they already had an extensive list and assumed they have see= n >> > a >> > lot of the video already. >> > >> > If deciding between H.26x and FFmpeg, my guess is that FFmpeg would be >> > better as it handles a lot more video than H.26x. >> > >> >> >> >> Or that we have a prefix with the origin of the list (e.g. ARIB >> >> STD-B67, >> >> from Japan, is not in ITU/ISO list, a 18 will be used in the future f= or >> >> something in ITU/ISO) >> > >> > Yeah HLG is relatively new, but has been requested by a few people. >> > >> > >> > >> > _______________________________________________ >> > Cellar mailing list >> > Cellar@ietf.org >> > https://www.ietf.org/mailman/listinfo/cellar >> > >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman > > > So I updated my original proposal based on comments from this list. > > Changes: > - Added more common ChromaSubsampling values > - ColourMatrix renamed to Matrix > - Added a default value of 0 to BitsPerChannel to signify "unspecified". > - Added "decoded" to BitsPerChannel note. > - Added ChromaSittingHorz and ChromaSittingVert elements. > > > In this case, I think the intended term is =E2=80=98siting=E2=80=99 rathe= r than =E2=80=98sitting=E2=80=99. > > - Added Broadcast range to Range element. > - Removed mandatory flag for elements with unspecified defaults. > - Updated element IDs. > > > - I kept "Defined by Matrix/TransferFunction" in Range element because th= ere > are ranges that fall outside of Broadcast and Full depending on the TF. E= .g. > xvYCC (61966-2-4) > - Does someone want to propose something better for ChromaSubsampling? > - I know some people expressed that they don't think starting from FFmpeg > for the TransferFunction is a good idea as they might have got something > wrong or too subjective. But I just used it as a starting point for a lis= t. > I can reorder the list however we want. I also don't think following anot= her > list, so we will be compatible with future additions, will give us what w= e > want as that list most likely will be incomplete with something that is > defined only in a different list. So should we just start with a list, > re-order it (so we are not explicitly following it), then add what is > currently missing? Then in the future if someone needs to add something t= o > the list it can be brought up here? > > > I think Jerome=E2=80=99s main point was that FFmpeg=E2=80=99s list themse= lves were based on > something else, so we should follow the source for a vocabulary authority= . > For instance, see ITU Recommendation H.264 at > https://www.itu.int/rec/T-REC-H.264-201402-I/en, article E 39577. Pages 3= 87 > (pdf page 409) gives a table of color primaries, page 388 has transfer > characteristics, and 392 has Matrix coefficients. The information in the = ITU > docs provides a lot more context than FFmpeg source code. > > This is what I currently have: > > The parent element would be Video [E0]. > > > Element Name: Colour > Level: 4 > ID: [55][A0] > Mandatory: - > Multiple: - > Default: - > Type: m > Description: Settings describing the colour format. > > > Element Name: Matrix > Level: 5 > ID: [55][A1] > Mandatory: - > Multiple: - > Default: 2 > Type: u > Description: Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB), 1: > BT709, > 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 17= 0M, > 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance, > 10: BT2020 Constant Luminance) > > > I suggest referencing a specific ITU document for these values and their > meaning. > > Element Name: BitsPerChannel > Level: 5 > ID: [55][A2] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: Number of decoded bits per channel. This number may be less > for > specific channels depending on the Matrix and > ChromaSubsampling. A > value of 0 is unspecified. > > > Element Name: ChromaSubsampling > Level: 5 > ID: [55][A3] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1, 5: > 4:2:0, > 6: 4:1:1, 7: 4:1:0, 8: 3:1:1) > > Element Name: ChromaSittingHorz > > > Siting > > Level: 5 > ID: [55][A4] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: How Chroma is subsampled horizontally. (0: Unspecified, 1: > Left > collocated , 2: Half) > > Element Name: ChromaSittingVert > > > Siting > > Level: 5 > ID: [55][A5] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: How Chroma is subsampled vertically. (0: Unspecified, 1: To= p > collocated , 2: Half) > > > Element Name: Range > Level: 5 > ID: [55][A6] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: (0: Unspecified, 1: Broadcast range, 2: Full range, 3: Defi= ned > by > Matrix/TransferFunction) > > > I think a description (beyond the list) is needed. > > Element Name: TransferFunction > Level: 5 > ID: [55][A7] > Mandatory: - > Multiple: - > Default: 2 > Type: u > Description: Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: > Unspecified, > 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, > 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, > 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut, > 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, > 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, > 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) > > > Consider referencing ITU document as an external authority for the > vocabulary. > > Element Name: Primaries > Level: 5 > Mandatory: - > Multiple: - > ID: [55][A8] > Default: 2 > Description: (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R > BT.470M, > 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM, > 9: ITU-R BT.2020, 10: SMPTE ST 428-1) > > > Consider reference to ITU document. Needs a description besides list. > > Element Name: MaxCLL > Level: 5 > ID: [55][A9] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: Maximum brightness of a single pixel in candelas per square > meter (cd/m=C2=B2). > > > Element Name: MaxFALL > Level: 5 > ID: [55][AA] > > > [55][AA] is already in use as FlagForced. > > Mandatory: - > Multiple: - > Default: - > Type: u > Description: Maximum brightness of a single full frame in candelas per > square > meter (cd/m=C2=B2). > > > Element Name: MasteringMetadata > Level: 5 > ID: [55][D0] > Mandatory: - > Multiple: - > Default: - > Type: m > Description: SMPTE 2086 mastering data. > > > I=E2=80=99m not well experienced in MasteringMetadata but wouldn=E2=80=99= t this data need to > change from scene to scene rather than be stored within the Tracks elemen= t > where the same values would apply to all scenes? > > Element Name: PrimaryRChromaticityX > Level: 6 > ID: [55][D1] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > The description is actually a range. When we initially drafted informatio= n > on expressing ranges in EBML definitions, I ignored float, see > https://github.com/Matroska-Org/ebml-specification/blob/master/specificat= ion.markdown#expression-of-range. > I can update this definition to include floats and greater-than-or-equal > values. But the description for this and the following elements should be > moved to range (suggested formatting as "0-1=E2=80=9D). Then these elemen= ts need > actual descriptions. Rather "0.0-1.0" then. > Element Name: PrimaryRChromaticityY > Level: 6 > ID: [55][D2] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > Element Name: PrimaryGChromaticityX > Level: 6 > ID: [55][D3] > Mandatory: - > Multiple: - > Default: - > f > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > Element Name: PrimaryGChromaticityY > Level: 6 > ID: [55][D4] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > Element Name: PrimaryBChromaticityX > Level: 6 > ID: [55][D5] > Mandatory: - > Multiple: - > Default: - > f > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > Element Name: PrimaryBChromaticityY > Level: 6 > ID: [55][D6] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > Element Name: WhitePointChromaticityX > Level: 6 > ID: [55][D7] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > Element Name: WhitePointChromaticityY > Level: 6 > ID: [55][D8] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > Element Name: LuminanceMax > Level: 6 > ID: [55][D9] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Maximum luminance. Shall be represented in candelas per squ= are > meter (cd/m=C2=B2). Valid value is in the range 0 <=3D f <= =3D 9999.99 > > > Add a Range value and split the Description and Range. > > Element Name: LuminanceMin > Level: 6 > ID: [55][DA] > Mandatory: - > Multiple: - > Default: - > Type: f > Description: Minimum luminance. Shall be represented in candelas per squ= are > meter (cd/m=C2=B2). Valid value is in the range 0 <=3D f <= =3D 999.9999 > > > Add a Range value and split the Description and Range. > > Best Regards, > Dave Rice > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Wed Feb 3 01:38:39 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2360B1A87CB for ; Wed, 3 Feb 2016 01:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 WlO5BJONjC2E for ; Wed, 3 Feb 2016 01:38:33 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 192DC1A87C5 for ; Wed, 3 Feb 2016 01:38:33 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id e6so9743065vkh.2 for ; Wed, 03 Feb 2016 01:38:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=DeDTiZl9HfO1mmjyZXbZznqQmb26AbiMcs4UjfW7Tk8=; b=GGlkX+K98K0cVQhrD8vGmC07zfw5gqq4dU0Vcp0JqZpoj+fd2+7ssc8ouKNOtxwyFy FeCCcra/FAeRhYpzm5hgqsBR4y0FHr++Ap7g75hJz9igCXpmJ1WVU7pFFtwoNBXM6BRZ kinxhuveU71FTY5djLlz8KuOZjAvXImCMhWFtNx8XR1KOi3/DsQ7Hga0da0RU3KvjFLc ZbTldGiEViYFL/AmVAJg4I4KZ+P32ex4WT4dRPsq4nJKvokK37SpRHTU5E0U7agu/Cvb LJWqU40kK2sgGdRjcc/VMmnmWEFmrEuulc7ZUEnBcbTi9LMD3+XEZqmAl9gLFU/I1TAG s1cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DeDTiZl9HfO1mmjyZXbZznqQmb26AbiMcs4UjfW7Tk8=; b=Mx+E1/gefrLqt6qadwRMy+y9s5bdRNYrxbRfS2WCWvPZNsmPmWgSq7rQ465uRCCxsT xst65Tuqk1CiBSkbuA1UcFrQWJL1Grf6fMxqw2Ov0H9ZEFMXlCokGWf0r8WfbajXoYXH CU83XHXA3hrvxLvu/ROG/kfpTAildkeBY68Hu8nqWvYWEqB7RSaL9rOsAXJI5Q1eHGXZ vlRI2yrGm9afG563oV7G2tUaaN3MTDVtAjLg2kzXA8+M0C2AyJF13vRn4MrPiAo0VlRV 6QwT/Wz/+gGyfk+ukjZYTCYUNELldid+xmY7pfdelKKM0t9TcVI25FCPUqtYpyAmv15K Ji/g== X-Gm-Message-State: AG10YOSPDt2R6WQspN3f0SeFMvfoaOqewaii/MNggtDpPdO7bdO0jwBLBVXo3jcRvlOs5zkQCTqsZezmp4NXAQ== MIME-Version: 1.0 X-Received: by 10.31.5.71 with SMTP id 68mr314419vkf.157.1454492311948; Wed, 03 Feb 2016 01:38:31 -0800 (PST) Received: by 10.31.165.151 with HTTP; Wed, 3 Feb 2016 01:38:31 -0800 (PST) In-Reply-To: References: <21E28D45-E45F-4CBE-AC3D-6E41DCE172B9@dericed.com> <20150828065002.GH3813@bunkus.org> <5606B89B-FCF0-4C75-BAB8-FB1E212F8D82@dericed.com> <5EDBE9D2-3E2F-4865-ACF9-497706E0CA07@dericed.com> <87110F5D-3199-4CF5-887E-D5B8C7A08C6C@dericed.com> Date: Wed, 3 Feb 2016 10:38:31 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] EBML Schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2016 09:38:37 -0000 2016-01-23 20:49 GMT+01:00 Dave Rice : > > On Jan 17, 2016, at 8:05 AM, Steve Lhomme wrote: > > 2016-01-15 16:35 GMT+01:00 Dave Rice : > > > On Jan 15, 2016, at 7:44 AM, Steve Lhomme wrote: > > 2016-01-15 7:27 GMT+01:00 Dave Rice : > > > On Dec 1, 2015, at 10:40 AM, Dave Rice wrote: > > On Nov 9, 2015, at 1:19 PM, Dave Rice wrote: > > On Oct 3, 2015, at 9:46 AM, Steve Lhomme wrote: > > On Aug 28, 2015 17:00, "Dave Rice" wrote: > > On Aug 28, 2015, at 2:50 AM, Moritz Bunkus wrote: > > Hey, > > I have no objections, however I don't know a lot about XML schemas in > the first place (neither about DTDs, to be honest). > > > > Honestly, I know a lot more about XML Schemas than I do about DTDs. As > wikipedia mentions at > https://en.wikipedia.org/wiki/Document_type_definition, DTDs have largely > been superseded by XML Schemas. And at this point I think that XML Schema= s > may be a more familiar analogy to use. > > I think XML Schemas also share more in common with specdata.xml than DTDs > do. Schemas use the node and have maxOccurs and minOccurs > attributes (specdata has semantically the same thing with mandatory and > multiple), they both have a similar declaration of element type, element > name and element description. Actually I think a semantically equivalent > version of specdata.xml could be written as an XML Schema. > > XML Schemas also offer a few advantages for machine readable expressions; > for instance XML Schemas can mandate a particular pattern or regex for a > value. > > I propose the specdata.xml file here > > https://github.com/Matroska-Org/foundation-source/blob/master/spectool/sp= ecdata.xml > > > is a good basis for the consideration of an EBML Schema. From what I > can see, specdata.xml is an expression of the EBML + Matroska > specifications to support automated creation of documentation, but the > structure of this already shares a lot of similarity to XML Schemas. > > > > For both documentation (e.g. the table on the matroska.org specs page is > generated from this file) and code (libMatroska's class hierarchy is > generated automatically from this file) actually. > > > > Does specdata.xml play a role in mkvalidate? I'm thinking of the potentia= l > to have an ebmlvalidator where you can provide the EBML Schema to validat= e > particular EBML docType. > > > Well the parsing code is generated from the XML file, so in a way, yes. B= ut > it's not parsed "live". > > Is there a preference in handling the standardization of Matroska: > documenting it in a similar fashion to our work in the EBML spec or to > define what an EBML Schema is and consider matroska an expression of > it? > > > > I'm not sure whether or not I understand the implications. But my gut > feeling is that having a definition for an EBML Schema would benefit > other formats than Matroska, too, therefore the latter seems the way to > go. > > > > I have the same feeling: > - document EBML as a specification that includes rules for defining a > docType in the form of an EBML Schema > - write an EBML Schema (updated specdata.xml) for Matroska and maybe webM > > Are some changes to specdata.xml acceptable? Such as a filename change > or changing the name of the
element of some attributes? > > > > Well, like I said above the specdata.xml is used for generating both > documentation and code. Both should stay viable. If changes to it are > made then the accompanying tools must be updated as well. > > Neither the current EBML specs nor the specdata.xml specifically refer > to the hierarchical arrangement of the elements, but this could be > presumed by their ordering. For instance, could any level 3 element be > a child of any level 2 Master-element? I presume not, but I don't > think it's clear anywhere what parent-child relationships are > feasible. Possibly specdata.xml and/or the EBML Schema Definition > could define the relationship between levels of related elements > similar to how an XML Schema (XSD) does. > > > > So far it is understood that an element not marked as a global element > must only occur as a child of its parent. Its parent is the last element > located before the child element in the specdata file with a lower level > than the child element. Or something like that. > > > > This will need some documentation. That's how I've understood the mkv spe= c > as well but the definition for how an EBML Schema works should be explici= t > about this. > > > Any more opinion about how to go about (or if to go about) modifying > specdata.xml towards becoming an expression of a to-be-defined EBML Schem= a > for matroska and webm? As a summary of proposed changes to specdata.xml > > - change to XML Schema conventions where relevant: > - use maxOccurs attribute instead of the current Multiple attribute. > - use minOccurs attribute instead of the current Mandatory attribute. > - move documentation of elements to a sub-element (allows for possible > internationalization in the schema and better semantics) > - arrange elements in hierarchical form to indicate parent-child > relationships (rather than the current practices where all elements are > defined at the same level, and you have to parse back in elements to the = one > with the lower-numbered level attribute to find the parent) > > A draft of specdata.xml with these changes is at > https://gist.github.com/dericed/f0a4bb0e7dc635ed1347. I can continue to w= ork > on this and send back changes for advice/approval but if I do so is there > someone who could later update the tools that use specdata.xml so that > newly-defined EBML Schemas may later to be into use? > > > I=E2=80=99m preparing a pull request on specdata.xml but want to update t= he > utilities in spectool at the same time so that spec2data, data2lib, and > data2spec still function properly. I=E2=80=99m having trouble getting the= spectool > utilities to build properly so that I can test them. I was able to build > coremake but not sure where to go from here. I=E2=80=99ve read spec2data = and have an > idea of how it works and am thinking that I could reproduce the spec2data > workflow with xsl and then we could have a make file which uses xsltproc = to > convert an EBML Schema into the Drupal table and library files as needed. > Any advice on which route to take: continue trying with getting spectool > utilities to build or redo the utilities in xsl? > > > I=E2=80=99d like to revive this thread to propose some changes in the def= inition of > the EBML Schema. The EBML Schema is intended to be a machine-readible > document that details the semantics and structure of an EBML Document Typ= e. > The EBML Schema for a Document Type is essential for understanding the > semantics and validating an EBML Document. This proposal builds upon an > earlier conversation started last year on matroska-devel, > http://lists.matroska.org/pipermail/matroska-devel/2015-August/004765.htm= l, > http://lists.matroska.org/pipermail/matroska-devel/2015-October/004807.ht= ml. > > I=E2=80=99m open to other solutions or approaches, but since Matroska is = based on > EBML which itself is becoming well-defined. I think there is utility in > documenting how to create a machine-readible document that describes an E= BML > Document Type. I think the concept of the XML Schema and XML Document is > analogous to EBML Schema and EBML Document and that adopting from the XML > community for documenting form may be beneficial. > > Thus far we have this section > https://github.com/Matroska-Org/ebml-specification/blob/3b30502d2adb6a22c= 60294c1e7ea68f703e07e50/specification.markdown#ebml-schema > which introduces the concept for the EBML Schema and then provides a list= of > attributes for defining Elements that make up a specific EBML Document Ty= pe > https://github.com/Matroska-Org/ebml-specification/blob/3b30502d2adb6a22c= 60294c1e7ea68f703e07e50/specification.markdown#ebml-schema-element-attribut= es. > This documentation currently reflects the specdata.xml file of the Matros= ka > foundation-source repo, which is here > https://github.com/Matroska-Org/foundation-source/blob/master/spectool/sp= ecdata.xml. > The specdata.xml file is used to create the HTML table of elements on > http://matroska.org/technical/specs/index.html and libraries used by > mkvalidate and other files. After drafting the EBML Schema and Attribute > documentation I found > http://matroska.org/technical/specs/notes.html#Table_Columns which covers > similar concepts. > > I=E2=80=99d like to propose the following changes to the definition of EB= ML Schema: > > - Replace
with . > > The node
makes sense in the context of the HTML table on > matroska.org but if there will be greater machine-readible usage I think = a > rename would clarify. > > - Add an XML NameSpace attribute to . > > This would add something like > xmlns=3D=E2=80=9Chttp://official_url_of_EBML_Schema_definition.org/EBMLSc= hema.xsd=E2=80=9D. > The EBMLSchema.xsd file would be an XML Schema that defines the EBMLSchem= a > document itself. Yes, this uses an XML Schema to define the EBML Schema, = but > this gives a way to validate the EBML Schemas and docType definitions mad= e > by others. > > - Add a =E2=80=9CdocType=E2=80=9D attribute to > > This would clarify what the EBMLSchema is documenting, thus it would star= t > with > > - Add =E2=80=9Cversion=E2=80=9D attribute to > > This would note the highest version number of the docType officially > documented by the EBML Schema, so the EBML Schema would be inferred to > document the noted docType from version 0 up to the version value listed > here. > > > Maybe we need something to say it's the final version or a draft. > > > With XML Schemas this is done by having an entirely separate document per > version. We could have separate files such as: > > matroska_v1.xml > matroska_v2.xml > matroska_v3.xml > matroska_v4.xml > matroska_v5RC.xml > webm_v1.xml > > Or we could add an attribute called something like "unofficial" so that w= e > may have an EBML Schema with non-standardized elements for testing. > > Any preference at which tactic? An advantage of having versioned EBML > Schemas (one doc per version) is that the deprecated elements are simply > removed rather than an eternal lingering presence. It may accept complexi= ty > in use though since you'd have to use the proper schema that matches both > the docType and docTypeVersion. > > > That makes omission by mistake a possibility, involves more proof > reading and it becomes harder to know which elements changed between > what versions. It's also harder to process to generate code. Also > should the documentation we currently have be duplicated on each > document ? I'd rather keep a single document. > > - Rename =E2=80=9Cmandatory=E2=80=9D as =E2=80=9CminOccurs=E2=80=9D and r= ename =E2=80=9Cmultiple=E2=80=9D as =E2=80=9CmaxOccurs=E2=80=9D > > > That may be odd when we add "repeatable" elements that must be maxOccurs = =3D > 1. > > > With maxOccurs it is usually set via numbers, however 'unbounded' is an > accepted maxOccurs value to say that the element may repeat for an infini= te > amount of times. In addition to "unbounded" we could also add a value > "identical" which would mean the same as "unbounded" with the added > constraint that every copy be identical. > > > That sounds good, yes. > > This is to match the meaning of minOccurs and maxOccurs in XML Schema, > https://www.w3.org/TR/xmlschema-0/#ref6. > mandatory=3D=E2=80=9C0=E2=80=9D would be equivalent to minOccurs=3D=E2=80= =9C0" > mandatory=3D=E2=80=9C1=E2=80=9D would be equivalent to minOccurs=3D=E2=80= =9C1=E2=80=9D > no mandatory attribute would be equivalent of no minOccurs attribute whic= h > is equivalent to minOccurs=3D=E2=80=9C1=E2=80=9D (as is true with minOccu= rs within an XML > Schema) > > multiple=3D=E2=80=9C0=E2=80=9D would be equivalent to maxOccurs =3D=E2=80= =9C1" > multiple =3D=E2=80=9C1=E2=80=9D would be equivalent to maxOccurs =3D=E2= =80=9Cunbounded=E2=80=9D > no multiple attribute would be equivalent of no maxOccurs attribute which= is > equivalent to maxOccurs =3D=E2=80=9C1=E2=80=9D (as is true with maxOccurs= within an XML > Schema) > > Moving from mandatory/multiple to minOccurs/maxOccurs can be done with no > semantic differences, but we=E2=80=99d have to advantage of allowing for = constraints > to the number of usage that are not 0, 1, and infinite. For instance, I > understand the logic to have 2 SeekHead Elements, but is there a scenario > for 3 or more SeekHeads at the same Level within the same EBML Document? > > > Limiting the amount of redirection might be a good thing indeed. > > > Are there other elements currently listed as multiple=3D"1" where they ar= e > intended for use greater than 1 and less than unbounded. SeekHead was the > only one coming to mind. > > > Not from the top of my mind. > > - Store nodes hierarchically rather than all at the same level. > > Currently with in the specdata.xml file it is difficult to ascertain the > parent of a given element. It can be done by seeking to the previous elem= ent > where the level of the element is one value lower, but there are exceptio= ns > for global elements. I suggest that a structure of > > ... > ... > > is more clear than all elements at the same level. I made an example draf= t > of specdata.xml with nested implementing here: > https://gist.github.com/dericed/f0a4bb0e7dc635ed1347. > > I can provide a patch to the current EBML Schema and EBML Schema Attribut= es > as well as incorporate a sample EBML Schema into the specification, but > wanted to nudge for comments before proceeding. > > > The current flat hierarchy is not good anyway. I will need a bit of > time to update the spec tools accordingly. But the change is OK for > me. > > > Thanks. Should I cross-post this to webm lists? > > > No idea if they use the document but it's worth a try. > > > Here are some changes made to the definition of EBML Schema. I placed the= m > into a pull request in github, > https://github.com/Matroska-Org/ebml-specification/pull/51/files, and wil= l > summarize the changes here. > > I removed the attributes for mandatory, multiple, and identical and repla= ced > them with minOccurs and maxOccurs (see in context at > https://github.com/MediaArea/ebml-specification/blob/ebml-schema-refactor= /specification.markdown#ebml-schema-element-attributes) > > minOccurs: > An integer to express the minimal number of occurrences that the EBML > Element MUST occur within its Parent Element if its Parent Element is use= d. > If the minOccurs attribute is not expressed for that Element then that > Element shall be considered to have a minOccurs value of 0. This value of > minOccurs MUST be a positive integer. The semantic meaning of minOccurs > within an EBML Schema is considered analogous to the meaning of minOccurs > within an [XML Schema](https://www.w3.org/TR/xmlschema-0/#ref6). > > maxOccurs > A value to express the maximum number of occurrences that the EBML Elemen= t > MUST occur within its Parent Element if its Parent Element is used. This > value may be either a positive integer or the term `unbounded` to indicat= e > there is no maximum number of occurrences or the term `identical` to > indicate that the Element is an Identically-Recurring Element. If the > maxOccurs attribute is not expressed for that Element then that Element > shall be considered to have a maxOccurs value of 1. The semantic meaning = of > maxOccurs within an EBML Schema is considered analogous to the meaning of > minOccurs within an [XML Schema](https://www.w3.org/TR/xmlschema-0/#ref6)= , > with EBML Schema adding the concept of Identically-Recurring Elements. > > I also added a section called "Identically-Recurring Elements" to define > them since they are enabled by setting maxOccurs to "enabled". See in > context at > https://github.com/MediaArea/ebml-specification/blob/ebml-schema-refactor= /specification.markdown#identically-recurring-elements. > > An Identically-Recurring Element is an Element that may occur within its > Parent Element more than once but that each recurrence within that Parent > Element MUST be identical both in storage and semantics. > Identically-Recurring Elements are permitted to be stored multiple times > within the same Parent Element in order to increase data resilience and > optimize the use of EBML in transmission. Identically-Recurring Elements > SHOULD include a CRC-32 Element as a Child Element; this is especially > recommended when EBML is used for long-term storage or transmission. If a > Parent Element contains more than one copy of an Identically-Recurring > Element which includes a CRC-32 Child Element then the first instance of = the > Identically-Recurring Element with a valid CRC-32 value should be used fo= r > interpretation. If a Parent Element contains more than one copy of an > Identically-Recurring Element which does not contain a CRC-32 Child Eleme= nt > or if CRC-32 Child Elements are present but none are valid then the first > instance of the Identically-Recurring Element should be used for > interpretation. > > > I also drafted a new section called "EBML Schema example" as a demonstrat= ion > of an EBML Schema. This example EBML Schema is simply the EBML Header wit= h > some structure to store files (somewhat based on the Attachments Element = of > Matroska). The section can be seen in a GitHub branch here: > https://github.com/MediaArea/ebml-specification/blob/ebml-schema-refactor= /specification.markdown#ebml-schema-example > or is pasted here. Compared to the existing implementation of specdata.xm= l, > this uses hierarchical arrangement and the changes mentioned above. > > > > maxOccurs=3D"1" minver=3D"1"> Does the EBML header need to be defined ? Can it be included from elsewhere ? That's prone to errors and incompatibilities if we go that way. > Set the EBML characteristics of the data t= o > follow. Each EBML Document has to start with this. > minOccurs=3D"1" default=3D"1" minver=3D"1"> > The version of EBML parser used to creat= e the > EBML Document. > > minOccurs=3D"1" default=3D"1" minver=3D"1"> > The minimum EBML version a parser has to > support to read this EBML Document. > > minOccurs=3D"1" default=3D"4" minver=3D"1"> > The EBMLMaxIDLength is the maximum lengt= h in > octets of the Element IDs to be found within the EBML Body. An > EBMLMaxIDLength value of four is recommended, though larger values are > allowed. > > minOccurs=3D"1" default=3D"8" minver=3D"1"> > The EBMLMaxSizeLength is the maximum len= gth > in octets of the expression of all Element Data Sizes to be found within = the > EBML Body. To be clear EBMLMaxSizeLength documents the maximum 'length' o= f > all Element Data Size expressions within the EBML Body and not the maximu= m > 'value' of all Element Data Size expressions within the EBML Body. Elemen= ts > that have a Element Data Size expression which is larger in octets than w= hat > is expressed by EBMLMaxSizeLength SHALL be considered > invalid. > > minOccurs=3D"1" default=3D"matroska" minver=3D"1"> > A string that describes and identifies t= he > content of the EBML Body that follows this EBML Header. > > minOccurs=3D"1" default=3D"1" minver=3D"1"> > The version of DocType interpreter used = to > create the EBML Document. > > minOccurs=3D"1" default=3D"1" minver=3D"1"> > The minimum DocType version an interpret= er > has to support to read this EBML Document. > > > minver=3D"1"> > Used to void damaged data, to avoid unexpe= cted > behaviors when using damaged data. The content is discarded. Also used to > reserve space in a sub-element for later use. > > minver=3D"1"> > The CRC is computed on all the data from t= he > last CRC element (or start of the upper level element), up to the CRC > element, including other previous CRC elements. All level 1 elements SHOU= LD > include a CRC-32. > > > Container of data and attributes represent= ing > one or many files. > maxOccurs=3D"unbounded" minver=3D"1"> > An attached file. > minOccurs=3D"1"> > Filename of the attached > file. > > minOccurs=3D"1"> > MIME type of the file. > > type=3D"date" minOccurs=3D"1"> > Modification timestamp of the > file. > > minOccurs=3D"1"> > The data of the file. > > > > > > > If this approach seems agreeable for defining machine-readable documents = of > EBML DocTypes then can next create versions of them according to Matroska > and webm. > > Best Regards, > Dave Rice --=20 Steve Lhomme Matroska association Chairman From nobody Thu Feb 4 12:52:00 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBF081AD365 for ; Thu, 4 Feb 2016 12:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 PCjtrgDfY_7j for ; Thu, 4 Feb 2016 12:51:52 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CDAE1AD364 for ; Thu, 4 Feb 2016 12:51:52 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id x21so24840977oix.3 for ; Thu, 04 Feb 2016 12:51:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DxaGtTMjlJGk1JDViumaHYp2ItcSXVgbfQTEogz40Jw=; b=mJ376XbjmysTmp2v7/XceDyPlm37fn6iQgZ82AtqT8p2lS3G/gyqHZvuXyo+hT7GPm fPzG/N5cWIkjaZuAfWrXUTYeDMBQHnvsB3FsZfifhkgPYByYkHfvJnuD4dnjuBXqowEo 8N14bgVrvlN++I7txyOxjFWsasrkSPBpKhjJmk2SlXdMdLpiQdSMo04vnRLirwUp2wUB RdzCoCBQxT7nncyz37hvyax/Hnizp1t873BPc1qD42i78a+rdxxy6ecmlPnsoW7iTonW BNWCwwd2Wr0WCblwwA8r6E3Vxeslb/26yqdqBPEEsjGOJXv3+U5/iXyaLpFjHOut5u/2 v9Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DxaGtTMjlJGk1JDViumaHYp2ItcSXVgbfQTEogz40Jw=; b=SwAwOt68Nii+8CdwWp/kGrIH7gy+5zgsynBFvrxseSBQ9PKbt3FM/LUDCgDnjrVBjZ +yyyPhqjCbo3/nLuP4eXF0VDyS2KFQMIVQG9o6bYXl3y6dMO1OTCSHrwwSk6UBi8J8x+ Z6tGC/e1Rg0ziZBtH3CtxnmUXkztWX4chAD6CIvpdUNgUSYaZ/vwUae5cblaMZ3BvBcT F1dJz2lMd9kN6oygFmT+wtqQslz05fpLYzaPd0RhZyuolTXYjkZ7EdsvRZITukLUU1EY Loq6ff6/IXAr/IehowPf4cr0rAQXguLCDWtGH2ONaciJiZSNUA5bwcgvPN5P440I9+Uc WQ7Q== X-Gm-Message-State: AG10YOTGVudIN5il22IvLu/I7hjNNFdoTujwe11Eqdle2PFeYU4dzq8vXtcuPAXC1oyz6UFpHeYnpWKsrfej/g== MIME-Version: 1.0 X-Received: by 10.60.117.137 with SMTP id ke9mr9423903oeb.16.1454619111420; Thu, 04 Feb 2016 12:51:51 -0800 (PST) Received: by 10.202.59.130 with HTTP; Thu, 4 Feb 2016 12:51:51 -0800 (PST) In-Reply-To: References: <568C3CA0.8040300@mediaarea.net> Date: Thu, 4 Feb 2016 12:51:51 -0800 Message-ID: From: Frank Galligan To: Steve Lhomme Content-Type: multipart/alternative; boundary=047d7b4720286b79db052af7e7e7 Archived-At: Cc: Dave Rice , cellar@ietf.org, Discussion about the current and future development of Matroska Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2016 20:51:58 -0000 --047d7b4720286b79db052af7e7e7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 3, 2016 at 1:30 AM, Steve Lhomme wrote: > 2016-02-03 7:25 GMT+01:00 Dave Rice : > > > > On Jan 22, 2016, at 5:54 PM, Frank Galligan via Matroska-devel > > wrote: > > > > On Thu, Jan 14, 2016 at 4:04 AM, Steve Lhomme > wrote: > >> > >> 2016-01-06 23:30 GMT+01:00 Frank Galligan : > >> > > >> > > >> > On Tue, Jan 5, 2016 at 1:58 PM, Jerome Martinez > > >> > wrote: > >> >> > >> >> Thanks for your detailed proposal. > >> >> It is a lot of items, I am not expert in all domains but I have som= e > >> >> comments: > >> > > >> > Neither am I, but I figured we might as well start from a proposal a= nd > >> > iterate from there. > >> > > >> >> > >> >> Name: MatrixCoefficients (or Matrix. You don't use "Colour" with > >> >> "Primaries" element, so I would not use it here too) > >> > > >> > Sounds good to me. > >> > > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> Element Name: BitsPerChannel > >> >> Level: 5 > >> >> ID: [55][A2] > >> >> Mandatory: ma > >> >> Multiple: - > >> >> Default: 8 > >> >> Type: u > >> >> Description: Number of bits per channel. This number may be less f= or > >> >> specific > >> >> channels depending on the ColourFormat and > >> >> ChromaSubsampling. > >> >> > >> >> > >> >> > >> >> BitsPerChannel is misleading, used to be the technical count of bit= s. > >> >> I propose QuantizationBits or ValidBitsPerChannel > >> >> Not mandatory, not default (this value is often unknown) > >> > > >> > When authoring the video, I'm not sure why the software would not kn= ow > >> > the > >> > bits per channel. Can you describe a use case where the this is > unknown? > >> > >> When remuxing an older file. Either from Matroska source or AVI or > other. > >> > >> Now if elements are mandatory with a default value to "unknown" it's > fine. > >> > >> > I really think we should make this mandatory and have authoring > software > >> > populate the element (or default) vs software thinking this was > >> > non-mandatory and not populating this element because the developer > >> > didn't > >> > think it was needed. > >> >> > >> >> > >> >> > >> >> > >> >> Element Name: ChromaSubsampling > >> >> Level: 5 > >> >> ID: [55][A3] > >> >> Mandatory: ma > >> >> Multiple: - > >> >> Default: 0 > >> >> Type: u > >> >> Description: (0: 4:2:0, 2: 4:2:2, 4: 4:4:4) > >> >> > >> >> > >> >> FFV1, for example, permits "weird" chroma values, more possibilitie= s. > >> >> And the following chroma values were seen at least once in some > specs: > >> >> 4:4:4 > >> >> 4:2:2 > >> >> 4:2:1 > >> >> 4:1:1 > >> >> 4:2:0 > >> >> 4:1:0 > >> >> 3:1:1 > >> >> > >> >> So having a list is maybe not the solution. > >> >> I like the way it is done in FFV1, except the power of 2 (so 3 can > not > >> >> be > >> >> expressed). > >> >> I propose to find a way for describing Chroma subsampling (e.g. > >> >> h_chroma_subsample and v_chroma_subsample; a ratio per plane with a= ny > >> >> number > >> >> of plane, think to alpha channel with a subsampling). > >> > > >> > I'm fine with coming up with a more extensible solution (Micheal ask= ed > >> > for > >> > that as well). > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> Element Name: ColourRange > >> >> Level: 5 > >> >> ID: [55][A4] > >> >> Mandatory: ma > >> >> Multiple: - > >> >> Default: 1 > >> >> Type: u > >> >> Description: (0: Unspecified, 1: Defined by > >> >> ColourMatrix/TransferFunction, > >> >> 2: Full range) > >> >> > >> >> > >> >> I don't understand the 1 value. > >> >> in at least AVC and HEVC, range is orthogonal to > >> >> ColourMatrix/TransferFunction. > >> >> I propose 0: unspecified 1: Broadcast range 1: Full range > >> >> and Default:0 > >> > > >> > I thought someone mentioned to me before that the range could change > >> > based > >> > on the matrix and transfer function. I'm fine with your proposal. > >> > > >> >> > >> >> > >> >> > >> >> I got requests for having information about "Capture Gamma Equation= " > >> >> (or > >> >> "Tone Curve"), e.g. "same as transfer characteristic", Scene Linear= , > >> >> S-Log, > >> >> Cine-Log, Log-C... > >> >> I am not an expert of this domain, but looks like it is sometimes > >> >> important. > >> > > >> > Someone who knows more about this should propose something to this > list > >> > to > >> > be included. > >> > > >> >> > >> >> there are also other colour ideas with e.g. EBU Tech 3349. > >> > > >> > If this is important to people, then we could add this as well. > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> I can post a link to a formatted document if that would be easier. > For > >> >> Matrix, Range, and Primaries, I'm pretty much using values that map > >> >> directly > >> >> to values defined in FFmpeg. > >> >> > >> >> > >> >> I don't like the idea to use the source code of a piece of software > for > >> >> lists. Too much subjective, may have historical flaws. > >> >> Lists from FFmpeg are nearly same as the ones in H.26x, I think I > >> >> prefer > >> >> we base our list on their list (I don't think there are copyright > >> >> issues > >> >> with such list) directly. > >> > > >> > I don't know the H.26x list. I started with my own, but then switche= d > to > >> > FFmpeg as they already had an extensive list and assumed they have > seen > >> > a > >> > lot of the video already. > >> > > >> > If deciding between H.26x and FFmpeg, my guess is that FFmpeg would = be > >> > better as it handles a lot more video than H.26x. > >> > > >> >> > >> >> Or that we have a prefix with the origin of the list (e.g. ARIB > >> >> STD-B67, > >> >> from Japan, is not in ITU/ISO list, a 18 will be used in the future > for > >> >> something in ITU/ISO) > >> > > >> > Yeah HLG is relatively new, but has been requested by a few people. > >> > > >> > > >> > > >> > _______________________________________________ > >> > Cellar mailing list > >> > Cellar@ietf.org > >> > https://www.ietf.org/mailman/listinfo/cellar > >> > > >> > >> > >> > >> -- > >> Steve Lhomme > >> Matroska association Chairman > > > > > > So I updated my original proposal based on comments from this list. > > > > Changes: > > - Added more common ChromaSubsampling values > > - ColourMatrix renamed to Matrix > > - Added a default value of 0 to BitsPerChannel to signify "unspecified"= . > > - Added "decoded" to BitsPerChannel note. > > - Added ChromaSittingHorz and ChromaSittingVert elements. > > > > > > In this case, I think the intended term is =E2=80=98siting=E2=80=99 rat= her than > =E2=80=98sitting=E2=80=99. > > > > - Added Broadcast range to Range element. > > - Removed mandatory flag for elements with unspecified defaults. > > - Updated element IDs. > > > > > > - I kept "Defined by Matrix/TransferFunction" in Range element because > there > > are ranges that fall outside of Broadcast and Full depending on the TF. > E.g. > > xvYCC (61966-2-4) > > - Does someone want to propose something better for ChromaSubsampling? > > - I know some people expressed that they don't think starting from FFmp= eg > > for the TransferFunction is a good idea as they might have got somethin= g > > wrong or too subjective. But I just used it as a starting point for a > list. > > I can reorder the list however we want. I also don't think following > another > > list, so we will be compatible with future additions, will give us what > we > > want as that list most likely will be incomplete with something that is > > defined only in a different list. So should we just start with a list, > > re-order it (so we are not explicitly following it), then add what is > > currently missing? Then in the future if someone needs to add something > to > > the list it can be brought up here? > > > > > > I think Jerome=E2=80=99s main point was that FFmpeg=E2=80=99s list them= selves were based > on > > something else, so we should follow the source for a vocabulary > authority. > > For instance, see ITU Recommendation H.264 at > > https://www.itu.int/rec/T-REC-H.264-201402-I/en, article E 39577. Pages > 387 > > (pdf page 409) gives a table of color primaries, page 388 has transfer > > characteristics, and 392 has Matrix coefficients. The information in th= e > ITU > > docs provides a lot more context than FFmpeg source code. > > > > This is what I currently have: > > > > The parent element would be Video [E0]. > > > > > > Element Name: Colour > > Level: 4 > > ID: [55][A0] > > Mandatory: - > > Multiple: - > > Default: - > > Type: m > > Description: Settings describing the colour format. > > > > > > Element Name: Matrix > > Level: 5 > > ID: [55][A1] > > Mandatory: - > > Multiple: - > > Default: 2 > > Type: u > > Description: Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB), 1: > > BT709, > > 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE > 170M, > > 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance, > > 10: BT2020 Constant Luminance) > > > > > > I suggest referencing a specific ITU document for these values and thei= r > > meaning. > > > > Element Name: BitsPerChannel > > Level: 5 > > ID: [55][A2] > > Mandatory: - > > Multiple: - > > Default: 0 > > Type: u > > Description: Number of decoded bits per channel. This number may be le= ss > > for > > specific channels depending on the Matrix and > > ChromaSubsampling. A > > value of 0 is unspecified. > > > > > > Element Name: ChromaSubsampling > > Level: 5 > > ID: [55][A3] > > Mandatory: - > > Multiple: - > > Default: 0 > > Type: u > > Description: (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1, = 5: > > 4:2:0, > > 6: 4:1:1, 7: 4:1:0, 8: 3:1:1) > > > > Element Name: ChromaSittingHorz > > > > > > Siting > > > > Level: 5 > > ID: [55][A4] > > Mandatory: - > > Multiple: - > > Default: 0 > > Type: u > > Description: How Chroma is subsampled horizontally. (0: Unspecified, 1= : > > Left > > collocated , 2: Half) > > > > Element Name: ChromaSittingVert > > > > > > Siting > > > > Level: 5 > > ID: [55][A5] > > Mandatory: - > > Multiple: - > > Default: 0 > > Type: u > > Description: How Chroma is subsampled vertically. (0: Unspecified, 1: > Top > > collocated , 2: Half) > > > > > > Element Name: Range > > Level: 5 > > ID: [55][A6] > > Mandatory: - > > Multiple: - > > Default: 0 > > Type: u > > Description: (0: Unspecified, 1: Broadcast range, 2: Full range, 3: > Defined > > by > > Matrix/TransferFunction) > > > > > > I think a description (beyond the list) is needed. > > > > Element Name: TransferFunction > > Level: 5 > > ID: [55][A7] > > Mandatory: - > > Multiple: - > > Default: 2 > > Type: u > > Description: Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: > > Unspecified, > > 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, > > 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, > > 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut= , > > 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, > > 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, > > 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) > > > > > > Consider referencing ITU document as an external authority for the > > vocabulary. > > > > Element Name: Primaries > > Level: 5 > > Mandatory: - > > Multiple: - > > ID: [55][A8] > > Default: 2 > > Description: (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R > > BT.470M, > > 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM, > > 9: ITU-R BT.2020, 10: SMPTE ST 428-1) > > > > > > Consider reference to ITU document. Needs a description besides list. > > > > Element Name: MaxCLL > > Level: 5 > > ID: [55][A9] > > Mandatory: - > > Multiple: - > > Default: - > > Type: u > > Description: Maximum brightness of a single pixel in candelas per squa= re > > meter (cd/m=C2=B2). > > > > > > Element Name: MaxFALL > > Level: 5 > > ID: [55][AA] > > > > > > [55][AA] is already in use as FlagForced. > > > > Mandatory: - > > Multiple: - > > Default: - > > Type: u > > Description: Maximum brightness of a single full frame in candelas per > > square > > meter (cd/m=C2=B2). > > > > > > Element Name: MasteringMetadata > > Level: 5 > > ID: [55][D0] > > Mandatory: - > > Multiple: - > > Default: - > > Type: m > > Description: SMPTE 2086 mastering data. > > > > > > I=E2=80=99m not well experienced in MasteringMetadata but wouldn=E2=80= =99t this data > need to > > change from scene to scene rather than be stored within the Tracks > element > > where the same values would apply to all scenes? > > > > Element Name: PrimaryRChromaticityX > > Level: 6 > > ID: [55][D1] > > Mandatory: - > > Multiple: - > > Default: - > > Type: f > > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > > > > The description is actually a range. When we initially drafted > information > > on expressing ranges in EBML definitions, I ignored float, see > > > https://github.com/Matroska-Org/ebml-specification/blob/master/specificat= ion.markdown#expression-of-range > . > > I can update this definition to include floats and greater-than-or-equa= l > > values. But the description for this and the following elements should = be > > moved to range (suggested formatting as "0-1=E2=80=9D). Then these elem= ents need > > actual descriptions. > > Rather "0.0-1.0" then. > > > Element Name: PrimaryRChromaticityY > > Level: 6 > > ID: [55][D2] > > Mandatory: - > > Multiple: - > > Default: - > > Type: f > > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > > > > Element Name: PrimaryGChromaticityX > > Level: 6 > > ID: [55][D3] > > Mandatory: - > > Multiple: - > > Default: - > > f > > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > > > > Element Name: PrimaryGChromaticityY > > Level: 6 > > ID: [55][D4] > > Mandatory: - > > Multiple: - > > Default: - > > Type: f > > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > > > > Element Name: PrimaryBChromaticityX > > Level: 6 > > ID: [55][D5] > > Mandatory: - > > Multiple: - > > Default: - > > f > > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > > > > Element Name: PrimaryBChromaticityY > > Level: 6 > > ID: [55][D6] > > Mandatory: - > > Multiple: - > > Default: - > > Type: f > > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > > > > Element Name: WhitePointChromaticityX > > Level: 6 > > ID: [55][D7] > > Mandatory: - > > Multiple: - > > Default: - > > Type: f > > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > > > > Element Name: WhitePointChromaticityY > > Level: 6 > > ID: [55][D8] > > Mandatory: - > > Multiple: - > > Default: - > > Type: f > > Description: Valid value is in the range 0 <=3D f <=3D 1. > > > > > > Element Name: LuminanceMax > > Level: 6 > > ID: [55][D9] > > Mandatory: - > > Multiple: - > > Default: - > > Type: f > > Description: Maximum luminance. Shall be represented in candelas per > square > > meter (cd/m=C2=B2). Valid value is in the range 0 <=3D f <= =3D 9999.99 > > > > > > Add a Range value and split the Description and Range. > > > > Element Name: LuminanceMin > > Level: 6 > > ID: [55][DA] > > Mandatory: - > > Multiple: - > > Default: - > > Type: f > > Description: Minimum luminance. Shall be represented in candelas per > square > > meter (cd/m=C2=B2). Valid value is in the range 0 <=3D f <= =3D > 999.9999 > > > > > > Add a Range value and split the Description and Range. > > > > Best Regards, > > Dave Rice > > > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > > > -- > Steve Lhomme > Matroska association Chairman > --047d7b4720286b79db052af7e7e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 3, 2016 at 1:30 AM, Steve Lhomme &l= t;slhomme@matrosk= a.org> wrote:
2016-02-03 7:25 GMT+01:00 Dave Rice <dave@dericed.com>:
>
> On Jan 22, 2016, at 5:54 PM, Frank Galligan via Matroska-devel
> <matroska-deve= l@lists.matroska.org> wrote:
>
> On Thu, Jan 14, 2016 at 4:04 AM, Steve Lhomme <slhomme@matroska.org> wrote:
>>
>> 2016-01-06 23:30 GMT+01:00 Frank Galligan <frankgalligan@gmail.com>:
>> >
>> >
>> > On Tue, Jan 5, 2016 at 1:58 PM, Jerome Martinez <jerome@mediaarea.net>
>> > wrote:
>> >>
>> >> Thanks for your detailed proposal.
>> >> It is a lot of items, I am not expert in all domains but = I have some
>> >> comments:
>> >
>> > Neither am I, but I figured we might as well start from a pro= posal and
>> > iterate from there.
>> >
>> >>
>> >> Name: MatrixCoefficients (or Matrix. You don't use &q= uot;Colour" with
>> >> "Primaries" element, so I would not use it here= too)
>> >
>> >=C2=A0 Sounds good to me.
>> >
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Element Name: BitsPerChannel
>> >> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>> >> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A2]
>> >> Mandatory:=C2=A0 =C2=A0 ma
>> >> Multiple:=C2=A0 =C2=A0 =C2=A0-
>> >> Default:=C2=A0 =C2=A0 =C2=A0 8
>> >> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>> >> Description:=C2=A0 Number of bits per channel. This numbe= r may be less for
>> >> specific
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cha= nnels depending on the ColourFormat and
>> >> ChromaSubsampling.
>> >>
>> >>
>> >>
>> >> BitsPerChannel is misleading, used to be the technical co= unt of bits.
>> >> I propose QuantizationBits or ValidBitsPerChannel
>> >> Not mandatory, not default (this value is often unknown)<= br> >> >
>> > When authoring the video, I'm not sure why the software w= ould not know
>> > the
>> > bits per channel. Can you describe a use case where the this = is unknown?
>>
>> When remuxing an older file. Either from Matroska source or AVI or= other.
>>
>> Now if elements are mandatory with a default value to "unknow= n" it's fine.
>>
>> > I really think we should make this mandatory and have authori= ng software
>> > populate the element (or default) vs software thinking this w= as
>> > non-mandatory and not populating this element because the dev= eloper
>> > didn't
>> > think it was needed.
>> >>
>> >>
>> >>
>> >>
>> >> Element Name: ChromaSubsampling
>> >> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>> >> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A3]
>> >> Mandatory:=C2=A0 =C2=A0 ma
>> >> Multiple:=C2=A0 =C2=A0 =C2=A0-
>> >> Default:=C2=A0 =C2=A0 =C2=A0 0
>> >> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>> >> Description:=C2=A0 (0: 4:2:0, 2: 4:2:2, 4: 4:4:4)
>> >>
>> >>
>> >> FFV1, for example, permits "weird" chroma value= s, more possibilities.
>> >> And the following chroma values were seen at least once i= n some specs:
>> >> 4:4:4
>> >> 4:2:2
>> >> 4:2:1
>> >> 4:1:1
>> >> 4:2:0
>> >> 4:1:0
>> >> 3:1:1
>> >>
>> >> So having a list is maybe not the solution.
>> >> I like the way it is done in FFV1, except the power of 2 = (so 3 can not
>> >> be
>> >> expressed).
>> >> I propose to find a way for describing Chroma subsampling= (e.g.
>> >> h_chroma_subsample and v_chroma_subsample; a ratio per pl= ane with any
>> >> number
>> >> of plane, think to alpha channel with a subsampling).
>> >
>> > I'm fine with coming up with a more extensible solution (= Micheal asked
>> > for
>> > that as well).
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Element Name: ColourRange
>> >> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>> >> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A4]
>> >> Mandatory:=C2=A0 =C2=A0 ma
>> >> Multiple:=C2=A0 =C2=A0 =C2=A0-
>> >> Default:=C2=A0 =C2=A0 =C2=A0 1
>> >> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>> >> Description:=C2=A0 (0: Unspecified, 1: Defined by
>> >> ColourMatrix/TransferFunction,
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02: = Full range)
>> >>
>> >>
>> >> I don't understand the 1 value.
>> >> in at least AVC and HEVC, range is orthogonal to
>> >> ColourMatrix/TransferFunction.
>> >> I propose 0: unspecified 1: Broadcast range 1: Full range=
>> >> and Default:0
>> >
>> > I thought someone mentioned to me before that the range could= change
>> > based
>> > on the matrix and transfer function. I'm fine with your p= roposal.
>> >
>> >>
>> >>
>> >>
>> >> I got requests for having information about "Capture= Gamma Equation"
>> >> (or
>> >> "Tone Curve"), e.g. "same as transfer char= acteristic", Scene Linear,
>> >> S-Log,
>> >> Cine-Log, Log-C...
>> >> I am not an expert of this domain, but looks like it is s= ometimes
>> >> important.
>> >
>> > Someone who knows more about=C2=A0 this should propose someth= ing to this list
>> > to
>> > be included.
>> >
>> >>
>> >> there are also other colour ideas with e.g. EBU Tech 3349= .
>> >
>> > If this is important to people, then we could add this as wel= l.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> I can post a link to a formatted document if that would b= e easier. For
>> >> Matrix, Range, and Primaries, I'm pretty much using v= alues that map
>> >> directly
>> >> to values defined in FFmpeg.
>> >>
>> >>
>> >> I don't like the idea to use the source code of a pie= ce of software for
>> >> lists. Too much subjective, may have historical flaws. >> >> Lists from FFmpeg are nearly same as the ones in H.26x, I= think I
>> >> prefer
>> >> we base our list on their list (I don't think there a= re copyright
>> >> issues
>> >> with such list) directly.
>> >
>> > I don't know the H.26x list. I started with my own, but t= hen switched to
>> > FFmpeg as they already had an extensive list and assumed they= have seen
>> > a
>> > lot of the video already.
>> >
>> > If deciding between H.26x and FFmpeg, my guess is that FFmpeg= would be
>> > better as it handles a lot more video than H.26x.
>> >
>> >>
>> >> Or that we have a prefix with the origin of the list (e.g= . ARIB
>> >> STD-B67,
>> >> from Japan, is not in ITU/ISO list, a 18 will be used in = the future for
>> >> something in ITU/ISO)
>> >
>> > Yeah HLG is relatively new, but has been requested by a few p= eople.
>> >
>> >
>> >
>> > _______________________________________________
>> > Cellar mailing list
>> > Cellar@ietf.org
>> > https://www.ietf.org/mailman/listinfo/cel= lar
>> >
>>
>>
>>
>> --
>> Steve Lhomme
>> Matroska association Chairman
>
>
> So I updated my original proposal based on comments from this list. >
> Changes:
> - Added more common ChromaSubsampling values
> - ColourMatrix renamed to Matrix
> - Added a default value of 0 to BitsPerChannel to signify "unspec= ified".
> - Added "decoded" to BitsPerChannel note.
> - Added ChromaSittingHorz and ChromaSittingVert elements.
>
>
> In this case, I think the intended term is =E2=80=98siting=E2=80=99 ra= ther than =E2=80=98sitting=E2=80=99.
>
> - Added Broadcast range to Range element.
> - Removed mandatory flag for elements with unspecified defaults.
> - Updated element IDs.
>
>
> - I kept "Defined by Matrix/TransferFunction" in Range eleme= nt because there
> are ranges that fall outside of Broadcast and Full depending on the TF= . E.g.
> xvYCC (61966-2-4)
> - Does someone want to propose something better for ChromaSubsampling?=
> - I know some people expressed that they don't think starting from= FFmpeg
> for the TransferFunction is a good idea as they might have got somethi= ng
> wrong or too subjective. But I just used it as a starting point for a = list.
> I can reorder the list however we want. I also don't think followi= ng another
> list, so we will be compatible with future additions, will give us wha= t we
> want as that list most likely will be incomplete with something that i= s
> defined only in a different list. So should we just start with a list,=
> re-order it (so we are not explicitly following it), then add what is<= br> > currently missing? Then in the future if someone needs to add somethin= g to
> the list it can be brought up here?
>
>
> I think Jerome=E2=80=99s main point was that FFmpeg=E2=80=99s list the= mselves were based on
> something else, so we should follow the source for a vocabulary author= ity.
> For instance, see ITU Recommendation H.264 at
> https://www.itu.int/rec/T-REC-H.264-201402-I/en<= /a>, article E 39577. Pages 387
> (pdf page 409) gives a table of color primaries, page 388 has transfer=
> characteristics, and 392 has Matrix coefficients. The information in t= he ITU
> docs provides a lot more context than FFmpeg source code.
>
> This is what I currently have:
>
> The parent element would be Video [E0].
>
>
> Element Name: Colour
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 4
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A0]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0m
> Description:=C2=A0 Settings describing the colour format.
>
>
> Element Name: Matrix
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A1]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 2
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB= ), 1:
> BT709,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2: Unspecified, 3: Res= erved, 4: FCC, 5: BT470BG, 6: SMPTE 170M,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7: SMPTE 240M, 8: YCOC= G, 9: BT2020 Non-constant Luminance,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10: BT2020 Constant Lu= minance)
>
>
> I suggest referencing a specific ITU document for these values and the= ir
> meaning.
>
> Element Name: BitsPerChannel
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A2]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 0
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 Number of decoded bits per channel. This number may= be less
> for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specific channels depe= nding on the Matrix and
> ChromaSubsampling. A
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 value of 0 is unspecif= ied.
>
>
> Element Name: ChromaSubsampling
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A3]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 0
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4= :2:1, 5:
> 4:2:0,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6: 4:1:1, 7: 4:1:0, 8:= 3:1:1)
>
> Element Name: ChromaSittingHorz
>
>
> Siting
>
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A4]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 0
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 How Chroma is subsampled horizontally. (0: Unspecif= ied, 1:
> Left
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collocated , 2: Half)<= br> >
> Element Name: ChromaSittingVert
>
>
> Siting
>
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A5]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 0
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 How Chroma is subsampled vertically. (0: Unspecifie= d, 1: Top
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collocated , 2: Half)<= br> >
>
> Element Name: Range
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A6]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 0
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 (0: Unspecified, 1: Broadcast range, 2: Full range,= 3: Defined
> by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Matrix/TransferFunctio= n)
>
>
> I think a description (beyond the list) is needed.
>
> Element Name: TransferFunction
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A7]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 2
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2= :
> Unspecified,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4: Gamma 2.2 curve, 5:= Gamma 2.8 curve, 6: SMPTE 170M,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7: SMPTE 240M, 8: Line= ar, 9: Log, 10: Log Sqrt,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11: IEC 61966-2-4, 12:= ITU-R BT.1361 Extended Colour Gamut,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13: IEC 61966-2-1, 14:= ITU-R BT.2020 10 bit,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15: ITU-R BT.2020 12 b= it, 16: SMPTE ST 2084,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 17: SMPTE ST 428-1 18:= ARIB STD-B67 (HLG))
>
>
> Consider referencing ITU document as an external authority for the
> vocabulary.
>
> Element Name: Primaries
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A8]
> Default:=C2=A0 =C2=A0 =C2=A0 2
> Description:=C2=A0 (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: I= TU-R
> BT.470M,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05: ITU-R BT.470B= G, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09: ITU-R BT.2020= , 10: SMPTE ST 428-1)
>
>
> Consider reference to ITU document. Needs a description besides list.<= br> >
> Element Name: MaxCLL
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A9]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 Maximum brightness of a single pixel in candelas pe= r square
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 meter (cd/m=C2=B2). >
>
> Element Name: MaxFALL
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][AA]
>
>
> [55][AA] is already in use as FlagForced.
>
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 Maximum brightness of a single full frame in candel= as per
> square
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 meter (cd/m=C2=B2). >
>
> Element Name: MasteringMetadata
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D0]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0m
> Description:=C2=A0 SMPTE 2086 mastering data.
>
>
> I=E2=80=99m not well experienced in MasteringMetadata but wouldn=E2=80= =99t this data need to
> change from scene to scene rather than be stored within the Tracks ele= ment
> where the same values would apply to all scenes?
>
> Element Name: PrimaryRChromaticityX
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D1]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> The description is actually a range. When we initially drafted informa= tion
> on expressing ranges in EBML definitions, I ignored float, see
> https://github.com/Matroska-Org/ebml-specification/blob/master/= specification.markdown#expression-of-range.
> I can update this definition to include floats and greater-than-or-equ= al
> values. But the description for this and the following elements should= be
> moved to range (suggested formatting as "0-1=E2=80=9D). Then thes= e elements need
> actual descriptions.

Rather "0.0-1.0" then.

> Element Name: PrimaryRChromaticityY
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D2]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> Element Name: PrimaryGChromaticityX
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D3]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> Element Name: PrimaryGChromaticityY
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D4]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> Element Name: PrimaryBChromaticityX
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D5]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> Element Name: PrimaryBChromaticityY
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D6]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> Element Name: WhitePointChromaticityX
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D7]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> Element Name: WhitePointChromaticityY
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D8]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> Element Name: LuminanceMax
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D9]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Maximum luminance. Shall be represented in candelas= per square
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 meter (cd/m=C2=B2). Va= lid value is in the range 0 <=3D f <=3D 9999.99
>
>
> Add a Range value and split the Description and Range.
>
> Element Name: LuminanceMin
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][DA]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Minimum luminance. Shall be represented in candelas= per square
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 meter (cd/m=C2=B2). Va= lid value is in the range 0 <=3D f <=3D 999.9999
>
>
> Add a Range value and split the Description and Range.
>
> Best Regards,
> Dave Rice
>
>
> __________________= _____________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar >



--
Steve Lhomme
Matroska association Chairman

--047d7b4720286b79db052af7e7e7-- From nobody Thu Feb 4 13:00:39 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020EF1AD2D9 for ; Thu, 4 Feb 2016 13:00:38 -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, SPF_PASS=-0.001] autolearn=ham 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 cR0WQOmzOewk for ; Thu, 4 Feb 2016 13:00:31 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277D81AD35E for ; Thu, 4 Feb 2016 13:00:31 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id x21so25183198oix.3 for ; Thu, 04 Feb 2016 13:00:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HiASosYOuVK9PtETG+mYVaO3uE649kq+GvdKR4d7lW4=; b=QxPoxT1NEz3DnYS5IX/9zD1DDJkNVTUQjnVOldKT38uh3M53RjE8AZQABCmQJot6RC +Oae2NtkfIXmxO+V6/g3RGssFhnHRCP1EMMeqJ9sg7PK8SIKUg1dI6ysxOjnzVr/z5Z5 bzmfrUPHRjYJgY5RwDJ3ifDnlv1tPK9Hh+K83xbq8INh9OuYEzUuLjrf+RXQ6l56qK0Y Y1Pacj2HPWUfmvCGDHAJs0h21xjv4+egRafe9pAmYUfszswVJC96eBAI4rv+4rP6LnxL vYQ+zryPNBQWF2I6urDkI0u0TIttZHhk1+vCOKtzOkzc01iZp8aDIYWCkpcDlabuwBEJ AwGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HiASosYOuVK9PtETG+mYVaO3uE649kq+GvdKR4d7lW4=; b=WaghbGE3xvaCbbFiM+hGf1uns747t3aIQ34Ptm7rlJUX6zUzjNL0mae5pF0LUU8zCq B6t5t3laI5ca6NZWITdJcRhFC76b43BsVXZizWctMLl7QeGjTg+jnDM678KlJzg5rEkK +aDN5UCPAkSZvVZ9YAQbjEy8z3itW9z04GB8sIiWQDrWmGd9b7Sens3yav6tZbk1Dk7m uFxeFPBgrlz7+21X9RWR2/RU3ESTB12PglaSj4Hb0A4AKBHm6t3A5M6I8rqlEYQrwohJ AWOpKodxNB8UMBnVdTi9bRr4fG1dHxVT80znJRfRpbSNm94Fu7eabgw24iLASjSaW+gX z+9A== X-Gm-Message-State: AG10YOQ9yJRKaYvSq9CMmJ8PAv0WFuaiIt9zUMdCGWBsbtpZEKf/UYZVEdd4LB3dsKJd894VmiHW/KpADKiSNQ== MIME-Version: 1.0 X-Received: by 10.60.220.230 with SMTP id pz6mr9476376oec.49.1454619630138; Thu, 04 Feb 2016 13:00:30 -0800 (PST) Received: by 10.202.59.130 with HTTP; Thu, 4 Feb 2016 13:00:30 -0800 (PST) In-Reply-To: References: <568C3CA0.8040300@mediaarea.net> Date: Thu, 4 Feb 2016 13:00:30 -0800 Message-ID: From: Frank Galligan To: Steve Lhomme Content-Type: multipart/alternative; boundary=001a11367c2e56904b052af8062a Archived-At: Cc: Dave Rice , cellar@ietf.org, Discussion about the current and future development of Matroska Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 04 Feb 2016 21:00:38 -0000 --001a11367c2e56904b052af8062a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 4, 2016 at 12:51 PM, Frank Galligan wrote: > > > On Wed, Feb 3, 2016 at 1:30 AM, Steve Lhomme wrote= : > >> 2016-02-03 7:25 GMT+01:00 Dave Rice : >> > >> > On Jan 22, 2016, at 5:54 PM, Frank Galligan via Matroska-devel >> > wrote: >> > >> > On Thu, Jan 14, 2016 at 4:04 AM, Steve Lhomme >> wrote: >> >> >> >> 2016-01-06 23:30 GMT+01:00 Frank Galligan : >> >> > >> >> > >> >> > On Tue, Jan 5, 2016 at 1:58 PM, Jerome Martinez < >> jerome@mediaarea.net> >> >> > wrote: >> >> >> >> >> >> Thanks for your detailed proposal. >> >> >> It is a lot of items, I am not expert in all domains but I have so= me >> >> >> comments: >> >> > >> >> > Neither am I, but I figured we might as well start from a proposal >> and >> >> > iterate from there. >> >> > >> >> >> >> >> >> Name: MatrixCoefficients (or Matrix. You don't use "Colour" with >> >> >> "Primaries" element, so I would not use it here too) >> >> > >> >> > Sounds good to me. >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Element Name: BitsPerChannel >> >> >> Level: 5 >> >> >> ID: [55][A2] >> >> >> Mandatory: ma >> >> >> Multiple: - >> >> >> Default: 8 >> >> >> Type: u >> >> >> Description: Number of bits per channel. This number may be less >> for >> >> >> specific >> >> >> channels depending on the ColourFormat and >> >> >> ChromaSubsampling. >> >> >> >> >> >> >> >> >> >> >> >> BitsPerChannel is misleading, used to be the technical count of >> bits. >> >> >> I propose QuantizationBits or ValidBitsPerChannel >> >> >> Not mandatory, not default (this value is often unknown) >> >> > >> >> > When authoring the video, I'm not sure why the software would not >> know >> >> > the >> >> > bits per channel. Can you describe a use case where the this is >> unknown? >> >> >> >> When remuxing an older file. Either from Matroska source or AVI or >> other. >> >> >> >> Now if elements are mandatory with a default value to "unknown" it's >> fine. >> >> >> >> > I really think we should make this mandatory and have authoring >> software >> >> > populate the element (or default) vs software thinking this was >> >> > non-mandatory and not populating this element because the developer >> >> > didn't >> >> > think it was needed. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Element Name: ChromaSubsampling >> >> >> Level: 5 >> >> >> ID: [55][A3] >> >> >> Mandatory: ma >> >> >> Multiple: - >> >> >> Default: 0 >> >> >> Type: u >> >> >> Description: (0: 4:2:0, 2: 4:2:2, 4: 4:4:4) >> >> >> >> >> >> >> >> >> FFV1, for example, permits "weird" chroma values, more >> possibilities. >> >> >> And the following chroma values were seen at least once in some >> specs: >> >> >> 4:4:4 >> >> >> 4:2:2 >> >> >> 4:2:1 >> >> >> 4:1:1 >> >> >> 4:2:0 >> >> >> 4:1:0 >> >> >> 3:1:1 >> >> >> >> >> >> So having a list is maybe not the solution. >> >> >> I like the way it is done in FFV1, except the power of 2 (so 3 can >> not >> >> >> be >> >> >> expressed). >> >> >> I propose to find a way for describing Chroma subsampling (e.g. >> >> >> h_chroma_subsample and v_chroma_subsample; a ratio per plane with >> any >> >> >> number >> >> >> of plane, think to alpha channel with a subsampling). >> >> > >> >> > I'm fine with coming up with a more extensible solution (Micheal >> asked >> >> > for >> >> > that as well). >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Element Name: ColourRange >> >> >> Level: 5 >> >> >> ID: [55][A4] >> >> >> Mandatory: ma >> >> >> Multiple: - >> >> >> Default: 1 >> >> >> Type: u >> >> >> Description: (0: Unspecified, 1: Defined by >> >> >> ColourMatrix/TransferFunction, >> >> >> 2: Full range) >> >> >> >> >> >> >> >> >> I don't understand the 1 value. >> >> >> in at least AVC and HEVC, range is orthogonal to >> >> >> ColourMatrix/TransferFunction. >> >> >> I propose 0: unspecified 1: Broadcast range 1: Full range >> >> >> and Default:0 >> >> > >> >> > I thought someone mentioned to me before that the range could chang= e >> >> > based >> >> > on the matrix and transfer function. I'm fine with your proposal. >> >> > >> >> >> >> >> >> >> >> >> >> >> >> I got requests for having information about "Capture Gamma Equatio= n" >> >> >> (or >> >> >> "Tone Curve"), e.g. "same as transfer characteristic", Scene Linea= r, >> >> >> S-Log, >> >> >> Cine-Log, Log-C... >> >> >> I am not an expert of this domain, but looks like it is sometimes >> >> >> important. >> >> > >> >> > Someone who knows more about this should propose something to this >> list >> >> > to >> >> > be included. >> >> > >> >> >> >> >> >> there are also other colour ideas with e.g. EBU Tech 3349. >> >> > >> >> > If this is important to people, then we could add this as well. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> I can post a link to a formatted document if that would be easier. >> For >> >> >> Matrix, Range, and Primaries, I'm pretty much using values that ma= p >> >> >> directly >> >> >> to values defined in FFmpeg. >> >> >> >> >> >> >> >> >> I don't like the idea to use the source code of a piece of softwar= e >> for >> >> >> lists. Too much subjective, may have historical flaws. >> >> >> Lists from FFmpeg are nearly same as the ones in H.26x, I think I >> >> >> prefer >> >> >> we base our list on their list (I don't think there are copyright >> >> >> issues >> >> >> with such list) directly. >> >> > >> >> > I don't know the H.26x list. I started with my own, but then >> switched to >> >> > FFmpeg as they already had an extensive list and assumed they have >> seen >> >> > a >> >> > lot of the video already. >> >> > >> >> > If deciding between H.26x and FFmpeg, my guess is that FFmpeg would >> be >> >> > better as it handles a lot more video than H.26x. >> >> > >> >> >> >> >> >> Or that we have a prefix with the origin of the list (e.g. ARIB >> >> >> STD-B67, >> >> >> from Japan, is not in ITU/ISO list, a 18 will be used in the futur= e >> for >> >> >> something in ITU/ISO) >> >> > >> >> > Yeah HLG is relatively new, but has been requested by a few people. >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > Cellar mailing list >> >> > Cellar@ietf.org >> >> > https://www.ietf.org/mailman/listinfo/cellar >> >> > >> >> >> >> >> >> >> >> -- >> >> Steve Lhomme >> >> Matroska association Chairman >> > >> > >> > So I updated my original proposal based on comments from this list. >> > >> > Changes: >> > - Added more common ChromaSubsampling values >> > - ColourMatrix renamed to Matrix >> > - Added a default value of 0 to BitsPerChannel to signify "unspecified= ". >> > - Added "decoded" to BitsPerChannel note. >> > - Added ChromaSittingHorz and ChromaSittingVert elements. >> > >> > >> > In this case, I think the intended term is =E2=80=98siting=E2=80=99 ra= ther than >> =E2=80=98sitting=E2=80=99. >> > >> > - Added Broadcast range to Range element. >> > - Removed mandatory flag for elements with unspecified defaults. >> > - Updated element IDs. >> > >> > >> > - I kept "Defined by Matrix/TransferFunction" in Range element because >> there >> > are ranges that fall outside of Broadcast and Full depending on the TF= . >> E.g. >> > xvYCC (61966-2-4) >> > - Does someone want to propose something better for ChromaSubsampling? >> > - I know some people expressed that they don't think starting from >> FFmpeg >> > for the TransferFunction is a good idea as they might have got somethi= ng >> > wrong or too subjective. But I just used it as a starting point for a >> list. >> > I can reorder the list however we want. I also don't think following >> another >> > list, so we will be compatible with future additions, will give us wha= t >> we >> > want as that list most likely will be incomplete with something that i= s >> > defined only in a different list. So should we just start with a list, >> > re-order it (so we are not explicitly following it), then add what is >> > currently missing? Then in the future if someone needs to add somethin= g >> to >> > the list it can be brought up here? >> > >> > >> > I think Jerome=E2=80=99s main point was that FFmpeg=E2=80=99s list the= mselves were >> based on >> > something else, so we should follow the source for a vocabulary >> authority. >> > For instance, see ITU Recommendation H.264 at >> > https://www.itu.int/rec/T-REC-H.264-201402-I/en, article E 39577. >> Pages 387 >> > (pdf page 409) gives a table of color primaries, page 388 has transfer >> > characteristics, and 392 has Matrix coefficients. The information in >> the ITU >> > docs provides a lot more context than FFmpeg source code. >> > >> > This is what I currently have: >> > >> > The parent element would be Video [E0]. >> > >> > >> > Element Name: Colour >> > Level: 4 >> > ID: [55][A0] >> > Mandatory: - >> > Multiple: - >> > Default: - >> > Type: m >> > Description: Settings describing the colour format. >> > >> > >> > Element Name: Matrix >> > Level: 5 >> > ID: [55][A1] >> > Mandatory: - >> > Multiple: - >> > Default: 2 >> > Type: u >> > Description: Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB), 1: >> > BT709, >> > 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE >> 170M, >> > 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance= , >> > 10: BT2020 Constant Luminance) >> > >> > >> > I suggest referencing a specific ITU document for these values and the= ir >> > meaning. >> > >> > Element Name: BitsPerChannel >> > Level: 5 >> > ID: [55][A2] >> > Mandatory: - >> > Multiple: - >> > Default: 0 >> > Type: u >> > Description: Number of decoded bits per channel. This number may be >> less >> > for >> > specific channels depending on the Matrix and >> > ChromaSubsampling. A >> > value of 0 is unspecified. >> > >> > >> > Element Name: ChromaSubsampling >> > Level: 5 >> > ID: [55][A3] >> > Mandatory: - >> > Multiple: - >> > Default: 0 >> > Type: u >> > Description: (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1, >> 5: >> > 4:2:0, >> > 6: 4:1:1, 7: 4:1:0, 8: 3:1:1) >> > >> > Element Name: ChromaSittingHorz >> > >> > >> > Siting >> > >> > Level: 5 >> > ID: [55][A4] >> > Mandatory: - >> > Multiple: - >> > Default: 0 >> > Type: u >> > Description: How Chroma is subsampled horizontally. (0: Unspecified, = 1: >> > Left >> > collocated , 2: Half) >> > >> > Element Name: ChromaSittingVert >> > >> > >> > Siting >> > >> > Level: 5 >> > ID: [55][A5] >> > Mandatory: - >> > Multiple: - >> > Default: 0 >> > Type: u >> > Description: How Chroma is subsampled vertically. (0: Unspecified, 1: >> Top >> > collocated , 2: Half) >> > >> > >> > Element Name: Range >> > Level: 5 >> > ID: [55][A6] >> > Mandatory: - >> > Multiple: - >> > Default: 0 >> > Type: u >> > Description: (0: Unspecified, 1: Broadcast range, 2: Full range, 3: >> Defined >> > by >> > Matrix/TransferFunction) >> > >> > >> > I think a description (beyond the list) is needed. >> > >> > Element Name: TransferFunction >> > Level: 5 >> > ID: [55][A7] >> > Mandatory: - >> > Multiple: - >> > Default: 2 >> > Type: u >> > Description: Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: >> > Unspecified, >> > 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, >> > 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, >> > 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamu= t, >> > 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, >> > 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, >> > 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) >> > >> > >> > Consider referencing ITU document as an external authority for the >> > vocabulary. >> > >> > Element Name: Primaries >> > Level: 5 >> > Mandatory: - >> > Multiple: - >> > ID: [55][A8] >> > Default: 2 >> > Description: (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R >> > BT.470M, >> > 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM= , >> > 9: ITU-R BT.2020, 10: SMPTE ST 428-1) >> > >> > >> > Consider reference to ITU document. Needs a description besides list. >> > >> > Element Name: MaxCLL >> > Level: 5 >> > ID: [55][A9] >> > Mandatory: - >> > Multiple: - >> > Default: - >> > Type: u >> > Description: Maximum brightness of a single pixel in candelas per >> square >> > meter (cd/m=C2=B2). >> > >> > >> > Element Name: MaxFALL >> > Level: 5 >> > ID: [55][AA] >> > >> > >> > [55][AA] is already in use as FlagForced. >> > >> > Mandatory: - >> > Multiple: - >> > Default: - >> > Type: u >> > Description: Maximum brightness of a single full frame in candelas pe= r >> > square >> > meter (cd/m=C2=B2). >> > >> > >> > Element Name: MasteringMetadata >> > Level: 5 >> > ID: [55][D0] >> > Mandatory: - >> > Multiple: - >> > Default: - >> > Type: m >> > Description: SMPTE 2086 mastering data. >> > >> > >> > I=E2=80=99m not well experienced in MasteringMetadata but wouldn=E2=80= =99t this data >> need to >> > change from scene to scene rather than be stored within the Tracks >> element >> > where the same values would apply to all scenes? >> > >> > Element Name: PrimaryRChromaticityX >> > Level: 6 >> > ID: [55][D1] >> > Mandatory: - >> > Multiple: - >> > Default: - >> > Type: f >> > Description: Valid value is in the range 0 <=3D f <=3D 1. >> > >> > >> > The description is actually a range. When we initially drafted >> information >> > on expressing ranges in EBML definitions, I ignored float, see >> > >> https://github.com/Matroska-Org/ebml-specification/blob/master/specifica= tion.markdown#expression-of-range >> . >> > I can update this definition to include floats and greater-than-or-equ= al >> > values. But the description for this and the following elements should >> be >> > moved to range (suggested formatting as "0-1=E2=80=9D). Then these ele= ments need >> > actual descriptions. >> >> Rather "0.0-1.0" then. >> >> > Element Name: PrimaryRChromaticityY >> > Level: 6 >> > ID: [55][D2] >> > Mandatory: - >> > Multiple: - >> > Default: - >> > Type: f >> > Description: Valid value is in the range 0 <=3D f <=3D 1. >> > >> > >> > Element Name: PrimaryGChromaticityX >> > Level: 6 >> > ID: [55][D3] >> > Mandatory: - >> > Multiple: - >> > Default: - >> > f >> > Description: Valid value is in the range 0 <=3D f <=3D 1. >> > >> > >> > Element Name: PrimaryGChromaticityY >> > Level: 6 >> > ID: [55][D4] >> > Mandatory: - >> > Multiple: - >> > Default: - >> > Type: f >> > Description: Valid value is in the range 0 <=3D f <=3D 1. >> > >> > >> > Element Name: PrimaryBChromaticityX >> > Level: 6 >> > ID: [55][D5] >> > Mandatory: - >> > Multiple: - >> > Default: - >> > f >> > Description: Valid value is in the range 0 <=3D f <=3D 1. >> > >> > >> > Element Name: PrimaryBChromaticityY >> > Level: 6 >> > ID: [55][D6] >> > Mandatory: - >> > Multiple: - >> > Default: - >> > Type: f >> > Description: Valid value is in the range 0 <=3D f <=3D 1. >> > >> > >> > Element Name: WhitePointChromaticityX >> > Level: 6 >> > ID: [55][D7] >> > Mandatory: - >> > Multiple: - >> > Default: - >> > Type: f >> > Description: Valid value is in the range 0 <=3D f <=3D 1. >> > >> > >> > Element Name: WhitePointChromaticityY >> > Level: 6 >> > ID: [55][D8] >> > Mandatory: - >> > Multiple: - >> > Default: - >> > Type: f >> > Description: Valid value is in the range 0 <=3D f <=3D 1. >> > >> > >> > Element Name: LuminanceMax >> > Level: 6 >> > ID: [55][D9] >> > Mandatory: - >> > Multiple: - >> > Default: - >> > Type: f >> > Description: Maximum luminance. Shall be represented in candelas per >> square >> > meter (cd/m=C2=B2). Valid value is in the range 0 <=3D f = <=3D >> 9999.99 >> > >> > >> > Add a Range value and split the Description and Range. >> > >> > Element Name: LuminanceMin >> > Level: 6 >> > ID: [55][DA] >> > Mandatory: - >> > Multiple: - >> > Default: - >> > Type: f >> > Description: Minimum luminance. Shall be represented in candelas per >> square >> > meter (cd/m=C2=B2). Valid value is in the range 0 <=3D f = <=3D >> 999.9999 >> > >> > >> > Add a Range value and split the Description and Range. >> > >> > Best Regards, >> > Dave Rice >> > >> > >> > _______________________________________________ >> > Cellar mailing list >> > Cellar@ietf.org >> > https://www.ietf.org/mailman/listinfo/cellar >> > >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman >> > > I'll look into referencing an ITU document. siting. Yes :) [55][AA], Yes I know I currently changed all the [55][Ax] to [55][Bx]. Range Description: How about: Clipping of the color ranges. (0: Unspecified, 1: Broadcast range, 2: Full range (no clipping), 3: Defined by Matrix/TransferFunction) 2086 Mastering metadata refers to the display the content was mastered on. So these values should not change scene to scene. How about these for the values with ranges. I didn't add a .0 for values which should be close to the integer value. Element Name: PrimaryRChromaticityX Level: 6 ID: [55][D1] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - Type: f Description: Red X chromaticity coordinate as defined by CIE 1931. Element Name: PrimaryRChromaticityY Level: 6 ID: [55][D2] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - Type: f Description: Red Y chromaticity coordinate as defined by CIE 1931. Element Name: PrimaryGChromaticityX Level: 6 ID: [55][D3] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - f Description: Green X chromaticity coordinate as defined by CIE 1931. Element Name: PrimaryGChromaticityY Level: 6 ID: [55][D4] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - Type: f Description: Green Y chromaticity coordinate as defined by CIE 1931. Element Name: PrimaryBChromaticityX Level: 6 ID: [55][D5] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - f Description: Blue X chromaticity coordinate as defined by CIE 1931. Element Name: PrimaryBChromaticityY Level: 6 ID: [55][D6] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - Type: f Description: Blue Y chromaticity coordinate as defined by CIE 1931. Element Name: WhitePointChromaticityX Level: 6 ID: [55][D7] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - Type: f Description: White point X chromaticity coordinate as defined by CIE 1931. Element Name: WhitePointChromaticityY Level: 6 ID: [55][D8] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - Type: f Description: White point Y chromaticity coordinate as defined by CIE 1931. Element Name: LuminanceMax Level: 6 ID: [55][D9] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 9999.99 Default: - Type: f Description: Maximum luminance. Shall be represented in candelas per squar= e meter (cd/m=C2=B2). Element Name: LuminanceMin Level: 6 ID: [55][DA] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 999.9999 Default: - Type: f Description: Minimum luminance. Shall be represented in candelas per squar= e meter (cd/m=C2=B2). --001a11367c2e56904b052af8062a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 4, 2016 at 12:51 PM, Frank Galligan <<= a href=3D"mailto:frankgalligan@gmail.com" target=3D"_blank">frankgalligan@g= mail.com> wrote:


On Wed, Feb 3, 2016 at 1:30 AM, Steve Lhomme <slh= omme@matroska.org> wrote:
2016-= 02-03 7:25 GMT+01:00 Dave Rice <dave@dericed.com>:
>
> On Jan 22, 2016, at 5:54 PM, Frank Galligan via Matroska-devel
> <matroska-devel@lists.matroska.org> wrote:
>
> On Thu, Jan 14, 2016 at 4:04 AM, Steve Lhomme <slhomme@matroska.org> wrote: >>
>> 2016-01-06 23:30 GMT+01:00 Frank Galligan <frankgalligan@gmail.com>: >> >
>> >
>> > On Tue, Jan 5, 2016 at 1:58 PM, Jerome Martinez <jerome@mediaarea.net= >
>> > wrote:
>> >>
>> >> Thanks for your detailed proposal.
>> >> It is a lot of items, I am not expert in all domains but = I have some
>> >> comments:
>> >
>> > Neither am I, but I figured we might as well start from a pro= posal and
>> > iterate from there.
>> >
>> >>
>> >> Name: MatrixCoefficients (or Matrix. You don't use &q= uot;Colour" with
>> >> "Primaries" element, so I would not use it here= too)
>> >
>> >=C2=A0 Sounds good to me.
>> >
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Element Name: BitsPerChannel
>> >> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>> >> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A2]
>> >> Mandatory:=C2=A0 =C2=A0 ma
>> >> Multiple:=C2=A0 =C2=A0 =C2=A0-
>> >> Default:=C2=A0 =C2=A0 =C2=A0 8
>> >> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>> >> Description:=C2=A0 Number of bits per channel. This numbe= r may be less for
>> >> specific
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0cha= nnels depending on the ColourFormat and
>> >> ChromaSubsampling.
>> >>
>> >>
>> >>
>> >> BitsPerChannel is misleading, used to be the technical co= unt of bits.
>> >> I propose QuantizationBits or ValidBitsPerChannel
>> >> Not mandatory, not default (this value is often unknown)<= br> >> >
>> > When authoring the video, I'm not sure why the software w= ould not know
>> > the
>> > bits per channel. Can you describe a use case where the this = is unknown?
>>
>> When remuxing an older file. Either from Matroska source or AVI or= other.
>>
>> Now if elements are mandatory with a default value to "unknow= n" it's fine.
>>
>> > I really think we should make this mandatory and have authori= ng software
>> > populate the element (or default) vs software thinking this w= as
>> > non-mandatory and not populating this element because the dev= eloper
>> > didn't
>> > think it was needed.
>> >>
>> >>
>> >>
>> >>
>> >> Element Name: ChromaSubsampling
>> >> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>> >> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A3]
>> >> Mandatory:=C2=A0 =C2=A0 ma
>> >> Multiple:=C2=A0 =C2=A0 =C2=A0-
>> >> Default:=C2=A0 =C2=A0 =C2=A0 0
>> >> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>> >> Description:=C2=A0 (0: 4:2:0, 2: 4:2:2, 4: 4:4:4)
>> >>
>> >>
>> >> FFV1, for example, permits "weird" chroma value= s, more possibilities.
>> >> And the following chroma values were seen at least once i= n some specs:
>> >> 4:4:4
>> >> 4:2:2
>> >> 4:2:1
>> >> 4:1:1
>> >> 4:2:0
>> >> 4:1:0
>> >> 3:1:1
>> >>
>> >> So having a list is maybe not the solution.
>> >> I like the way it is done in FFV1, except the power of 2 = (so 3 can not
>> >> be
>> >> expressed).
>> >> I propose to find a way for describing Chroma subsampling= (e.g.
>> >> h_chroma_subsample and v_chroma_subsample; a ratio per pl= ane with any
>> >> number
>> >> of plane, think to alpha channel with a subsampling).
>> >
>> > I'm fine with coming up with a more extensible solution (= Micheal asked
>> > for
>> > that as well).
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> Element Name: ColourRange
>> >> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
>> >> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A4]
>> >> Mandatory:=C2=A0 =C2=A0 ma
>> >> Multiple:=C2=A0 =C2=A0 =C2=A0-
>> >> Default:=C2=A0 =C2=A0 =C2=A0 1
>> >> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
>> >> Description:=C2=A0 (0: Unspecified, 1: Defined by
>> >> ColourMatrix/TransferFunction,
>> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02: = Full range)
>> >>
>> >>
>> >> I don't understand the 1 value.
>> >> in at least AVC and HEVC, range is orthogonal to
>> >> ColourMatrix/TransferFunction.
>> >> I propose 0: unspecified 1: Broadcast range 1: Full range=
>> >> and Default:0
>> >
>> > I thought someone mentioned to me before that the range could= change
>> > based
>> > on the matrix and transfer function. I'm fine with your p= roposal.
>> >
>> >>
>> >>
>> >>
>> >> I got requests for having information about "Capture= Gamma Equation"
>> >> (or
>> >> "Tone Curve"), e.g. "same as transfer char= acteristic", Scene Linear,
>> >> S-Log,
>> >> Cine-Log, Log-C...
>> >> I am not an expert of this domain, but looks like it is s= ometimes
>> >> important.
>> >
>> > Someone who knows more about=C2=A0 this should propose someth= ing to this list
>> > to
>> > be included.
>> >
>> >>
>> >> there are also other colour ideas with e.g. EBU Tech 3349= .
>> >
>> > If this is important to people, then we could add this as wel= l.
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> I can post a link to a formatted document if that would b= e easier. For
>> >> Matrix, Range, and Primaries, I'm pretty much using v= alues that map
>> >> directly
>> >> to values defined in FFmpeg.
>> >>
>> >>
>> >> I don't like the idea to use the source code of a pie= ce of software for
>> >> lists. Too much subjective, may have historical flaws. >> >> Lists from FFmpeg are nearly same as the ones in H.26x, I= think I
>> >> prefer
>> >> we base our list on their list (I don't think there a= re copyright
>> >> issues
>> >> with such list) directly.
>> >
>> > I don't know the H.26x list. I started with my own, but t= hen switched to
>> > FFmpeg as they already had an extensive list and assumed they= have seen
>> > a
>> > lot of the video already.
>> >
>> > If deciding between H.26x and FFmpeg, my guess is that FFmpeg= would be
>> > better as it handles a lot more video than H.26x.
>> >
>> >>
>> >> Or that we have a prefix with the origin of the list (e.g= . ARIB
>> >> STD-B67,
>> >> from Japan, is not in ITU/ISO list, a 18 will be used in = the future for
>> >> something in ITU/ISO)
>> >
>> > Yeah HLG is relatively new, but has been requested by a few p= eople.
>> >
>> >
>> >
>> > _______________________________________________
>> > Cellar mailing list
>> > Cellar@i= etf.org
>> > https://www.ietf.org/mailman/listinfo/cel= lar
>> >
>>
>>
>>
>> --
>> Steve Lhomme
>> Matroska association Chairman
>
>
> So I updated my original proposal based on comments from this list. >
> Changes:
> - Added more common ChromaSubsampling values
> - ColourMatrix renamed to Matrix
> - Added a default value of 0 to BitsPerChannel to signify "unspec= ified".
> - Added "decoded" to BitsPerChannel note.
> - Added ChromaSittingHorz and ChromaSittingVert elements.
>
>
> In this case, I think the intended term is =E2=80=98siting=E2=80=99 ra= ther than =E2=80=98sitting=E2=80=99.
>
> - Added Broadcast range to Range element.
> - Removed mandatory flag for elements with unspecified defaults.
> - Updated element IDs.
>
>
> - I kept "Defined by Matrix/TransferFunction" in Range eleme= nt because there
> are ranges that fall outside of Broadcast and Full depending on the TF= . E.g.
> xvYCC (61966-2-4)
> - Does someone want to propose something better for ChromaSubsampling?=
> - I know some people expressed that they don't think starting from= FFmpeg
> for the TransferFunction is a good idea as they might have got somethi= ng
> wrong or too subjective. But I just used it as a starting point for a = list.
> I can reorder the list however we want. I also don't think followi= ng another
> list, so we will be compatible with future additions, will give us wha= t we
> want as that list most likely will be incomplete with something that i= s
> defined only in a different list. So should we just start with a list,=
> re-order it (so we are not explicitly following it), then add what is<= br> > currently missing? Then in the future if someone needs to add somethin= g to
> the list it can be brought up here?
>
>
> I think Jerome=E2=80=99s main point was that FFmpeg=E2=80=99s list the= mselves were based on
> something else, so we should follow the source for a vocabulary author= ity.
> For instance, see ITU Recommendation H.264 at
> https://www.itu.int/rec/T-REC-H.264-201402-I/en<= /a>, article E 39577. Pages 387
> (pdf page 409) gives a table of color primaries, page 388 has transfer=
> characteristics, and 392 has Matrix coefficients. The information in t= he ITU
> docs provides a lot more context than FFmpeg source code.
>
> This is what I currently have:
>
> The parent element would be Video [E0].
>
>
> Element Name: Colour
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 4
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A0]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0m
> Description:=C2=A0 Settings describing the colour format.
>
>
> Element Name: Matrix
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A1]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 2
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB= ), 1:
> BT709,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2: Unspecified, 3: Res= erved, 4: FCC, 5: BT470BG, 6: SMPTE 170M,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7: SMPTE 240M, 8: YCOC= G, 9: BT2020 Non-constant Luminance,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10: BT2020 Constant Lu= minance)
>
>
> I suggest referencing a specific ITU document for these values and the= ir
> meaning.
>
> Element Name: BitsPerChannel
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A2]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 0
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 Number of decoded bits per channel. This number may= be less
> for
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 specific channels depe= nding on the Matrix and
> ChromaSubsampling. A
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 value of 0 is unspecif= ied.
>
>
> Element Name: ChromaSubsampling
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A3]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 0
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4= :2:1, 5:
> 4:2:0,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6: 4:1:1, 7: 4:1:0, 8:= 3:1:1)
>
> Element Name: ChromaSittingHorz
>
>
> Siting
>
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A4]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 0
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 How Chroma is subsampled horizontally. (0: Unspecif= ied, 1:
> Left
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collocated , 2: Half)<= br> >
> Element Name: ChromaSittingVert
>
>
> Siting
>
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A5]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 0
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 How Chroma is subsampled vertically. (0: Unspecifie= d, 1: Top
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 collocated , 2: Half)<= br> >
>
> Element Name: Range
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A6]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 0
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 (0: Unspecified, 1: Broadcast range, 2: Full range,= 3: Defined
> by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Matrix/TransferFunctio= n)
>
>
> I think a description (beyond the list) is needed.
>
> Element Name: TransferFunction
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A7]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 2
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2= :
> Unspecified,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 4: Gamma 2.2 curve, 5:= Gamma 2.8 curve, 6: SMPTE 170M,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 7: SMPTE 240M, 8: Line= ar, 9: Log, 10: Log Sqrt,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11: IEC 61966-2-4, 12:= ITU-R BT.1361 Extended Colour Gamut,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 13: IEC 61966-2-1, 14:= ITU-R BT.2020 10 bit,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 15: ITU-R BT.2020 12 b= it, 16: SMPTE ST 2084,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 17: SMPTE ST 428-1 18:= ARIB STD-B67 (HLG))
>
>
> Consider referencing ITU document as an external authority for the
> vocabulary.
>
> Element Name: Primaries
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A8]
> Default:=C2=A0 =C2=A0 =C2=A0 2
> Description:=C2=A0 (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: I= TU-R
> BT.470M,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A05: ITU-R BT.470B= G, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A09: ITU-R BT.2020= , 10: SMPTE ST 428-1)
>
>
> Consider reference to ITU document. Needs a description besides list.<= br> >
> Element Name: MaxCLL
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][A9]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 Maximum brightness of a single pixel in candelas pe= r square
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 meter (cd/m=C2=B2). >
>
> Element Name: MaxFALL
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][AA]
>
>
> [55][AA] is already in use as FlagForced.
>
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0u
> Description:=C2=A0 Maximum brightness of a single full frame in candel= as per
> square
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 meter (cd/m=C2=B2). >
>
> Element Name: MasteringMetadata
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 5
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D0]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0m
> Description:=C2=A0 SMPTE 2086 mastering data.
>
>
> I=E2=80=99m not well experienced in MasteringMetadata but wouldn=E2=80= =99t this data need to
> change from scene to scene rather than be stored within the Tracks ele= ment
> where the same values would apply to all scenes?
>
> Element Name: PrimaryRChromaticityX
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D1]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> The description is actually a range. When we initially drafted informa= tion
> on expressing ranges in EBML definitions, I ignored float, see
> https://github.com/Matroska-Org/ebml-specification/blob/master/= specification.markdown#expression-of-range.
> I can update this definition to include floats and greater-than-or-equ= al
> values. But the description for this and the following elements should= be
> moved to range (suggested formatting as "0-1=E2=80=9D). Then thes= e elements need
> actual descriptions.

Rather "0.0-1.0" then.

> Element Name: PrimaryRChromaticityY
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D2]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> Element Name: PrimaryGChromaticityX
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D3]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> Element Name: PrimaryGChromaticityY
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D4]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> Element Name: PrimaryBChromaticityX
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D5]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> Element Name: PrimaryBChromaticityY
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D6]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> Element Name: WhitePointChromaticityX
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D7]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> Element Name: WhitePointChromaticityY
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D8]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Valid value is in the range 0 <=3D f <=3D 1.<= br> >
>
> Element Name: LuminanceMax
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][D9]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Maximum luminance. Shall be represented in candelas= per square
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 meter (cd/m=C2=B2). Va= lid value is in the range 0 <=3D f <=3D 9999.99
>
>
> Add a Range value and split the Description and Range.
>
> Element Name: LuminanceMin
> Level:=C2=A0 =C2=A0 =C2=A0 =C2=A0 6
> ID:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[55][DA]
> Mandatory:=C2=A0 =C2=A0 -
> Multiple:=C2=A0 =C2=A0 =C2=A0-
> Default:=C2=A0 =C2=A0 =C2=A0 -
> Type:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0f
> Description:=C2=A0 Minimum luminance. Shall be represented in candelas= per square
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 meter (cd/m=C2=B2). Va= lid value is in the range 0 <=3D f <=3D 999.9999
>
>
> Add a Range value and split the Description and Range.
>
> Best Regards,
> Dave Rice
>
>
> _______________________________________________<= br> > Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar >



--
Steve Lhomme
Matroska association Chairman



I'll look into referencing an ITU documen= t.

sit= ing. Yes :)

[55][AA], Yes I know I currently changed all the [55][Ax] to [55][Bx]= .

Rang= e Description: How about:

Clipping of the color ranges. <= span style=3D"font-size:13.3333px;font-family:'Courier New';vertica= l-align:baseline;white-space:pre-wrap">(0: Unspecified, 1: Broadcast range,=

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A02: Full range (no = clipping), 3: Defined by

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0Matrix/TransferFunction)

2086 Mastering metadata refers to the display the c= ontent was mastered on. So these values should not change scene to scene.

How about these for the values with range= s. I didn't add a .0 for values which should be close to the integer va= lue.

Elem= ent Name: PrimaryRChromaticityX

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0[55][D1]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= /span>0 <=3D f <=3D 1

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0f

Description: = =C2=A0Red X chromaticity coordinate as defined by CIE 193= 1.



Element Name: = PrimaryRChromaticityY

Lev= el: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0[55][D2]

Mand= atory: =C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 1

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f=

Description: =C2=A0Red Y chromaticity coordinate as defined by CIE 1931.

Element Name: PrimaryGChr= omaticityX

Level: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0[55][D3]

Mandatory: = =C2=A0=C2=A0=C2=A0-

Multi= ple: =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 0 <=3D f <=3D 1

Def= ault: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

f

Descriptio= n: =C2=A0Green X chromaticity coordinate as defined by CI= E 1931.



Element N= ame: PrimaryGChromaticityY

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0[55][D4]

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 1

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0f

Description: =C2= =A0Green Y chromaticity coordinate as defined by CIE 1931= .



Element Name: PrimaryBChromaticityX

Level: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A06

ID= : =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D5]

Mandatory: =C2=A0=C2=A0=C2=A0= -

Multiple: =C2=A0=C2=A0= =C2=A0=C2=A0-

Range: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <= =3D 1

Default: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0-

f<= /span>

Description: =C2=A0Blue X chromaticity coordinate as defined by CIE 1931.

Element Name: PrimaryBChr= omaticityY

Level: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0[55][D6]

Mandatory: = =C2=A0=C2=A0=C2=A0-

Multi= ple: =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 0 <=3D f <=3D 1

Def= ault: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f=

Description: =C2=A0Blue Y chromaticity coordinate as defined by CIE 1931.


=

Element Name: WhitePointChromat= icityX

Level: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[= 55][D7]

Mandatory: =C2=A0= =C2=A0=C2=A0-

Multiple: = =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <= =3D f <=3D 1

Default: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

Description: =C2=A0= White point X chromaticity coordinate as defined by CIE 1931.


Element Name: WhitePointChroma= ticityY

Level: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[= 55][D8]

Mandatory: =C2=A0= =C2=A0=C2=A0-

Multiple: = =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <= =3D f <=3D 1

Default: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

Description: =C2=A0= White point Y chromaticity coordinate as defined by CIE 1931.


Element Name: LuminanceMax

Level: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A06

ID= : =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D9]

Mandatory: =C2=A0=C2=A0=C2=A0= -

Multiple: =C2=A0=C2=A0= =C2=A0=C2=A0-

Range: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <= =3D 9999.99

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-<= /span>

Type: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

Description: =C2=A0Maximum luminance. Shall be represented in candel= as per square

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0meter = (cd/m=C2=B2).



Ele= ment Name: LuminanceMin

L= evel: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0[55][DA]

M= andatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D = 999.9999

Default: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

Description: =C2=A0Minimum luminance. Sha= ll be represented in candelas per square

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0meter (cd/m=C2=B2).



--001a11367c2e56904b052af8062a-- From nobody Mon Feb 8 09:15:22 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B578A1B2F75 for ; Mon, 8 Feb 2016 09:15:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 kczG0Z35gGYb for ; Mon, 8 Feb 2016 09:15:19 -0800 (PST) Received: from 20.mo4.mail-out.ovh.net (20.mo4.mail-out.ovh.net [46.105.33.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CEEC1B2F79 for ; Mon, 8 Feb 2016 09:15:17 -0800 (PST) Received: from mail178.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo4.mail-out.ovh.net (Postfix) with SMTP id 30F7E101C11D for ; Mon, 8 Feb 2016 18:15:15 +0100 (CET) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 8 Feb 2016 19:15:14 +0200 Received: from p5ddb7157.dip0.t-ipconnect.de (HELO ?192.168.2.101?) (jerome@francoallemand.eu@93.219.113.87) by ns0.ovh.net with SMTP; 8 Feb 2016 19:15:07 +0200 To: cellar@ietf.org, Frank Galligan References: <568C3CA0.8040300@mediaarea.net> From: Jerome Martinez Message-ID: <56B8CD1A.20307@mediaarea.net> Date: Mon, 8 Feb 2016 18:15:06 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050206080401020503080904" X-Ovh-Tracer-Id: 14779406602360328277 X-Ovh-Remote: 93.219.113.87 (p5ddb7157.dip0.t-ipconnect.de) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -100 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrvdejucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrvdekgddutdcutefuodetggdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm Archived-At: Cc: Discussion about the current and future development of Matroska Subject: Re: [Cellar] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 08 Feb 2016 17:15:21 -0000 This is a multi-part message in MIME format. --------------050206080401020503080904 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sorry for the late answer, here are my comments: On 22/01/2016 23:54, Frank Galligan wrote: > [...] > > - I know some people expressed that they don't think starting from > FFmpeg for the TransferFunction is a good idea as they might have got > something wrong or too subjective. But I just used it as a starting > point for a list. I can reorder the list however we want. I also don't > think following another list, so we will be compatible with future > additions, will give us what we want as that list most likely will be > incomplete with something that is defined only in a different list. So > should we just start with a list, re-order it (so we are not > explicitly following it), then add what is currently missing? Then in > the future if someone needs to add something to the list it can be > brought up here? That was me. I am OK with that as long as we are clear that we don't follow FFmpeg list. > > [...] > > Element Name: Matrix > > Level: 5 > > ID: [55][A1] > > Mandatory: - > > Multiple: - > > Default: 2 > > Type: u > > Description: Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB), 1: > BT709, > > 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE > 170M, > > 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance, > > 10: BT2020 Constant Luminance) > If we don't follow FFmpeg list, what is the purpose of value 3 and why unspecified is 2 rather than 0? Using FFmpeg list (which is based on MPEG list, with same oddities) is not bad, and I am not against it, just wondering if it is good to take the same oddities rather than a clean list without oddities. Does anyone plan to transfer from DPX? If yes, we may need to add now missing elements in the list (e.g. "Printing density") but I am not expert enough for know which one is worth it. > > > [...] > > > > Element Name: ChromaSubsampling > > Level: 5 > > ID: [55][A3] > > Mandatory: - > > Multiple: - > > Default: 0 > > Type: u > > Description: (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1, > 5: 4:2:0, > > 6: 4:1:1, 7: 4:1:0, 8: 3:1:1) > I am more, as some other people, for something more generic, e.g. ChromaSubsamplingHorz and ChromaSubsamplingVert, with a value of the subsampling (0 unspecified and default). I am afraid that someone crazy used e.g. a vertical subsampling of 4 (which can not be defined by X:X:X values), it is possible (and I have a file like that if I remember well) with FFV1. > > [...] > > Element Name: TransferFunction > > Level: 5 > > ID: [55][A7] > > Mandatory: - > > Multiple: - > > Default: 2 > > Type: u > > Description: Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: > Unspecified, > > 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, > > 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, > > 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut, > > 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, > > 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, > > 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) > > > > Element Name: Primaries > > Level: 5 > > Mandatory: - > > Multiple: - > > ID: [55][A8] > > Default: 2 > > Description: (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R > BT.470M, > > 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM, > > 9: ITU-R BT.2020, 10: SMPTE ST 428-1) > Same remark as with Matrix. > > [...] > --------------050206080401020503080904 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
Sorry for the late answer, here are my comments:

On 22/01/2016 23:54, Frank Galligan wrote:
[...]

- I know some people expressed that they don't think starting from FFmpeg for the TransferFunction is a good idea as they might have got something wrong or too subjective. But I just used it as a starting point for a list. I can reorder the list however we want. I also don't think following another list, so we will be compatible with future additions, will give us what we want as that list most likely will be incomplete with something that is defined only in a different list. So should we just start with a list, re-order it (so we are not explicitly following it), then add what is currently missing? Then in the future if someone needs to add something to the list it can be brought up here?

That was me.
I am OK with that as long as we are clear that we don't follow FFmpeg list.


[...]

Element Name: Matrix

Level:        5

ID:           [55][A1]

Mandatory:    -

Multiple:     -

Default:      2

Type:         u

Description:  Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB), 1: BT709,

             2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M,

             7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance,

             10: BT2020 Constant Luminance)



If we don't follow FFmpeg list, what is the purpose of  value 3 and why unspecified is 2 rather than 0?
Using FFmpeg list (which is based on MPEG list, with same oddities) is not bad, and I am not against it, just wondering if it is good to take the same oddities rather than a clean list without oddities.

Does anyone plan to transfer from DPX? If yes, we may need to add now missing elements in the list (e.g. "Printing density") but I am not expert enough for know which one is worth it.




[...]



Element Name: ChromaSubsampling

Level:        5

ID:           [55][A3]

Mandatory:    -

Multiple:     -

Default:      0

Type:         u

Description:  (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1, 5: 4:2:0,             

             6: 4:1:1, 7: 4:1:0, 8: 3:1:1)


I am more, as some other people, for something more generic, e.g. ChromaSubsamplingHorz and ChromaSubsamplingVert, with a value of the subsampling (0 unspecified and default). I am afraid that someone crazy used e.g. a vertical subsampling of 4 (which can not be defined by X:X:X values), it is possible (and I have a file like that if I remember well) with FFV1.




[...]

Element Name: TransferFunction

Level:        5

ID:           [55][A7]

Mandatory:    -

Multiple:     -

Default:      2

Type:         u

Description:  Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified,

             4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M,

             7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt,

             11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut,

             13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit,

             15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084,

             17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG))



Element Name: Primaries

Level:        5

Mandatory:    -

Multiple:     -

ID:           [55][A8]

Default:      2

Description:  (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R BT.470M,

              5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM,

              9: ITU-R BT.2020, 10: SMPTE ST 428-1)


Same remark as with Matrix.


[...]


--------------050206080401020503080904-- From nobody Mon Feb 8 14:23:11 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42791B2CA8 for ; Mon, 8 Feb 2016 14:23: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, SPF_PASS=-0.001] autolearn=ham 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 ko2wMwqmi3df for ; Mon, 8 Feb 2016 14:23:06 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 A26401A88DC for ; Mon, 8 Feb 2016 14:23:06 -0800 (PST) Received: by mail-ob0-x232.google.com with SMTP id wb13so172183849obb.1 for ; Mon, 08 Feb 2016 14:23:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6hewrtXHwklIhfujRyCqNLLVg9bge+2s6L043eM+hh0=; b=y6JbpV7McEQp0SZ9M1mPVhAeGtVcCldzYQ+lOlbVotkVpZOLrZwgPXE05i++sIbNfe VgjW6syhzcVCthAqIf0VNX5DZ+tXhdhVPQY7pnDhfcrvvDh/nTJMq/kv0KB15+oHxT4S 0fO/cPT88YV42dhZMEoTgEXh+OxXtUK/2JCoK0ns0mMIjcRlz/MSEN3ZROk7M/lPoMgU ybq26B/tc2jCoLmYgyw/9M4kMOCV4lfq5QXMsnfTJbRveMBnNYgcS1tLQnxzSntQDFzK AXNSqjKCUwM7YnUMZ8DlT89tafC+D+4bdAm+RJDvulBvB/IOZ15sPyAUgZOtnTLUOhmU GPeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6hewrtXHwklIhfujRyCqNLLVg9bge+2s6L043eM+hh0=; b=DthGHaxyCd+DTR/Wyy0r5yhosbODivRPq2KlH3mbMz7xJw1djEaOfSzqQGYPptLM9Q uYIk26+rf5V5sT6pnchd1bLjpFheD4mKnJBJTvvf/pblUhmKoBfcXDyxCLxOVsbToLuE iNbTTf5uCr5IBjOJZw2PzBzWphcHUVGhoo9vRSkou6LHnzO7ElVwxBtv0ZdhvDVT8fYx oybMBbkh5YTFeLKXV5SlqWLshZYIrox7rPCQuQpJ8WC8MJmYRwI3+IzAtzFdblUMSq4y bDjjiHP1TDkY6naPJvC0GaubqTAKLYy5E16nAwmE0hvtLWK25TONLHCDUgKbdjU0rEyC 7jgw== X-Gm-Message-State: AG10YOQV6LiIQ2SZwXzBXwK24Irvh48+mC7ioOcLbG6y+mIKVwaarTCy3YVMtGQvn9zgK5Skn2L6ZuxUuK5gEw== MIME-Version: 1.0 X-Received: by 10.182.137.198 with SMTP id qk6mr27015725obb.5.1454970185900; Mon, 08 Feb 2016 14:23:05 -0800 (PST) Received: by 10.202.59.130 with HTTP; Mon, 8 Feb 2016 14:23:05 -0800 (PST) In-Reply-To: <56B8CD1A.20307@mediaarea.net> References: <568C3CA0.8040300@mediaarea.net> <56B8CD1A.20307@mediaarea.net> Date: Mon, 8 Feb 2016 14:23:05 -0800 Message-ID: From: Frank Galligan To: Jerome Martinez Content-Type: multipart/alternative; boundary=001a11c2e4ae16e699052b49a56f Archived-At: Cc: Discussion about the current and future development of Matroska , cellar@ietf.org Subject: Re: [Cellar] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 08 Feb 2016 22:23:09 -0000 --001a11c2e4ae16e699052b49a56f Content-Type: text/plain; charset=UTF-8 On Mon, Feb 8, 2016 at 9:15 AM, Jerome Martinez wrote: > Sorry for the late answer, here are my comments: > > On 22/01/2016 23:54, Frank Galligan wrote: > > [...] > > - I know some people expressed that they don't think starting from FFmpeg > for the TransferFunction is a good idea as they might have got something > wrong or too subjective. But I just used it as a starting point for a list. > I can reorder the list however we want. I also don't think following > another list, so we will be compatible with future additions, will give us > what we want as that list most likely will be incomplete with something > that is defined only in a different list. So should we just start with a > list, re-order it (so we are not explicitly following it), then add what is > currently missing? Then in the future if someone needs to add something to > the list it can be brought up here? > > > That was me. > I am OK with that as long as we are clear that we don't follow FFmpeg list. > OK, I changed the text to see ISO/IEC 23001-8 document, which has the same values as FFmpeg as well as the 264 ITU doc. > > > [...] > > Element Name: Matrix > > Level: 5 > > ID: [55][A1] > > Mandatory: - > > Multiple: - > > Default: 2 > > Type: u > > Description: Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB), 1: > BT709, > > 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE > 170M, > > 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance, > > 10: BT2020 Constant Luminance) > > > > If we don't follow FFmpeg list, what is the purpose of value 3 and why > unspecified is 2 rather than 0? > That is the way it is specified in ISO/IEC 23001-8 and 264 ITU doc. Using FFmpeg list (which is based on MPEG list, with same oddities) is not > bad, and I am not against it, just wondering if it is good to take the same > oddities rather than a clean list without oddities. > I don't think there are any oddities. Looks like FFmpeg's list matches exactly to ISO/IEC 23001-8 and 264 ITU doc, except for #10 in Primaries and #16 and #17 in Transfer function, which were added here [1]. Also #18 in Transfer, which is HLG [2]. I think this is the whole issue. Do we follow some list (standardized or not)? What if the list goes stale? What if the list doesn't include algorithms from different lists (E.g. maybe HLG)? > Does anyone plan to transfer from DPX? If yes, we may need to add now > missing elements in the list (e.g. "Printing density") but I am not expert > enough for know which one is worth it. > > > > > [...] > > > Element Name: ChromaSubsampling > > Level: 5 > > ID: [55][A3] > > Mandatory: - > > Multiple: - > > Default: 0 > > Type: u > > Description: (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1, 5: > 4:2:0, > > 6: 4:1:1, 7: 4:1:0, 8: 3:1:1) > > > I am more, as some other people, for something more generic, e.g. > ChromaSubsamplingHorz and ChromaSubsamplingVert, with a value of the > subsampling (0 unspecified and default). I am afraid that someone crazy > used e.g. a vertical subsampling of 4 (which can not be defined by X:X:X > values), it is possible (and I have a file like that if I remember well) > with FFV1. > > > > > [...] > > Element Name: TransferFunction > > Level: 5 > > ID: [55][A7] > > Mandatory: - > > Multiple: - > > Default: 2 > > Type: u > > Description: Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: > Unspecified, > > 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, > > 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, > > 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut, > > 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, > > 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, > > 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) > > > Element Name: Primaries > > Level: 5 > > Mandatory: - > > Multiple: - > > ID: [55][A8] > > Default: 2 > > Description: (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R > BT.470M, > > 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM, > > 9: ITU-R BT.2020, 10: SMPTE ST 428-1) > > > Same remark as with Matrix. > > > [...] > > > [1] https://github.com/FFmpeg/FFmpeg/commit/c3cd6dd106b1381933e2f24898eeec0d8aa17746 [2] http://www.arib.or.jp/english/html/overview/std-b67.html --001a11c2e4ae16e699052b49a56f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 8, 2016 at 9:15 AM, Jerome Martinez <<= a href=3D"mailto:jerome@mediaarea.net" target=3D"_blank">jerome@mediaarea.n= et> wrote:
=20 =20 =20
Sorry for the late answer, here are my comments:

On 22/01/2016 23:54, Frank Galligan wrote:
[...]

- I know some people expressed that they don't think starting from FFmpeg for the TransferFunction is a good idea as they might have got something wrong or too subjective. But I just used it as a starting point for a list. I can reorder the list however we want. I also don'= t think following another list, so we will be compatible with future additions, will give us what we want as that list most likely will be incomplete with something that is defined only in a different list. So should we just start with a list, re-order it (so we are not explicitly following it), then add what is currently missing? Then in the future if someone needs to add something to the list it can be brought up here?

That was me.
I am OK with that as long as we are clear that we don't follow FFmpeg list.
OK, I changed the text to see I= SO/IEC 23001-8 document, which has the same values as FFmpeg as well as the= 264 ITU doc.


[...]

Element Name: Matrix<= /span>

Level: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][A1]

Mandatory: =C2=A0=C2= =A0=C2=A0-

Multiple: =C2=A0=C2= =A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A02

Type: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0Co= lour Matrix of the video. (0: IEC 61966-2-1 (sRGB), 1: BT709,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A02: Unspecified,= 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A07: SMPTE 240M, = 8: YCOCG, 9: BT2020 Non-constant Luminance,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A010: BT2020 Cons= tant Luminance)



If we don't follow FFmpeg list, what is the purpose of=C2=A0 value = 3 and why unspecified is 2 rather than 0?
That is = the way it is specified in ISO/IEC 23001-8=C2=A0and 264 ITU doc.=C2=A0

Using FFmpeg list (which is based on MPEG list, with same oddities) is not bad, and I am not against it, just wondering if it is good to take the same oddities rather than a clean list without oddities.
I don't think there are any oddities. Looks like = FFmpeg's list matches exactly to =C2=A0ISO/IEC 23001-8=C2=A0and 264 ITU= doc, except for #10 in Primaries and #16 and #17 in Transfer function, whi= ch were added here [1]. Also #18 in Transfer, which is HLG [2].
<= br>
I think this is the whole issue. Do we follow some list (stan= dardized or not)? What if the list goes stale? What if the list doesn't= include algorithms from different lists (E.g. maybe HLG)?



Does anyone plan to transfer from DPX? If yes, we may need to add now missing elements in the list (e.g. "Printing density") bu= t I am not expert enough for know which one is worth it.




[...]



Element Name: Chrom= aSubsampling

Level: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][A3]

Mandatory: =C2=A0= =C2=A0=C2=A0-

Multiple: =C2=A0=C2= =A0=C2=A0=C2=A0-

Default: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A00

Type: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0= (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1, 5: 4:2:0, =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06: 4:1:1, 7: 4:= 1:0, 8: 3:1:1)


I am more, as some other people, for something more generic, e.g. ChromaSubsamplingHorz and ChromaSubsamplingVert, with a value of the subsampling (0 unspecified and default). I am afraid that someone crazy used e.g. a vertical subsampling of 4 (which can not be defined by X:X:X values), it is possible (and I have a file like that if I remember well) with FFV1.




[...]<= /span>

Element Name: Trans= ferFunction

Level: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][A7]

Mandatory: =C2=A0= =C2=A0=C2=A0-

Multiple: =C2=A0=C2= =A0=C2=A0=C2=A0-

Default: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A02

Type: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0= Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A04: Gamma 2.2 cu= rve, 5: Gamma 2.8 curve, 6: SMPTE 170M,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A07: SMPTE 240M, = 8: Linear, 9: Log, 10: Log Sqrt,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A011: IEC 61966-2= -4, 12: ITU-R BT.1361 Extended Colour Gamut,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A013: IEC 61966-2= -1, 14: ITU-R BT.2020 10 bit,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A015: ITU-R BT.20= 20 12 bit, 16: SMPTE ST 2084,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A017: SMPTE ST 42= 8-1 18: ARIB STD-B67 (HLG))



Element Name: Prima= ries

Level: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

Mandatory: =C2=A0= =C2=A0=C2=A0-

Multiple: =C2=A0=C2= =A0=C2=A0=C2=A0-

ID: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][A8]

Default: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A02

Description: =C2=A0= (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R BT.470M,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05: ITU-R = BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A09: ITU-R = BT.2020, 10: SMPTE ST 428-1)


Same remark as with Matrix.


[...]



[1]=C2=A0https://github.com/FFmpeg/FFmpeg/commit/c3cd6dd106b1381933e2f24898e= eec0d8aa17746
[2]=C2=A0http://www.arib.or.jp/= english/html/overview/std-b67.html

=

--001a11c2e4ae16e699052b49a56f-- From nobody Mon Feb 8 20:45:45 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 196461A038D for ; Mon, 8 Feb 2016 20:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 L3uecbzIZpAW for ; Mon, 8 Feb 2016 20:45:37 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F2941A03A0 for ; Mon, 8 Feb 2016 20:45:37 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:44017 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aT0B2-002ir2-Ll; Mon, 08 Feb 2016 23:45:36 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_C236A7B1-4E97-4E42-8A41-BEA5172A5446" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Mon, 8 Feb 2016 23:45:15 -0500 Message-Id: References: <21E28D45-E45F-4CBE-AC3D-6E41DCE172B9@dericed.com> <20150828065002.GH3813@bunkus.org> <5606B89B-FCF0-4C75-BAB8-FB1E212F8D82@dericed.com> <5EDBE9D2-3E2F-4865-ACF9-497706E0CA07@dericed.com> <87110F5D-3199-4CF5-887E-D5B8C7A08C6C@dericed.com> To: cellar@ietf.org X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-0.7 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Steve Lhomme Subject: Re: [Cellar] EBML Schema X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 09 Feb 2016 04:45:45 -0000 --Apple-Mail=_C236A7B1-4E97-4E42-8A41-BEA5172A5446 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 3, 2016, at 4:38 AM, Steve Lhomme wrote: >=20 > 2016-01-23 20:49 GMT+01:00 Dave Rice : >>=20 >> On Jan 17, 2016, at 8:05 AM, Steve Lhomme = wrote: >>=20 >> 2016-01-15 16:35 GMT+01:00 Dave Rice : >>=20 >>=20 >> On Jan 15, 2016, at 7:44 AM, Steve Lhomme = wrote: >>=20 >> 2016-01-15 7:27 GMT+01:00 Dave Rice : >>=20 >>=20 >> On Dec 1, 2015, at 10:40 AM, Dave Rice wrote: >>=20 >> On Nov 9, 2015, at 1:19 PM, Dave Rice wrote: >>=20 >> On Oct 3, 2015, at 9:46 AM, Steve Lhomme = wrote: >>=20 >> On Aug 28, 2015 17:00, "Dave Rice" wrote: >>=20 >> On Aug 28, 2015, at 2:50 AM, Moritz Bunkus wrote: >>=20 >> Hey, >>=20 >> I have no objections, however I don't know a lot about XML schemas in >> the first place (neither about DTDs, to be honest). >>=20 >>=20 >>=20 >> Honestly, I know a lot more about XML Schemas than I do about DTDs. = As >> wikipedia mentions at >> https://en.wikipedia.org/wiki/Document_type_definition, DTDs have = largely >> been superseded by XML Schemas. And at this point I think that XML = Schemas >> may be a more familiar analogy to use. >>=20 >> I think XML Schemas also share more in common with specdata.xml than = DTDs >> do. Schemas use the node and have maxOccurs and minOccurs >> attributes (specdata has semantically the same thing with mandatory = and >> multiple), they both have a similar declaration of element type, = element >> name and element description. Actually I think a semantically = equivalent >> version of specdata.xml could be written as an XML Schema. >>=20 >> XML Schemas also offer a few advantages for machine readable = expressions; >> for instance XML Schemas can mandate a particular pattern or regex = for a >> value. >>=20 >> I propose the specdata.xml file here >>=20 >> = https://github.com/Matroska-Org/foundation-source/blob/master/spectool/spe= cdata.xml >>=20 >> = >> is a good basis for the consideration of an EBML Schema. =46rom what = I >> can see, specdata.xml is an expression of the EBML + Matroska >> specifications to support automated creation of documentation, but = the >> structure of this already shares a lot of similarity to XML Schemas. >>=20 >>=20 >>=20 >> For both documentation (e.g. the table on the matroska.org specs page = is >> generated from this file) and code (libMatroska's class hierarchy is >> generated automatically from this file) actually. >>=20 >>=20 >>=20 >> Does specdata.xml play a role in mkvalidate? I'm thinking of the = potential >> to have an ebmlvalidator where you can provide the EBML Schema to = validate >> particular EBML docType. >>=20 >>=20 >> Well the parsing code is generated from the XML file, so in a way, = yes. But >> it's not parsed "live". >>=20 >> Is there a preference in handling the standardization of Matroska: >> documenting it in a similar fashion to our work in the EBML spec or = to >> define what an EBML Schema is and consider matroska an expression of >> it? >>=20 >>=20 >>=20 >> I'm not sure whether or not I understand the implications. But my gut >> feeling is that having a definition for an EBML Schema would benefit >> other formats than Matroska, too, therefore the latter seems the way = to >> go. >>=20 >>=20 >>=20 >> I have the same feeling: >> - document EBML as a specification that includes rules for defining a >> docType in the form of an EBML Schema >> - write an EBML Schema (updated specdata.xml) for Matroska and maybe = webM >>=20 >> Are some changes to specdata.xml acceptable? Such as a filename = change >> or changing the name of the
element of some attributes? >>=20 >>=20 >>=20 >> Well, like I said above the specdata.xml is used for generating both >> documentation and code. Both should stay viable. If changes to it are >> made then the accompanying tools must be updated as well. >>=20 >> Neither the current EBML specs nor the specdata.xml specifically = refer >> to the hierarchical arrangement of the elements, but this could be >> presumed by their ordering. For instance, could any level 3 element = be >> a child of any level 2 Master-element? I presume not, but I don't >> think it's clear anywhere what parent-child relationships are >> feasible. Possibly specdata.xml and/or the EBML Schema Definition >> could define the relationship between levels of related elements >> similar to how an XML Schema (XSD) does. >>=20 >>=20 >>=20 >> So far it is understood that an element not marked as a global = element >> must only occur as a child of its parent. Its parent is the last = element >> located before the child element in the specdata file with a lower = level >> than the child element. Or something like that. >>=20 >>=20 >>=20 >> This will need some documentation. That's how I've understood the mkv = spec >> as well but the definition for how an EBML Schema works should be = explicit >> about this. >>=20 >>=20 >> Any more opinion about how to go about (or if to go about) modifying >> specdata.xml towards becoming an expression of a to-be-defined EBML = Schema >> for matroska and webm? As a summary of proposed changes to = specdata.xml >>=20 >> - change to XML Schema conventions where relevant: >> - use maxOccurs attribute instead of the current Multiple attribute. >> - use minOccurs attribute instead of the current Mandatory attribute. >> - move documentation of elements to a sub-element (allows for = possible >> internationalization in the schema and better semantics) >> - arrange elements in hierarchical form to indicate parent-child >> relationships (rather than the current practices where all elements = are >> defined at the same level, and you have to parse back in elements to = the one >> with the lower-numbered level attribute to find the parent) >>=20 >> A draft of specdata.xml with these changes is at >> https://gist.github.com/dericed/f0a4bb0e7dc635ed1347. I can continue = to work >> on this and send back changes for advice/approval but if I do so is = there >> someone who could later update the tools that use specdata.xml so = that >> newly-defined EBML Schemas may later to be into use? >>=20 >>=20 >> I=E2=80=99m preparing a pull request on specdata.xml but want to = update the >> utilities in spectool at the same time so that spec2data, data2lib, = and >> data2spec still function properly. I=E2=80=99m having trouble getting = the spectool >> utilities to build properly so that I can test them. I was able to = build >> coremake but not sure where to go from here. I=E2=80=99ve read = spec2data and have an >> idea of how it works and am thinking that I could reproduce the = spec2data >> workflow with xsl and then we could have a make file which uses = xsltproc to >> convert an EBML Schema into the Drupal table and library files as = needed. >> Any advice on which route to take: continue trying with getting = spectool >> utilities to build or redo the utilities in xsl? >>=20 >>=20 >> I=E2=80=99d like to revive this thread to propose some changes in the = definition of >> the EBML Schema. The EBML Schema is intended to be a machine-readible >> document that details the semantics and structure of an EBML Document = Type. >> The EBML Schema for a Document Type is essential for understanding = the >> semantics and validating an EBML Document. This proposal builds upon = an >> earlier conversation started last year on matroska-devel, >> = http://lists.matroska.org/pipermail/matroska-devel/2015-August/004765.html= , >> = http://lists.matroska.org/pipermail/matroska-devel/2015-October/004807.htm= l. >>=20 >> I=E2=80=99m open to other solutions or approaches, but since Matroska = is based on >> EBML which itself is becoming well-defined. I think there is utility = in >> documenting how to create a machine-readible document that describes = an EBML >> Document Type. I think the concept of the XML Schema and XML Document = is >> analogous to EBML Schema and EBML Document and that adopting from the = XML >> community for documenting form may be beneficial. >>=20 >> Thus far we have this section >> = https://github.com/Matroska-Org/ebml-specification/blob/3b30502d2adb6a22c6= 0294c1e7ea68f703e07e50/specification.markdown#ebml-schema >> which introduces the concept for the EBML Schema and then provides a = list of >> attributes for defining Elements that make up a specific EBML = Document Type >> = https://github.com/Matroska-Org/ebml-specification/blob/3b30502d2adb6a22c6= 0294c1e7ea68f703e07e50/specification.markdown#ebml-schema-element-attribut= es. >> This documentation currently reflects the specdata.xml file of the = Matroska >> foundation-source repo, which is here >> = https://github.com/Matroska-Org/foundation-source/blob/master/spectool/spe= cdata.xml. >> The specdata.xml file is used to create the HTML table of elements on >> http://matroska.org/technical/specs/index.html and libraries used by >> mkvalidate and other files. After drafting the EBML Schema and = Attribute >> documentation I found >> http://matroska.org/technical/specs/notes.html#Table_Columns which = covers >> similar concepts. >>=20 >> I=E2=80=99d like to propose the following changes to the definition = of EBML Schema: >>=20 >> - Replace
with . >>=20 >> The node
makes sense in the context of the HTML table on >> matroska.org but if there will be greater machine-readible usage I = think a >> rename would clarify. >>=20 >> - Add an XML NameSpace attribute to . >>=20 >> This would add something like >> = xmlns=3D=E2=80=9Chttp://official_url_of_EBML_Schema_definition.org/EBMLSch= ema.xsd=E2=80=9D. >> The EBMLSchema.xsd file would be an XML Schema that defines the = EBMLSchema >> document itself. Yes, this uses an XML Schema to define the EBML = Schema, but >> this gives a way to validate the EBML Schemas and docType definitions = made >> by others. >>=20 >> - Add a =E2=80=9CdocType=E2=80=9D attribute to >>=20 >> This would clarify what the EBMLSchema is documenting, thus it would = start >> with >>=20 >> - Add =E2=80=9Cversion=E2=80=9D attribute to >>=20 >> This would note the highest version number of the docType officially >> documented by the EBML Schema, so the EBML Schema would be inferred = to >> document the noted docType from version 0 up to the version value = listed >> here. >>=20 >>=20 >> Maybe we need something to say it's the final version or a draft. >>=20 >>=20 >> With XML Schemas this is done by having an entirely separate document = per >> version. We could have separate files such as: >>=20 >> matroska_v1.xml >> matroska_v2.xml >> matroska_v3.xml >> matroska_v4.xml >> matroska_v5RC.xml >> webm_v1.xml >>=20 >> Or we could add an attribute called something like "unofficial" so = that we >> may have an EBML Schema with non-standardized elements for testing. >>=20 >> Any preference at which tactic? An advantage of having versioned EBML >> Schemas (one doc per version) is that the deprecated elements are = simply >> removed rather than an eternal lingering presence. It may accept = complexity >> in use though since you'd have to use the proper schema that matches = both >> the docType and docTypeVersion. >>=20 >>=20 >> That makes omission by mistake a possibility, involves more proof >> reading and it becomes harder to know which elements changed between >> what versions. It's also harder to process to generate code. Also >> should the documentation we currently have be duplicated on each >> document ? I'd rather keep a single document. >>=20 >> - Rename =E2=80=9Cmandatory=E2=80=9D as =E2=80=9CminOccurs=E2=80=9D = and rename =E2=80=9Cmultiple=E2=80=9D as =E2=80=9CmaxOccurs=E2=80=9D >>=20 >>=20 >> That may be odd when we add "repeatable" elements that must be = maxOccurs =3D >> 1. >>=20 >>=20 >> With maxOccurs it is usually set via numbers, however 'unbounded' is = an >> accepted maxOccurs value to say that the element may repeat for an = infinite >> amount of times. In addition to "unbounded" we could also add a value >> "identical" which would mean the same as "unbounded" with the added >> constraint that every copy be identical. >>=20 >>=20 >> That sounds good, yes. >>=20 >> This is to match the meaning of minOccurs and maxOccurs in XML = Schema, >> https://www.w3.org/TR/xmlschema-0/#ref6. >> mandatory=3D=E2=80=9C0=E2=80=9D would be equivalent to = minOccurs=3D=E2=80=9C0" >> mandatory=3D=E2=80=9C1=E2=80=9D would be equivalent to = minOccurs=3D=E2=80=9C1=E2=80=9D >> no mandatory attribute would be equivalent of no minOccurs attribute = which >> is equivalent to minOccurs=3D=E2=80=9C1=E2=80=9D (as is true with = minOccurs within an XML >> Schema) >>=20 >> multiple=3D=E2=80=9C0=E2=80=9D would be equivalent to maxOccurs = =3D=E2=80=9C1" >> multiple =3D=E2=80=9C1=E2=80=9D would be equivalent to maxOccurs = =3D=E2=80=9Cunbounded=E2=80=9D >> no multiple attribute would be equivalent of no maxOccurs attribute = which is >> equivalent to maxOccurs =3D=E2=80=9C1=E2=80=9D (as is true with = maxOccurs within an XML >> Schema) >>=20 >> Moving from mandatory/multiple to minOccurs/maxOccurs can be done = with no >> semantic differences, but we=E2=80=99d have to advantage of allowing = for constraints >> to the number of usage that are not 0, 1, and infinite. For instance, = I >> understand the logic to have 2 SeekHead Elements, but is there a = scenario >> for 3 or more SeekHeads at the same Level within the same EBML = Document? >>=20 >>=20 >> Limiting the amount of redirection might be a good thing indeed. >>=20 >>=20 >> Are there other elements currently listed as multiple=3D"1" where = they are >> intended for use greater than 1 and less than unbounded. SeekHead was = the >> only one coming to mind. >>=20 >>=20 >> Not from the top of my mind. >>=20 >> - Store nodes hierarchically rather than all at the same = level. >>=20 >> Currently with in the specdata.xml file it is difficult to ascertain = the >> parent of a given element. It can be done by seeking to the previous = element >> where the level of the element is one value lower, but there are = exceptions >> for global elements. I suggest that a structure of >> >> ... >> ... >> >> is more clear than all elements at the same level. I made an example = draft >> of specdata.xml with nested implementing here: >> https://gist.github.com/dericed/f0a4bb0e7dc635ed1347. >>=20 >> I can provide a patch to the current EBML Schema and EBML Schema = Attributes >> as well as incorporate a sample EBML Schema into the specification, = but >> wanted to nudge for comments before proceeding. >>=20 >>=20 >> The current flat hierarchy is not good anyway. I will need a bit of >> time to update the spec tools accordingly. But the change is OK for >> me. >>=20 >>=20 >> Thanks. Should I cross-post this to webm lists? >>=20 >>=20 >> No idea if they use the document but it's worth a try. >>=20 >>=20 >> Here are some changes made to the definition of EBML Schema. I placed = them >> into a pull request in github, >> https://github.com/Matroska-Org/ebml-specification/pull/51/files, and = will >> summarize the changes here. >>=20 >> I removed the attributes for mandatory, multiple, and identical and = replaced >> them with minOccurs and maxOccurs (see in context at >> = https://github.com/MediaArea/ebml-specification/blob/ebml-schema-refactor/= specification.markdown#ebml-schema-element-attributes) >>=20 >> minOccurs: >> An integer to express the minimal number of occurrences that the EBML >> Element MUST occur within its Parent Element if its Parent Element is = used. >> If the minOccurs attribute is not expressed for that Element then = that >> Element shall be considered to have a minOccurs value of 0. This = value of >> minOccurs MUST be a positive integer. The semantic meaning of = minOccurs >> within an EBML Schema is considered analogous to the meaning of = minOccurs >> within an [XML Schema](https://www.w3.org/TR/xmlschema-0/#ref6). >>=20 >> maxOccurs >> A value to express the maximum number of occurrences that the EBML = Element >> MUST occur within its Parent Element if its Parent Element is used. = This >> value may be either a positive integer or the term `unbounded` to = indicate >> there is no maximum number of occurrences or the term `identical` to >> indicate that the Element is an Identically-Recurring Element. If the >> maxOccurs attribute is not expressed for that Element then that = Element >> shall be considered to have a maxOccurs value of 1. The semantic = meaning of >> maxOccurs within an EBML Schema is considered analogous to the = meaning of >> minOccurs within an [XML = Schema](https://www.w3.org/TR/xmlschema-0/#ref6), >> with EBML Schema adding the concept of Identically-Recurring = Elements. >>=20 >> I also added a section called "Identically-Recurring Elements" to = define >> them since they are enabled by setting maxOccurs to "enabled". See in >> context at >> = https://github.com/MediaArea/ebml-specification/blob/ebml-schema-refactor/= specification.markdown#identically-recurring-elements. >>=20 >> An Identically-Recurring Element is an Element that may occur within = its >> Parent Element more than once but that each recurrence within that = Parent >> Element MUST be identical both in storage and semantics. >> Identically-Recurring Elements are permitted to be stored multiple = times >> within the same Parent Element in order to increase data resilience = and >> optimize the use of EBML in transmission. Identically-Recurring = Elements >> SHOULD include a CRC-32 Element as a Child Element; this is = especially >> recommended when EBML is used for long-term storage or transmission. = If a >> Parent Element contains more than one copy of an = Identically-Recurring >> Element which includes a CRC-32 Child Element then the first instance = of the >> Identically-Recurring Element with a valid CRC-32 value should be = used for >> interpretation. If a Parent Element contains more than one copy of an >> Identically-Recurring Element which does not contain a CRC-32 Child = Element >> or if CRC-32 Child Elements are present but none are valid then the = first >> instance of the Identically-Recurring Element should be used for >> interpretation. >>=20 >>=20 >> I also drafted a new section called "EBML Schema example" as a = demonstration >> of an EBML Schema. This example EBML Schema is simply the EBML Header = with >> some structure to store files (somewhat based on the Attachments = Element of >> Matroska). The section can be seen in a GitHub branch here: >> = https://github.com/MediaArea/ebml-specification/blob/ebml-schema-refactor/= specification.markdown#ebml-schema-example >> or is pasted here. Compared to the existing implementation of = specdata.xml, >> this uses hierarchical arrangement and the changes mentioned above. >>=20 >> >> >> > maxOccurs=3D"1" minver=3D"1"> >=20 > Does the EBML header need to be defined ? Can it be included from > elsewhere ? That's prone to errors and incompatibilities if we go that > way. If the EBML Header is considered as analogous to the XML Declaration = then perhaps it should not be included in an EBML Schema, since the XML = Declaration isn=E2=80=99t referred to in XML Schemas. In the XML = Specification it says "XML = 1.1 documents MUST begin with an XML declaration which specifies the = version of XML being used.=E2=80=9D but later implies that if an XML = Declaration is not included that the parser can consider the document to = be XML 1.0 (the declaration was not mandatory in XML 1.0). I squashed some updates into the GitHub pull request at=20 This includes making a separate table to define the attribute of = : https://github.com/Matroska-Org/ebml-specification/pull/51 | attribute name | required | definition | |----------------|----------|------------| | docType | Yes | The `docType` lists the official name of = the EBML Document Type that is defined by the EBML Schema; for example, = ``. | | version | Yes | The `version` lists an incremental = non-negative integer that specifies the version of the docType = documented by the EBML Schema. Unlike XML Schemas, an EBML Schema = documents all versions of a docType's definition rather than using = separate EBML Schemas for each version of a docType. Elements may be = introduced and deprecated by using the minver and maxver attributes of = . | I also added definitions for minver and maxver attributes for , = partly based on conversations with Steve about this at FOSDEM: | minver | No | The `minver` (minimum version) attribute = stores a non-negative integer that represents the first version of the = docType to support the element. If the `minver` attribute is not used it = is assumed that the element has a minimum version of "1". | | maxver | No | The `maxver` (maximum version) attribute = stores a non-negative integer that represents the last or most recent = version of the docType to support the element. If the `maxver` attribute = is not used it is assumed that the element has a maximum version equal = to the value stored in the `version` attribute of . | I also updated the EBML Schema example according to this changes to the = specification, so now it looks like: Container of data and attributes = representing one or many files. An attached file. Filename of the attached = file. MIME type of the = file. Modification timestamp of the = file. The data of the file. Please review the changes in context at = https://github.com/Matroska-Org/ebml-specification/pull/51. Best Regards, Dave Rice >> Set the EBML characteristics of the = data to >> follow. Each EBML Document has to start with this. >> > minOccurs=3D"1" default=3D"1" minver=3D"1"> >> The version of EBML parser used to = create the >> EBML Document. >> >> > minOccurs=3D"1" default=3D"1" minver=3D"1"> >> The minimum EBML version a parser has = to >> support to read this EBML Document. >> >> > minOccurs=3D"1" default=3D"4" minver=3D"1"> >> The EBMLMaxIDLength is the maximum = length in >> octets of the Element IDs to be found within the EBML Body. An >> EBMLMaxIDLength value of four is recommended, though larger values = are >> allowed. >> >> > minOccurs=3D"1" default=3D"8" minver=3D"1"> >> The EBMLMaxSizeLength is the maximum = length >> in octets of the expression of all Element Data Sizes to be found = within the >> EBML Body. To be clear EBMLMaxSizeLength documents the maximum = 'length' of >> all Element Data Size expressions within the EBML Body and not the = maximum >> 'value' of all Element Data Size expressions within the EBML Body. = Elements >> that have a Element Data Size expression which is larger in octets = than what >> is expressed by EBMLMaxSizeLength SHALL be considered >> invalid. >> >> > minOccurs=3D"1" default=3D"matroska" minver=3D"1"> >> A string that describes and = identifies the >> content of the EBML Body that follows this EBML = Header. >> >> > minOccurs=3D"1" default=3D"1" minver=3D"1"> >> The version of DocType interpreter = used to >> create the EBML Document. >> >> > minOccurs=3D"1" default=3D"1" minver=3D"1"> >> The minimum DocType version an = interpreter >> has to support to read this EBML Document. >> >> >> > minver=3D"1"> >> Used to void damaged data, to avoid = unexpected >> behaviors when using damaged data. The content is discarded. Also = used to >> reserve space in a sub-element for later use. >> >> > minver=3D"1"> >> The CRC is computed on all the data = from the >> last CRC element (or start of the upper level element), up to the CRC >> element, including other previous CRC elements. All level 1 elements = SHOULD >> include a CRC-32. >> >> >> Container of data and attributes = representing >> one or many files. >> > maxOccurs=3D"unbounded" minver=3D"1"> >> An attached file. >> > minOccurs=3D"1"> >> Filename of the attached >> file. >> >> > minOccurs=3D"1"> >> MIME type of the = file. >> >> > type=3D"date" minOccurs=3D"1"> >> Modification timestamp of the >> file. >> >> > minOccurs=3D"1"> >> The data of the = file. >> >> >> >> >>=20 >>=20 >> If this approach seems agreeable for defining machine-readable = documents of >> EBML DocTypes then can next create versions of them according to = Matroska >> and webm. >>=20 >> Best Regards, >> Dave Rice >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_C236A7B1-4E97-4E42-8A41-BEA5172A5446 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 3, 2016, at 4:38 = AM, Steve Lhomme <slhomme@matroska.org> wrote:

2016-01-23 20:49 GMT+01:00 Dave Rice <dave@dericed.com>:

On Jan 17, 2016, at 8:05 AM, Steve Lhomme = <slhomme@matroska.org> wrote:

2016-01-15 16:35 GMT+01:00 Dave Rice = <dave@dericed.com>:


On = Jan 15, 2016, at 7:44 AM, Steve Lhomme <slhomme@matroska.org> = wrote:

2016-01-15 7:27 GMT+01:00 Dave Rice = <dave@dericed.com>:


On = Dec 1, 2015, at 10:40 AM, Dave Rice <dave@dericed.com> wrote:

On Nov 9, 2015, at 1:19 PM, Dave Rice = <dave@dericed.com> wrote:

On Oct 3, = 2015, at 9:46 AM, Steve Lhomme <slhomme@matroska.org> wrote:

On Aug 28, 2015 17:00, "Dave Rice" = <dave@dericed.com> wrote:

On Aug 28, = 2015, at 2:50 AM, Moritz Bunkus <moritz@bunkus.org> wrote:

Hey,

I have no = objections, however I don't know a lot about XML schemas in
the first place (neither about DTDs, to be honest).



Honestly, I know = a lot more about XML Schemas than I do about DTDs. As
wikipedia mentions at
https://en.wikipedia.org/wiki/Document_type_definition, DTDs = have largely
been superseded by XML Schemas. And at this = point I think that XML Schemas
may be a more familiar = analogy to use.

I think XML Schemas also = share more in common with specdata.xml than DTDs
do. = Schemas use the <element> node and have maxOccurs and minOccurs
attributes (specdata has semantically the same thing with = mandatory and
multiple), they both have a similar = declaration of element type, element
name and element = description. Actually I think a semantically equivalent
version of specdata.xml could be written as an XML Schema.

XML Schemas also offer a few advantages for = machine readable expressions;
for instance XML Schemas can = mandate a particular pattern or regex for a
value.

I propose the specdata.xml file here

https://github.com/Matroska-Org/foundation-source/blob/master/s= pectool/specdata.xml

<https://github.com/Matroska-Org/foundation-source/blob/mast= er/spectool/specdata.xml>
is a good basis for the = consideration of an EBML Schema. =46rom what I
can see, = specdata.xml is an expression of the EBML + Matroska
specifications to support automated creation of = documentation, but the
structure of this already shares a = lot of similarity to XML Schemas.



For both documentation (e.g. the table on the = matroska.org specs page is
generated from this file) and = code (libMatroska's class hierarchy is
generated = automatically from this file) actually.



Does specdata.xml play a role in mkvalidate? = I'm thinking of the potential
to have an ebmlvalidator = where you can provide the EBML Schema to validate
particular= EBML docType.


Well the = parsing code is generated from the XML file, so in a way, yes. But
it's not parsed "live".

Is there = a preference in handling the standardization of Matroska:
documenting it in a similar fashion to our work in the EBML = spec or to
define what an EBML Schema is and consider = matroska an expression of
it?



I'm not sure whether or not I = understand the implications. But my gut
feeling is that = having a definition for an EBML Schema would benefit
other = formats than Matroska, too, therefore the latter seems the way to
go.



I have the same feeling:
- document EBML as a = specification that includes rules for defining a
docType = in the form of an EBML Schema
- write an EBML Schema = (updated specdata.xml) for Matroska and maybe webM

Are some changes to specdata.xml acceptable? Such as a = filename change
or changing the name of the <table> = element of some attributes?



Well, like I said above the specdata.xml is = used for generating both
documentation and code. Both = should stay viable. If changes to it are
made then the = accompanying tools must be updated as well.

Neither the current EBML specs nor the specdata.xml = specifically refer
to the hierarchical arrangement of the = elements, but this could be
presumed by their ordering. = For instance, could any level 3 element be
a child of any = level 2 Master-element? I presume not, but I don't
think = it's clear anywhere what parent-child relationships are
feasible. Possibly specdata.xml and/or the EBML Schema = Definition
could define the relationship between levels of = related elements
similar to how an XML Schema (XSD) = does.



So far = it is understood that an element not marked as a global element
must only occur as a child of its parent. Its parent is the = last element
located before the child element in the = specdata file with a lower level
than the child element. = Or something like that.



This will need some documentation. That's how I've understood = the mkv spec
as well but the definition for how an EBML = Schema works should be explicit
about this.


Any more opinion about how to = go about (or if to go about) modifying
specdata.xml = towards becoming an expression of a to-be-defined EBML Schema
for matroska and webm? As a summary of proposed changes to = specdata.xml

- change to XML Schema = conventions where relevant:
- use maxOccurs attribute = instead of the current Multiple attribute.
- use minOccurs = attribute instead of the current Mandatory attribute.
- = move documentation of elements to a sub-element (allows for possible
internationalization in the schema and better semantics)
- arrange elements in hierarchical form to indicate = parent-child
relationships (rather than the current = practices where all elements are
defined at the same = level, and you have to parse back in elements to the one
with the lower-numbered level attribute to find the = parent)

A draft of specdata.xml with these = changes is at
https://gist.github.com/dericed/f0a4bb0e7dc635ed1347. I can = continue to work
on this and send back changes for = advice/approval but if I do so is there
someone who could = later update the tools that use specdata.xml so that
newly-defined EBML Schemas may later to be into use?


I=E2=80=99m preparing a pull = request on specdata.xml but want to update the
utilities = in spectool at the same time so that spec2data, data2lib, and
data2spec still function properly. I=E2=80=99m having trouble = getting the spectool
utilities to build properly so that I = can test them. I was able to build
coremake but not sure = where to go from here. I=E2=80=99ve read spec2data and have an
idea of how it works and am thinking that I could reproduce = the spec2data
workflow with xsl and then we could have a = make file which uses xsltproc to
convert an EBML Schema = into the Drupal table and library files as needed.
Any = advice on which route to take: continue trying with getting spectool
utilities to build or redo the utilities in xsl?


I=E2=80=99d like to revive this = thread to propose some changes in the definition of
the = EBML Schema. The EBML Schema is intended to be a machine-readible
document that details the semantics and structure of an EBML = Document Type.
The EBML Schema for a Document Type is = essential for understanding the
semantics and validating = an EBML Document. This proposal builds upon an
earlier = conversation started last year on matroska-devel,
http://lists.matroska.org/pipermail/matroska-devel/2015-August/= 004765.html,
http://lists.matroska.org/pipermail/matroska-devel/2015-October= /004807.html.

I=E2=80=99m open to other = solutions or approaches, but since Matroska is based on
EBML= which itself is becoming well-defined. I think there is utility in
documenting how to create a machine-readible document that = describes an EBML
Document Type. I think the concept of = the XML Schema and XML Document is
analogous to EBML = Schema and EBML Document and that adopting from the XML
community for documenting form may be beneficial.

Thus far we have this section
https://github.com/Matroska-Org/ebml-specification/blob/3b30502= d2adb6a22c60294c1e7ea68f703e07e50/specification.markdown#ebml-schema
which introduces the concept for the EBML Schema and then = provides a list of
attributes for defining Elements that = make up a specific EBML Document Type
https://github.com/Matroska-Org/ebml-specification/blob/3b30502= d2adb6a22c60294c1e7ea68f703e07e50/specification.markdown#ebml-schema-eleme= nt-attributes.
This documentation currently reflects the = specdata.xml file of the Matroska
foundation-source repo, = which is here
https://github.com/Matroska-Org/foundation-source/blob/master/s= pectool/specdata.xml.
The specdata.xml file is used to = create the HTML table of elements on
http://matroska.org/technical/specs/index.html and libraries = used by
mkvalidate and other files. After drafting the = EBML Schema and Attribute
documentation I found
http://matroska.org/technical/specs/notes.html#Table_Columns = which covers
similar concepts.

I=E2=80=99d like to propose the following changes to the = definition of EBML Schema:

- Replace = <table> with <EBMLSchema>.

The = node <table> makes sense in the context of the HTML table on
matroska.org but if there will be greater machine-readible = usage I think a
rename would clarify.

- Add an XML NameSpace attribute to <EBMLSchema>.

This would add something like
xmlns=3D=E2=80=9Chttp://official_url_of_EBML_Schema_definition.= org/EBMLSchema.xsd=E2=80=9D.
The EBMLSchema.xsd file would = be an XML Schema that defines the EBMLSchema
document = itself. Yes, this uses an XML Schema to define the EBML Schema, but
this gives a way to validate the EBML Schemas and docType = definitions made
by others.

- = Add a =E2=80=9CdocType=E2=80=9D attribute to <EBMLSchema>

This would clarify what the EBMLSchema is = documenting, thus it would start
with <EBMLSchema = docType=3D=E2=80=9Cmatroska=E2=80=9D>

- = Add =E2=80=9Cversion=E2=80=9D attribute to <EBMLSchema>

This would note the highest version number of = the docType officially
documented by the EBML Schema, so = the EBML Schema would be inferred to
document the noted = docType from version 0 up to the version value listed
here.


Maybe we = need something to say it's the final version or a draft.

With XML Schemas this is done by having an = entirely separate document per
version. We could have = separate files such as:

matroska_v1.xml
matroska_v2.xml
matroska_v3.xml
matroska_v4.xml
matroska_v5RC.xml
webm_v1.xml

Or we could add an = attribute called something like "unofficial" so that we
may = have an EBML Schema with non-standardized elements for testing.

Any preference at which tactic? An advantage = of having versioned EBML
Schemas (one doc per version) is = that the deprecated elements are simply
removed rather = than an eternal lingering presence. It may accept complexity
in use though since you'd have to use the proper schema that = matches both
the docType and docTypeVersion.


That makes omission by mistake = a possibility, involves more proof
reading and it becomes = harder to know which elements changed between
what = versions. It's also harder to process to generate code. Also
should the documentation we currently have be duplicated on = each
document ? I'd rather keep a single document.

- Rename =E2=80=9Cmandatory=E2=80=9D as = =E2=80=9CminOccurs=E2=80=9D and rename =E2=80=9Cmultiple=E2=80=9D as = =E2=80=9CmaxOccurs=E2=80=9D


That may be odd when we add "repeatable" elements that must = be maxOccurs =3D
1.


With maxOccurs it is usually set via numbers, however = 'unbounded' is an
accepted maxOccurs value to say that the = element may repeat for an infinite
amount of times. In = addition to "unbounded" we could also add a value
"identical" which would mean the same as "unbounded" with the = added
constraint that every copy be identical.


That sounds good, yes.

This is to match the meaning of minOccurs and = maxOccurs in XML Schema,
https://www.w3.org/TR/xmlschema-0/#ref6.
mandatory=3D=E2=80=9C0=E2=80=9D would be equivalent to = minOccurs=3D=E2=80=9C0"
mandatory=3D=E2=80=9C1=E2=80=9D = would be equivalent to minOccurs=3D=E2=80=9C1=E2=80=9D
no = mandatory attribute would be equivalent of no minOccurs attribute = which
is equivalent to minOccurs=3D=E2=80=9C1=E2=80=9D (as = is true with minOccurs within an XML
Schema)

multiple=3D=E2=80=9C0=E2=80=9D would be = equivalent to maxOccurs =3D=E2=80=9C1"
multiple =3D=E2=80=9C= 1=E2=80=9D would be equivalent to maxOccurs =3D=E2=80=9Cunbounded=E2=80=9D=
no multiple attribute would be equivalent of no maxOccurs = attribute which is
equivalent to maxOccurs =3D=E2=80=9C1=E2=80= =9D (as is true with maxOccurs within an XML
Schema)

Moving from mandatory/multiple to = minOccurs/maxOccurs can be done with no
semantic = differences, but we=E2=80=99d have to advantage of allowing for = constraints
to the number of usage that are not 0, 1, and = infinite. For instance, I
understand the logic to have 2 = SeekHead Elements, but is there a scenario
for 3 or more = SeekHeads at the same Level within the same EBML Document?


Limiting the amount of = redirection might be a good thing indeed.

Are there other elements currently listed as multiple=3D"1" = where they are
intended for use greater than 1 and less = than unbounded. SeekHead was the
only one coming to = mind.


Not from the top of my = mind.

- Store <element> nodes = hierarchically rather than all at the same level.

Currently with in the specdata.xml file it is difficult to = ascertain the
parent of a given element. It can be done by = seeking to the previous element
where the level of the = element is one value lower, but there are exceptions
for = global elements. I suggest that a structure of
<element>
<element>...</element>
<element>...</element>
</element>
is more clear than all = elements at the same level. I made an example draft
of = specdata.xml with nested implementing here:
https://gist.github.com/dericed/f0a4bb0e7dc635ed1347.

I can provide a patch to the current EBML = Schema and EBML Schema Attributes
as well as incorporate a = sample EBML Schema into the specification, but
wanted to = nudge for comments before proceeding.


The current flat hierarchy is not good anyway. I will need a = bit of
time to update the spec tools accordingly. But the = change is OK for
me.


Thanks. Should I cross-post this to webm lists?


No idea if they use the = document but it's worth a try.


Here are some changes made to the definition of EBML Schema. = I placed them
into a pull request in github,
https://github.com/Matroska-Org/ebml-specification/pull/51/file= s, and will
summarize the changes here.

I removed the attributes for mandatory, multiple, and = identical and replaced
them with minOccurs and maxOccurs = (see in context at
https://github.com/MediaArea/ebml-specification/blob/ebml-schem= a-refactor/specification.markdown#ebml-schema-element-attributes)

minOccurs:
An integer to express = the minimal number of occurrences that the EBML
Element = MUST occur within its Parent Element if its Parent Element is used.
If the minOccurs attribute is not expressed for that Element = then that
Element shall be considered to have a minOccurs = value of 0. This value of
minOccurs MUST be a positive = integer. The semantic meaning of minOccurs
within an EBML = Schema is considered analogous to the meaning of minOccurs
within an [XML = Schema](https://www.w3.org/TR/xmlschema-0/#ref6).

maxOccurs
A value to express the maximum number = of occurrences that the EBML Element
MUST occur within its = Parent Element if its Parent Element is used. This
value = may be either a positive integer or the term `unbounded` to indicate
there is no maximum number of occurrences or the term = `identical` to
indicate that the Element is an = Identically-Recurring Element. If the
maxOccurs attribute = is not expressed for that Element then that Element
shall = be considered to have a maxOccurs value of 1. The semantic meaning of
maxOccurs within an EBML Schema is considered analogous to = the meaning of
minOccurs within an [XML = Schema](https://www.w3.org/TR/xmlschema-0/#ref6),
with = EBML Schema adding the concept of Identically-Recurring Elements.

I also added a section called = "Identically-Recurring Elements" to define
them since they = are enabled by setting maxOccurs to "enabled". See in
context at
https://github.com/MediaArea/ebml-specification/blob/ebml-schem= a-refactor/specification.markdown#identically-recurring-elements.

An Identically-Recurring Element is an Element = that may occur within its
Parent Element more than once = but that each recurrence within that Parent
Element MUST = be identical both in storage and semantics.
Identically-Recurring Elements are permitted to be stored = multiple times
within the same Parent Element in order to = increase data resilience and
optimize the use of EBML in = transmission. Identically-Recurring Elements
SHOULD = include a CRC-32 Element as a Child Element; this is especially
recommended when EBML is used for long-term storage or = transmission. If a
Parent Element contains more than one = copy of an Identically-Recurring
Element which includes a = CRC-32 Child Element then the first instance of the
Identically-Recurring Element with a valid CRC-32 value = should be used for
interpretation. If a Parent Element = contains more than one copy of an
Identically-Recurring = Element which does not contain a CRC-32 Child Element
or = if CRC-32 Child Elements are present but none are valid then the = first
instance of the Identically-Recurring Element should = be used for
interpretation.

I also drafted a new section called "EBML Schema example" as = a demonstration
of an EBML Schema. This example EBML = Schema is simply the EBML Header with
some structure to = store files (somewhat based on the Attachments Element of
Matroska). The section can be seen in a GitHub branch = here:
https://github.com/MediaArea/ebml-specification/blob/ebml-schem= a-refactor/specification.markdown#ebml-schema-example
or = is pasted here. Compared to the existing implementation of = specdata.xml,
this uses hierarchical arrangement and the = changes mentioned above.

<?xml = version=3D"1.0" encoding=3D"utf-8"?>
<EBMLSchema = docType=3D"files-in-ebml-demo">
 <element = name=3D"EBML" level=3D"0" id=3D"0x1A45DFA3" type=3D"master" = minOccurs=3D"1"
maxOccurs=3D"1" minver=3D"1">

Does the EBML header need to be = defined ? Can it be included from
elsewhere ? That's prone = to errors and incompatibilities if we go that
way.

If the EBML Header is considered as analogous to the XML = Declaration then perhaps it should not be included in an EBML Schema, = since the XML Declaration isn=E2=80=99t referred to in XML Schemas. In = the XML Specification it says "XML 1.1 = documents MUST begin with an XML declaration which = specifies the version of XML being used.=E2=80=9D but later implies = that if an XML Declaration is not included that the parser can consider = the document to be XML 1.0 (the declaration was not mandatory in XML = 1.0).

I = squashed some updates into the GitHub pull request at 

This includes making a = separate table to define the attribute of <EBMLSchema>: https://github.com/Matroska-Org/ebml-specification/pull/51<= /div>

| attribute name | required | definition |
|----------------|----------|------------|
| docType        | Yes     =  | The `docType` lists the official name of the EBML Document Type = that is defined by the EBML Schema; for example, `<EBMLSchema = docType=3D"matroska">`. |
| version   =      | Yes      | The `version` lists an = incremental non-negative integer that specifies the version of the = docType documented by the EBML Schema. Unlike XML Schemas, an EBML = Schema documents all versions of a docType's definition rather than = using separate EBML Schemas for each version of a docType. Elements may = be introduced and deprecated by using the minver and maxver attributes = of <element>. |

I also added definitions for minver and maxver attributes = for <element>, partly based on conversations with Steve about this = at FOSDEM:

| minver         | No     =   | The `minver` (minimum version) attribute stores a non-negative = integer that represents the first version of the docType to support the = element. If the `minver` attribute is not used it is assumed that the = element has a minimum version of "1". |
| maxver =         | No       | The `maxver` = (maximum version) attribute stores a non-negative integer that = represents the last or most recent version of the docType to support the = element. If the `maxver` attribute is not used it is assumed that the = element has a maximum version equal to the value stored in the `version` = attribute of <EBMLSchema>. |

I also updated the EBML Schema example = according to this changes to the specification, so now it looks = like:

<?xml version=3D"1.0" encoding=3D"utf-8"?>
<EBMLSchema docType=3D"files-in-ebml-demo" = version=3D"1">
  <element name=3D"Files" = level=3D"0" id=3D"0x1946696C" type=3D"master">
    <documentation lang=3D"en">Container of = data and attributes representing one or many = files.</documentation>
    = <element name=3D"File" level=3D"1" id=3D"0x6146" type=3D"master" = minOccurs=3D"1" maxOccurs=3D"unbounded">
  =     <documentation lang=3D"en">An attached = file.</documentation>
      = <element name=3D"FileName" level=3D"2" id=3D"0x614E" type=3D"utf-8" = minOccurs=3D"1">
        = <documentation lang=3D"en">Filename of the attached = file.</documentation>
      = </element>
      <element = name=3D"MimeType" level=3D"2" id=3D"0x464D" type=3D"string" = minOccurs=3D"1">
        = <documentation lang=3D"en">MIME type of the = file.</documentation>
      = </element>
      <element = name=3D"ModificationTimestamp" level=3D"2" id=3D"0x4654" type=3D"date" = minOccurs=3D"1">
        = <documentation lang=3D"en">Modification timestamp of the = file.</documentation>
      = </element>
      <element = name=3D"Data" level=3D"2" id=3D"0x4664" type=3D"binary" = minOccurs=3D"1">
        = <documentation lang=3D"en">The data of the = file.</documentation>
      = </element>
    = </element>
  </element>
</EBMLSchema>

Please review the changes in context = at https://github.com/Matroska-Org/ebml-specification/pull/51.=

Best = Regards,
Dave Rice

   <documentation lang=3D"en">Set the EBML = characteristics of the data to
follow. Each EBML Document = has to start with this.</documentation>
  =  <element name=3D"EBMLVersion" level=3D"1" id=3D"0x4286" = type=3D"uinteger"
minOccurs=3D"1" default=3D"1" = minver=3D"1">
     <documentation = lang=3D"en">The version of EBML parser used to create the
EBML Document.</documentation>
  =  </element>
   <element = name=3D"EBMLReadVersion" level=3D"1" id=3D"0x42F7" type=3D"uinteger"
minOccurs=3D"1" default=3D"1" minver=3D"1">
     <documentation lang=3D"en">The = minimum EBML version a parser has to
support to read this = EBML Document.</documentation>
  =  </element>
   <element = name=3D"EBMLMaxIDLength" level=3D"1" id=3D"0x42F2" type=3D"uinteger"
minOccurs=3D"1" default=3D"4" minver=3D"1">
     <documentation lang=3D"en">The = EBMLMaxIDLength is the maximum length in
octets of the = Element IDs to be found within the EBML Body. An
EBMLMaxIDLength value of four is recommended, though larger = values are
allowed.</documentation>
   </element>
  =  <element name=3D"EBMLMaxSizeLength" level=3D"1" id=3D"0x42F3" = type=3D"uinteger"
minOccurs=3D"1" default=3D"8" = minver=3D"1">
     <documentation = lang=3D"en">The EBMLMaxSizeLength is the maximum length
in octets of the expression of all Element Data Sizes to be = found within the
EBML Body. To be clear EBMLMaxSizeLength = documents the maximum 'length' of
all Element Data Size = expressions within the EBML Body and not the maximum
'value'= of all Element Data Size expressions within the EBML Body. Elements
that have a Element Data Size expression which is larger in = octets than what
is expressed by EBMLMaxSizeLength SHALL = be considered
invalid.</documentation>
   </element>
  =  <element name=3D"DocType" level=3D"1" id=3D"0x4282" = type=3D"string"
minOccurs=3D"1" default=3D"matroska" = minver=3D"1">
     <documentation = lang=3D"en">A string that describes and identifies the
content of the EBML Body that follows this EBML = Header.</documentation>
  =  </element>
   <element = name=3D"DocTypeVersion" level=3D"1" id=3D"0x4287" type=3D"uinteger"
minOccurs=3D"1" default=3D"1" minver=3D"1">
     <documentation lang=3D"en">The = version of DocType interpreter used to
create the EBML = Document.</documentation>
  =  </element>
   <element = name=3D"DocTypeReadVersion" level=3D"1" id=3D"0x4285" type=3D"uinteger"minOccurs=3D"1" default=3D"1" minver=3D"1">
     <documentation lang=3D"en">The = minimum DocType version an interpreter
has to support to = read this EBML Document.</documentation>
  =  </element>
 </element>
 <element name=3D"Void" global=3D"1" level=3D"0+" = id=3D"0xEC" type=3D"binary"
minver=3D"1">
   <documentation lang=3D"en">Used to void = damaged data, to avoid unexpected
behaviors when using = damaged data. The content is discarded. Also used to
reserve= space in a sub-element for later use.</documentation>
 </element>
 <element = name=3D"CRC-32" global=3D"1" level=3D"1+" id=3D"0xBF" type=3D"binary"
minver=3D"1">
   <documentation = lang=3D"en">The CRC is computed on all the data from the
last CRC element (or start of the upper level element), up to = the CRC
element, including other previous CRC elements. = All level 1 elements SHOULD
include a = CRC-32.</documentation>
 </element>
 <element name=3D"Files" level=3D"0" id=3D"0x1946696C" = type=3D"master" minver=3D"1">
  =  <documentation lang=3D"en">Container of data and attributes = representing
one or many files.</documentation>
   <element name=3D"File" level=3D"1" = id=3D"0x6146" type=3D"master" minOccurs=3D"1"
maxOccurs=3D"unbounded" minver=3D"1">
  =    <documentation lang=3D"en">An attached = file.</documentation>
    =  <element name=3D"FileName" level=3D"2" id=3D"0x614E" = type=3D"utf-8"
minOccurs=3D"1">
  =      <documentation lang=3D"en">Filename of the = attached
file.</documentation>
  =    </element>
    =  <element name=3D"MimeType" level=3D"2" id=3D"0x464D" = type=3D"string"
minOccurs=3D"1">
  =      <documentation lang=3D"en">MIME type of the = file.</documentation>
    =  </element>
     <element = name=3D"ModificationTimestamp" level=3D"2" id=3D"0x4654"
type=3D"date" minOccurs=3D"1">
    =    <documentation lang=3D"en">Modification timestamp of = the
file.</documentation>
  =    </element>
    =  <element name=3D"Data" level=3D"2" id=3D"0x4664" = type=3D"binary"
minOccurs=3D"1">
  =      <documentation lang=3D"en">The data of the = file.</documentation>
    =  </element>
   </element>
 </element>
</EBMLSchema>


If this approach seems = agreeable for defining machine-readable documents of
EBML = DocTypes then can next create versions of them according to Matroska
and webm.

Best Regards,
Dave Rice



-- 
Steve Lhomme
Matroska association Chairman

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

= --Apple-Mail=_C236A7B1-4E97-4E42-8A41-BEA5172A5446-- From nobody Tue Feb 9 00:29:52 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5381A6FBC for ; Tue, 9 Feb 2016 00:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 DhM5-NAQZC5U for ; Tue, 9 Feb 2016 00:29:49 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7CC51A6FAE for ; Tue, 9 Feb 2016 00:29:48 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id g127so121598171ywf.2 for ; Tue, 09 Feb 2016 00:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=jom6hZsQCXjcBNuqtmcWtKtohJBT+1rhR2Jjb/xLflA=; b=kpV3Ow82PUmVMOpUNUq8GgTMwdekTijE2sE0dmdsVYsYXth2L6/DDGXYFGCyDPl6wf pz7tkS82AtrDhzL6jdgumq5J+tL8r+DUknpLux964BBEB9Hb+kPexHxk3zyewe9SbBoM hH6HWfdIktXpMNvAhUD7SK1BGDNJ0gGJxSI2Qb4VH7cgywds8aP6lz+3fFTnf6ZoPX/j Uu3E5wWJd27enggOgyKGhkxiH6ytd33hNbXR16RYDYykJOZ2g2DZrLqBiqJ7eAcMlk5i OGQY7a5lOZtWHH4gIfBZvHEWEf+jaq09KiCmgPmHPxc3QMeHIsXl6uja0wKYn0HrN4Ly xxjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=jom6hZsQCXjcBNuqtmcWtKtohJBT+1rhR2Jjb/xLflA=; b=h71Kbx0GelSsYQDgKBl0rwpxeIF4+d3ukghDPTApWOJQpZpBGwNBlCCSrvtovgamb4 vofO1tSppfPGO09foYl1p2E7LiNSLIZ1/PF4SWOpNg8KWkBvU6xzAq8g81v48ogD774u nfZIp4jpLyB+/ot0mJtZOieowWChhTlNsofHsLSSxJZ+TGW+qleLeovo2LjcA7cIgF+b 74ycawoj+EShNtaSaCq28oyzgSMlaZbpOubhxfx8NZidWLzJWWAcxCrY2D2H+vKqxoN9 nzIT7tbrePplenGtf/GtO4HKjwFE9eeYRxw4ZvwfNB2RBjpdOquDFNg8V0v4gPdY6CY7 gZzA== X-Gm-Message-State: AG10YOQT+JajqunDc7/h6eLPEbSB5c6NUERh40Ue1X+ZEgkiqoTQrH7qPIsGUVHb+uObucYANuR0ZlcsaA5+RQ== MIME-Version: 1.0 X-Received: by 10.129.39.140 with SMTP id n134mr16122764ywn.303.1455006588046; Tue, 09 Feb 2016 00:29:48 -0800 (PST) Received: by 10.129.113.133 with HTTP; Tue, 9 Feb 2016 00:29:48 -0800 (PST) In-Reply-To: References: Date: Tue, 9 Feb 2016 13:59:48 +0530 Message-ID: From: Nithin Mathew Kurien To: cellar@ietf.org, Discussion about the current and future development of Matroska Content-Type: multipart/alternative; boundary=001a1141c114d395fc052b521e0b Archived-At: Subject: Re: [Cellar] Menu System in Matroska Files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 09 Feb 2016 08:29:51 -0000 --001a1141c114d395fc052b521e0b Content-Type: text/plain; charset=UTF-8 Hello, Since DVDMenuXtractor is incompatible with the current versions of MKVToolNix and VLC, and has been out of development for a long time, can we have a new menu specification for Matroska, designed from scratch if necessary? Thanks and regards, Nithin On Mon, Jan 25, 2016 at 9:23 PM, Nithin Mathew Kurien < nithinmkurien@gmail.com> wrote: > Hi, > > I downloaded DvdMenuXtractor (rev1295) from > http://tirnanog.fate.jp/mirror/DvdMenuXtractor/ and tested it on a > DVD. The program completed execution and output .BAT files along with > the demuxed tracks. I use the latest versions of MKVToolNix (v.8.8.0) > and VLC Player (v.2.2.1). When I ran the .BAT files which invoked > MKVToolNix, most of them aborted execution midway with error. A few of > them completed, but when I opened the resulting MKV files in VLC, it > showed the error "VLC can't recognize the input's format: > The format cannot be detected." It seems that DVDMenuXtractor is not > working correctly. Is there any way to fix this? Are there some > example MKV files with menus which I can test in VLC? > > Thanks and regards, > Nithin > > > On Sat, Jan 2, 2016 at 1:49 PM, Steve Lhomme wrote: > > 2015-12-17 11:41 GMT+01:00 Nithin Mathew Kurien >: > >> Dear all, > >> > >> The Matroska specification includes a menu system which is currently > >> in a draft state (http://matroska.org/technical/menu/index.html). > >> Currently there are no open-source players supporting this feature. > > > > Yes, VLC can handle Matroska files with DVD menus extracted using > > DVDMenuXtractor: > > https://github.com/Matroska-Org/dvdmenuxtractor > > > > This was a project meant to demonstrate that Matroska menus are > > possible. It was never finished though as not all DVD commands were > > translated into Matroska menus. It was also done ~10 years ago and > > support in VLC might be broken by now. > > > > The idea was to be able to keep all the information contained in a DVD > > ISO, but in a different format. > > > >> But there is at least one proprietary format, namely PGMX, a variant > >> of MKV, that includes a working menu. These files are created by a > >> proprietary TMPGENC PGMX creator and played by a freeware TMPGENC PGMX > >> player. A PGMX file also supports including multiple related titles > >> inside a single file. Opening this file on open-source players will > >> play it as a normal MKV file without menus. There are some samples > >> given in their website > >> (http://tmpgenc.pegasys-inc.com/en/download/tpxp.html). > >> > >> I think the menu feature would be a good idea to implement in Matroska > >> files and humbly request for the same. I think this feature would be > >> useful for content authors who would like to distribute their works > >> freely under a Creative Commons license, for example, who would > >> otherwise have to adopt proprietary formats like DVD and Blu-ray. I > >> understand that implementing a menu system from scratch might involve > >> some complexity. In that case, would it be possible to adopt some > >> features from the open-source libdvdnav and libbluray? > >> > >> Thanks and regards, > >> Nithin > >> > >> _______________________________________________ > >> Cellar mailing list > >> Cellar@ietf.org > >> https://www.ietf.org/mailman/listinfo/cellar > > > > > > > > -- > > Steve Lhomme > > Matroska association Chairman > --001a1141c114d395fc052b521e0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Since DVDMenuXtractor is incompa= tible with the current versions of MKVToolNix and VLC, and has been out of = development for a long time, can we have a new menu specification for Matro= ska, designed from scratch if necessary?

Thanks an= d regards,
Nithin


On Mon, Jan 25, 2016 at 9:23 PM, Nithi= n Mathew Kurien <nithinmkurien@gmail.com> wrote:
Hi,

I downloaded DvdMenuXtractor (rev1295) from
http://tirnanog.fate.jp/mirror/DvdMenuXtractor/ a= nd tested it on a
DVD. The program completed execution and output .BAT files along with
the demuxed tracks. I use the latest versions of MKVToolNix (v.8.8.0)
and VLC Player (v.2.2.1). When I ran the .BAT files which invoked
MKVToolNix, most of them aborted execution midway with error. A few of
them completed, but when I opened the resulting MKV files in VLC, it
showed the error "VLC can't recognize the input's format:
The format cannot be detected." It seems that DVDMenuXtractor is not working correctly. Is there any way to fix this? Are there some
example MKV files with menus which I can test in VLC?

Thanks and regards,
Nithin


On Sat, Jan 2, 2016 at 1:49 PM, Steve Lhomme <slhomme@matroska.org> wrote:
> 2015-12-17 11:41 GMT+01:00 Nithin Mathew Kurien <nithinmkurien@gmail.com>:
>> Dear all,
>>
>> The Matroska specification includes a menu system which is current= ly
>> in a draft state (http://matroska.org/technica= l/menu/index.html).
>> Currently there are no open-source players supporting this feature= .
>
> Yes, VLC can handle Matroska files with DVD menus extracted using
> DVDMenuXtractor:
> https://github.com/Matroska-Org/dvdmenuxtractor<= /a>
>
> This was a project meant to demonstrate that Matroska menus are
> possible. It was never finished though as not all DVD commands were > translated into Matroska menus. It was also done ~10 years ago and
> support in VLC might be broken by now.
>
> The idea was to be able to keep all the information contained in a DVD=
> ISO, but in a different format.
>
>> But there is at least one proprietary format, namely PGMX, a varia= nt
>> of MKV, that includes a working menu. These files are created by a=
>> proprietary TMPGENC PGMX creator and played by a freeware TMPGENC = PGMX
>> player. A PGMX file also supports including multiple related title= s
>> inside a single file. Opening this file on open-source players wil= l
>> play it as a normal MKV file without menus. There are some samples=
>> given in their website
>> (http://tmpgenc.pegasys-inc.com/en/down= load/tpxp.html).
>>
>> I think the menu feature would be a good idea to implement in Matr= oska
>> files and humbly request for the same. I think this feature would = be
>> useful for content authors who would like to distribute their work= s
>> freely under a Creative Commons license, for example, who would >> otherwise have to adopt proprietary formats like DVD and Blu-ray. = I
>> understand that implementing a menu system from scratch might invo= lve
>> some complexity. In that case, would it be possible to adopt some<= br> >> features from the open-source libdvdnav and libbluray?
>>
>> Thanks and regards,
>> Nithin
>>
>> _______________________________________________
>> Cellar mailing list
>> Cellar@ietf.org
>> https://www.ietf.org/mailman/listinfo/cellar
>
>
>
> --
> Steve Lhomme
> Matroska association Chairman

--001a1141c114d395fc052b521e0b-- From nobody Tue Feb 9 06:39:12 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E971A90A2 for ; Tue, 9 Feb 2016 06:39:09 -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 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 O2UK2fpULSaN for ; Tue, 9 Feb 2016 06:39:05 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3F091A909F for ; Tue, 9 Feb 2016 06:39:05 -0800 (PST) Received: from [146.96.19.240] (port=24012 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aT9RV-0024ws-ON; Tue, 09 Feb 2016 09:39:05 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_7A65559C-F064-4951-85A5-DAD840D80A4C" Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\)) From: Dave Rice In-Reply-To: Date: Tue, 9 Feb 2016 09:39:02 -0500 Message-Id: References: To: Nithin Mathew Kurien , Discussion about the current and future development of Matroska X-Mailer: Apple Mail (2.1990.1) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] [Matroska-devel] Menu System in Matroska Files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 09 Feb 2016 14:39:09 -0000 --Apple-Mail=_7A65559C-F064-4951-85A5-DAD840D80A4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Feb 9, 2016, at 3:29 AM, Nithin Mathew Kurien via Matroska-devel = wrote: >=20 > Hello, >=20 > Since DVDMenuXtractor is incompatible with the current versions of = MKVToolNix and VLC, and has been out of development for a long time, can = we have a new menu specification for Matroska, designed from scratch if = necessary? =46rom scratch is a bit daunting. Would the dvdauthor menu xml format = serve as a good starting point? Dave Rice > Thanks and regards, > Nithin >=20 >=20 > On Mon, Jan 25, 2016 at 9:23 PM, Nithin Mathew Kurien = > wrote: > Hi, >=20 > I downloaded DvdMenuXtractor (rev1295) from > http://tirnanog.fate.jp/mirror/DvdMenuXtractor/ = and tested it on a > DVD. The program completed execution and output .BAT files along with > the demuxed tracks. I use the latest versions of MKVToolNix (v.8.8.0) > and VLC Player (v.2.2.1). When I ran the .BAT files which invoked > MKVToolNix, most of them aborted execution midway with error. A few of > them completed, but when I opened the resulting MKV files in VLC, it > showed the error "VLC can't recognize the input's format: > The format cannot be detected." It seems that DVDMenuXtractor is not > working correctly. Is there any way to fix this? Are there some > example MKV files with menus which I can test in VLC? >=20 > Thanks and regards, > Nithin >=20 >=20 > On Sat, Jan 2, 2016 at 1:49 PM, Steve Lhomme > wrote: > > 2015-12-17 11:41 GMT+01:00 Nithin Mathew Kurien = >: > >> Dear all, > >> > >> The Matroska specification includes a menu system which is = currently > >> in a draft state (http://matroska.org/technical/menu/index.html = ). > >> Currently there are no open-source players supporting this feature. > > > > Yes, VLC can handle Matroska files with DVD menus extracted using > > DVDMenuXtractor: > > https://github.com/Matroska-Org/dvdmenuxtractor = > > > > This was a project meant to demonstrate that Matroska menus are > > possible. It was never finished though as not all DVD commands were > > translated into Matroska menus. It was also done ~10 years ago and > > support in VLC might be broken by now. > > > > The idea was to be able to keep all the information contained in a = DVD > > ISO, but in a different format. > > > >> But there is at least one proprietary format, namely PGMX, a = variant > >> of MKV, that includes a working menu. These files are created by a > >> proprietary TMPGENC PGMX creator and played by a freeware TMPGENC = PGMX > >> player. A PGMX file also supports including multiple related titles > >> inside a single file. Opening this file on open-source players will > >> play it as a normal MKV file without menus. There are some samples > >> given in their website > >> (http://tmpgenc.pegasys-inc.com/en/download/tpxp.html = ). > >> > >> I think the menu feature would be a good idea to implement in = Matroska > >> files and humbly request for the same. I think this feature would = be > >> useful for content authors who would like to distribute their works > >> freely under a Creative Commons license, for example, who would > >> otherwise have to adopt proprietary formats like DVD and Blu-ray. I > >> understand that implementing a menu system from scratch might = involve > >> some complexity. In that case, would it be possible to adopt some > >> features from the open-source libdvdnav and libbluray? > >> > >> Thanks and regards, > >> Nithin > >> > >> _______________________________________________ > >> Cellar mailing list > >> Cellar@ietf.org > >> https://www.ietf.org/mailman/listinfo/cellar = > > > > > > > > -- > > Steve Lhomme > > Matroska association Chairman >=20 > _______________________________________________ > Matroska-devel mailing list > Matroska-devel@lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: = http://dir.gmane.org/gmane.comp.multimedia.matroska.devel --Apple-Mail=_7A65559C-F064-4951-85A5-DAD840D80A4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Feb 9, 2016, at 3:29 AM, Nithin Mathew Kurien via = Matroska-devel <matroska-devel@lists.matroska.org> wrote:

Hello,

Since DVDMenuXtractor is incompatible with the current = versions of MKVToolNix and VLC, and has been out of development for a = long time, can we have a new menu specification for Matroska, designed = from scratch if necessary?

=46rom scratch is a bit daunting. Would the = dvdauthor menu xml format serve as a good starting point?
Dave = Rice

Thanks and = regards,
Nithin


On Mon, Jan 25, 2016 at 9:23 PM, Nithin Mathew = Kurien <nithinmkurien@gmail.com> wrote:
Hi,

I downloaded DvdMenuXtractor (rev1295) from
http://tirnanog.fate.jp/mirror/DvdMenuXtractor/ and = tested it on a
DVD. The program completed execution and output .BAT files along with
the demuxed tracks. I use the latest versions of MKVToolNix (v.8.8.0)
and VLC Player (v.2.2.1). When I ran the .BAT files which invoked
MKVToolNix, most of them aborted execution midway with error. A few = of
them completed, but when I opened the resulting MKV files in VLC, it
showed the error "VLC can't recognize the input's format:
The format cannot be detected." It seems that DVDMenuXtractor is not
working correctly. Is there any way to fix this? Are there some
example MKV files with menus which I can test in VLC?

Thanks and regards,
Nithin


On Sat, Jan 2, 2016 at 1:49 PM, Steve Lhomme <slhomme@matroska.org> wrote:
> 2015-12-17 11:41 GMT+01:00 Nithin Mathew Kurien <nithinmkurien@gmail.com>:
>> Dear all,
>>
>> The Matroska specification includes a menu system which is = currently
>> in a draft state (http://matroska.org/technical/menu/index.html).
>> Currently there are no open-source players supporting this = feature.
>
> Yes, VLC can handle Matroska files with DVD menus extracted = using
> DVDMenuXtractor:
> https://github.com/Matroska-Org/dvdmenuxtractor
>
> This was a project meant to demonstrate that Matroska menus are
> possible. It was never finished though as not all DVD commands = were
> translated into Matroska menus. It was also done ~10 years ago = and
> support in VLC might be broken by now.
>
> The idea was to be able to keep all the information contained in a = DVD
> ISO, but in a different format.
>
>> But there is at least one proprietary format, namely PGMX, a = variant
>> of MKV, that includes a working menu. These files are created = by a
>> proprietary TMPGENC PGMX creator and played by a freeware = TMPGENC PGMX
>> player. A PGMX file also supports including multiple related = titles
>> inside a single file. Opening this file on open-source players = will
>> play it as a normal MKV file without menus. There are some = samples
>> given in their website
>> (http://tmpgenc.pegasys-inc.com/en/download/tpxp.html).
>>
>> I think the menu feature would be a good idea to implement in = Matroska
>> files and humbly request for the same. I think this feature = would be
>> useful for content authors who would like to distribute their = works
>> freely under a Creative Commons license, for example, who = would
>> otherwise have to adopt proprietary formats like DVD and = Blu-ray. I
>> understand that implementing a menu system from scratch might = involve
>> some complexity. In that case, would it be possible to adopt = some
>> features from the open-source libdvdnav and libbluray?
>>
>> Thanks and regards,
>> Nithin
>>
>> _______________________________________________
>> Cellar mailing list
>> Cellar@ietf.org
>> https://www.ietf.org/mailman/listinfo/cellar
= >
>
>
> --
> Steve Lhomme
> Matroska association Chairman

_______________________________________________
Matroska-devel mailing list
Matroska-devel@lists.matroska.org
http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-dev= el
Read Matroska-Devel on GMane: = http://dir.gmane.org/gmane.comp.multimedia.matroska.devel

= --Apple-Mail=_7A65559C-F064-4951-85A5-DAD840D80A4C-- From nobody Thu Feb 11 10:32:37 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94D4B1B38E1 for ; Thu, 11 Feb 2016 10:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 onktNj6GWupp for ; Thu, 11 Feb 2016 10:32:31 -0800 (PST) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C501B38C2 for ; Thu, 11 Feb 2016 10:32:31 -0800 (PST) Received: by mail-ob0-x229.google.com with SMTP id ba1so86153259obb.3 for ; Thu, 11 Feb 2016 10:32:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0xQmCo0vRRfKPfuTTUeo3qQGvRw5ci+1or87CTzVMgM=; b=hsWZm8Wh70b3T3lYW4cVY/+k3K36yrx4BfyImH0Nu7Iy3khZK8FBGehg7Fbn+ywClc 6b3ZhI4NHbGsHITZcSjLqA2Va6UfiX6Z8LwYozRdL8HyCiOLKFLlDxic2VhOak7LfNXz rE4p16Okh17lYxJptuMfE+puOitBRZDXkWpIF6WM40uxQSiTcVhU0j56VLrMIdCRCyq4 X1hhK5vEUIZsjoq9DDb9NngiLXbXYE8jFJiBRqSOJ9bTkSGvu2Yz5Ah3o9bAayLPOYvO 24CCpLnuuFVCfKGMB5SnjYhGSi5pLM20HyWCwk5sAXT6V06xk2K/IxJQDLmguXAwSpgV 8fwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=0xQmCo0vRRfKPfuTTUeo3qQGvRw5ci+1or87CTzVMgM=; b=UgsMJvwzV/Yqho2RrDiNJYggZuG0jx9TqFk4f3hdrByanX3DNXvLDm59XLDlB5KCOr K42NkTDTZ/gnZuIbjv8g5PrjTFDsBvAYoas+ZL5dck2AACxGHNQASutegvDCGrC4YH1U RCPxv5U5ah1LXlwuHgvz3V7hGDMTiyWt3K0M0LuJriEX6t/KobOQL+cSxUYEEidCpws+ SPAaXP6683VOq18UdYTVbaB2vShLYrAQ5EDw2hoCwfZuX4ki9T+c7dC3IbMngxbLkFlX d0ewnEiX0mD8GB7BJzJeGqZoWYlll2GVykwCEK2o0X5BRaQyga9WIPcQqYI0BiBlm7tF x0YQ== X-Gm-Message-State: AG10YORmGjfrSp881Tq5uKBPxz7tc1gOfFgodxN7XlB1mFODhXKH0AysETbdcETFqGEVaB0iXPQjTnAZF6WSXQ== MIME-Version: 1.0 X-Received: by 10.60.79.102 with SMTP id i6mr28939202oex.4.1455215550521; Thu, 11 Feb 2016 10:32:30 -0800 (PST) Received: by 10.202.59.130 with HTTP; Thu, 11 Feb 2016 10:32:30 -0800 (PST) In-Reply-To: References: <568C3CA0.8040300@mediaarea.net> <56B8CD1A.20307@mediaarea.net> Date: Thu, 11 Feb 2016 10:32:30 -0800 Message-ID: From: Frank Galligan To: Jerome Martinez Content-Type: multipart/alternative; boundary=089e0112ce78f5ebe5052b82c5f7 Archived-At: Cc: Discussion about the current and future development of Matroska , cellar@ietf.org Subject: Re: [Cellar] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 11 Feb 2016 18:32:36 -0000 --089e0112ce78f5ebe5052b82c5f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 8, 2016 at 2:23 PM, Frank Galligan wrote: > > > On Mon, Feb 8, 2016 at 9:15 AM, Jerome Martinez > wrote: > >> Sorry for the late answer, here are my comments: >> >> On 22/01/2016 23:54, Frank Galligan wrote: >> >> [...] >> >> - I know some people expressed that they don't think starting from FFmpe= g >> for the TransferFunction is a good idea as they might have got something >> wrong or too subjective. But I just used it as a starting point for a li= st. >> I can reorder the list however we want. I also don't think following >> another list, so we will be compatible with future additions, will give = us >> what we want as that list most likely will be incomplete with something >> that is defined only in a different list. So should we just start with a >> list, re-order it (so we are not explicitly following it), then add what= is >> currently missing? Then in the future if someone needs to add something = to >> the list it can be brought up here? >> >> >> That was me. >> I am OK with that as long as we are clear that we don't follow FFmpeg >> list. >> > OK, I changed the text to see ISO/IEC 23001-8 document, which has the sam= e > values as FFmpeg as well as the 264 ITU doc. > >> >> >> [...] >> >> Element Name: Matrix >> >> Level: 5 >> >> ID: [55][A1] >> >> Mandatory: - >> >> Multiple: - >> >> Default: 2 >> >> Type: u >> >> Description: Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB), 1: >> BT709, >> >> 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE >> 170M, >> >> 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance, >> >> 10: BT2020 Constant Luminance) >> >> >> >> If we don't follow FFmpeg list, what is the purpose of value 3 and why >> unspecified is 2 rather than 0? >> > That is the way it is specified in ISO/IEC 23001-8 and 264 ITU doc. > > Using FFmpeg list (which is based on MPEG list, with same oddities) is no= t >> bad, and I am not against it, just wondering if it is good to take the s= ame >> oddities rather than a clean list without oddities. >> > I don't think there are any oddities. Looks like FFmpeg's list matches > exactly to ISO/IEC 23001-8 and 264 ITU doc, except for #10 in Primaries > and #16 and #17 in Transfer function, which were added here [1]. Also #18 > in Transfer, which is HLG [2]. > > I think this is the whole issue. Do we follow some list (standardized or > not)? What if the list goes stale? What if the list doesn't include > algorithms from different lists (E.g. maybe HLG)? > > > >> Does anyone plan to transfer from DPX? If yes, we may need to add now >> missing elements in the list (e.g. "Printing density") but I am not expe= rt >> enough for know which one is worth it. >> >> >> >> >> [...] >> >> >> Element Name: ChromaSubsampling >> >> Level: 5 >> >> ID: [55][A3] >> >> Mandatory: - >> >> Multiple: - >> >> Default: 0 >> >> Type: u >> >> Description: (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1, 5= : >> 4:2:0, >> >> 6: 4:1:1, 7: 4:1:0, 8: 3:1:1) >> >> >> I am more, as some other people, for something more generic, e.g. >> ChromaSubsamplingHorz and ChromaSubsamplingVert, with a value of the >> subsampling (0 unspecified and default). I am afraid that someone crazy >> used e.g. a vertical subsampling of 4 (which can not be defined by X:X:X >> values), it is possible (and I have a file like that if I remember well) >> with FFV1. >> >> >> >> >> [...] >> >> Element Name: TransferFunction >> >> Level: 5 >> >> ID: [55][A7] >> >> Mandatory: - >> >> Multiple: - >> >> Default: 2 >> >> Type: u >> >> Description: Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: >> Unspecified, >> >> 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, >> >> 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, >> >> 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut, >> >> 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, >> >> 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, >> >> 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) >> >> >> Element Name: Primaries >> >> Level: 5 >> >> Mandatory: - >> >> Multiple: - >> >> ID: [55][A8] >> >> Default: 2 >> >> Description: (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R >> BT.470M, >> >> 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM, >> >> 9: ITU-R BT.2020, 10: SMPTE ST 428-1) >> >> >> Same remark as with Matrix. >> >> >> [...] >> >> >> > [1] > https://github.com/FFmpeg/FFmpeg/commit/c3cd6dd106b1381933e2f24898eeec0d8= aa17746 > [2] http://www.arib.or.jp/english/html/overview/std-b67.html > > > So this is what I have currently: The parent element would be Video [E0]. Element Name: Colour Level: 4 ID: [55][B0] Mandatory: - Multiple: - Default: - Type: m Description: Settings describing the colour format. Element Name: Matrix Level: 5 ID: [55][B1] Mandatory: - Multiple: - Default: 2 Type: u Description: ColourMatrix of the video. See ISO/IEC 23001-8 for more information on enumerations. (0: IEC 61966-2-1 (sRGB), 1: BT709, 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M= , 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance, 10: BT2020 Constant Luminance) Element Name: BitsPerChannel Level: 5 ID: [55][B2] Mandatory: - Multiple: - Default: 0 Type: u Description: Number of decoded bits per channel. This number may be less for specific channels depending on the Matrix and ChromaSubsampling. A value of 0 is unspecified. Element Name: ChromaSubsamplingHorz Level: 5 ID: [55][B3] Mandatory: - Multiple: - Default: - Type: u Description: The amount of chrominance pixels to remove for every chrominance pixel not removed horizontally. Element Name: ChromaSubsamplingVert Level: 5 ID: [55][B4] Mandatory: - Multiple: - Default: - Type: u Description: The amount of chrominance pixels to remove for every chrominance pixel not removed vertically. Element Name: CbSubsamplingHorz Level: 5 ID: [55][B5] Mandatory: - Multiple: - Default: - Type: u Description: The amount of Cb chrominance pixels to remove for every Cb chrominance pixel not removed horizontally. This is additive with ChromaSubsamplingHorz. Element Name: CbSubsamplingVert Level: 5 ID: [55][B6] Mandatory: - Multiple: - Default: - Type: u Description: The amount of Cb chrominance pixels to remove for every Cb chrominance pixel not removed vertically. This is additive wit= h ChromaSubsamplingVert. Element Name: ChromaSitingHorz Level: 5 ID: [55][B7] Mandatory: - Multiple: - Default: 0 Type: u Description: How Chroma is subsampled horizontally. (0: Unspecified, 1: Left collocated , 2: Half) Element Name: ChromaSitingVert Level: 5 ID: [55][B8] Mandatory: - Multiple: - Default: 0 Type: u Description: How Chroma is subsampled vertically. (0: Unspecified, 1: Top collocated , 2: Half) Element Name: Range Level: 5 ID: [55][B9] Mandatory: - Multiple: - Default: 0 Type: u Description: Clipping of the color ranges. (0: Unspecified, 1: Broadcast range, 2: Full range (no clipping), 3: Defined by Matrix/TransferFunction) Element Name: TransferFunction Level: 5 ID: [55][BA] Mandatory: - Multiple: - Default: 2 Type: u Description: Transfer Function. See ISO/IEC 23001-8 for more information o= n enumerations. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) Element Name: Primaries Level: 5 Mandatory: - Multiple: - ID: [55][BB] Default: 2 Type: u Description: Values that can be represented in the CIE 1931 colour space. See ISO/IEC 23001-8 for more information on enumerations. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1) Element Name: MaxCLL Level: 5 ID: [55][BC] Mandatory: - Multiple: - Default: - Type: u Description: Maximum brightness of a single pixel in candelas per square meter (cd/m=C2=B2). Element Name: MaxFALL Level: 5 ID: [55][BD] Mandatory: - Multiple: - Default: - Type: u Description: Maximum brightness of a single full frame in candelas per square meter (cd/m=C2=B2). Element Name: MasteringMetadata Level: 5 ID: [55][D0] Mandatory: - Multiple: - Default: - Type: m Description: SMPTE 2086 mastering data. Element Name: PrimaryRChromaticityX Level: 6 ID: [55][D1] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - Type: f Description: Red X chromaticity coordinate as defined by CIE 1931. Element Name: PrimaryRChromaticityY Level: 6 ID: [55][D2] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - Type: f Description: Red Y chromaticity coordinate as defined by CIE 1931. Element Name: PrimaryGChromaticityX Level: 6 ID: [55][D3] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - f Description: Green X chromaticity coordinate as defined by CIE 1931. Element Name: PrimaryGChromaticityY Level: 6 ID: [55][D4] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - Type: f Description: Green Y chromaticity coordinate as defined by CIE 1931. Element Name: PrimaryBChromaticityX Level: 6 ID: [55][D5] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - f Description: Blue X chromaticity coordinate as defined by CIE 1931. Element Name: PrimaryBChromaticityY Level: 6 ID: [55][D6] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - Type: f Description: Blue Y chromaticity coordinate as defined by CIE 1931. Element Name: WhitePointChromaticityX Level: 6 ID: [55][D7] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - Type: f Description: White point X chromaticity coordinate as defined by CIE 1931. Element Name: WhitePointChromaticityY Level: 6 ID: [55][D8] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 1 Default: - Type: f Description: White point Y chromaticity coordinate as defined by CIE 1931. Element Name: LuminanceMax Level: 6 ID: [55][D9] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 9999.99 Default: - Type: f Description: Maximum luminance. Shall be represented in candelas per squar= e meter (cd/m=C2=B2). Element Name: LuminanceMin Level: 6 ID: [55][DA] Mandatory: - Multiple: - Range: 0 <=3D f <=3D 999.9999 Default: - Type: f Description: Minimum luminance. Shall be represented in candelas per squar= e meter (cd/m=C2=B2). I removed ChromaSubsampling and added ChromaSubsamplingHorz, ChromaSubsamplingVert, CbSubsamplingHorz, and CbSubsamplingVert. This is how I think the elements should be written for the different subsampling types: 1: 4:4:4 - ChromaSubsamplingHorz and ChromaSubsamplingVert will not be set as there should be no chroma subsampling. 2: 4:4:0 - ChromaSubsamplingHorz :not set - ChromaSubsamplingVert :1 3: 4:2:2 - ChromaSubsamplingHorz :1 - ChromaSubsamplingVert :not set 4: 4:2:1 - ChromaSubsamplingHorz :1 - ChromaSubsamplingVert :not set - CbSubsamplingHorz :1 - CbSubsamplingVert :not set - We could remove CbSubsamplingHorz and CbSubsamplingVert if we didn't care about handling formats where the Cr and Cb channels are different sizes. 5: 4:2:0 - ChromaSubsamplingHorz :1 - ChromaSubsamplingVert :1 6: 4:1:1 - ChromaSubsamplingHorz :3 - ChromaSubsamplingVert :not set 7: 4:1:0 - ChromaSubsamplingHorz :3 - ChromaSubsamplingVert :1 8: 3:1:1 - ChromaSubsamplingHorz :2 - ChromaSubsamplingVert :not set - I'm assuming the luma subsampling can be handled by PixelWidth, and DisaplyWidth. Jerome's vertical subsampling of 4 - ChromaSubsamplingHorz :not set - ChromaSubsamplingVert :3 The other issue I want to bring up is the value of "18: ARIB STD-B67 (HLG)" in TransferFunction. Unfortunately, in WebM we will need to use this value sooner than Matroska v4 will be finalized. Should I make this value much higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17: SMPTE ST 428-1= " will be standardized across most documents, like 1-15 are. Just not sure if 18 will be HLG. Thanks, Frank --089e0112ce78f5ebe5052b82c5f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Feb 8, 2016 at 2:23 PM, Frank Galligan <frankgalligan@gmail.= com> wrote:


On Mon, = Feb 8, 2016 at 9:15 AM, Jerome Martinez <jerome@mediaarea.net> wrote:
=20 =20 =20
Sorry for the late answer, here are my comments:

On 22/01/2016 23:54, Frank Galligan wrote:
[...]

- I know some people expressed that they don't think starting from FFmpeg for the TransferFunction is a good idea as they might have got something wrong or too subjective. But I just used it as a starting point for a list. I can reorder the list however we want. I also don'= t think following another list, so we will be compatible with future additions, will give us what we want as that list most likely will be incomplete with something that is defined only in a different list. So should we just start with a list, re-order it (so we are not explicitly following it), then add what is currently missing? Then in the future if someone needs to add something to the list it can be brought up here?

That was me.
I am OK with that as long as we are clear that we don't follow FFmpeg list.
OK, I changed the text t= o see ISO/IEC 23001-8 document, which has the same values as FFmpeg as well= as the 264 ITU doc.


[...]

Element Name: Matrix<= /span>

Level: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][A1]

Mandatory: =C2=A0=C2= =A0=C2=A0-

Multiple: =C2=A0=C2= =A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A02

Type: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0Co= lour Matrix of the video. (0: IEC 61966-2-1 (sRGB), 1: BT709,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A02: Unspecified,= 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A07: SMPTE 240M, = 8: YCOCG, 9: BT2020 Non-constant Luminance,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A010: BT2020 Cons= tant Luminance)



If we don't follow FFmpeg list, what is the purpose of=C2=A0 value = 3 and why unspecified is 2 rather than 0?
T= hat is the way it is specified in ISO/IEC 23001-8=C2=A0and 264 ITU doc.=C2= =A0

Using FFmpeg list (which is based on MPEG list, with same oddities) is not bad, and I am not against it, just wondering if it is good to take the same oddities rather than a clean list without oddities.
I don't think there are any oddities. Look= s like FFmpeg's list matches exactly to =C2=A0ISO/IEC 23001-8=C2=A0and = 264 ITU doc, except for #10 in Primaries and #16 and #17 in Transfer functi= on, which were added here [1]. Also #18 in Transfer, which is HLG [2].

I think this is the whole issue. Do we follow some lis= t (standardized or not)? What if the list goes stale? What if the list does= n't include algorithms from different lists (E.g. maybe HLG)?



Does anyone plan to transfer from DPX? If yes, we may need to add now missing elements in the list (e.g. "Printing density") bu= t I am not expert enough for know which one is worth it.




[...]



Element Name: Chrom= aSubsampling

Level: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][A3]

Mandatory: =C2=A0= =C2=A0=C2=A0-

Multiple: =C2=A0=C2= =A0=C2=A0=C2=A0-

Default: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A00

Type: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0= (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1, 5: 4:2:0, =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06: 4:1:1, 7: 4:= 1:0, 8: 3:1:1)


I am more, as some other people, for something more generic, e.g. ChromaSubsamplingHorz and ChromaSubsamplingVert, with a value of the subsampling (0 unspecified and default). I am afraid that someone crazy used e.g. a vertical subsampling of 4 (which can not be defined by X:X:X values), it is possible (and I have a file like that if I remember well) with FFV1.




[...]<= /span>

Element Name: Trans= ferFunction

Level: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][A7]

Mandatory: =C2=A0= =C2=A0=C2=A0-

Multiple: =C2=A0=C2= =A0=C2=A0=C2=A0-

Default: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A02

Type: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0= Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A04: Gamma 2.2 cu= rve, 5: Gamma 2.8 curve, 6: SMPTE 170M,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A07: SMPTE 240M, = 8: Linear, 9: Log, 10: Log Sqrt,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A011: IEC 61966-2= -4, 12: ITU-R BT.1361 Extended Colour Gamut,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A013: IEC 61966-2= -1, 14: ITU-R BT.2020 10 bit,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A015: ITU-R BT.20= 20 12 bit, 16: SMPTE ST 2084,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A017: SMPTE ST 42= 8-1 18: ARIB STD-B67 (HLG))



Element Name: Prima= ries

Level: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

Mandatory: =C2=A0= =C2=A0=C2=A0-

Multiple: =C2=A0=C2= =A0=C2=A0=C2=A0-

ID: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][A8]

Default: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A02

Description: =C2=A0= (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R BT.470M,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05: ITU-R = BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A09: ITU-R = BT.2020, 10: SMPTE ST 428-1)


Same remark as with Matrix.


[...]



[1]=C2= =A0https://github.com/FFmpeg/FFmpeg/com= mit/c3cd6dd106b1381933e2f24898eeec0d8aa17746
[2]=C2=A0http://www.arib.or.jp/english/html/overview/std-= b67.html



So this is what I h= ave currently:

The parent element would be Video [E0= ].


Element Name: Colour

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A04

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0[55][B0]

Mandatory: =C2=A0=C2=A0=C2= =A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

=

= Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0m<= /span>

Description: =C2=A0Settings describing the col= our format.



Element Name: = Matrix

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B1]

Mand= atory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2= =A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A02

Type: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0C= olourMatrix of the video. See ISO/IEC 23001-8 for more

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0information on enumerations. (0: IEC 61966-2-1 (sRGB), 1: BT= 709,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A02: Unspecified, 3: Reserved, 4: FCC,= 5: BT470BG, 6: SMPTE 170M,

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A07: SMPTE 240= M, 8: YCOCG, 9: BT2020 Non-constant Luminance,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A010: BT2020 Constant Luminance)



Element Name: BitsPerChannel

Leve= l: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B2]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A00

T= ype: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0Number of decoded bits per channel. This number= may be less for

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0specific channels depend= ing on the Matrix and ChromaSubsampling. A

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0value of 0 is unspecified.



Element Name: ChromaSubsamplingHorz

Level:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

I= D: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B3]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

T= ype: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0The amount of chrominance pixels to remove for = every chrominance

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0pixel not removed horizo= ntally.



Element Name: Chro= maSubsamplingVert

Level: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B4]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: = =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description= : =C2=A0The amount of chrominance pixels to remove for every chrominance

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0pixel not removed vertically.


<= /b>

Element Name: CbSubsamplingHorz

=

= Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0[55][B5]

Mandatory: =C2=A0=C2= =A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-=

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0u

Description: =C2=A0The amount of Cb ch= rominance pixels to remove for every Cb

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= chrominance pixel not removed horizontally. This is additive with

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0ChromaSubsamplingHorz.



Element Name: CbSubsamplingVert

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0[55][B6]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u=

Description: =C2=A0The amount of Cb chrominance pixe= ls to remove for every Cb

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0chrominance pix= el not removed vertically. This is additive with

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0ChromaSubsamplingVert.



Element Name: ChromaSitingHorz

Level: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

I= D: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B7]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A00

T= ype: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0How Chroma is subsampled horizontally. (0: Unsp= ecified, 1: Left

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0collocated , 2: Half)


Element Name: ChromaSitingVert

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A05

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0[55][B8]

Mandatory: = =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2= =A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A00

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0u

Description: =C2=A0How Chr= oma is subsampled vertically. (0: Unspecified, 1: Top

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0collocated , 2: Half)



Element Name: Range

Level: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B9]

Mandatory: =C2=A0=C2=A0=C2=A0-

Default:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A00

Type: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

D= escription: =C2=A0Clipping of the color ranges. <= /span>(0: Unspecified, 1: Broadcast range,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A02: Full range (no clipping), 3: Defined by

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:13.3333px;font-family:'Courier New';color:r= gb(34,34,34);font-weight:400;font-style:normal;font-variant:normal;text-dec= oration:none;vertical-align:baseline;white-space:pre-wrap;background-color:= rgb(255,255,255)"> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0Matrix/TransferFunction)



=

Element Name: TransferFunction

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0[55][BA]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A02

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u=

Description: =C2=A0Transfer Function. See ISO/IEC 23= 001-8 for more information on

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0enumerations= . (0: Reserved, 1: ITU-R BT.709, 2: Unspecified,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A03: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A06: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: L= og Sqrt,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A011: IEC 61966-2-4, 12: ITU-R BT.1= 361 Extended Colour Gamut,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A013: IEC 61966-2= -1, 14: ITU-R BT.2020 10 bit,

=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A015: ITU-R BT= .2020 12 bit, 16: SMPTE ST 2084,

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A017: SMPTE= ST 428-1 18: ARIB STD-B67 (HLG))



Element Name: Primaries

Level: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

Mandator= y: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0= =C2=A0=C2=A0-

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][BB]

Defa= ult: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A02

Type: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0Values that can be represented in the CIE 1931 colour s= pace. See

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ISO/IEC 23001-8 for more infor= mation on enumerations.

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(0: Reserved, 1: I= TU-R BT.709, 2: Unspecified, 3: Reserved,

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A08: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1)



Element Name: MaxCLL=

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0[55][BC]

Mandatory: =C2=A0= =C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2= =A0-

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-<= /span>

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0u

Description: =C2=A0Maximum brightne= ss of a single pixel in candelas per square

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0meter (cd/m=C2=B2).



E= lement Name: MaxFALL

Level: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][BD]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multipl= e: =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Descript= ion: =C2=A0Maximum brightness of a single full frame in candelas per square=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0meter (cd/m=C2=B2).



=

Element Name: MasteringMetadata

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0[55][D0]

Mandatory: =C2=A0=C2=A0= =C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-<= /p>

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0m

Description: =C2=A0SMPTE 2086 mastering d= ata.



Element Name: Primary= RChromaticityX

Level: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D1]

Multiple: =C2= =A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 1

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

Description: =C2=A0Red X chroma= ticity coordinate as defined by CIE 1931.



Element Name: PrimaryRChromaticityY

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0[55][D2]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 1

Default: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

Descript= ion: =C2=A0Red Y chromaticity coordinate as defined by CI= E 1931.



Element Name: Prim= aryGChromaticityX

Level: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D3]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: = =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 1

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

=

= f

Description: =C2=A0Green X chromaticity coordinate as defined by CIE 1931.<= /p>

=

Element Name: PrimaryGChromaticit= yY

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D4]

Mandatory:= =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2= =A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A00 <=3D f <=3D 1

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

Description: =C2=A0Green Y chromaticity coo= rdinate as defined by CIE 1931.



<= /b>

Element Name: PrimaryBChromaticityX=

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0[55][D5]

Mandatory: =C2=A0= =C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2= =A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A00 <=3D f <=3D 1

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

f=

Description: =C2=A0Blue X c= hromaticity coordinate as defined by CIE 1931.



Element Name: PrimaryBChromaticityY

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:13.3333px;font-family:'Courier New';color:r= gb(34,34,34);font-weight:400;font-style:normal;font-variant:normal;text-dec= oration:none;vertical-align:baseline;white-space:pre-wrap;background-color:= rgb(255,255,255)">ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0[55][D6]

Mandatory: =C2=A0=C2=A0=C2= =A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 1

Default:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

D= escription: =C2=A0Blue Y chromaticity coordinate as defin= ed by CIE 1931.



Element N= ame: WhitePointChromaticityX

Level: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D7]

Mandatory: =C2=A0=C2=A0=C2=A0-

Range: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <= ;=3D 1

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= -

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0f

Description: =C2=A0White point X chromaticity coordinate as defined by CIE 1931.

<= br>

Element Name: WhitePointChromatici= tyY

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D8]

Mandato= ry: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0= =C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A00 <=3D f <=3D 1

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:13.3333px;font-family:'Courier New';color:r= gb(34,34,34);font-weight:400;font-style:normal;font-variant:normal;text-dec= oration:none;vertical-align:baseline;white-space:pre-wrap;background-color:= rgb(255,255,255)">Description: =C2=A0White point Y chroma= ticity coordinate as defined by CIE 1931.



Element Name: LuminanceMax

L= evel: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D9= ]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 0 <=3D f <=3D 9999.99

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

Description: =C2=A0Maximum luminance. Shall be represented in = candelas per square

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0meter (cd/m=C2=B2).



Element Name: LuminanceMin<= /span>

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0[55][DA]

Mandatory: = =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2= =A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A00 <=3D f <=3D 999.9999

Default: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0f

Description: =C2=A0Minimum= luminance. Shall be represented in candelas per square

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0meter (cd/m=C2=B2).



I removed ChromaSubsampling = and added ChromaSubsamplingHorz, ChromaSubsamplingVert, CbSubsamplingHorz, = and CbSubsamplingVert.

This is how I think the ele= ments should be written for the different subsampling types:
1: 4:4:4
=C2=A0 =C2=A0 - ChromaSubsamplingHorz and ChromaSubsamp= lingVert will not be set as there should be no chroma subsampling.

2: 4:4:0
=C2=A0 - ChromaSubsamplingHorz :no= t set
=C2=A0 - ChromaSubsamplingVert :1

3: 4:2:2
=C2=A0 - ChromaSubsamplingHorz :1
= =C2=A0 - ChromaSubsamplingVert :not set

4: 4= :2:1
=C2=A0 - ChromaSubsamplingHorz :1
=C2=A0 - Ch= romaSubsamplingVert :not set
=C2=A0 - CbSubsamplingHor= z :1
=C2=A0 - CbSubsamplingVert :not set
=C2=A0 -= We could remove CbSubsamplingHorz and CbSubsamplingVert if we didn't c= are about handling formats where the Cr and Cb channels are different sizes= .

5: 4:2:0
=C2=A0 - ChromaSubsamplingHor= z :1
=C2=A0 - ChromaSubsamplingVert :1

6= : 4:1:1
=C2=A0 - ChromaSubsamplingHorz :3
=C2=A0 -= ChromaSubsamplingVert :not set

7: 4:1:0
=C2=A0 - ChromaSubsamplingHorz :3
=C2=A0 - ChromaSubs= amplingVert :1

8: 3:1:1
=C2=A0 - ChromaSubsamplingHorz :2
=C2=A0 - ChromaSubsamplingVert= :not set
=C2=A0 - I'm assuming the luma subsampling ca= n be handled by PixelWidth, and DisaplyWidth.

Jero= me's vertical subsampling of 4
=C2=A0 - ChromaSubsamplin= gHorz :not set
=C2=A0 - ChromaSubsamplingVert :3
=


The other issue I want to brin= g up is the value of "18: ARIB STD-= B67 (HLG)" in TransferFunction. Unfortunately, in WebM we will = need to use this value sooner than Matroska v4 will be finalized. Should I = make this value much higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17: SMPTE ST 428-1" will be standardized ac= ross most documents, like 1-15 are. Just not sure if 18 will be HLG.
<= div>
Thanks,
Frank


--089e0112ce78f5ebe5052b82c5f7-- From nobody Fri Feb 12 17:53:39 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF8781B29BB for ; Fri, 12 Feb 2016 17:53:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 ezKdhEsUE9Xe for ; Fri, 12 Feb 2016 17:53:29 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60FEA1B29B8 for ; Fri, 12 Feb 2016 17:53:29 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:35028 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aUPOg-001LzC-D3; Fri, 12 Feb 2016 20:53:28 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_0C4FB45F-6C7D-4AE5-91CA-D2B0A13332F0" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Fri, 12 Feb 2016 20:53:15 -0500 Message-Id: <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> References: <568C3CA0.8040300@mediaarea.net> <56B8CD1A.20307@mediaarea.net> To: Frank Galligan , Discussion about the current and future development of Matroska X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Jerome Martinez , cellar@ietf.org Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2016 01:53:36 -0000 --Apple-Mail=_0C4FB45F-6C7D-4AE5-91CA-D2B0A13332F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > On Feb 11, 2016, at 1:32 PM, Frank Galligan via Matroska-devel = wrote: >=20 >=20 > On Mon, Feb 8, 2016 at 2:23 PM, Frank Galligan = > wrote: >=20 >=20 > On Mon, Feb 8, 2016 at 9:15 AM, Jerome Martinez > wrote: > Sorry for the late answer, here are my comments: >=20 > On 22/01/2016 23:54, Frank Galligan wrote: >> [...] >>=20 >> - I know some people expressed that they don't think starting from = FFmpeg for the TransferFunction is a good idea as they might have got = something wrong or too subjective. But I just used it as a starting = point for a list. I can reorder the list however we want. I also don't = think following another list, so we will be compatible with future = additions, will give us what we want as that list most likely will be = incomplete with something that is defined only in a different list. So = should we just start with a list, re-order it (so we are not explicitly = following it), then add what is currently missing? Then in the future if = someone needs to add something to the list it can be brought up here? >=20 > That was me. > I am OK with that as long as we are clear that we don't follow FFmpeg = list. > OK, I changed the text to see ISO/IEC 23001-8 document, which has the = same values as FFmpeg as well as the 264 ITU doc. >=20 >>=20 >> [...] >>=20 >> Element Name: Matrix >> Level: 5 >> ID: [55][A1] >> Mandatory: - >> Multiple: - >> Default: 2 >> Type: u >> Description: Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB), = 1: BT709, >> 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: = SMPTE 170M, >> 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant = Luminance, >> 10: BT2020 Constant Luminance)=20 >=20 >=20 > If we don't follow FFmpeg list, what is the purpose of value 3 and = why unspecified is 2 rather than 0? > That is the way it is specified in ISO/IEC 23001-8 and 264 ITU doc.=20 >=20 > Using FFmpeg list (which is based on MPEG list, with same oddities) is = not bad, and I am not against it, just wondering if it is good to take = the same oddities rather than a clean list without oddities. > I don't think there are any oddities. Looks like FFmpeg's list matches = exactly to ISO/IEC 23001-8 and 264 ITU doc, except for #10 in Primaries = and #16 and #17 in Transfer function, which were added here [1]. Also = #18 in Transfer, which is HLG [2]. >=20 > I think this is the whole issue. Do we follow some list (standardized = or not)? What if the list goes stale? What if the list doesn't include = algorithms from different lists (E.g. maybe HLG)? >=20 >=20 >=20 > Does anyone plan to transfer from DPX? If yes, we may need to add now = missing elements in the list (e.g. "Printing density") but I am not = expert enough for know which one is worth it. >=20 >=20 >>=20 >>=20 >> [...] >>=20 >>=20 >> Element Name: ChromaSubsampling >> Level: 5 >> ID: [55][A3] >> Mandatory: - >> Multiple: - >> Default: 0 >> Type: u >> Description: (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: = 4:2:1, 5: 4:2:0, =20 >> 6: 4:1:1, 7: 4:1:0, 8: 3:1:1) >=20 > I am more, as some other people, for something more generic, e.g. = ChromaSubsamplingHorz and ChromaSubsamplingVert, with a value of the = subsampling (0 unspecified and default). I am afraid that someone crazy = used e.g. a vertical subsampling of 4 (which can not be defined by X:X:X = values), it is possible (and I have a file like that if I remember well) = with FFV1. >=20 >=20 >=20 >>=20 >> [...] >>=20 >> Element Name: TransferFunction >> Level: 5 >> ID: [55][A7] >> Mandatory: - >> Multiple: - >> Default: 2 >> Type: u >> Description: Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified, >> 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, >> 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, >> 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut, >> 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, >> 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, >> 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) >>=20 >>=20 >> Element Name: Primaries >> Level: 5 >> Mandatory: - >> Multiple: - >> ID: [55][A8] >> Default: 2 >> Description: (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R = BT.470M, >> 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: = FILM, >> 9: ITU-R BT.2020, 10: SMPTE ST 428-1) >=20 > Same remark as with Matrix. >=20 >>=20 >> [...] >>=20 >=20 >=20 > [1] = https://github.com/FFmpeg/FFmpeg/commit/c3cd6dd106b1381933e2f24898eeec0d8a= a17746 = > [2] http://www.arib.or.jp/english/html/overview/std-b67.html = >=20 >=20 >=20 > So this is what I have currently: > The parent element would be Video [E0]. >=20 >=20 > Element Name: Colour > Level: 4 > ID: [55][B0] > Mandatory: - > Multiple: - > Default: - > Type: m > Description: Settings describing the colour format. >=20 >=20 > Element Name: Matrix To align better with ISO/IEC 23001-8, could this be labelled as = MatrixCoefficients? > Level: 5 > ID: [55][B1] > Mandatory: - > Multiple: - > Default: 2 > Type: u > Description: ColourMatrix of the video. See ISO/IEC 23001-8 for more > information on enumerations. (0: IEC 61966-2-1 (sRGB), = 1: BT709, > 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: = SMPTE 170M, > 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant = Luminance, > 10: BT2020 Constant Luminance) Suggested description edit: The Matrix Coefficients of the video used to derive luma and chroma = values from reg, green, and blue color primaries. For clarity, the value = and meanings for MatrixCoefficients are adopted from Table 4 of ISO/IEC = 23001-8:2013/DCOR1. (0: IEC 61966-2-1 (sRGB), 1: BT709, 2: Unspecified, = 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: YCOCG, = 9: BT2020 Non-constant Luminance, 10: BT2020 Constant Luminance) Question: Value 0 is listed as "IEC 61966-2-1 (sRGB)" but the table for matrix = coefficients in ISO/IEC 23001-8 says "GBR / Typically referred to as = RGB". Should value 0 =3D RGB? Add footnote: [IEC23001-8] ISO/IEC 23001-8:2013/DCOR1, "Coding independent media = description code points", 2013, = . > Element Name: BitsPerChannel > Level: 5 > ID: [55][B2] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: Number of decoded bits per channel. This number may be = less for=20 > specific channels depending on the Matrix and = ChromaSubsampling. A > value of 0 is unspecified. It may be fine, but I don't understand "This number may be less for = specific channels depending on the Matrix and ChromaSubsampling." Is the = value is less for specific channels, then it seems as if the value would = different among channels, but only one BitsPerChannel is stored for a = multi-channel video. I suggest changing the last line to: A value of 0 indicates that the = BitsPerChannel is unspecified. > Element Name: ChromaSubsamplingHorz > Level: 5 > ID: [55][B3] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of chrominance pixels to remove for every = chrominance > pixel not removed horizontally. For these subsampling elements, we may need a statement to say when they = should be used. For instance in QuickTime's TN2162 = https://developer.apple.com/library/mac/technotes/tn2162/_index.html = = it mandates the use of many values to better describe uncompressed = video. When would these chroma subsampling elements be suggested? I also suggest including an example; such as "Example: For video with = 4:1:1 chroma subsampling the ChromaSubsamplingHorz should be set to 3. > Element Name: ChromaSubsamplingVert > Level: 5 > ID: [55][B4] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of chrominance pixels to remove for every = chrominance > pixel not removed vertically. >=20 > Element Name: CbSubsamplingHorz > Level: 5 > ID: [55][B5] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of Cb chrominance pixels to remove for every = Cb > chrominance pixel not removed horizontally. This is = additive with > ChromaSubsamplingHorz. I'm confused about the relationship between CbSubsamplingHorz and = ChromaSubsamplingHorz. > Element Name: CbSubsamplingVert > Level: 5 > ID: [55][B6] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of Cb chrominance pixels to remove for every = Cb > chrominance pixel not removed vertically. This is = additive with > ChromaSubsamplingVert. >=20 >=20 > Element Name: ChromaSitingHorz > Level: 5 > ID: [55][B7] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: How Chroma is subsampled horizontally. (0: Unspecified, = 1: Left=20 > collocated , 2: Half) >=20 > Element Name: ChromaSitingVert > Level: 5 > ID: [55][B8] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: How Chroma is subsampled vertically. (0: Unspecified, 1: = Top > collocated , 2: Half) >=20 >=20 > Element Name: Range > Level: 5 > ID: [55][B9] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: Clipping of the color ranges. (0: Unspecified, 1: = Broadcast range, > 2: Full range (no clipping), 3: Defined by > Matrix/TransferFunction) >=20 >=20 > Element Name: TransferFunction To align with ISO/IEC 23001-8, could we use TransferCharacteristics? > Level: 5 > ID: [55][BA] > Mandatory: - > Multiple: - > Default: 2 > Type: u > Description: Transfer Function. See ISO/IEC 23001-8 for more = information on > enumerations. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified, > 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, > 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log = Sqrt, > 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut, > 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, > 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, > 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) Comment: The table in ISO/IEC 23001-8 for transfer characteristics does not = include values or meaning for 16, 17 and 18 as above. Are these values = from ffmpeg's list? Suggested description edit: The transfer characteristics of the video. For clarity, the value and = meanings for TransferCharacteristics are adopted from Table 3 of ISO/IEC = 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: = Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, 7: = SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, 11: IEC 61966-2-4, 12: = ITU-R BT.1361 Extended Colour Gamut, 13: IEC 61966-2-1, 14: ITU-R = BT.2020 10 bit, 15: ITU-R BT.2020 12 bit) > Element Name: Primaries > Level: 5 > Mandatory: - > Multiple: - > ID: [55][BB] > Default: 2 > Type: u > Description: Values that can be represented in the CIE 1931 colour = space. See > ISO/IEC 23001-8 for more information on enumerations. > (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: = Reserved, > 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: = SMPTE 240M, > 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1) Suggested description edit: The colour primaries of the video. For clarity, the value and meanings = for TransferCharacteristics are adopted from Table 2 of ISO/IEC = 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: = Reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE = 240M, 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1) Note that ISO/IEC 23001-8 also includes a value for 22 for JEDEC P22 = phosphors. Any reason to exclude this? > Element Name: MaxCLL > Level: 5 > ID: [55][BC] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: Maximum brightness of a single pixel in candelas per = square > meter (cd/m=C2=B2). Suggested: Maximum brightness of a single pixel (Maximum Content Light Level) in = candelas per square meter (cd/m=C2=B2). > Element Name: MaxFALL > Level: 5 > ID: [55][BD] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: Maximum brightness of a single full frame in candelas = per square > meter (cd/m=C2=B2). Suggested: Maximum brightness of a single full frame (Maximum Frame-Average Light = Level) in candelas per square meter (cd/m=C2=B2). > Element Name: MasteringMetadata > Level: 5 > ID: [55][D0] > Mandatory: - > Multiple: - > Default: - > Type: m > Description: SMPTE 2086 mastering data. >=20 >=20 > Element Name: PrimaryRChromaticityX > Level: 6 > ID: [55][D1] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 I think "0.0-1.0" is preferred for float range expressions. > Default: - > Type: f > Description: Red X chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: PrimaryRChromaticityY > Level: 6 > ID: [55][D2] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: Red Y chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: PrimaryGChromaticityX > Level: 6 > ID: [55][D3] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > f > Description: Green X chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: PrimaryGChromaticityY > Level: 6 > ID: [55][D4] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: Green Y chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: PrimaryBChromaticityX > Level: 6 > ID: [55][D5] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > f > Description: Blue X chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: PrimaryBChromaticityY > Level: 6 > ID: [55][D6] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: Blue Y chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: WhitePointChromaticityX > Level: 6 > ID: [55][D7] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: White point X chromaticity coordinate as defined by CIE = 1931. >=20 >=20 > Element Name: WhitePointChromaticityY > Level: 6 > ID: [55][D8] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: White point Y chromaticity coordinate as defined by CIE = 1931. >=20 >=20 > Element Name: LuminanceMax > Level: 6 > ID: [55][D9] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 9999.99 > Default: - > Type: f > Description: Maximum luminance. Shall be represented in candelas per = square > meter (cd/m=C2=B2). >=20 >=20 > Element Name: LuminanceMin > Level: 6 > ID: [55][DA] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 999.9999 > Default: - > Type: f > Description: Minimum luminance. Shall be represented in candelas per = square > meter (cd/m=C2=B2). > I removed ChromaSubsampling and added ChromaSubsamplingHorz, = ChromaSubsamplingVert, CbSubsamplingHorz, and CbSubsamplingVert. >=20 > This is how I think the elements should be written for the different = subsampling types: > 1: 4:4:4 > - ChromaSubsamplingHorz and ChromaSubsamplingVert will not be set = as there should be no chroma subsampling. >=20 > 2: 4:4:0 > - ChromaSubsamplingHorz :not set > - ChromaSubsamplingVert :1 >=20 > 3: 4:2:2 > - ChromaSubsamplingHorz :1 > - ChromaSubsamplingVert :not set >=20 > 4: 4:2:1 > - ChromaSubsamplingHorz :1 > - ChromaSubsamplingVert :not set > - CbSubsamplingHorz :1 > - CbSubsamplingVert :not set > - We could remove CbSubsamplingHorz and CbSubsamplingVert if we = didn't care about handling formats where the Cr and Cb channels are = different sizes. I forgot about 4:2:1. That answers my question about CbSubsmaplingHorz = though perhaps we need a narrative section to expand on this with the = examples you have here. > 5: 4:2:0 > - ChromaSubsamplingHorz :1 > - ChromaSubsamplingVert :1 >=20 > 6: 4:1:1 > - ChromaSubsamplingHorz :3 > - ChromaSubsamplingVert :not set >=20 > 7: 4:1:0 > - ChromaSubsamplingHorz :3 > - ChromaSubsamplingVert :1 >=20 > 8: 3:1:1 > - ChromaSubsamplingHorz :2 > - ChromaSubsamplingVert :not set > - I'm assuming the luma subsampling can be handled by PixelWidth, = and DisaplyWidth. >=20 > Jerome's vertical subsampling of 4 > - ChromaSubsamplingHorz :not set > - ChromaSubsamplingVert :3 >=20 >=20 >=20 > The other issue I want to bring up is the value of "18: ARIB STD-B67 = (HLG)" in TransferFunction. Unfortunately, in WebM we will need to use = this value sooner than Matroska v4 will be finalized. Should I make this = value much higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17: = SMPTE ST 428-1" will be standardized across most documents, like 1-15 = are. Just not sure if 18 will be HLG. I see a few references to ARIB STD-B67 as 18, such as = http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_5.pdf = . = Perhaps we need a caveat that values 1-15 are defined based upon ISO/IEC = 23001-8. Then for values 16, 17, and 18 we could add better descriptions = and citations to define it better internally. If (hopefully) a revision = to ISO/IEC 23001-8 adds those values (as expected) then we could update = are description to say all values are defined by ISO/IEC 23001-8. > Thanks, > Frank Thanks too, Dave Rice --Apple-Mail=_0C4FB45F-6C7D-4AE5-91CA-D2B0A13332F0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi,

On Feb 11, 2016, at 1:32 PM, = Frank Galligan via Matroska-devel <matroska-devel@lists.matroska.org> wrote:


On Mon, Feb 8, 2016 at 2:23 PM, Frank Galligan = <frankgalligan@gmail.com> wrote:


On Mon, Feb 8, 2016 at 9:15 AM, = Jerome Martinez <jerome@mediaarea.net> wrote:
=20 =20 =20
Sorry for the late answer, here are my comments:

On 22/01/2016 23:54, Frank Galligan wrote:
[...]

- I know some people expressed that they = don't think starting from FFmpeg for the TransferFunction is a good idea as they might have got something wrong or too subjective. But I just used it as a starting point for a list. I can reorder the list however we want. I also don't think following another list, so we will be compatible with future additions, will give us what we want as that list most likely will be incomplete with something that is defined only in a different list. So should we just start with a list, re-order it (so we are not explicitly following it), then add what is currently missing? Then in the future if someone needs to add something to the list it can be brought up here?

That was me.
I am OK with that as long as we are clear that we don't follow FFmpeg list.
OK, I changed the text to see ISO/IEC 23001-8 document, which = has the same values as FFmpeg as well as the 264 ITU doc.


[...]

Element = Name: Matrix
Level: =        5
ID: =           [55][A1]
Mandatory: =    -
Multiple: =     -
Default: =      2
Type: =         u
Description:=  Colour Matrix of the video. (0: IEC 61966-2-1 (sRGB), 1: = BT709,
=             &n= bsp;2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE = 170M,
=             &n= bsp;7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant = Luminance,
=             &n= bsp;10: BT2020 Constant Luminance)


If we don't follow FFmpeg list, what is the purpose of  value 3 = and why unspecified is 2 rather than 0?
That is the way it = is specified in ISO/IEC 23001-8 and 264 ITU doc. 

Using FFmpeg list (which is based on MPEG list, with same oddities) is not bad, and I am not against it, just wondering if it is good to take the same oddities rather than a clean list without oddities.
I don't think there = are any oddities. Looks like FFmpeg's list matches exactly to =  ISO/IEC 23001-8 and 264 ITU doc, except for #10 in Primaries = and #16 and #17 in Transfer function, which were added here [1]. Also = #18 in Transfer, which is HLG [2].

I think this is the whole issue. Do we = follow some list (standardized or not)? What if the list goes stale? = What if the list doesn't include algorithms from different lists (E.g. = maybe HLG)?



Does anyone plan to transfer from DPX? If yes, we may need to add now missing elements in the list (e.g. "Printing density") but I am not expert enough for know which one is worth it.




[...]


Element = Name: ChromaSubsampling
Level: =        5
ID: =           [55][A3]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:=  (0: Unspecified, 1: 4:4:4, 2: 4:4:0, 3: 4:2:2, 4: 4:2:1, 5: = 4:2:0, =             
=             &n= bsp;6: 4:1:1, 7: 4:1:0, 8: 3:1:1)

I am more, as some other people, for something more generic, e.g. ChromaSubsamplingHorz and ChromaSubsamplingVert, with a value of the subsampling (0 unspecified and default). I am afraid that someone crazy used e.g. a vertical subsampling of 4 (which can not be defined by X:X:X values), it is possible (and I have a file like that if I remember well) with FFV1.




[...]

Element = Name: TransferFunction
Level: =        5
ID: =           [55][A7]
Mandatory: =    -
Multiple: =     -
Default: =      2
Type: =         u
Description:=  Transfer Function. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified,
=             &n= bsp;4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE = 170M,
=             &n= bsp;7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt,
=             &n= bsp;11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut,
=             &n= bsp;13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit,
=             &n= bsp;15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084,
=             &n= bsp;17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG))


Element = Name: Primaries
Level: =        5
Mandatory: =    -
Multiple: =     -
ID: =           [55][A8]
Default: =      2
Description:=  (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 4: ITU-R = BT.470M,
=             &n= bsp; 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: = FILM,
=             &n= bsp; 9: ITU-R BT.2020, 10: SMPTE ST 428-1)

Same remark as with Matrix.


[...]



[1] https://github.com/FFmpeg/FFmpeg/commit/c3cd6dd106b1381933e2f24= 898eeec0d8aa17746
[2] http://www.arib.or.jp/english/html/overview/std-b67.html



So this is what I have = currently:
The parent element would be = Video [E0].


Element Name: = Colour
Level: =        4
ID: =           [55][B0]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         m
Description:  Settings = describing the colour format.


Element Name: = Matrix
=
To align better with ISO/IEC 23001-8, could = this be labelled as MatrixCoefficients?

Level: =        5
ID: =           [55][B1]
Mandatory: =    -
Multiple: =     -
Default: =      2
Type: =         u
Description: =  ColourMatrix of the video. See ISO/IEC 23001-8 for = more
=             &n= bsp;information on enumerations. (0: IEC 61966-2-1 (sRGB), 1: = BT709,
=             &n= bsp;2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE = 170M,
=             &n= bsp;7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant = Luminance,
=             &n= bsp;10: BT2020 Constant = Luminance)
<= div>
Suggested description = edit:
The Matrix Coefficients of the video used to = derive luma and chroma values from reg, green, and blue color primaries. = For clarity, the value and meanings for MatrixCoefficients are adopted = from Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0: IEC 61966-2-1 (sRGB), 1: = BT709, 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M, = 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance, 10: BT2020 = Constant Luminance)

Question:
Value 0 is listed as "IEC = 61966-2-1 (sRGB)" but the table for matrix coefficients in ISO/IEC = 23001-8 says "GBR / Typically referred to as RGB". Should value 0 =3D = RGB?

Add = footnote:
[IEC23001-8] ISO/IEC 23001-8:2013/DCOR1, "Coding = independent media description code points", 2013, <http://standards.iso.org/ittf/PubliclyAvailableStandards/c06208= 8_ISO_IEC_23001-8_2013.zip>.

Element Name: = BitsPerChannel
Level: =        5
ID: =           [55][B2]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:  Number of = decoded bits per channel. This number may be less for
=             &n= bsp;specific channels depending on the Matrix and ChromaSubsampling. = A
=             &n= bsp;value of 0 is = unspecified.

It may be fine, but I don't understand = "This number may be less for specific channels depending on the Matrix = and ChromaSubsampling." Is the value is less for specific channels, then = it seems as if the value would different among channels, but only one = BitsPerChannel is stored for a multi-channel video.

I suggest changing the last line to: A value of 0 = indicates that the BitsPerChannel is unspecified.

Element Name: = ChromaSubsamplingHorz
Level: =        5
ID: =           [55][B3]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount = of chrominance pixels to remove for every chrominance
=             &n= bsp;pixel not removed = horizontally.

For these subsampling elements, we may need a = statement to say when they should be used. For instance in = QuickTime's TN2162 https://developer.apple.com/library/mac/technotes/tn2162/_index= .html it mandates the use of many values to better describe = uncompressed video. When would these chroma subsampling elements be = suggested?

I also suggest including = an example; such as "Example: For video with 4:1:1 chroma subsampling = the ChromaSubsamplingHorz should be set to 3.

Element Name: = ChromaSubsamplingVert
Level: =        5
ID: =           [55][B4]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount = of chrominance pixels to remove for every chrominance
=             &n= bsp;pixel not removed vertically.

Element Name: = CbSubsamplingHorz
Level: =        5
ID: =           [55][B5]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount = of Cb chrominance pixels to remove for every Cb
=             &n= bsp;chrominance pixel not removed horizontally. This is additive = with
=             &n= bsp;ChromaSubsamplingHorz.

I'm confused about the = relationship between CbSubsamplingHorz = and ChromaSubsamplingHorz.

Element Name: = CbSubsamplingVert
Level: =        5
ID: =           [55][B6]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount = of Cb chrominance pixels to remove for every Cb
=             &n= bsp;chrominance pixel not removed vertically. This is additive = with
=             &n= bsp;ChromaSubsamplingVert.


Element Name: = ChromaSitingHorz
Level: =        5
ID: =           [55][B7]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:  How Chroma = is subsampled horizontally. (0: Unspecified, 1: Left
=             &n= bsp;collocated , 2: Half)

Element Name: = ChromaSitingVert
Level: =        5
ID: =           [55][B8]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:  How Chroma = is subsampled vertically. (0: Unspecified, 1: Top
=             &n= bsp;collocated , 2: Half)


Element Name: = Range
Level: =        5
ID: =           [55][B9]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description: =  Clipping of the color ranges. = (0: Unspecified, 1: Broadcast = range,
=             &n= bsp;2: Full range (no clipping), 3: Defined by
=             &n= bsp;Matrix/TransferFunction)


Element Name: = TransferFunction
<= div>
To align with ISO/IEC 23001-8, could we = use TransferCharacteristics?

Level: =        5
ID: =           [55][BA]
Mandatory: =    -
Multiple: =     -
Default: =      2
Type: =         u
Description:  Transfer = Function. See ISO/IEC 23001-8 for more information on
=             &n= bsp;enumerations. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified,
=             &n= bsp;3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 = curve,
=             &n= bsp;6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log = Sqrt,
=             &n= bsp;11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut,
=             &n= bsp;13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit,
=             &n= bsp;15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084,
=             &n= bsp;17: SMPTE ST 428-1 18: ARIB STD-B67 = (HLG))

Comment:
The table in ISO/IEC 23001-8 = for transfer characteristics does not include values or meaning for 16, = 17 and 18 as above. Are these values from ffmpeg's list?

Suggested description = edit:
The transfer characteristics of the video. = For clarity, the value and meanings = for TransferCharacteristics are adopted from Table 3 of = ISO/IEC 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified, 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 = curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log = Sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: ITU-R = BT.2020 12 bit)

Element Name: = Primaries
Level: =        5
Mandatory: =    -
Multiple: =     -
ID: =           [55][BB]
Default: =      2
Type: =         u
Description:  Values = that can be represented in the CIE 1931 colour space. = See
=             &n= bsp;ISO/IEC 23001-8 for more information on = enumerations.
=             &n= bsp;(0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: = Reserved,
=             &n= bsp;4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE = 240M,
=             &n= bsp;8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST = 428-1)

Suggested description edit:
The = colour primaries of the video. For clarity, the value and meanings for = TransferCharacteristics are adopted from Table 2 of ISO/IEC = 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: = Reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE = 240M, 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST = 428-1)

Note that ISO/IEC = 23001-8 also includes a value for 22 for JEDEC P22 phosphors. Any reason = to exclude this?

Element Name: = MaxCLL
Level: =        5
ID: =           [55][BC]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  Maximum = brightness of a single pixel in candelas per square
=             &n= bsp;meter = (cd/m=C2=B2).

Suggested:
Maximum brightness of a = single pixel (Maximum Content Light Level) in candelas per square meter = (cd/m=C2=B2).

Element Name: = MaxFALL
Level: =        5
ID: =           [55][BD]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  Maximum = brightness of a single full frame in candelas per = square
=             &n= bsp;meter = (cd/m=C2=B2).

Suggested:
Maximum brightness = of a single full frame (Maximum Frame-Average Light Level) in = candelas per square meter (cd/m=C2=B2).

Element Name: = MasteringMetadata
Level: =        5
ID: =           [55][D0]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         m
Description:  SMPTE 2086 = mastering data.


Element Name: = PrimaryRChromaticityX
Level: =        6
ID: =           [55][D1]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D = 1

I think "0.0-1.0" is preferred for float range = expressions.

Default: =      -
Type: =         f
Description: =  Red X chromaticity coordinate = as defined by CIE 1931.


Element Name: = PrimaryRChromaticityY
Level: =        6
ID: =           [55][D2]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 1
Default: =      -
Type: =         f
Description: =  Red Y chromaticity coordinate = as defined by CIE 1931.


Element Name: = PrimaryGChromaticityX
Level: =        6
ID: =           [55][D3]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 1
Default: =      -
f
Description: =  Green X chromaticity = coordinate as defined by CIE 1931.


Element Name: = PrimaryGChromaticityY
Level: =        6
ID: =           [55][D4]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 1
Default: =      -
Type: =         f
Description: =  Green Y chromaticity = coordinate as defined by CIE 1931.


Element Name: = PrimaryBChromaticityX
Level: =        6
ID: =           [55][D5]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 1
Default: =      -
f
Description: =  Blue X chromaticity = coordinate as defined by CIE 1931.


Element Name: = PrimaryBChromaticityY
Level: =        6
ID: =           [55][D6]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 1
Default: =      -
Type: =         f
Description: =  Blue Y chromaticity = coordinate as defined by CIE 1931.


Element Name: = WhitePointChromaticityX
Level: =        6
ID: =           [55][D7]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 1
Default: =      -
Type: =         f
Description: =  White point X chromaticity = coordinate as defined by CIE 1931.


Element Name: = WhitePointChromaticityY
Level: =        6
ID: =           [55][D8]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 1
Default: =      -
Type: =         f
Description: =  White point Y chromaticity = coordinate as defined by CIE 1931.


Element Name: = LuminanceMax
Level: =        6
ID: =           [55][D9]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 9999.99
Default: =      -
Type: =         f
Description:  Maximum = luminance. Shall be represented in candelas per square
=             &n= bsp;meter (cd/m=C2=B2).


Element Name: = LuminanceMin
Level: =        6
ID: =           [55][DA]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 999.9999
Default: =      -
Type: =         f
Description:  Minimum = luminance. Shall be represented in candelas per square
=             &n= bsp;meter = (cd/m=C2=B2).



I = removed ChromaSubsampling and added ChromaSubsamplingHorz, = ChromaSubsamplingVert, CbSubsamplingHorz, and = CbSubsamplingVert.

This is how I think the elements should be written for the = different subsampling types:
1: = 4:4:4
    - ChromaSubsamplingHorz and = ChromaSubsamplingVert will not be set as there should be no chroma = subsampling.

2: = 4:4:0
  - = ChromaSubsamplingHorz :not set
  - = ChromaSubsamplingVert :1

3: 4:2:2
  - ChromaSubsamplingHorz :1
  = - ChromaSubsamplingVert :not set

4: 4:2:1
  - ChromaSubsamplingHorz :1
  = - ChromaSubsamplingVert :not set
  - CbSubsamplingHorz :1
  - = CbSubsamplingVert :not set
  - We could = remove CbSubsamplingHorz and CbSubsamplingVert if we didn't care about = handling formats where the Cr and Cb channels are different = sizes.

I forgot about 4:2:1. That answers my question = about CbSubsmaplingHorz though perhaps we need a narrative section to = expand on this with the examples you have here.

5: 4:2:0
  - ChromaSubsamplingHorz :1
  = - ChromaSubsamplingVert :1

6: 4:1:1
  - = ChromaSubsamplingHorz :3
  - = ChromaSubsamplingVert :not set

7: 4:1:0
  - ChromaSubsamplingHorz :3
  = - ChromaSubsamplingVert :1

8: 3:1:1
  - ChromaSubsamplingHorz :2
  = - ChromaSubsamplingVert :not set
  - I'm = assuming the luma subsampling can be handled by PixelWidth, and = DisaplyWidth.

Jerome's vertical subsampling of 4
  - ChromaSubsamplingHorz :not set
  - ChromaSubsamplingVert :3



The other issue I want = to bring up is the value of "18: ARIB STD-B67 (HLG)" in TransferFunction. = Unfortunately, in WebM we will need to use this value sooner than = Matroska v4 will be finalized. Should I make this value much higher? Or = leave at 18? I think "16: SMPTE ST 2084" and "17: SMPTE ST 428-1" will be standardized across most = documents, like 1-15 are. Just not sure if 18 will be = HLG.

I see a few references to ARIB STD-B67 as 18, such = as http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_5.p= df. Perhaps we need a caveat that values 1-15 are defined based upon = ISO/IEC 23001-8. Then for values 16, 17, and 18 we could add better = descriptions and citations to define it better internally. If = (hopefully) a revision to ISO/IEC 23001-8 adds those values (as = expected) then we could update are description to say all values are = defined by ISO/IEC 23001-8.

Thanks,
Frank

Thanks too,
Dave Rice


= --Apple-Mail=_0C4FB45F-6C7D-4AE5-91CA-D2B0A13332F0-- From nobody Fri Feb 12 18:07:38 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9F61B29FF for ; Fri, 12 Feb 2016 18:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 a9BSIiuVXyOU for ; Fri, 12 Feb 2016 18:07:35 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA861B29F0 for ; Fri, 12 Feb 2016 18:07:35 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:36657 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aUPcS-001qlB-QF for cellar@ietf.org; Fri, 12 Feb 2016 21:07:35 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_729D4B5C-5383-4E2A-A0D7-461BE0672C1B" Message-Id: <2146ACE8-EB0D-4D83-9F56-EA51DF74EB67@dericed.com> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Date: Fri, 12 Feb 2016 21:07:30 -0500 References: <56A3E997.6050408@gmx.de> To: cellar@ietf.org In-Reply-To: <56A3E997.6050408@gmx.de> X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] EBML Introduction section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2016 02:07:38 -0000 --Apple-Mail=_729D4B5C-5383-4E2A-A0D7-461BE0672C1B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 23, 2016, at 3:59 PM, Sebastian G. wrote: >=20 > 23.01.2016, 20:36 Dave Rice: >> Each RFC must include an Introduction section to follow the TOC. >> There is some detail about the requirements [...] >>=20 >> I used the existing EBML Principle >> = >> section, Moritz's comments >> = , >> and my own text to create an introduction section. Comments? >=20 > Nothing of great importance from my side. Just a few thoughts or > suggestions. >=20 >> ## Introduction >>=20 >> EBML is short for Extensible Binary Meta Language. EBML specifies a >> binary and octet (byte) aligned format inspired by the principle of >> XML. EBML itself is a generalized description of the technique of >> binary markup. Like XML, it is completely agnostic to any data that >> it might contain. The format is made of 2 parts: the semantic and the >> structural. The structural part defines how EBML elements may be >> defined, arranged, and implemented. The semantic part specifies a >> number of Elements along with their identifier, name, type, and >> definition. Just like XML, the specific "tags" (IDs in EBML parlance) >> used in an EBML implementation are arbitrary. However, the semantic >> of EBML outlines general data types and ID's. >=20 > The start might be shortened to: >=20 > "EBML, short for Extensible Binary Meta Language, specifies a binary = and > octet (byte) aligned format inspired by the principle of XML." >=20 >> The goal of the EBML Specification is to define a generic, binary, >> space-efficient format which may be utilized to define more complex >> formats (such a containers for multimedia content) using an EBML >=20 > 'such a' has to be 'such as'. You could also use 'like', although that > gets used often in the section already. >=20 >> Schema. The definition of the EBML format recognizes the idea behind >> HTML and XML as a good one: separate structure and semantics allowing >> the same structural layer to be used with multiple, possibly widely >> differing semantic layers. Except for the EBML Header and a few >> global elements this specification does not define particular EBML >> format semantics; however this specification is intended to define >> how other EBML-based formats may be defined. >>=20 >> EBML uses a simple approach of building Elements upon three pieces of >> data (tag, length, and value) as this approach is well-known, easy to >> parse, and allows selective data parsing. The EBML structure >> additionally allows for hierarchical arrangement to support complex >> structural formats in an efficient manner. I updated the intro according to Sebastian's suggestions and submitted = it as a pull request. = https://github.com/Matroska-Org/ebml-specification/pull/52/files = Dave Rice --Apple-Mail=_729D4B5C-5383-4E2A-A0D7-461BE0672C1B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jan 23, 2016, at 3:59 PM, Sebastian G. <bastik> = wrote:

23.01.2016, 20:36 Dave Rice:
Each RFC must include an Introduction section = to follow the TOC.
There is some detail about the = requirements [...]

I used the existing EBML = Principle
<https://github.com/Matroska-Org/ebml-specification/blob/master/= specification.markdown#ebml-principle>
section, = Moritz's comments
<https://github.com/Matroska-Org/ebml-specification/issues/5#iss= uecomment-99932625>,
and my own text to create an = introduction section. Comments?

Nothing of great importance from my side. Just a few thoughts = or
suggestions.

## Introduction

EBML= is short for Extensible Binary Meta Language. EBML specifies a
binary and octet (byte) aligned format inspired by the = principle of
XML. EBML itself is a generalized description = of the technique of
binary markup. Like XML, it is = completely agnostic to any data that
it might contain. The = format is made of 2 parts: the semantic and the
structural. = The structural part defines how EBML elements may be
defined, arranged, and implemented. The semantic part = specifies a
number of Elements along with their = identifier, name, type, and
definition. Just like XML, the = specific "tags" (IDs in EBML parlance)
used in an EBML = implementation are arbitrary. However, the semantic
of = EBML outlines general data types and ID's.

The start might be shortened to:

"EBML, short for Extensible Binary Meta Language, specifies a = binary and
octet (byte) aligned format inspired by the = principle of XML."

The goal of the EBML Specification is to define a generic, = binary,
space-efficient format which may be utilized to = define more complex
formats (such a containers for = multimedia content) using an EBML

'such a' has to be 'such as'. You could also use 'like', = although that
gets used often in the section already.

Schema. = The definition of the EBML format recognizes the idea behind
HTML and XML as a good one: separate structure and semantics = allowing
the same structural layer to be used with = multiple, possibly widely
differing semantic layers. = Except for the EBML Header and a few
global elements this = specification does not define particular EBML
format = semantics; however this specification is intended to define
how other EBML-based formats may be defined.

EBML uses a simple approach of building Elements upon three = pieces of
data (tag, length, and value) as this approach = is well-known, easy to
parse, and allows selective data = parsing. The EBML structure
additionally allows for = hierarchical arrangement to support complex
structural = formats in an efficient manner.

I updated the intro according to Sebastian's suggestions and = submitted it as a pull request. https://github.com/Matroska-Org/ebml-specification/pull/52/file= s

Dave = Rice

= --Apple-Mail=_729D4B5C-5383-4E2A-A0D7-461BE0672C1B-- From nobody Sat Feb 13 08:23:10 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCA61A047A for ; Sat, 13 Feb 2016 08:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 1WIV5hDKw3e3 for ; Sat, 13 Feb 2016 08:22:49 -0800 (PST) Received: from 10.mo1.mail-out.ovh.net (10.mo1.mail-out.ovh.net [178.32.96.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0E571A0470 for ; Sat, 13 Feb 2016 08:22:48 -0800 (PST) Received: from mail604.ha.ovh.net (b9.ovh.net [213.186.33.59]) by mo1.mail-out.ovh.net (Postfix) with SMTP id 6773C106017F for ; Sat, 13 Feb 2016 17:22:46 +0100 (CET) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 13 Feb 2016 18:22:45 +0200 Received: from p5ddb7157.dip0.t-ipconnect.de (HELO ?192.168.2.101?) (jerome@francoallemand.eu@93.219.113.87) by ns0.ovh.net with SMTP; 13 Feb 2016 18:22:44 +0200 To: Dave Rice , Frank Galligan , Discussion about the current and future development of Matroska , cellar@ietf.org References: <568C3CA0.8040300@mediaarea.net> <56B8CD1A.20307@mediaarea.net> <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> From: Jerome Martinez Message-ID: <56BF5847.7030901@mediaarea.net> Date: Sat, 13 Feb 2016 17:22:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> Content-Type: multipart/alternative; boundary="------------020908070502060109040701" X-Ovh-Tracer-Id: 6364430698944401554 X-Ovh-Remote: 93.219.113.87 (p5ddb7157.dip0.t-ipconnect.de) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: -100 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrfeekucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrfeekgdekgecutefuodetggdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm Archived-At: Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2016 16:22:52 -0000 This is a multi-part message in MIME format. --------------020908070502060109040701 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit On 13/02/2016 02:53, Dave Rice wrote: > >> On Feb 11, 2016, at 1:32 PM, Frank Galligan via Matroska-devel >> > > wrote: >> [...] >> >> 4: 4:2:1 >> - ChromaSubsamplingHorz :1 >> - ChromaSubsamplingVert :not set >> - CbSubsamplingHorz :1 >> - CbSubsamplingVert :not set >> - We could remove CbSubsamplingHorz and CbSubsamplingVert if we >> didn't care about handling formats where the Cr and Cb channels are >> different sizes. > > I forgot about 4:2:1. That answers my question about CbSubsmaplingHorz > though perhaps we need a narrative section to expand on this with the > examples you have here. I was also disturbed by CbSubsamplingHorz and CbSubsamplingVert because there is no explaination about Cb and Cr in SubsamplingHorz and SubsamplingVert. So maybe we need to add explanation. SubsamplingHorz and SubsamplingVert are for both Cb and Cr except indicated otherwise. CbSubsamplingHorz and CbSubsamplingVert are same as SubsamplingHorz and SubsamplingVert if not present. >> [...] >> >> The other issue I want to bring up is the value of "18: ARIB STD-B67 >> (HLG)" in TransferFunction. Unfortunately, in WebM we will need to >> use this value sooner than Matroska v4 will be finalized. Should I >> make this value much higher? Or leave at 18? I think "16: SMPTE ST >> 2084" and "17: SMPTE ST 428-1" will be standardized across most >> documents, like 1-15 are. Just not sure if 18 will be HLG. > > I see a few references to ARIB STD-B67 as 18, such as > http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_5.pdf. > Perhaps we need a caveat that values 1-15 are defined based upon > ISO/IEC 23001-8. I don't follow: either we say that the list is the ISO/MPEG one and we need to find another way to provide HLG value, or we say that we don't care of MPEG list. Looks like we are in the middle (+ trying to use the FFmpeg list). For example an answer about the reason we keep 0 and 3 as reserved is that it is in other specs, but we also say that we don't care of other specs. I am lost. About HLG, my concern is not about Matroska v4 finalization, a bit out of topic actually (a list would be update without a new version of Matroska) but about the MPEG list. From document pointed by Dave, looks like ARIB has a deal with MPEG and ISO, or tries to force value 18 for HLG, so I would also use value 18, hoping that MPEG and ISO and ITU will accept value 18 for HLG. > Then for values 16, 17, and 18 we could add better descriptions and > citations to define it better internally. If (hopefully) a revision to > ISO/IEC 23001-8 adds those values (as expected) then we could update > are description to say all values are defined by ISO/IEC 23001-8. Values 16 and 17 are already in ITU H.265 documentation. I would reference this document (bonus: it is publicly available) I would just add a comment about value 18 = HLG. But as a general view of how we manage the list: how do we plan to manage it? If we say we try to follow MPEG list, maybe we need to have "temporary" value e.g. >0x1000000 and we wait for an official announcement from ITU/MPEG/ISO about value 18; if we don't care on any other list, we don't care of the value for HLG (18 or whatever). I think that before freezing the list, we need to clear about what is this list, if we try to follow another list we need to wait for its maintainer, else we need to be coherent e.g. if we don't follow MPEG or FFmpeg list, why do we have 0=reserved and 3=reserved and why 2=unspecified when all other tags have 0=unspecified and why 4 values (1, 6, 14, 15) for the same transfer characteristic? I would ask for a reason to have such value in the list or remove it from the list, i.e 0=unspecified, 1=ITU-R BT.709, 2=ITU-R BT.470M... And define a method for updating it (and say who is the list maintainer) if we are the "owner" of the list. Jérôme --------------020908070502060109040701 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 13/02/2016 02:53, Dave Rice wrote:

On Feb 11, 2016, at 1:32 PM, Frank Galligan via Matroska-devel <matroska-devel@lists.matroska.org> wrote:
[...]

4: 4:2:1
  - ChromaSubsamplingHorz :1
  - ChromaSubsamplingVert :not set
  - CbSubsamplingHorz :1
  - CbSubsamplingVert :not set
  - We could remove CbSubsamplingHorz and CbSubsamplingVert if we didn't care about handling formats where the Cr and Cb channels are different sizes.

I forgot about 4:2:1. That answers my question about CbSubsmaplingHorz though perhaps we need a narrative section to expand on this with the examples you have here.

I was also disturbed by CbSubsamplingHorz and CbSubsamplingVert because there is no explaination about Cb and Cr in SubsamplingHorz and SubsamplingVert.
So maybe we need to add explanation.
SubsamplingHorz and SubsamplingVert are for both Cb and Cr except indicated otherwise.
CbSubsamplingHorz and CbSubsamplingVert are same as SubsamplingHorz and SubsamplingVert if not present.

[...]

The other issue I want to bring up is the value of "18: ARIB STD-B67 (HLG)" in TransferFunction. Unfortunately, in WebM we will need to use this value sooner than Matroska v4 will be finalized. Should I make this value much higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17: SMPTE ST 428-1" will be standardized across most documents, like 1-15 are. Just not sure if 18 will be HLG.

I see a few references to ARIB STD-B67 as 18, such as http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_5.pdf. Perhaps we need a caveat that values 1-15 are defined based upon ISO/IEC 23001-8.

I don't follow: either we say that the list is the ISO/MPEG one and we need to find another way to provide HLG value, or we say that we don't care of MPEG list.
Looks like we are in the middle (+ trying to use the FFmpeg list).
For example an answer about the reason we keep 0 and 3 as reserved is that it is in other specs, but we also say that we don't care of other specs. I am lost.

About HLG, my concern is not about Matroska v4 finalization, a bit out of topic actually (a list would be update without a new version of Matroska) but about the MPEG list. From document pointed by Dave, looks like ARIB has a deal with MPEG and ISO, or tries to force value 18 for HLG, so I would also use value 18, hoping that MPEG and ISO and ITU will accept value 18 for HLG.

Then for values 16, 17, and 18 we could add better descriptions and citations to define it better internally. If (hopefully) a revision to ISO/IEC 23001-8 adds those values (as expected) then we could update are description to say all values are defined by ISO/IEC 23001-8.

Values 16 and 17 are already in ITU H.265 documentation. I would reference this document (bonus: it is publicly available)
I would just add a comment about value 18 = HLG.

But as a general view of how we manage the list: how do we plan to manage it? If we say we try to follow MPEG list, maybe we need to have "temporary" value e.g. >0x1000000 and we wait for an official announcement from ITU/MPEG/ISO about value 18; if we don't care on any other list, we don't care of the value for HLG (18 or whatever).

I think that before freezing the list, we need to clear about what is this list, if we try to follow another list we need to wait for its maintainer, else we need to be coherent e.g. if we don't follow MPEG or FFmpeg list, why do we have 0=reserved and 3=reserved and why 2=unspecified when all other tags have 0=unspecified and why 4 values (1, 6, 14, 15) for the same transfer characteristic? I would ask for a reason to have such value in the list or remove it from the list, i.e 0=unspecified, 1=ITU-R BT.709, 2=ITU-R BT.470M...
And define a method for updating it (and say who is the list maintainer) if we are the "owner" of the list.

Jérôme
--------------020908070502060109040701-- From nobody Sat Feb 13 10:40:04 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 715F21A1A7F for ; Sat, 13 Feb 2016 10:40:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no 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 8oK1Hf5JR7-F for ; Sat, 13 Feb 2016 10:40:01 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 220AD1A1A7E for ; Sat, 13 Feb 2016 10:40:01 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:42595 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aUf6t-002XzD-0c for cellar@ietf.org; Sat, 13 Feb 2016 13:40:01 -0500 From: Dave Rice Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 13 Feb 2016 13:39:56 -0500 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 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] EBML notations X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2016 18:40:02 -0000 Hi all, I created a pull request here:=20 It includes adding the RFC2119 boilerplate: = https://github.com/Matroska-Org/ebml-specification/pull/53 > ## Notation and Conventions >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", = "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this = document are to be interpreted as described in [RFC = 2119](https://tools.ietf.org/html/rfc2119). Any other boilerplate applicable or worthwhile here? I also included a new definition for VINTMAX in the Element Date Size = section: > The maximum possible value that can be stored as Element Data Size is = referred to as `VINTMAX`. This allows some of the EBML Element Type length definitions to be = shortened, such as: > A binary element may declare any length (including zero) up to the = maximum Element Data Size value permitted. to > A binary element may declare any length (including zero) to `VINTMAX`. Any other suggestions for terminology to define in the EBML spec? And Moritz merged it even before I sent this email :) but comments are = still welcome. Best Regards, Dave Rice= From nobody Sat Feb 13 10:50:25 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1978A1A1B00 for ; Sat, 13 Feb 2016 10:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.745 X-Spam-Level: *** X-Spam-Status: No, score=3.745 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FF_IHOPE_YOU_SINK=2.166, SPF_NEUTRAL=0.779] autolearn=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 H5ZllwqD5EmR for ; Sat, 13 Feb 2016 10:50:22 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BAA11A1AFC for ; Sat, 13 Feb 2016 10:50:22 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:34050 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aUfGv-002fCj-10 for cellar@ietf.org; Sat, 13 Feb 2016 13:50:22 -0500 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Sat, 13 Feb 2016 13:50:19 -0500 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 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] expressing a float in text X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2016 18:50:24 -0000 To accommodate the float range expressions in Frank=E2=80=99s color = work, I=E2=80=99m expanding the =E2=80=9CExpression of range=E2=80=9D = [1] section to accommodate floats (currently it only discusses signed = and unsigned integers). Frank=E2=80=99s use of float ranges are quite = simple, such as 0.0 to 1.0; however, in defining a method to document a = float range, I think the definition should work for any possible float = value. Is there an standard document to point to for how to represent a float = value as text? i.e. I=E2=80=99m familiar with float values in text such = as 3.88E-4 but where it this style of expression defined? Best Regards, Dave Rice [1] = https://github.com/Matroska-Org/ebml-specification/blob/master/specificati= on.markdown#expression-of-range= From nobody Sat Feb 13 10:58:10 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5BE71A1B49 for ; Sat, 13 Feb 2016 10:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 ZG2fdjYspo7A for ; Sat, 13 Feb 2016 10:58:06 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3AE1A1B45 for ; Sat, 13 Feb 2016 10:58:05 -0800 (PST) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u1DIvImV026742 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sat, 13 Feb 2016 19:57:19 +0100 Received: from Castor.local (85-218-38-132.dclient.lsne.ch [85.218.38.132]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u1DIvHq9030279; Sat, 13 Feb 2016 19:57:18 +0100 Date: Sat, 13 Feb 2016 19:57:18 +0100 From: Reto Kromer To: Dave Rice X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] expressing a float in text X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2016 18:58:08 -0000 Dave Rice wrote: >Is there an standard document to point to for how to >represent a float value as text? i.e. I=E2=80=99m familiar with >float values in text such as 3.88E-4 but where it this >style of expression defined? IEEE 754-2008? Best regards, Reto AV Preservation by reto.ch chemin du Suchet 5 | 1024 Ecublens | Switzerland Web: http://reto.ch | Twitter: @retoch From nobody Sat Feb 13 11:24:22 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE541A219B for ; Sat, 13 Feb 2016 11:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.167 X-Spam-Level: X-Spam-Status: No, score=0.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 LdQHiWyb7kbP for ; Sat, 13 Feb 2016 11:24:19 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 1A18A1A2119 for ; Sat, 13 Feb 2016 11:24:19 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id h129so88854071ywb.1 for ; Sat, 13 Feb 2016 11:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=TIGAdzjjt53TwxiAMnM12ayTOUiTEvLq4E44Zk+IId0=; b=U32qm3qIibHXJ0yEvjRrWbYDRXbSpqr3gANojQsR5kW53k2SMkB1KylxjhmE4WSJn1 GbMAGyG5SMmF9aesABtwjTUEKE1LSri3qFRD4tsHdsAAA/h0shlufgvhvVuNMFSJbZ3X ic3kIXcnJoiir8vmWdGs5P5cHUHJd6pizMnOvtr1nZ0Fip0QtZwdW3MKY6d9X9zMJy4r nKmmzkqfu90ZA3n77k0LV+/7M4Is+FRb20JDf1n9zWbLEjwVg+ttRJZApHAvuBqD0StK hpAUIQvOB9H29pqEzUFyLykltct7y53ngZqcQTyZheL1DJuKxokVHn1qPtYrkeG9NANY BIxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=TIGAdzjjt53TwxiAMnM12ayTOUiTEvLq4E44Zk+IId0=; b=J/lzmhCSCbX1AqB71r81JaQQKxd+XM6tRKg0uGXW1w8HM6qqMvGynVjPl158SL4Bn7 75o2iLrTDAswqbB/A1ZCBzDa7AGpoaXjt6J7WamBXf2hGSgMNL2uwfHnqwXXeBzUVRch 26w8K7RffA32stj0Uu7y00JzN7xqIKoXUxVhBl0nWfOwGK7/zwFLZYkzZO7hS6MMdoaG yinmG/r0RrL6KyzABXs2yeSM95u/C/FiEYOT+zsepIqmRBR0UhDDdAqnbO200yzvUiqQ efK2mmGOuZ8/e+6+xJA4ZWVLHz2FR/3cnKCpJgwlRXdadmdHvDb9xMQu62PyUn4KRPkx 0sUQ== X-Gm-Message-State: AG10YOT2TGXiyTU0/QrqI2OrjuVR0Mi0AKwN09Ck6CWHn1MfzbOz84zHeHkEHiLm0owlVHt0HxsBA4m6fCR8AQ== MIME-Version: 1.0 X-Received: by 10.129.52.12 with SMTP id b12mr4772686ywa.8.1455391458405; Sat, 13 Feb 2016 11:24:18 -0800 (PST) Received: by 10.13.221.22 with HTTP; Sat, 13 Feb 2016 11:24:18 -0800 (PST) In-Reply-To: References: Date: Sun, 14 Feb 2016 00:54:18 +0530 Message-ID: From: Nithin Mathew Kurien To: Dave Rice Content-Type: multipart/alternative; boundary=001a1141b2a6e333ba052babba14 Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] expressing a float in text X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2016 19:24:20 -0000 --001a1141b2a6e333ba052babba14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Not sure if it is suitable in this context, but C99 supports writing floats accurately in hexadecimal notation ( http://www.exploringbinary.com/hexadecimal-floating-point-constants/). The advantage of hexadecimal notation is that values can be represented accurately, unlike representions like 1.67e-3, which will result in rounding errors when converted from decimal to the native binary form. With a C99 compiler like GCC, we can output the hexadecimal form of any float. double num =3D 1.55e1; printf("%a", num); would output 0x1.fp3 which is equal to (1 + 15/16) * 2^3. Thanks and regards, Nithin On Sun, Feb 14, 2016 at 12:20 AM, Dave Rice wrote: > To accommodate the float range expressions in Frank=E2=80=99s color work,= I=E2=80=99m > expanding the =E2=80=9CExpression of range=E2=80=9D [1] section to accomm= odate floats > (currently it only discusses signed and unsigned integers). Frank=E2=80= =99s use of > float ranges are quite simple, such as 0.0 to 1.0; however, in defining a > method to document a float range, I think the definition should work for > any possible float value. > > Is there an standard document to point to for how to represent a float > value as text? i.e. I=E2=80=99m familiar with float values in text such a= s 3.88E-4 > but where it this style of expression defined? > > Best Regards, > Dave Rice > > [1] > https://github.com/Matroska-Org/ebml-specification/blob/master/specificat= ion.markdown#expression-of-range > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --001a1141b2a6e333ba052babba14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Not sure if it is suitable in this = context, but C99 supports writing floats accurately in hexadecimal notation= (http://www.exploringbinary.com/hexadecimal-floating-point-constants= /). The advantage of hexadecimal notation is that values can be represe= nted accurately, unlike representions like 1.67e-3, which will result in ro= unding errors when converted from decimal to the native binary form. With a= C99 compiler like GCC, we can output the hexadecimal form of any float.

double num =C2=A0=3D=C2=A01.55e1;
printf(= "%a", num);

would output<= /div>

0x1.fp3

= which is equal to (1 + 15/16) * 2^3.

Thank= s and regards,
Nithin


On Sun, Feb 14, 201= 6 at 12:20 AM, Dave Rice <dave@dericed.com> wrote:
To accommodate the float range expressions in Frank= =E2=80=99s color work, I=E2=80=99m expanding the =E2=80=9CExpression of ran= ge=E2=80=9D [1] section to accommodate floats (currently it only discusses = signed and unsigned integers). Frank=E2=80=99s use of float ranges are quit= e simple, such as 0.0 to 1.0; however, in defining a method to document a f= loat range, I think the definition should work for any possible float value= .

Is there an standard document to point to for how to represent a float valu= e as text? i.e. I=E2=80=99m familiar with float values in text such as 3.88= E-4 but where it this style of expression defined?

Best Regards,
Dave Rice

[1] https://github.com/Matroska-Org/ebml-specification/blob/master/spe= cification.markdown#expression-of-range
_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

--001a1141b2a6e333ba052babba14-- From nobody Sat Feb 13 13:04:44 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995DB1A8712 for ; Sat, 13 Feb 2016 13:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no 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 19lbeWurMoEY for ; Sat, 13 Feb 2016 13:04:40 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6BBB1A870E for ; Sat, 13 Feb 2016 13:04:40 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:43892 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aUhMs-00200P-F9; Sat, 13 Feb 2016 16:04:40 -0500 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 13 Feb 2016 16:04:36 -0500 Message-Id: <0A176C1B-19D5-4579-8447-4A5075B8D94B@dericed.com> To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Moritz Bunkus Subject: [Cellar] EBML Security Considerations section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2016 21:04:42 -0000 Here is a draft Security Considerations section for the EBML spec. The = section is based off Moritz=E2=80=99s comment here = https://github.com/Matroska-Org/ebml-specification/issues/6#issuecomment-9= 9937237 with some minor re-wording. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ## Security Considerations EBML itself does not offer any kind of security. It has nothing to do = with authentication, it dose not provide confidentiality, only = marginally useful and effective data integrity options (CRC elements). EBML does not provide any kind of authorization. Even if the semantic layer offers and kind of encryption EBML itself = leaks information, at the least the sematic layer used via the DocType = element, but also certain information about the structure from the = elements (you can derive the presence of EBML elements even with an = unknown semantic layer with a heuristic approach; not without errors, of = course, but with a certain degree of confidence). Attacks on an EBML reader may include: - Invalid Element IDs that are longer than the limit stated in the = EBMLMaxIDLength Element of the EBML Header. - Invalid Element IDs that not encoded in the shortest-possible way. - Invalid Element Ids comprised of reserved values. - Invalid Element Data Size values that are longer than the limit stated = in the EBMLMaxSizeLength Element of the EBML Header. - Invalid Element Data Size values (e.g. extending the length of the = Element beyond the scope of the Parent Element; possibly triggering = access-out-of-bounds issues). - Very high lengths in order to force out-of-memory situations resulting = in a denial of service, access-out-of-bounds issues etc. - Missing Elements that are mandatory and have no declared default = value. - Usage of 0x00 octets in EBML Elements with a string type. - Usage of invalid UTF-8 encoding in EBML Elements of UTF-8 type (e.g. = in order to trigger acces-out-of-bounds or buffer overflow issues). - Usage of invalid data in EBML Elements with a date type. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Of the points, I don=E2=80=99t quite understand a few.. Originally Moritz wrote: > Usage of \0 characters in EbmlString elements I changed it to > - Usage of 0x00 octets in EBML Elements with a string type. but the string elements are allowed to be terminated with one or many = 0x00 octets. What is an example of a null terminated EBML string that is = a security consideration. Regarding: > - Usage of invalid data in EBML Elements with a date type. Any 0 or 8 octet date value is valid, right? Other lengths are already = invalid for date elements, so is this necessary to include? A PR of the draft Security Considerations section is here: = https://github.com/Matroska-Org/ebml-specification/pull/54. Dave Rice= From nobody Sat Feb 13 13:09:21 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B41F1A871F for ; Sat, 13 Feb 2016 13:09:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 yCOA9SfE_RBh for ; Sat, 13 Feb 2016 13:09:18 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F8521A8714 for ; Sat, 13 Feb 2016 13:09:18 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:41414 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aUhRM-002GgZ-7I for cellar@ietf.org; Sat, 13 Feb 2016 16:09:18 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_25A64DC7-3E3C-4806-9631-F7E094ADD397" Date: Sat, 13 Feb 2016 16:09:14 -0500 References: <20150702175013.3f2e8427@miuna> To: cellar@ietf.org Message-Id: <6C67F2DE-5F7F-4D67-8FF9-69CAFB25E769@dericed.com> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 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] Fwd: [Matroska-devel] EBML data type constraints X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2016 21:09:20 -0000 --Apple-Mail=_25A64DC7-3E3C-4806-9631-F7E094ADD397 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, Working on the Security Considerations section reminded me that = there=E2=80=99s some open discussion about the use of null bytes as = terminators in UTF-8 and String elements. This is an extract from = Matroska-devel last year: > Begin forwarded message: >=20 > From: wm4 > Subject: Re: [Matroska-devel] EBML data type constraints > Date: July 2, 2015 at 11:50:13 AM EDT > To: matroska-devel@lists.matroska.org > Reply-To: Discussion about the current and future development of = Matroska >=20 > On Thu, 02 Jul 2015 17:26:07 +0200 > Jerome Martinez wrote: >=20 >> Le 02/07/2015 16:21, wm4 a =C3=A9crit : >>> On the other hand, allowing zero-padded strings will cause weirdness=20= >>> with other languages which do byte strings, and where a zero byte=20 >>> won't automatically terminate a string. IMHO this stupid detail = should=20 >>> just be disallowed (or deprecated). >>=20 >> In that case, I propose: >>=20 >> String - Printable ASCII (0x20 to 0x7E) >> Muxers MUST NOT append any NULL byte >> Demuxers SHOULD accept NULL padding when present and consider such = bytes=20 >> as non existent. >>=20 >> UTF-8 - Printable Unicode string (Unicode character value >=3D0x20)=20= >> conforming to RFC 2279 >> Muxers MUST NOT append any NULL byte >> Demuxers SHOULD accept NULL padding when present and consider such = bytes=20 >> as non existent. >=20 > +1 >=20 > (This wording doesn't specify what happens if there are null bytes in > the middle of the string, with trailing non-null bytes - should be > refined.) The present wording for string and UTF-8 Element Types is: > A String Element may either be empty (zero-length) or contain = Printable ASCII characters in the range of 0x20 to 0x7E. Octets with all = bits set to zero may follow the string value when needed. and > A UTF-8 Element shall contain only a valid Unicode string as defined = in [RFC 2279](http://www.faqs.org/rfcs/rfc2279.html). Octets with all = bits set to zero may follow the UTF-8 value when needed. Is the current wording sufficient or should there be further constraints = or explanation? Dave Rice= --Apple-Mail=_25A64DC7-3E3C-4806-9631-F7E094ADD397 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi all,
Working on the Security = Considerations section reminded me that there=E2=80=99s some open = discussion about the use of null bytes as terminators in UTF-8 and = String elements. This is an extract from Matroska-devel last year:

Begin forwarded message:

From: = wm4 <nfxjfg@googlemail.com>
Subject: = Re: = [Matroska-devel] EBML data type constraints
Date: = July 2, 2015 at 11:50:13 AM = EDT
To: = matroska-devel@lists.matroska.org
Reply-To: = Discussion about the current = and future development of Matroska <matroska-devel@lists.matroska.org>

On = Thu, 02 Jul 2015 17:26:07 +0200
Jerome Martinez <jerome@mediaarea.net> wrote:

Le 02/07/2015 16:21, wm4 = a =C3=A9crit :
On the = other hand, allowing zero-padded strings will cause weirdness
with other languages which do byte strings, and where a zero = byte
won't automatically terminate a string. IMHO this = stupid detail should
just be disallowed (or = deprecated).

In that case, I = propose:

String - Printable ASCII (0x20 to = 0x7E)
Muxers MUST NOT append any NULL byte
Demuxers SHOULD accept NULL padding when present and consider = such bytes
as non existent.

UTF-8 - Printable Unicode string (Unicode character value = >=3D0x20)
conforming to RFC 2279
Muxers = MUST NOT append any NULL byte
Demuxers SHOULD accept NULL = padding when present and consider such bytes
as non = existent.

+1

(This wording doesn't specify what happens if there are null = bytes in
the middle of the string, with trailing non-null = bytes - should be
refined.)

The present wording for string and UTF-8 Element Types = is:
A = String Element may either be empty (zero-length) or contain Printable = ASCII characters in the range of 0x20 to 0x7E. Octets with all bits set = to zero may follow the string value when = needed.
 and
A UTF-8 Element shall = contain only a valid Unicode string as defined in [RFC 2279](http://www.faqs.org/rfcs/rfc2279.html). Octets with all = bits set to zero may follow the UTF-8 value when needed.

Is the current wording sufficient = or should there be further constraints or explanation?
Dave Rice
= --Apple-Mail=_25A64DC7-3E3C-4806-9631-F7E094ADD397-- From nobody Sat Feb 13 13:37:02 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18011A878E for ; Sat, 13 Feb 2016 13:37:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no 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 lmnmyjppGqjv for ; Sat, 13 Feb 2016 13:37:00 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D87B1A8795 for ; Sat, 13 Feb 2016 13:37:00 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:43326 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aUhsA-0032Ow-7a for cellar@ietf.org; Sat, 13 Feb 2016 16:37:00 -0500 From: Dave Rice Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <74651E49-02F2-4BFF-9B91-0C78A169DD5B@dericed.com> Date: Sat, 13 Feb 2016 16:36:56 -0500 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 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] adding unknownsizeallowed attribute for EBML definitions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 13 Feb 2016 21:37:01 -0000 Current the EBML spec implies that any Master-element may use an unknown = Element Data Size and may contain data that is not part of an EBML = Element. I propose that this should be constrained in EBML Element = definitions. I drafted another attribute for EBML Element definitions called = unknownsizeallowed (better names welcome). The proposed attribute is not required and I drafted this definition: > A boolean to express if an EBML Element MAY use an Element Data Size = that is Unknown (having all VINT\_DATA bits set to 1). The = `unknownsizeallowed` attribute MAY only be applied to Master-elements. = If the `unknownsizeallowed` attribute is not used it is assumed that the = element not allowed to use an unknown Element Data Size. With the added definition, I also changed a sentence in the definition = of the Master-element Data Type from: > When EBML is used in transmission or streaming, data that is not part = of an EBML Element is permitted to be present within a Master-element. to > When EBML is used in transmission or streaming, data that is not part = of an EBML Element is permitted to be present within a Master-element if = `unknownsizeallowed` is enabled within that Master-element's definition. The adjustment presumes that non-EBML junk data is only permitted in = Master-elements with unknown size. Possibly these two qualities could be = separated but I can=E2=80=99t really see a reason to have a = Master-element with a known size also contain junk data. A draft PR is here: = https://github.com/Matroska-Org/ebml-specification/pull/55 Comments? Also if using this, we=E2=80=99ll have to clarify which Matroska/webm = elements would use this? I suspect it=E2=80=99s a small percentage of = the Master-elements declared for those document types. Dave Rice From nobody Sun Feb 14 06:39:16 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6741ACE30 for ; Sun, 14 Feb 2016 06:39:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 Cc9sZeL6Frzf for ; Sun, 14 Feb 2016 06:39:13 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE521ACE2E for ; Sun, 14 Feb 2016 06:39:13 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id e185so90801742vkb.1 for ; Sun, 14 Feb 2016 06:39:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=zR3CuB2vOkth7XtgcdIHLkMETZua/kR+BuTW1nZZHno=; b=ZonEchQdIucQT2xOHZ+Tx4L8Vgy86WMi/hZvFiOIfOZiDwKNVdQLRCiaKbqDXDlomW BvOVAFk8PBfGn6lb5a7Lk36mJitfcbufF47DPEd/oC3f3rdqdWi6gjlb6lK3/zobXHLn 2jndpO30ulQfCbsXmGrrFebPM4DbGOyMBOubstmjmKGDFc2VdoEcm5BKTMNlC7Bra+Y+ hzZ6Y9HFzgg5knCiZ7SgZ2OVwpRuJ4/HdoWaniG05H6M8sYbXxAyStNiacq/BpNtgAe8 rUpr24Clr00DlRRounmPfybu30WokKF99DJr0zjCttF/bHiuDqMIqDRcLC4LnoORtRtC Bq5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zR3CuB2vOkth7XtgcdIHLkMETZua/kR+BuTW1nZZHno=; b=aQcvaqE2xM8cMLCE+dEFZ7uvGAS8WH21gZO2YnKwJP/+d6+RBw48R5O7f001shpyaN j34QV3uhuCrH7O4qqfYmOXc5xSNLic0k8SUVQrB3ChxA2O4cP5//+o5Of5Ed9+WjntDN cOZxAnIp2VuiPS8COw8VDrW+/2Xuf+cqAa5gLjnNMRGs1BUI1kwPAtMDM+NLZq6hIjRb SHFVvCWz4+On3+ny+q/1PIM71BG2gzAvfsl1hB68ROKtbDK7/oHQRrZliu+ERkSyF+bm kXJC4WnYprt3UGHZmjbhkTNtLyhROMfeFK2W5ikd4KEs7voLkMpcry2s5dmOfYh7s0PO EExw== X-Gm-Message-State: AG10YOSjEvzEZNBQMeElbH+diBTZf/ILQQ/DSvjzreKpuMBMlRUhDomb9obxVTYS0yJmmjFYFMy/LPkDzhHi0Q== MIME-Version: 1.0 X-Received: by 10.31.160.6 with SMTP id j6mr9803979vke.87.1455460752025; Sun, 14 Feb 2016 06:39:12 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 06:39:11 -0800 (PST) In-Reply-To: References: Date: Sun, 14 Feb 2016 15:39:11 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Discussion about the current and future development of Matroska , cellar@ietf.org, Nithin Mathew Kurien Subject: Re: [Cellar] [Matroska-devel] Menu System in Matroska Files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 14:39:15 -0000 2016-02-09 15:39 GMT+01:00 Dave Rice : > > On Feb 9, 2016, at 3:29 AM, Nithin Mathew Kurien via Matroska-devel > wrote: > > Hello, > > Since DVDMenuXtractor is incompatible with the current versions of > MKVToolNix and VLC, and has been out of development for a long time, can we > have a new menu specification for Matroska, designed from scratch if > necessary? > > > From scratch is a bit daunting. Would the dvdauthor menu xml format serve as > a good starting point? DVDMenuXtractor was designed to be a proof of concept of how Matroska menus could work. I think a good menu system should be able to do what DVDs and Blu-rays do, so that would be a good starting point. Given that there might different ways to achieve the same goal. The DVD format being a bit constraining. I suppose the Blu-ray one is too. A menu system is a very big project on its own. I think we should keep that on the side for now. We can surely discuss and start the project. But right now that should not be the main focus. One of the implications of this work, though, was to allow concatenated Matroska files to play. Segments in the one file could reference each other, since that's the main goal of a menu anyway. Since they might not be encoded with the same size/speed/etc and having different tracks. We should keep that in mind when finalizing Matroska. > Dave Rice > > Thanks and regards, > Nithin > > > On Mon, Jan 25, 2016 at 9:23 PM, Nithin Mathew Kurien > wrote: >> >> Hi, >> >> I downloaded DvdMenuXtractor (rev1295) from >> http://tirnanog.fate.jp/mirror/DvdMenuXtractor/ and tested it on a >> DVD. The program completed execution and output .BAT files along with >> the demuxed tracks. I use the latest versions of MKVToolNix (v.8.8.0) >> and VLC Player (v.2.2.1). When I ran the .BAT files which invoked >> MKVToolNix, most of them aborted execution midway with error. A few of >> them completed, but when I opened the resulting MKV files in VLC, it >> showed the error "VLC can't recognize the input's format: >> The format cannot be detected." It seems that DVDMenuXtractor is not >> working correctly. Is there any way to fix this? Are there some >> example MKV files with menus which I can test in VLC? >> >> Thanks and regards, >> Nithin >> >> >> On Sat, Jan 2, 2016 at 1:49 PM, Steve Lhomme wrote: >> > 2015-12-17 11:41 GMT+01:00 Nithin Mathew Kurien >> > : >> >> Dear all, >> >> >> >> The Matroska specification includes a menu system which is currently >> >> in a draft state (http://matroska.org/technical/menu/index.html). >> >> Currently there are no open-source players supporting this feature. >> > >> > Yes, VLC can handle Matroska files with DVD menus extracted using >> > DVDMenuXtractor: >> > https://github.com/Matroska-Org/dvdmenuxtractor >> > >> > This was a project meant to demonstrate that Matroska menus are >> > possible. It was never finished though as not all DVD commands were >> > translated into Matroska menus. It was also done ~10 years ago and >> > support in VLC might be broken by now. >> > >> > The idea was to be able to keep all the information contained in a DVD >> > ISO, but in a different format. >> > >> >> But there is at least one proprietary format, namely PGMX, a variant >> >> of MKV, that includes a working menu. These files are created by a >> >> proprietary TMPGENC PGMX creator and played by a freeware TMPGENC PGMX >> >> player. A PGMX file also supports including multiple related titles >> >> inside a single file. Opening this file on open-source players will >> >> play it as a normal MKV file without menus. There are some samples >> >> given in their website >> >> (http://tmpgenc.pegasys-inc.com/en/download/tpxp.html). >> >> >> >> I think the menu feature would be a good idea to implement in Matroska >> >> files and humbly request for the same. I think this feature would be >> >> useful for content authors who would like to distribute their works >> >> freely under a Creative Commons license, for example, who would >> >> otherwise have to adopt proprietary formats like DVD and Blu-ray. I >> >> understand that implementing a menu system from scratch might involve >> >> some complexity. In that case, would it be possible to adopt some >> >> features from the open-source libdvdnav and libbluray? >> >> >> >> Thanks and regards, >> >> Nithin >> >> >> >> _______________________________________________ >> >> Cellar mailing list >> >> Cellar@ietf.org >> >> https://www.ietf.org/mailman/listinfo/cellar >> > >> > >> > >> > -- >> > Steve Lhomme >> > Matroska association Chairman > > > _______________________________________________ > Matroska-devel mailing list > Matroska-devel@lists.matroska.org > http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel > Read Matroska-Devel on GMane: > http://dir.gmane.org/gmane.comp.multimedia.matroska.devel > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > -- Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 06:50:55 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23FB1AC398 for ; Sun, 14 Feb 2016 06:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 HW_O6QVlEcEb for ; Sun, 14 Feb 2016 06:50:52 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (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 E030B1ABD3D for ; Sun, 14 Feb 2016 06:50:51 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id c3so90807549vkb.3 for ; Sun, 14 Feb 2016 06:50:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hHCE/72dISAVtPvcxlK2f3lJahl8sio2KvSRWK31yWI=; b=gF9yDYIuLa7ZppHMEJFy0tQaJSjfdgyqI6EFvjBGp3L4BQf9wp+1VrDXTmUFUQfFOc 5Lq3y0hOImrLIpg+TvBZw7cHeRY47/R6NqizNJGvqdX9nC8duhqWVcio/DsCUBCUHHgy 6b2BlFSpKQtYf3PP8j0i813mQqx41joCsQMvw0pyVVc1lBAglvNXZuIIaPnlc00YxNjb GG3379X7jQo12G0LdXzJTO0b7GfanMht/u7TbSxNviORPZHZfREGeRLv5zyqQgQcfwIp bs5zyMXV1fZvabFZIAARuWahPJcU4A+DQaQneTZXJ9dCNQxDz1V0VZ6Vbbt08b8Rb+5k P2tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=hHCE/72dISAVtPvcxlK2f3lJahl8sio2KvSRWK31yWI=; b=eJNKuh8A0zDHqC4iWWsc/gB+Oyf2EzmAyxp2gaOBwLGTGIlPAeSryYYMbUMeqcUJ+u 1H8Jw3XN9N3xRM1wbeWs3YcTIYQu/KJjRAgACmNKMgjX/4Q1aJjjo5TDaKODgWauBzs5 2nEBMOAx4w9FYSM04Dhm7bWTbrns1jUKAttDAI9NkiKml95jQwWiy15irF+IAZ7bajQu Fq4kNSpYXnPi+9dKFLlABTQhzNHwo3qvUQMg9hUXkx81JLZDdFLmTxgOcq415aoKa0UY j1dxrsKn5tA2tTZfnNMMsGn7YYDB5ypyT9JpyPxSQlNLVHm+8/javfUSYUdYmNBBYJro cb7g== X-Gm-Message-State: AG10YOTy1ykHKel8tOQl2qCAIqnXoO8EQsHO8mif/lZuCx5u61TJSQvSlui7FN2x11XGZHBrXqz6X3n9lzfWpw== MIME-Version: 1.0 X-Received: by 10.31.160.6 with SMTP id j6mr9837614vke.87.1455461451048; Sun, 14 Feb 2016 06:50:51 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 06:50:50 -0800 (PST) In-Reply-To: References: Date: Sun, 14 Feb 2016 15:50:50 +0100 Message-ID: From: Steve Lhomme To: Nithin Mathew Kurien Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Discussion about the current and future development of Matroska , cellar@ietf.org, madshi Subject: Re: [Cellar] [Matroska-devel] Depth offsets for subtitles in case of 3D MVC tracks in MKV files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 14:50:54 -0000 2016-01-26 14:39 GMT+01:00 Nithin Mathew Kurien : > Hi, > > It's like this. Suppose the MVC video track has 8 frames. Also suppose it > has 5 Offset Metadata Sequences embedded in it at the time of encoding. > (Sequence entries are in pixels, positive if in front of the screen, and > negative if behind.) > > Frame 1 2 3 4 5 6 7 8 > Seq1 5 1 -8 -2 -9 1 -3 -1 > Seq2 8 1 0 8 -4 -5 4 -1 > Seq3 -2 8 -3 -5 7 5 -5 -4 > Seq4 9 0 0 -5 -2 1 -4 -1 > Seq5 -9 3 -2 -4 -6 0 -3 6 > > If the M2TS container has 2 subtitle tracks P1, P2 and 1 menu track I1, then > a mapping can be defined in the M2TS container like this: > P1 : Seq1 > P2 : Seq3 > I1 : Seq4 OK, so it seems it's both in the header and in the track (the GOP is part of the stream, I think). > So basically, the sequences are defined in the MVC track and the mapping is > defined in the M2TS container. If this mapping is not defined in the > container, the player would display the subtitle or menu track at the plane > of the screen. Thus the outcome would be as if a sequence whose all entries > are 0, is assigned to the subtitle or menu track. This has been a problem > with the few hardware media players supporting MVC inside MKV, for example > the Mede8er ones (http://www.mede8erforum.com/index.php?topic=9624.0). > > Ideally, a menu track should be displayed in front of the subtitle track, > which should be in front of the video track. This can be done through the > proper definitions of sequences and mappings. The free program > MVCPlanes2OFS.exe from the package BD3D2MK3D > (http://forum.doom9.org/showthread.php?t=170828) can display all Offset > Metadata Sequences embedded in a .MVC file. > > Thanks and regards, > Nithin > > > On Tue, Jan 26, 2016 at 6:46 PM, madshi wrote: >> >> 2016-01-26 13:34 GMT+01:00 Steve Lhomme via Matroska-devel >> : >> > I'm not sure I understand. Is the offset per track or per frame for >> > the subtitle ? If it's per track it should go in the Track Info. If >> > not that means a mechanism to add that information for each frame. >> > Maybe BlockGroup could help. >> >> The 3D Blu-Ray spec says: >> >> > P.9.3.3.6 Offset metadata >> > The offset_metadata() shall be stored in the user data container >> > (defined in 9.16.3.1) which is contained in MVC scalable nesting >> > SEI message of the first view component of each GOP of MPEG-4 >> > MVC Dependent view video stream in decoding order. >> >> I'm not a big expert on these things, but doesn't that mean it's part >> of the MVC video bitstream? In that case there's probably no need to >> store it in separate MKV fields/properties? >> >> Best regards, Mathias. > > -- Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 07:11:21 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9A11ACDCE for ; Sun, 14 Feb 2016 07:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 y6KKB_esn4YI for ; Sun, 14 Feb 2016 07:11:18 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 BA14D1ACDA9 for ; Sun, 14 Feb 2016 07:11:18 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id e185so91093926vkb.1 for ; Sun, 14 Feb 2016 07:11:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Bcj4p0Ef2750SM7HINyeDGa7ybxxcfPSuPdEglZVcTQ=; b=0FVFBeLpowfWxTjskMHKuEpPnKMyB9VBLXU/5NuL8ZeJAXCPdizC8snjoHLYNSYI8g TZH4SCBD7Fxqa6WDacabY4MbWfiN1w1P1Xrl3ewsB8Pf40VBunTiADWAH8PunNlg95Fa n14ohdo525RzR1R1a9DWSeez3cwL5U2YR/rBmEdkHHFd4tXYQxyAK+mXPs4adpXmlFOD 4ltRGMJyrNN6wZfGXE9rGKa6pNb1V8XmT4NDBzOANFkI5om/aiqKNkxnNwONcSC7HVyr 7CEtblutrCScRkmr/M/jC15eU9ZBhV2mJ5AVxcPDeywVM2QovS71ETmE7Fz48c+vDkAw QEmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Bcj4p0Ef2750SM7HINyeDGa7ybxxcfPSuPdEglZVcTQ=; b=e4GZpac24EdWakrvzkV5PPFmewE3RI7W55W4mIYg8kWN8dkeA4tcYR4r9QhuWIvWFE aq4HYU5Q8XUFII7A2CDe+JQdadx6G2oRkVSUbkFQGoibnxtPK8GatTAV/dPu4sXIaLMi T3qAQ4wfHjgmBqE5pD9KPXE59uOTnGrty0d/YfFN9IggOftke9hflpgZdz+alHLnRm5h KPmeRYu5pN5E1HL4XXJWx8jSbdYZv5A9sgdBDu+aRgHXrHnrOxOSThFsO7EVqKZ4LBFP 4G7YIpw6ybibZab4xHii05GSx3LXxgFrTL48DaBA9yEX/1G96CyUaRJF41pS+BEZ7Gxb zjNg== X-Gm-Message-State: AG10YOQywFyJcgybHCG8vgsaPjtwOARJiVrv23yWJAyNgwQP96eHH4m6rdYwuvy3EAI484t0QiyEIrk70I5Hag== MIME-Version: 1.0 X-Received: by 10.31.160.6 with SMTP id j6mr9899925vke.87.1455462677820; Sun, 14 Feb 2016 07:11:17 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 07:11:17 -0800 (PST) In-Reply-To: <0A176C1B-19D5-4579-8447-4A5075B8D94B@dericed.com> References: <0A176C1B-19D5-4579-8447-4A5075B8D94B@dericed.com> Date: Sun, 14 Feb 2016 16:11:17 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Moritz Bunkus , cellar@ietf.org Subject: Re: [Cellar] EBML Security Considerations section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 15:11:20 -0000 2016-02-13 22:04 GMT+01:00 Dave Rice : > Here is a draft Security Considerations section for the EBML spec. The se= ction is based off Moritz=E2=80=99s comment here https://github.com/Matrosk= a-Org/ebml-specification/issues/6#issuecomment-99937237 with some minor re-= wording. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > ## Security Considerations > > EBML itself does not offer any kind of security. It has nothing to do wit= h authentication, it dose not provide confidentiality, only marginally usef= ul and effective data integrity options (CRC elements). > > EBML does not provide any kind of authorization. > > Even if the semantic layer offers and kind of encryption EBML itself leak= s information, at the least the sematic layer used via the DocType element,= but also certain information about the structure from the elements (you ca= n derive the presence of EBML elements even with an unknown semantic layer = with a heuristic approach; not without errors, of course, but with a certai= n degree of confidence). > > Attacks on an EBML reader may include: > - Invalid Element IDs that are longer than the limit stated in the EBMLMa= xIDLength Element of the EBML Header. It could also be an invalid size, like 13 for floats. > - Invalid Element IDs that not encoded in the shortest-possible way. Missing *is* > - Invalid Element Ids comprised of reserved values. > - Invalid Element Data Size values that are longer than the limit stated = in the EBMLMaxSizeLength Element of the EBML Header. > - Invalid Element Data Size values (e.g. extending the length of the Elem= ent beyond the scope of the Parent Element; possibly triggering access-out-= of-bounds issues). > - Very high lengths in order to force out-of-memory situations resulting = in a denial of service, access-out-of-bounds issues etc. > - Missing Elements that are mandatory and have no declared default value. > - Usage of 0x00 octets in EBML Elements with a string type. > - Usage of invalid UTF-8 encoding in EBML Elements of UTF-8 type (e.g. in= order to trigger acces-out-of-bounds or buffer overflow issues). > - Usage of invalid data in EBML Elements with a date type. > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Of the points, I don=E2=80=99t quite understand a few.. > > Originally Moritz wrote: >> Usage of \0 characters in EbmlString elements > I changed it to >> - Usage of 0x00 octets in EBML Elements with a string type. > but the string elements are allowed to be terminated with one or many 0x0= 0 octets. What is an example of a null terminated EBML string that is a sec= urity consideration. > > Regarding: >> - Usage of invalid data in EBML Elements with a date type. > > > Any 0 or 8 octet date value is valid, right? Other lengths are already in= valid for date elements, so is this necessary to include? > > A PR of the draft Security Considerations section is here: https://github= .com/Matroska-Org/ebml-specification/pull/54. > > Dave Rice > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 07:26:28 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D909E1A92B7 for ; Sun, 14 Feb 2016 07:26:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 JikmQ1h9LTRF for ; Sun, 14 Feb 2016 07:26:25 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9B91A92A9 for ; Sun, 14 Feb 2016 07:26:25 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id k196so91572462vka.0 for ; Sun, 14 Feb 2016 07:26:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nijBb2V3bwL7EalqYkmbkkKHOV/0x0u5my0ZydO1dEs=; b=YCfCVW0xtGOOkQXAtzmop6Q5r5v4fV2mtjupJw0WZ3/oy+ZUw8etCIiYTxD6eKb8X9 c747WGkpAOJVP88M2uj4lIonqiYlkMTQuolvZLISgagYjD2gtO14IKF4HpURbe0iFDI0 IQX7DQFKpayHYZUHBVH+Lm8QX4TLtKv3bcJJlF6gfJ57JvOq8VBcMza2pPqfffduAUxC ypJb8sMNGcSH7NDWwDesn3OgxE+dpx1fP1oSk4mfBKjBn23a7ffRqEDY6u+3cnUHWkmq JQH5TTaVle3uEJ6T/lnBy/b0m8B05jQ5Io+OGbdf4z2UJnxgsQ8RaUh9n07B3mkThJa8 4JsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=nijBb2V3bwL7EalqYkmbkkKHOV/0x0u5my0ZydO1dEs=; b=d5bEaIuMAyilUvCZKBU8d/E67jFVPI8U8quLnponPD/1acxPD41jPMpXO5mKP0rii2 yPhbItscIJjyFPKdiy4TZr6DjdyOZPNwuiRp1QbPCW7lkKJ5y5Do8SPcpeCuwd2CsvKt /GJonGvnOLl+V5Z10rHSDiT0P0pGAA5E/0WRn2ezpcADD4EYMbU6kAaNSLXsraK06lQI LHBL4C4MEoGLw/wkJHaCL4hTmogK0Hyda+ttLPEG+nmjaKjtAjc8gMQep/YM6EZH9gQs BuqZxAI9Dag+3Li2rMlKZshu941bYLToGvf0rypRXiSg5UbTUwVuMtz8LI2HICaZ0KD3 mKBw== X-Gm-Message-State: AG10YOTCN9nfYPqBxuZ14aRyO23QfW6PS1Mq2O6DF21gWUexuVxTudFrDVGUSwVVfSn5ysx0prWe1VQNb4k1qw== MIME-Version: 1.0 X-Received: by 10.31.135.79 with SMTP id j76mr8565419vkd.91.1455463584512; Sun, 14 Feb 2016 07:26:24 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 07:26:24 -0800 (PST) In-Reply-To: <74651E49-02F2-4BFF-9B91-0C78A169DD5B@dericed.com> References: <74651E49-02F2-4BFF-9B91-0C78A169DD5B@dericed.com> Date: Sun, 14 Feb 2016 16:26:24 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] adding unknownsizeallowed attribute for EBML definitions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 15:26:27 -0000 2016-02-13 22:36 GMT+01:00 Dave Rice : > Current the EBML spec implies that any Master-element may use an unknown = Element Data Size and may contain data that is not part of an EBML Element.= I propose that this should be constrained in EBML Element definitions. > > I drafted another attribute for EBML Element definitions called unknownsi= zeallowed (better names welcome). > > The proposed attribute is not required and I drafted this definition: >> A boolean to express if an EBML Element MAY use an Element Data Size tha= t is Unknown (having all VINT\_DATA bits set to 1). The `unknownsizeallowed= ` attribute MAY only be applied to Master-elements. If the `unknownsizeallo= wed` attribute is not used it is assumed that the element not allowed to us= e an unknown Element Data Size. > > With the added definition, I also changed a sentence in the definition of= the Master-element Data Type from: >> When EBML is used in transmission or streaming, data that is not part of= an EBML Element is permitted to be present within a Master-element. > > to >> When EBML is used in transmission or streaming, data that is not part of= an EBML Element is permitted to be present within a Master-element if `unk= nownsizeallowed` is enabled within that Master-element's definition. > > The adjustment presumes that non-EBML junk data is only permitted in Mast= er-elements with unknown size. Possibly these two qualities could be separa= ted but I can=E2=80=99t really see a reason to have a Master-element with a= known size also contain junk data. > > A draft PR is here: https://github.com/Matroska-Org/ebml-specification/pu= ll/55 > > Comments? >From the Matrosk point of view, I don't see exactly where this would be used, or only to restrict the feature to certain elements. But it seems more like a profile (live streaming or not) rather that something to set for all Matroska files. For example an archive should never allow such unknown sizes. This is bad for error recovery. So should we define 2 versions of the specs ? Or profiles that allow variations on the values? Such elements would be marked in the specs with possible/allowed variations. I understand that some other EBML derivatives may have the use for the feature only on specific elements and never some others. > Also if using this, we=E2=80=99ll have to clarify which Matroska/webm ele= ments would use this? I suspect it=E2=80=99s a small percentage of the Mast= er-elements declared for those document types. In practice only The Segments and (some) level-1 elements that can't be held in memory or need low latency transmission. > Dave Rice > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 07:33:25 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A3E81A009F for ; Sun, 14 Feb 2016 07:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 UJUypnpgWqtr for ; Sun, 14 Feb 2016 07:33:21 -0800 (PST) Received: from mail-vk0-x242.google.com (mail-vk0-x242.google.com [IPv6:2607:f8b0:400c:c05::242]) (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 A7DAB1A009E for ; Sun, 14 Feb 2016 07:33:21 -0800 (PST) Received: by mail-vk0-x242.google.com with SMTP id k196so6817420vka.3 for ; Sun, 14 Feb 2016 07:33:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=upoRp5/B2RFGJAzrv/6c6Hf7NmtcGG6Quj8Vy8UF4Fs=; b=2TGPlSfc2UGBwHDMRENO2T9ZfnMWSu0vvHD2geEp5gh8nhwdYqjKZQFRef7Y7wvAhJ ACN7bmzEdYgiP2TxTmzHtJDfsKh0U8lEJ29BCrdE1t4eNNr34Roz9lpUvS8/pqyovjx8 K/OHmalaSmEyAFqW1+oMcsSLrPzxZIeX9psP0upqqpvxTQgctlkmQBJXLN97MtxNAhYo 6x+2d5B8Ql4qNrK470glBmVr8+vI3X+58XueDsDCtiCDlZ1mT/gweKC15ShZeE1KO8Jl TI/uNcmlr0RRpzZx9OtzAdJTTQlrR0JMvbS0hCb6tOY3Wj4ZrtCBiydVsTbR1HiqKQhf KqIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=upoRp5/B2RFGJAzrv/6c6Hf7NmtcGG6Quj8Vy8UF4Fs=; b=X0eI3Hf5Nf6USHB98x6G4V8CC6qd1CIyAXNztaWC94eJnbaxoxM11M500/tS5L8hcw 5JYKebBFVXEZF4gYomigbOg6YGJC8LaZl50f9YobMLiJ14OmWnUjMitOSsi0EeSUiBR+ h9f8xnoxC9I8P7Zct9GAZfFyFoZIXWa16GUNsVEWY3oSMSX/5QSni7EXoCwG++Ugi7OC Evpw352lQTjjZcqO3nPg6F7/8VmkCKtQUMk43tx6eA7AB8jkkEufCSd13GdaVkUjDXy3 GPziDu39O/F4reyNTaLWLxWx2N3YtDcBn01oBk8PwWcl38/pg5tgAeS9fIOZXjVdmvL9 mCYw== X-Gm-Message-State: AG10YOTOCvcDsG2Pmfw+dPUsGuY625rm5WxqdbsCjfbYJDXWJ/ZRAsDdx+991XDKkOcIHx3/tpP5lsPocdk7RQ== MIME-Version: 1.0 X-Received: by 10.31.41.86 with SMTP id p83mr9614407vkp.157.1455464000785; Sun, 14 Feb 2016 07:33:20 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 07:33:20 -0800 (PST) In-Reply-To: <6C67F2DE-5F7F-4D67-8FF9-69CAFB25E769@dericed.com> References: <20150702175013.3f2e8427@miuna> <6C67F2DE-5F7F-4D67-8FF9-69CAFB25E769@dericed.com> Date: Sun, 14 Feb 2016 16:33:20 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Fwd: [Matroska-devel] EBML data type constraints X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 15:33:23 -0000 2016-02-13 22:09 GMT+01:00 Dave Rice : > Hi all, > Working on the Security Considerations section reminded me that there=E2= =80=99s some > open discussion about the use of null bytes as terminators in UTF-8 and > String elements. This is an extract from Matroska-devel last year: > > Begin forwarded message: > > From: wm4 > Subject: Re: [Matroska-devel] EBML data type constraints > Date: July 2, 2015 at 11:50:13 AM EDT > To: matroska-devel@lists.matroska.org > Reply-To: Discussion about the current and future development of Matroska > > > On Thu, 02 Jul 2015 17:26:07 +0200 > Jerome Martinez wrote: > > Le 02/07/2015 16:21, wm4 a =C3=A9crit : > > On the other hand, allowing zero-padded strings will cause weirdness > with other languages which do byte strings, and where a zero byte > won't automatically terminate a string. IMHO this stupid detail should > just be disallowed (or deprecated). > > > In that case, I propose: > > String - Printable ASCII (0x20 to 0x7E) > Muxers MUST NOT append any NULL byte > Demuxers SHOULD accept NULL padding when present and consider such bytes > as non existent. > > UTF-8 - Printable Unicode string (Unicode character value >=3D0x20) > conforming to RFC 2279 > Muxers MUST NOT append any NULL byte > Demuxers SHOULD accept NULL padding when present and consider such bytes > as non existent. > > > +1 > > (This wording doesn't specify what happens if there are null bytes in > the middle of the string, with trailing non-null bytes - should be > refined.) > > > The present wording for string and UTF-8 Element Types is: > > A String Element may either be empty (zero-length) or contain Printable > ASCII characters in the range of 0x20 to 0x7E. Octets with all bits set t= o > zero may follow the string value when needed. > > and > > A UTF-8 Element shall contain only a valid Unicode string as defined in [= RFC > 2279](http://www.faqs.org/rfcs/rfc2279.html). Octets with all bits set to > zero may follow the UTF-8 value when needed. > > > Is the current wording sufficient or should there be further constraints = or > explanation? Same remark as above, it doesn't take in consideration if there's data after the first 0x00. Any data after the first 0x00 should be discarded. This kinda sucks for languages that don't use NULL terminators. They have to parse every single strings from the back (and possibly never ever finding NULL). It would be easier to assume that if the last octet is not 0x00 then there's no 0x00 elsewhere in the string. Since EBML has the ability to void elements, I'd rather not keep the NULL termination at all. Not sure what are the implications with real world files. > Dave Rice > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 08:05:55 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8C51ACE6E for ; Sun, 14 Feb 2016 08:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 6iJZ68uvuc3P for ; Sun, 14 Feb 2016 08:05:51 -0800 (PST) Received: from 13.mo4.mail-out.ovh.net (13.mo4.mail-out.ovh.net [178.33.251.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 766C21AD09A for ; Sun, 14 Feb 2016 08:05:51 -0800 (PST) Received: from mail693.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo4.mail-out.ovh.net (Postfix) with SMTP id 7F424106C094 for ; Sun, 14 Feb 2016 17:05:44 +0100 (CET) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 14 Feb 2016 18:05:44 +0200 Received: from p5ddb6320.dip0.t-ipconnect.de (HELO ?192.168.2.101?) (jerome@francoallemand.eu@93.219.99.32) by ns0.ovh.net with SMTP; 14 Feb 2016 18:05:43 +0200 References: <20150702175013.3f2e8427@miuna> <6C67F2DE-5F7F-4D67-8FF9-69CAFB25E769@dericed.com> To: cellar@ietf.org From: Jerome Martinez Message-ID: <56C0A5C9.6090707@mediaarea.net> Date: Sun, 14 Feb 2016 17:05:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 11950020137296531602 X-Ovh-Remote: 93.219.99.32 (p5ddb6320.dip0.t-ipconnect.de) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrfeelucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrfeelgdekvdcutefuodetggdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] Fwd: [Matroska-devel] EBML data type constraints X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 16:05:53 -0000 On 14/02/2016 16:33, Steve Lhomme wrote: > [...] > Same remark as above, it doesn't take in consideration if there's data > after the first 0x00. Any data after the first 0x00 should be > discarded. This kinda sucks for languages that don't use NULL > terminators. as C++ std::string. > They have to parse every single strings from the back > (and possibly never ever finding NULL). It would be easier to assume > that if the last octet is not 0x00 then there's no 0x00 elsewhere in > the string. And what a demuxer must do if there are actually 0x00 in the string? From my understanding of RFC 2279 "Character values from 0000 0000 to 0000 007F (US-ASCII repertoire) correspond to octets 00 to 7F (7 bit US-ASCII values)." 0x00 is a valid UTF-8 character (as well as all in the range 0x00-0x1F, forbidden by the current EBML proposal) so 0x00410041 is a valid UTF-8 (or ASCII) string. > > Since EBML has the ability to void elements, Except for 1-byte padding. > I'd rather not keep the > NULL termination at all. Not sure what are the implications with real > world files. Currently I don't understand the reason we could not use 0x00 as padding if it is forbidden in the string. I see 2 policies: 1/ 0x00-0x1F are forbidden as real content (we restrict ASCII and UTF-8) I don't see a reason muxers must not write 0x00 if demuxers should accept 0x00 as padding. It does not hurt. 2/ We do no restrictions and take ASCII and UTF-8 as is (full range) We consider 0x00 as a character like any other character and it is the role of the software to deal with non printable characters. I have a preference on no restriction when using other standards because I consider it is not the role of the container to forbid characters, but this preference is not strong. if we keep invalid 0x00-0x1F, I would change the wording for ASCII and UTF-8 string: Muxers MUST NOT put invalid bytes sequences in UTF-8 (for UTF-8 part only) Muxers MUST NOT put characters in the range 0x00-0x1F Demuxers SHOULD accept characters in the range 0x00-0x1F and invalid invalid bytes sequences, and consider such bytes as non existent. Note about : > (This wording doesn't specify what happens if there are null bytes in > the middle of the string, with trailing non-null bytes - should be > refined.) If we talk about "Demuxers SHOULD accept NULL padding when present and consider such bytes as non existent.", it does ("padding" does not mean that it is at the end of the string). Jérôme From nobody Sun Feb 14 08:16:32 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD391AD35A for ; Sun, 14 Feb 2016 08:16:30 -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 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 m3vMHoYb7d18 for ; Sun, 14 Feb 2016 08:16:29 -0800 (PST) Received: from 10.mo4.mail-out.ovh.net (10.mo4.mail-out.ovh.net [188.165.33.109]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A9121AD355 for ; Sun, 14 Feb 2016 08:16:27 -0800 (PST) Received: from mail693.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo4.mail-out.ovh.net (Postfix) with SMTP id 921A31018019 for ; Sun, 14 Feb 2016 17:16:25 +0100 (CET) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 14 Feb 2016 18:16:25 +0200 Received: from p5ddb6320.dip0.t-ipconnect.de (HELO ?192.168.2.101?) (jerome@francoallemand.eu@93.219.99.32) by ns0.ovh.net with SMTP; 14 Feb 2016 18:16:24 +0200 To: cellar@ietf.org References: <20150702175013.3f2e8427@miuna> <6C67F2DE-5F7F-4D67-8FF9-69CAFB25E769@dericed.com> From: Jerome Martinez Message-ID: <56C0A84A.6080908@mediaarea.net> Date: Sun, 14 Feb 2016 17:16:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <6C67F2DE-5F7F-4D67-8FF9-69CAFB25E769@dericed.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 12130445598141386898 X-Ovh-Remote: 93.219.99.32 (p5ddb6320.dip0.t-ipconnect.de) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrfeelucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrfeelgdekhecutefuodetggdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] Fwd: [Matroska-devel] EBML data type constraints X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 16:16:30 -0000 On 13/02/2016 22:09, Dave Rice wrote: >>> >>> String - Printable ASCII (0x20 to 0x7E) >>> >>> [...] >>> >>> UTF-8 - Printable Unicode string (Unicode character value >=0x20) > BTW, how should be filled a tag string with a content having line feeds (thinking to e.g. a summary of the content in the file, some summaries have several paragraphs)? On the Matroska website, UTF-8 string has no "Unicode character value >=0x20" restriction, I am afraid that we make a lot of files invalid. Maybe ">0x00"? Jérôme From nobody Sun Feb 14 08:23:14 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9B31B29A6 for ; Sun, 14 Feb 2016 08:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.745 X-Spam-Level: *** X-Spam-Status: No, score=3.745 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FF_IHOPE_YOU_SINK=2.166, SPF_NEUTRAL=0.779] autolearn=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 VNDHpvTk2qDv for ; Sun, 14 Feb 2016 08:23:10 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0DB11B29A3 for ; Sun, 14 Feb 2016 08:23:10 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:45271 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aUzS0-0031iD-2E; Sun, 14 Feb 2016 11:23:10 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Sun, 14 Feb 2016 11:23:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0A176C1B-19D5-4579-8447-4A5075B8D94B@dericed.com> To: Steve Lhomme X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org, Moritz Bunkus Subject: Re: [Cellar] EBML Security Considerations section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 16:23:12 -0000 > On Feb 14, 2016, at 10:11 AM, Steve Lhomme = wrote: >=20 > 2016-02-13 22:04 GMT+01:00 Dave Rice : >> Here is a draft Security Considerations section for the EBML spec. = The section is based off Moritz=E2=80=99s comment here = https://github.com/Matroska-Org/ebml-specification/issues/6#issuecomment-9= 9937237 with some minor re-wording. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> ## Security Considerations >>=20 >> EBML itself does not offer any kind of security. It has nothing to do = with authentication, it dose not provide confidentiality, only = marginally useful and effective data integrity options (CRC elements). >>=20 >> EBML does not provide any kind of authorization. >>=20 >> Even if the semantic layer offers and kind of encryption EBML itself = leaks information, at the least the sematic layer used via the DocType = element, but also certain information about the structure from the = elements (you can derive the presence of EBML elements even with an = unknown semantic layer with a heuristic approach; not without errors, of = course, but with a certain degree of confidence). >>=20 >> Attacks on an EBML reader may include: >> - Invalid Element IDs that are longer than the limit stated in the = EBMLMaxIDLength Element of the EBML Header. >=20 > It could also be an invalid size, like 13 for floats. Not sure I understand. The Element Data Size is only expressed in VINT = and the Floats of EBML are only within Elements defined as float. For = instance is Matroska;Duration is expressed as a float value of 13, it is = invalid, but is this a security issue? >> - Invalid Element IDs that not encoded in the shortest-possible way. >=20 > Missing *is* Fixed locally. >> - Invalid Element Ids comprised of reserved values. >> - Invalid Element Data Size values that are longer than the limit = stated in the EBMLMaxSizeLength Element of the EBML Header. >> - Invalid Element Data Size values (e.g. extending the length of the = Element beyond the scope of the Parent Element; possibly triggering = access-out-of-bounds issues). >> - Very high lengths in order to force out-of-memory situations = resulting in a denial of service, access-out-of-bounds issues etc. >> - Missing Elements that are mandatory and have no declared default = value. >> - Usage of 0x00 octets in EBML Elements with a string type. >> - Usage of invalid UTF-8 encoding in EBML Elements of UTF-8 type = (e.g. in order to trigger acces-out-of-bounds or buffer overflow = issues). >> - Usage of invalid data in EBML Elements with a date type. >>=20 >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Of the points, I don=E2=80=99t quite understand a few.. >>=20 >> Originally Moritz wrote: >>> Usage of \0 characters in EbmlString elements >> I changed it to >>> - Usage of 0x00 octets in EBML Elements with a string type. >> but the string elements are allowed to be terminated with one or many = 0x00 octets. What is an example of a null terminated EBML string that is = a security consideration. >>=20 >> Regarding: >>> - Usage of invalid data in EBML Elements with a date type. >>=20 >>=20 >> Any 0 or 8 octet date value is valid, right? Other lengths are = already invalid for date elements, so is this necessary to include? >>=20 >> A PR of the draft Security Considerations section is here: = https://github.com/Matroska-Org/ebml-specification/pull/54. >>=20 >> Dave Rice >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Sun Feb 14 08:25:26 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7327A1B29BC for ; Sun, 14 Feb 2016 08:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 5sYyZQNP41Pb for ; Sun, 14 Feb 2016 08:25:23 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B35411B29BB for ; Sun, 14 Feb 2016 08:25:23 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id k196so92117438vka.0 for ; Sun, 14 Feb 2016 08:25:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=BOUAe/I7SlONnGO9kLKBWVVapFQRPjEhFrlDZ3bvae8=; b=lC0xkrtJXZkvu8F+IWRlo8iycpK5hnFHK6s7DFcm9mAbaGs3iVXBFyVO/rJREOcZJJ Z9RzMakYR5TQvX2WC6+hiyqHFM52q/Hrh+JG7iF6XzI62aBDQ1sCnxNqHa9Npvjzr0l0 Sqjn75+2gDoFCIvGOqOwhN9Uk2dtG3mhAE3QrjX+weqIKcphbAtuDRz0YrXlsnn2Wsdy nENLxzV3D7EKkgStGSdAq8r753cjxFq6Ibccy1jfL14ClE6JmrCxqBbBZlYfrfCfadJM dk5ufviUy6xbQp1hxyqK4Sv4T/QGLMbTRAR4rnJ4K6KJZr5f17Od0ByRTHfqVnpfnkuW gRHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BOUAe/I7SlONnGO9kLKBWVVapFQRPjEhFrlDZ3bvae8=; b=bGz50EqIC9mVGW/FEXxnsHAsqNXXOJfIBAyomomcGA0dhKK1O2pj3i1uEGtxYUcq+3 7dnStBgJhL0/byJSmxpN23l1g3kamDuDqFEKU3UuQVQ4jNWzukx2kyIlfc3kkXpJ+2gY cjdK06oAV1dCSee+9PWEWRlHjHO23/bB1TjtKsJeX6zQeWd/Rb/r8Ljv+AjASDqxZA1H Y3xYRi4a+08p8YghOh6PIXAH6D0kdHKjCe7xl/RpHSKiIS/6hzAtltT/jr5Huniv4rJQ NU3AaBbld21hMBHyf0TR5MasTntlWJHJnzAI6zoYGX/bROaooYBJ6hOSX1JZ9GAmpLW1 pabw== X-Gm-Message-State: AG10YORTz4j+4mU6asxSFqqZKyMROwnQk5SE0KSIxYtwIX/5MRsobKXVisLTtZpx1rq7hN4v4sL0Qv3qKqQJkQ== MIME-Version: 1.0 X-Received: by 10.31.168.76 with SMTP id r73mr9824542vke.117.1455467122812; Sun, 14 Feb 2016 08:25:22 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 08:25:22 -0800 (PST) In-Reply-To: <56C0A5C9.6090707@mediaarea.net> References: <20150702175013.3f2e8427@miuna> <6C67F2DE-5F7F-4D67-8FF9-69CAFB25E769@dericed.com> <56C0A5C9.6090707@mediaarea.net> Date: Sun, 14 Feb 2016 17:25:22 +0100 Message-ID: From: Steve Lhomme To: Jerome Martinez Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Fwd: [Matroska-devel] EBML data type constraints X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 16:25:25 -0000 2016-02-14 17:05 GMT+01:00 Jerome Martinez : > On 14/02/2016 16:33, Steve Lhomme wrote: >> >> [...] >> Same remark as above, it doesn't take in consideration if there's data >> after the first 0x00. Any data after the first 0x00 should be >> discarded. This kinda sucks for languages that don't use NULL >> terminators. > > > as C++ std::string. > >> They have to parse every single strings from the back >> (and possibly never ever finding NULL). It would be easier to assume >> that if the last octet is not 0x00 then there's no 0x00 elsewhere in >> the string. > > > And what a demuxer must do if there are actually 0x00 in the string? Not use it. > From my understanding of RFC 2279 > "Character values from 0000 0000 to 0000 007F (US-ASCII repertoire) > correspond to octets 00 to 7F (7 bit US-ASCII values)." > 0x00 is a valid UTF-8 character (as well as all in the range 0x00-0x1F, > forbidden by the current EBML proposal) > so 0x00410041 is a valid UTF-8 (or ASCII) string. Uh! It could also be the last octect of a multi-octet value. So indeed, parsing from the back is not even a clean solution. I'd rather avoid NULL padding if possible. Dave can you run a test on the archive files you use to see if that ever happens ? I don't think I've actually wrote such padding in my own code. Reading is automatic 'cause it can always in C or C++. >> >> Since EBML has the ability to void elements, > > > Except for 1-byte padding. Correct. That is an issue when editing tags. When removing just one char in a string it's not possible to write to void the remaining space. What is possible is to add an octet to the length of the element. If it's maxed out then removing one octet could be an option. If it's maxed out because it needs all 4 octets for the size, then it's not possible. But a string of 2^28 size should not ever happen. >> I'd rather not keep the >> NULL termination at all. Not sure what are the implications with real >> world files. > > > Currently I don't understand the reason we could not use 0x00 as padding = if > it is forbidden in the string. > I see 2 policies: > > 1/ 0x00-0x1F are forbidden as real content (we restrict ASCII and UTF-8) > I don't see a reason muxers must not write 0x00 if demuxers should accept > 0x00 as padding. It does not hurt. > > 2/ We do no restrictions and take ASCII and UTF-8 as is (full range) > We consider 0x00 as a character like any other character and it is the ro= le > of the software to deal with non printable characters. > > I have a preference on no restriction when using other standards because = I > consider it is not the role of the container to forbid characters, but th= is > preference is not strong. I think we should stick to what UTF-8 says. Forcing constraints on another standard, another piece of code just for the container is not a good idea IMO. > if we keep invalid 0x00-0x1F, I would change the wording for ASCII and UT= F-8 > string: > Muxers MUST NOT put invalid bytes sequences in UTF-8 (for UTF-8 part only= ) > Muxers MUST NOT put characters in the range 0x00-0x1F > Demuxers SHOULD accept characters in the range 0x00-0x1F and invalid inva= lid > bytes sequences, and consider such bytes as non existent. > > > > Note about : > >> (This wording doesn't specify what happens if there are null bytes in >> the middle of the string, with trailing non-null bytes - should be >> refined.) > > > If we talk about "Demuxers SHOULD accept NULL padding when present and > consider such bytes as non existent.", it does ("padding" does not mean t= hat > it is at the end of the string). > > J=C3=A9r=C3=B4me > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 08:27:11 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB9301A90F9 for ; Sun, 14 Feb 2016 08:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 oSp4t4yFMOYD for ; Sun, 14 Feb 2016 08:27:09 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B2171A90F7 for ; Sun, 14 Feb 2016 08:27:09 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id e185so91783939vkb.1 for ; Sun, 14 Feb 2016 08:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Acufr2sbKOHxOtdo0omt2FIP2QjyTeNN6/vr0gf7Hqo=; b=r97CRVXFg/KoqkuI1sODkGlbUUm30jxO6GhR5qtwSVjWHibpDcz1jzs3n7I+XLegrp ObBxMYzjiWVSQmO0U2IfN5nv+aOYkybTDPXxSZ98mxb5PFNBDguuaoH4doJSFwmOEcDy 9v9oCB6I3eEzsxPHqhtxb8136yoZ6CMtMoCVn0VF+5+HpPJZhB28PxFnS96LT97+vyAI NPKZ43ixMzcY517IsbeNeCZSec3lBRuD/i6I8xra4nZvxeZKQ1saCmRTOmC1nxgZTJZ6 tJYLsYfo+Z1G1ZA4CThfiPHngPunkI80Nkh5YSiD4RWSpNqZdGqCCBbFXzOwOijMELOm H3dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Acufr2sbKOHxOtdo0omt2FIP2QjyTeNN6/vr0gf7Hqo=; b=eWAnFS7cZjhRRzfLRetfJcsUutHeH7h4p24/0GRBlpH7xhNc6em1XTuxq4lwshsI1N vctSMzW1vv9QVai/wOxTSMCdBL216cfVHdwrQrP/6AYnDOGTrEcpRhxT9Z9UmbNe99mi 13eIufr+c186Z+ZmzXFzXaNaxN4kGOcZ7K4yRFexLi1cYzALJdcm4XKXT5NXy84gV33c pDVrCd99r/j/HI08k10fdbXLbfqEwmxIdXxApmPkT+wglPb00KISwO2Htt+Gr1EG4FSn vyeWepgpTBb79lQ3MjqlVhA2oSsYzWEcltYYQOJ7eXG3Wt9a36W5mWXAY520aZdAik5R OpkA== X-Gm-Message-State: AG10YOS4T+vOmFfxSUKh+3KMUUo3J9Gzod/n/sre/8lrWSqPz3eZpEGGPCoi7uxqHsPRDo4NY/ipi62vi8Bn3g== MIME-Version: 1.0 X-Received: by 10.31.160.6 with SMTP id j6mr10127882vke.87.1455467228678; Sun, 14 Feb 2016 08:27:08 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 08:27:08 -0800 (PST) In-Reply-To: <56C0A84A.6080908@mediaarea.net> References: <20150702175013.3f2e8427@miuna> <6C67F2DE-5F7F-4D67-8FF9-69CAFB25E769@dericed.com> <56C0A84A.6080908@mediaarea.net> Date: Sun, 14 Feb 2016 17:27:08 +0100 Message-ID: From: Steve Lhomme To: Jerome Martinez Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Fwd: [Matroska-devel] EBML data type constraints X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 16:27:10 -0000 2016-02-14 17:16 GMT+01:00 Jerome Martinez : > On 13/02/2016 22:09, Dave Rice wrote: >>>> >>>> >>>> String - Printable ASCII (0x20 to 0x7E) >>>> >>>> [...] >>>> >>>> UTF-8 - Printable Unicode string (Unicode character value >=3D0x20) >> >> > > BTW, how should be filled a tag string with a content having line feeds > (thinking to e.g. a summary of the content in the file, some summaries ha= ve > several paragraphs)? > > On the Matroska website, UTF-8 string has no "Unicode character value >>=3D0x20" restriction, I am afraid that we make a lot of files invalid. Ma= ybe > ">0x00"? I agree, line feeds are perfectly fine. I suppose the "non-printable" chars should be fine. Even 0x00 is sometimes represented with a [NUL] character in some fonts. > > J=C3=A9r=C3=B4me > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 08:29:55 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E2D1B29CE for ; Sun, 14 Feb 2016 08:29:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.888 X-Spam-Level: X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622] autolearn=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 mexYWiajRcjc for ; Sun, 14 Feb 2016 08:29:52 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F7D81B29CC for ; Sun, 14 Feb 2016 08:29:52 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id c3so91714882vkb.3 for ; Sun, 14 Feb 2016 08:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=/LA3968Qv36sEea29u4nDKVj4eqjahD3fTiWUa+5+Zs=; b=msdIXGaphs4MfH2LFSgk0C3XdhGbo8lOay1hAJqRYFUwH5FVTlX+l6oHhpHz5LxIT4 nBEgvpdmWxZ8ZYYlTLR5lUYa1RH268aYYqTre1NS/CJl0UsVIZ3V1HzarOR8D/iSACvp HylwxfgQXZoHRgoKmntoEkf+noS1d+IC9CscOTj1eGo3WLIi0Xs6Io78MDL6OaT6kWbn 6aaf1ncy8ccF7VSwwXXybmj/XG8t3LEXKAycbs35CBByOdKiRGJW7J4b/t07flOnWTk3 7ZLhgu58pqlAKBwXav8eJ+G/dMKYBgIPvVcMP1RObd+fCKERBFQ1jsF6ef/2Td25IjhP cyng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/LA3968Qv36sEea29u4nDKVj4eqjahD3fTiWUa+5+Zs=; b=m8uV3yfYG3HN5JnbNPWv/k3EZdOMiktBNwk25+JHd0OAn17POMs9HsjYdtupEf09vO UsvpHhOvNWYhjO0QwG0zqn66gRzyyDSA9ZDAeQLTNWZcZjqIQ/YL4QLgrhnVQYtbIwW5 DMMjCSr4bTYZGW86M/LNuYpwjEzBJUrEWnMD+PufQ7eu6tvM1SGaYMKjZjWFbXfogyS6 YzDTyw5L8qLCZ+/IHrjLhRnFnYwu9TKwVLFg3Uz2ibRjrPd49Qd5CzYje2e2lctcmEM5 BYUOPgbKR0yBH22nLiltdIoGrfZ0+U7dzz9opFmYHqbqfY+/fTQnkcNWakhaKrQjYs6+ G2lw== X-Gm-Message-State: AG10YOSVtGW18A04OQY1VpaDb6tnEc1MD+UKiSSFNeEWSY550/0rR2BBLwLZosHkNSVsPADIiJWXebxHzNylBw== MIME-Version: 1.0 X-Received: by 10.31.41.86 with SMTP id p83mr9784003vkp.157.1455467391763; Sun, 14 Feb 2016 08:29:51 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 08:29:51 -0800 (PST) In-Reply-To: References: <0A176C1B-19D5-4579-8447-4A5075B8D94B@dericed.com> Date: Sun, 14 Feb 2016 17:29:51 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org, Moritz Bunkus Subject: Re: [Cellar] EBML Security Considerations section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 16:29:54 -0000 2016-02-14 17:23 GMT+01:00 Dave Rice : > >> On Feb 14, 2016, at 10:11 AM, Steve Lhomme wrote: >> >> 2016-02-13 22:04 GMT+01:00 Dave Rice : >>> Here is a draft Security Considerations section for the EBML spec. The = section is based off Moritz=E2=80=99s comment here https://github.com/Matro= ska-Org/ebml-specification/issues/6#issuecomment-99937237 with some minor r= e-wording. >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> ## Security Considerations >>> >>> EBML itself does not offer any kind of security. It has nothing to do w= ith authentication, it dose not provide confidentiality, only marginally us= eful and effective data integrity options (CRC elements). >>> >>> EBML does not provide any kind of authorization. >>> >>> Even if the semantic layer offers and kind of encryption EBML itself le= aks information, at the least the sematic layer used via the DocType elemen= t, but also certain information about the structure from the elements (you = can derive the presence of EBML elements even with an unknown semantic laye= r with a heuristic approach; not without errors, of course, but with a cert= ain degree of confidence). >>> >>> Attacks on an EBML reader may include: >>> - Invalid Element IDs that are longer than the limit stated in the EBML= MaxIDLength Element of the EBML Header. >> >> It could also be an invalid size, like 13 for floats. > > Not sure I understand. The Element Data Size is only expressed in VINT an= d the Floats of EBML are only within Elements defined as float. For instanc= e is Matroska;Duration is expressed as a float value of 13, it is invalid, = but is this a security issue? My bad. That comment was for the Element Size, not the Element ID. >>> - Invalid Element IDs that not encoded in the shortest-possible way. >> >> Missing *is* > > Fixed locally. > >>> - Invalid Element Ids comprised of reserved values. >>> - Invalid Element Data Size values that are longer than the limit state= d in the EBMLMaxSizeLength Element of the EBML Header. >>> - Invalid Element Data Size values (e.g. extending the length of the El= ement beyond the scope of the Parent Element; possibly triggering access-ou= t-of-bounds issues). As said above. For elements with only a set of bounds you may not extend the size. For example one could write a float of size 1. >>> - Very high lengths in order to force out-of-memory situations resultin= g in a denial of service, access-out-of-bounds issues etc. >>> - Missing Elements that are mandatory and have no declared default valu= e. >>> - Usage of 0x00 octets in EBML Elements with a string type. >>> - Usage of invalid UTF-8 encoding in EBML Elements of UTF-8 type (e.g. = in order to trigger acces-out-of-bounds or buffer overflow issues). >>> - Usage of invalid data in EBML Elements with a date type. >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> >>> Of the points, I don=E2=80=99t quite understand a few.. >>> >>> Originally Moritz wrote: >>>> Usage of \0 characters in EbmlString elements >>> I changed it to >>>> - Usage of 0x00 octets in EBML Elements with a string type. >>> but the string elements are allowed to be terminated with one or many 0= x00 octets. What is an example of a null terminated EBML string that is a s= ecurity consideration. >>> >>> Regarding: >>>> - Usage of invalid data in EBML Elements with a date type. >>> >>> >>> Any 0 or 8 octet date value is valid, right? Other lengths are already = invalid for date elements, so is this necessary to include? >>> >>> A PR of the draft Security Considerations section is here: https://gith= ub.com/Matroska-Org/ebml-specification/pull/54. >>> >>> Dave Rice >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 08:34:24 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7A01B29B4 for ; Sun, 14 Feb 2016 08:34:23 -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 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 0aylj0hrZMRX for ; Sun, 14 Feb 2016 08:34:22 -0800 (PST) Received: from 6.mo4.mail-out.ovh.net (6.mo4.mail-out.ovh.net [188.165.36.253]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F72C1B29D5 for ; Sun, 14 Feb 2016 08:34:19 -0800 (PST) Received: from mail693.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo4.mail-out.ovh.net (Postfix) with SMTP id 6FBD010A4110 for ; Sun, 14 Feb 2016 17:34:17 +0100 (CET) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 14 Feb 2016 18:34:17 +0200 Received: from p5ddb6320.dip0.t-ipconnect.de (HELO ?192.168.2.101?) (jerome@francoallemand.eu@93.219.99.32) by ns0.ovh.net with SMTP; 14 Feb 2016 18:34:15 +0200 References: <20150702175013.3f2e8427@miuna> <6C67F2DE-5F7F-4D67-8FF9-69CAFB25E769@dericed.com> <56C0A5C9.6090707@mediaarea.net> To: cellar@ietf.org From: Jerome Martinez Message-ID: <56C0AC77.7040100@mediaarea.net> Date: Sun, 14 Feb 2016 17:33:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 12431905297430155410 X-Ovh-Remote: 93.219.99.32 (p5ddb6320.dip0.t-ipconnect.de) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrfeelucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrfeelgdeklecutefuodetggdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] Fwd: [Matroska-devel] EBML data type constraints X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 16:34:23 -0000 On 14/02/2016 17:25, Steve Lhomme wrote: > 2016-02-14 17:05 GMT+01:00 Jerome Martinez : >> On 14/02/2016 16:33, Steve Lhomme wrote: >>> [...] >>> Same remark as above, it doesn't take in consideration if there's data >>> after the first 0x00. Any data after the first 0x00 should be >>> discarded. This kinda sucks for languages that don't use NULL >>> terminators. >> >> as C++ std::string. >> >>> They have to parse every single strings from the back >>> (and possibly never ever finding NULL). It would be easier to assume >>> that if the last octet is not 0x00 then there's no 0x00 elsewhere in >>> the string. >> >> And what a demuxer must do if there are actually 0x00 in the string? > Not use it. So "consider such bytes as non existent" as in the proposal, right? > >> From my understanding of RFC 2279 >> "Character values from 0000 0000 to 0000 007F (US-ASCII repertoire) >> correspond to octets 00 to 7F (7 bit US-ASCII values)." >> 0x00 is a valid UTF-8 character (as well as all in the range 0x00-0x1F, >> forbidden by the current EBML proposal) >> so 0x00410041 is a valid UTF-8 (or ASCII) string. > Uh! It could also be the last octect of a multi-octet value. No! by design (see UTF-8 encoding scheme). > So > indeed, parsing from the back is not even a clean solution. 1/ choice of the developer 2/ it is clean, by UTF-8 design (mutli-byte always start with highest bit set to 1, i.e. b1xxxxxxx) > I'd rather > avoid NULL padding if possible. I am OK with it, but in that case is there a reason to reject NULL character (valid in both ASCII and UTF8)? >> >> Currently I don't understand the reason we could not use 0x00 as padding if >> it is forbidden in the string. >> I see 2 policies: >> >> 1/ 0x00-0x1F are forbidden as real content (we restrict ASCII and UTF-8) >> I don't see a reason muxers must not write 0x00 if demuxers should accept >> 0x00 as padding. It does not hurt. >> >> 2/ We do no restrictions and take ASCII and UTF-8 as is (full range) >> We consider 0x00 as a character like any other character and it is the role >> of the software to deal with non printable characters. >> >> I have a preference on no restriction when using other standards because I >> consider it is not the role of the container to forbid characters, but this >> preference is not strong. > I think we should stick to what UTF-8 says. Forcing constraints on > another standard, another piece of code just for the container is not > a good idea IMO. so NULL padding is dead. Due to legacy reasons, I propose to keep NULL padding and 0x00-0x1F forbidden for Matroska v1-v3, and consider 0x00-0x1F as any other character (normal characters). Jérôme From nobody Sun Feb 14 08:36:18 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6223E1A00FA for ; Sun, 14 Feb 2016 08:36:16 -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 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 Tn6kWIjxOCjp for ; Sun, 14 Feb 2016 08:36:15 -0800 (PST) Received: from 13.mo4.mail-out.ovh.net (13.mo4.mail-out.ovh.net [178.33.251.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14C4A1A00DD for ; Sun, 14 Feb 2016 08:36:15 -0800 (PST) Received: from mail693.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo4.mail-out.ovh.net (Postfix) with SMTP id DF26710A8004 for ; Sun, 14 Feb 2016 17:36:12 +0100 (CET) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 14 Feb 2016 18:36:12 +0200 Received: from p5ddb6320.dip0.t-ipconnect.de (HELO ?192.168.2.101?) (jerome@francoallemand.eu@93.219.99.32) by ns0.ovh.net with SMTP; 14 Feb 2016 18:36:12 +0200 To: cellar@ietf.org References: <20150702175013.3f2e8427@miuna> <6C67F2DE-5F7F-4D67-8FF9-69CAFB25E769@dericed.com> <56C0A84A.6080908@mediaarea.net> From: Jerome Martinez Message-ID: <56C0ACEE.3080708@mediaarea.net> Date: Sun, 14 Feb 2016 17:35:58 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 12464837869843320978 X-Ovh-Remote: 93.219.99.32 (p5ddb6320.dip0.t-ipconnect.de) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrfeelucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrfeelgdeklecutefuodetggdotffvucfrrhhofhhilhgvmecuqfggjfenuceurghilhhouhhtmecufedttdenuc Archived-At: Subject: Re: [Cellar] Fwd: [Matroska-devel] EBML data type constraints X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 16:36:16 -0000 On 14/02/2016 17:27, Steve Lhomme wrote: > 2016-02-14 17:16 GMT+01:00 Jerome Martinez : >> On 13/02/2016 22:09, Dave Rice wrote: >>>>> >>>>> String - Printable ASCII (0x20 to 0x7E) >>>>> >>>>> [...] >>>>> >>>>> UTF-8 - Printable Unicode string (Unicode character value >=0x20) >>> >> BTW, how should be filled a tag string with a content having line feeds >> (thinking to e.g. a summary of the content in the file, some summaries have >> several paragraphs)? >> >> On the Matroska website, UTF-8 string has no "Unicode character value >>> =0x20" restriction, I am afraid that we make a lot of files invalid. Maybe >> ">0x00"? > I agree, line feeds are perfectly fine. I suppose the "non-printable" > chars should be fine. Even 0x00 is sometimes represented with a [NUL] > character in some fonts. What about current "String - Printable ASCII (0x20 to 0x7E), zero-padded when needed" Shouldn't it be changed to "0x01 to 0x7E"? From nobody Sun Feb 14 08:41:35 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E80A01A912C for ; Sun, 14 Feb 2016 08:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_JHO_1H5K9l for ; Sun, 14 Feb 2016 08:41:32 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329961A910E for ; Sun, 14 Feb 2016 08:41:32 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:45060 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aUzjl-003TJj-OV; Sun, 14 Feb 2016 11:41:32 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Sun, 14 Feb 2016 11:41:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <639B3594-4514-4BE7-BA59-8D14C856AFC5@dericed.com> References: <74651E49-02F2-4BFF-9B91-0C78A169DD5B@dericed.com> To: Steve Lhomme X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] adding unknownsizeallowed attribute for EBML definitions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 16:41:34 -0000 > On Feb 14, 2016, at 10:26 AM, Steve Lhomme = wrote: >=20 > 2016-02-13 22:36 GMT+01:00 Dave Rice : >> Current the EBML spec implies that any Master-element may use an = unknown Element Data Size and may contain data that is not part of an = EBML Element. I propose that this should be constrained in EBML Element = definitions. >>=20 >> I drafted another attribute for EBML Element definitions called = unknownsizeallowed (better names welcome). >>=20 >> The proposed attribute is not required and I drafted this definition: >>> A boolean to express if an EBML Element MAY use an Element Data Size = that is Unknown (having all VINT\_DATA bits set to 1). The = `unknownsizeallowed` attribute MAY only be applied to Master-elements. = If the `unknownsizeallowed` attribute is not used it is assumed that the = element not allowed to use an unknown Element Data Size. >>=20 >> With the added definition, I also changed a sentence in the = definition of the Master-element Data Type from: >>> When EBML is used in transmission or streaming, data that is not = part of an EBML Element is permitted to be present within a = Master-element. >>=20 >> to >>> When EBML is used in transmission or streaming, data that is not = part of an EBML Element is permitted to be present within a = Master-element if `unknownsizeallowed` is enabled within that = Master-element's definition. >>=20 >> The adjustment presumes that non-EBML junk data is only permitted in = Master-elements with unknown size. Possibly these two qualities could be = separated but I can=E2=80=99t really see a reason to have a = Master-element with a known size also contain junk data. >>=20 >> A draft PR is here: = https://github.com/Matroska-Org/ebml-specification/pull/55 >>=20 >> Comments? >=20 > =46rom the Matrosk point of view, I don't see exactly where this would > be used, or only to restrict the feature to certain elements. =46rom my understanding, most Master-elements are not intended to ever = use an unknown size. For example having an unknown size for the EBML = Header or ChapterTrack or Seek doesn't seem to make sense. Since the use = of unknown sizes increases the challenges to parse the stream, I propose = that the EBML Schema of the docType could specify where the unknown size = is allowed. > But it > seems more like a profile (live streaming or not) rather that > something to set for all Matroska files. For example an archive should > never allow such unknown sizes. This is bad for error recovery. So > should we define 2 versions of the specs ? This is feasible on another layer, but I'm distinguishing: - saying that unknown sizes are only valid for certain defined elements = (can be clarified by the element definition) - recommending not to use unknown sizes in certain circumstances (the = role of profiles) > Or profiles that allow > variations on the values? Such elements would be marked in the specs > with possible/allowed variations. >=20 > I understand that some other EBML derivatives may have the use for the > feature only on specific elements and never some others. >=20 >> Also if using this, we=E2=80=99ll have to clarify which Matroska/webm = elements would use this? I suspect it=E2=80=99s a small percentage of = the Master-elements declared for those document types. >=20 > In practice only The Segments and (some) level-1 elements that can't > be held in memory or need low latency transmission. >=20 >> Dave Rice >>=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 Sun Feb 14 08:42:47 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C346B1ACE8B for ; Sun, 14 Feb 2016 08:42:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 1LK15cI8roM4 for ; Sun, 14 Feb 2016 08:42:45 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB361A9134 for ; Sun, 14 Feb 2016 08:42:45 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id k196so92273355vka.0 for ; Sun, 14 Feb 2016 08:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=GoQrLCHChyUzeOesmu9z8EoAe412kQAUu07AeQwsQiQ=; b=hRt52LazGMSS4t9f8bwA74FJiDHslDKAGhIEwLVGdnohkFMnQxUVgIoFuxLveUL3Wf AWD8+dTLF5SfvC2fP4LTBs6dwHJCzNukkIVXy71XChybKErBzChUo67bg3dMk8DNndmK u42lrSNJtSwA4B+qEoVz00nxhJ8F2qacfT5tPwewyJK4LQrK/ReMK6OuMDX1L7SmyQfj OwlMX5Gz7zHrrPnV/ANv1HR5fd+aujF8S1OpnP8cAhds7bVZe+EMMzAlK0QMukghNxE4 ZmIney248Q4Y6IQF9vGDdz1n8Qcuxl9QN2zLsPZwUX6Cj0ijJtTE4Mzv/DAL7ct1RigW oJQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GoQrLCHChyUzeOesmu9z8EoAe412kQAUu07AeQwsQiQ=; b=nHXB6J42fMOpnrC3AkMsNUQqZFUJ7Uvfa5iswqmceYZkb7Ydmx9UpWpBgu9RLHtcC2 Xb4tUck4Tk07dFV8cVD0ZejwgZrQouyjq4uUI2U2o30OjndgRd0756oVqvWhUrG7je/S v35txTbwtWl6z7axy3dVSj41/TpHRRZsAmDM/hMTS498Dnjfj6zyMmtwz7hLoJXAHn9u IhWCT/VNkBpwTERJoi92+lM+L5bcvWwuz8RuHf0gvJFIhRRaehcRKDYAHpdCgY63xAME T9Qy93zSFhJIifBSoPGfHUzd0APafIfCx2wyT9hphGNv94g3RdACgrMVHu3vJhod7TIp M5jg== X-Gm-Message-State: AG10YORsw09+XNWoOtbDsl/ywjGidoz6z1Q0cv4aGyRrFku0oXc6V7CKL4zCruzQiOBGtU1IcadAUiBA4j2+Dw== MIME-Version: 1.0 X-Received: by 10.31.47.205 with SMTP id v196mr9496130vkv.18.1455468164495; Sun, 14 Feb 2016 08:42:44 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 08:42:44 -0800 (PST) In-Reply-To: <56C0AC77.7040100@mediaarea.net> References: <20150702175013.3f2e8427@miuna> <6C67F2DE-5F7F-4D67-8FF9-69CAFB25E769@dericed.com> <56C0A5C9.6090707@mediaarea.net> <56C0AC77.7040100@mediaarea.net> Date: Sun, 14 Feb 2016 17:42:44 +0100 Message-ID: From: Steve Lhomme To: Jerome Martinez Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Fwd: [Matroska-devel] EBML data type constraints X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 16:42:46 -0000 2016-02-14 17:33 GMT+01:00 Jerome Martinez : > On 14/02/2016 17:25, Steve Lhomme wrote: >> >> 2016-02-14 17:05 GMT+01:00 Jerome Martinez : >>> >>> On 14/02/2016 16:33, Steve Lhomme wrote: >>>> >>>> [...] >>>> Same remark as above, it doesn't take in consideration if there's data >>>> after the first 0x00. Any data after the first 0x00 should be >>>> discarded. This kinda sucks for languages that don't use NULL >>>> terminators. >>> >>> >>> as C++ std::string. >>> >>>> They have to parse every single strings from the back >>>> (and possibly never ever finding NULL). It would be easier to assume >>>> that if the last octet is not 0x00 then there's no 0x00 elsewhere in >>>> the string. >>> >>> >>> And what a demuxer must do if there are actually 0x00 in the string? >> >> Not use it. > > > So "consider such bytes as non existent" as in the proposal, right? Correct. >> >>> From my understanding of RFC 2279 >>> "Character values from 0000 0000 to 0000 007F (US-ASCII repertoire) >>> correspond to octets 00 to 7F (7 bit US-ASCII values)." >>> 0x00 is a valid UTF-8 character (as well as all in the range 0x00-0x1F, >>> forbidden by the current EBML proposal) >>> so 0x00410041 is a valid UTF-8 (or ASCII) string. >> >> Uh! It could also be the last octect of a multi-octet value. > > > No! > by design (see UTF-8 encoding scheme). Ouf. So we're safe to chose between the end-padding or not allowing padding at all. >> So >> indeed, parsing from the back is not even a clean solution. > > > 1/ choice of the developer > 2/ it is clean, by UTF-8 design (mutli-byte always start with highest bit > set to 1, i.e. b1xxxxxxx) > >> I'd rather >> avoid NULL padding if possible. > > > I am OK with it, but in that case is there a reason to reject NULL charac= ter > (valid in both ASCII and UTF8)? If we remove padding, NULL would become valid. That means older parsers may consider it like padding. It may also truncate the string if it's found in the middle. Given it would only be valid for UTF-8 Strings, that means only non vital part of the file (ie not codec IDs and such) so IMO it's ok to break backward compatibility here. Not that this case would be common... >>> >>> Currently I don't understand the reason we could not use 0x00 as paddin= g >>> if >>> it is forbidden in the string. >>> I see 2 policies: >>> >>> 1/ 0x00-0x1F are forbidden as real content (we restrict ASCII and UTF-8= ) >>> I don't see a reason muxers must not write 0x00 if demuxers should acce= pt >>> 0x00 as padding. It does not hurt. >>> >>> 2/ We do no restrictions and take ASCII and UTF-8 as is (full range) >>> We consider 0x00 as a character like any other character and it is the >>> role >>> of the software to deal with non printable characters. >>> >>> I have a preference on no restriction when using other standards becaus= e >>> I >>> consider it is not the role of the container to forbid characters, but >>> this >>> preference is not strong. >> >> I think we should stick to what UTF-8 says. Forcing constraints on >> another standard, another piece of code just for the container is not >> a good idea IMO. > > > so NULL padding is dead. > > Due to legacy reasons, I propose to keep NULL padding and 0x00-0x1F > forbidden for Matroska v1-v3, and consider 0x00-0x1F as any other charact= er > (normal characters). > > > J=C3=A9r=C3=B4me > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 08:45:44 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28821AD04E for ; Sun, 14 Feb 2016 08:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 Hq9kGbFvlxja for ; Sun, 14 Feb 2016 08:45:41 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A55F21AD061 for ; Sun, 14 Feb 2016 08:45:41 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id e185so91950366vkb.1 for ; Sun, 14 Feb 2016 08:45:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wXmbjCzd3YL2s+ZjIYc694m0hOAq9UrfhGY9G0oOg4E=; b=lxVbUoi12Sl5oerSudo3kq2JfE/O2Pq8ZrmYChr2njmd0EDjksyKlDrxEc7RfBf2mq EWxte8eWD3jDnVkXf2iy5nnjtZkYzYpWk9MJZnrcyNVMgpgrGAOKgIv8gqE1ZLrEYpwM 3NMjQ5Cy1qS/e7eDOnXUNkZfh7qR+Y9ekIBLG01lW4RPyvbHuubVdbgJRQYMjNfN3JTi y0SSk67HDqAYGj/uMbw6YvA/Nv0lHDFfCSaG4RvqItOZGn8Cb4BlBhEGueL99eqUcpMf OXFWpQU+2yl84+1rhtNSluS3zUDFtD+7s2XkVHAp3Jbz2sjgJgQm+ACrpfuO3s8+SbDh d55w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wXmbjCzd3YL2s+ZjIYc694m0hOAq9UrfhGY9G0oOg4E=; b=Cke9Jyjhd0zmAfimEq/kW2VNKRARc7uI2HM1FMNeaUnSRWWd6lgWYNZmNEquDb2tJP qC1XeT5dks6DVIAwn5uXwvKe9baF8NDto5EEf5Y/mQ75UIV0n3/OBHfA8q1NM2mZFQn8 55FR92vySsOIHFZfC3S4q2Mb1NSzSqRrIoaSKeeSnbS4SRiVOWYyyju4bytDvcuZJp+w BvyZBN8JZz8KNo2xXZshhstFAbEAN+IviF4aVO+GPIEdOm/hbBOpafJ03TUMBXXyb6Xt 4Fo9FQNlFVSo7NyOkJnd3WnJEr7KiKivAnv+UStZCvnrPFSxzUGCfFQc/V2iCnYi94uD 9wYA== X-Gm-Message-State: AG10YORbn7z+TGLyNkn8hxqtsxAvvfu2qZxIMpyE1MUqa/osZiF6WbfXBVq6HMUIMCllI9TBljTrFPXNyNhSPA== MIME-Version: 1.0 X-Received: by 10.31.5.9 with SMTP id 9mr9888612vkf.109.1455468340871; Sun, 14 Feb 2016 08:45:40 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 08:45:40 -0800 (PST) In-Reply-To: <56C0ACEE.3080708@mediaarea.net> References: <20150702175013.3f2e8427@miuna> <6C67F2DE-5F7F-4D67-8FF9-69CAFB25E769@dericed.com> <56C0A84A.6080908@mediaarea.net> <56C0ACEE.3080708@mediaarea.net> Date: Sun, 14 Feb 2016 17:45:40 +0100 Message-ID: From: Steve Lhomme To: Jerome Martinez Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Fwd: [Matroska-devel] EBML data type constraints X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 16:45:42 -0000 2016-02-14 17:35 GMT+01:00 Jerome Martinez : > On 14/02/2016 17:27, Steve Lhomme wrote: >> >> 2016-02-14 17:16 GMT+01:00 Jerome Martinez : >>> >>> On 13/02/2016 22:09, Dave Rice wrote: >>>>>> >>>>>> >>>>>> String - Printable ASCII (0x20 to 0x7E) >>>>>> >>>>>> [...] >>>>>> >>>>>> UTF-8 - Printable Unicode string (Unicode character value >=0x20) >>>> >>>> >>> BTW, how should be filled a tag string with a content having line feeds >>> (thinking to e.g. a summary of the content in the file, some summaries >>> have >>> several paragraphs)? >>> >>> On the Matroska website, UTF-8 string has no "Unicode character value >>>> >>>> =0x20" restriction, I am afraid that we make a lot of files invalid. >>>> Maybe >>> >>> ">0x00"? >> >> I agree, line feeds are perfectly fine. I suppose the "non-printable" >> chars should be fine. Even 0x00 is sometimes represented with a [NUL] >> character in some fonts. > > > What about current "String - Printable ASCII (0x20 to 0x7E), zero-padded > when needed" > Shouldn't it be changed to "0x01 to 0x7E"? The String format is usually for things not meant for user display such as Codec IDs, languages and MIME types. They are not supported to have extended and weird characters. So we should stick to printable ASCII. > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 08:48:03 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698711AC3D4 for ; Sun, 14 Feb 2016 08:48:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 wBhDiu81Q8H9 for ; Sun, 14 Feb 2016 08:48:01 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD5711AC3C2 for ; Sun, 14 Feb 2016 08:48:00 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id e6so91777744vkh.2 for ; Sun, 14 Feb 2016 08:48:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JsVLJ9PX2SIYn2Y3LQ4G0f4jDbhLYy8C2ZPkAlFPugo=; b=LCa6gUD1Xa78+5z5B/n1/V92cPPNVnSNysivj0mkbcqtLx0PWRElEcvr2VxZT6Jj31 3Dzc3jOZjXldL2nT9LoEjGLEL/1+KF+N6PqHWv/s7/VB2WA42eKTVigdnfzmgDyafJkf CiulEej4C8Gi4iR96DMb+sqW4YiCfvB84O9v0c2+MHkvkK1yCVljuoporKFpJcHQMWfC MYujKTSVJXRltTSDWHO1WkQGnQ7Pz7kerDdI3/ej0pEqQ7pHVzbgvTji71lxTFx6mVl5 l56V5hZel4ss93t49ustVsHavmjlPYoQG+NLApELAFrcgQciY0RAY9V+I+0E9Zcqklff QBzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=JsVLJ9PX2SIYn2Y3LQ4G0f4jDbhLYy8C2ZPkAlFPugo=; b=Td2RBaVZdOvQ6dd5VxsVLh27KbybZn+q5/tI8+DFEO8EXfgYXelVmu9B4n1804JEy6 sChesX8GIjuB9Qlyp7SRYdyAbG4GAogI5TIhQmRANE5Wjd+7sFCYlT/KGtX8XCfJICzl SRBphQpJes7iQt/7ztdmOyU34BP8xJDPP48fZAyrIHoMnIsZ9H+wJ7uR3W+UIJbOEX+P S423IInVPj76mROaUOl279xzI8htjPGfTgisgZAFyHMsI22Kf0mxHzOt4+sy8QPxiIEo 5dPczXTQ/FMybkcneMaUfIWQgg21HiY7LvNoRU1dbEWo3XPVZLJZfGh5BYOfDn2Y7WQ/ wpnQ== X-Gm-Message-State: AG10YORWpdpDgKGt4bBDhnkd4VnWk4M1xf+gskK5q9ZlSEsc7IBOypTMX5ISaq7yO1Fgqa/04jjNHqI59eJelg== MIME-Version: 1.0 X-Received: by 10.31.168.76 with SMTP id r73mr9888938vke.117.1455468479984; Sun, 14 Feb 2016 08:47:59 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 08:47:59 -0800 (PST) In-Reply-To: <639B3594-4514-4BE7-BA59-8D14C856AFC5@dericed.com> References: <74651E49-02F2-4BFF-9B91-0C78A169DD5B@dericed.com> <639B3594-4514-4BE7-BA59-8D14C856AFC5@dericed.com> Date: Sun, 14 Feb 2016 17:47:59 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] adding unknownsizeallowed attribute for EBML definitions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 16:48:02 -0000 2016-02-14 17:41 GMT+01:00 Dave Rice : > >> On Feb 14, 2016, at 10:26 AM, Steve Lhomme wrote: >> >> 2016-02-13 22:36 GMT+01:00 Dave Rice : >>> Current the EBML spec implies that any Master-element may use an unknow= n Element Data Size and may contain data that is not part of an EBML Elemen= t. I propose that this should be constrained in EBML Element definitions. >>> >>> I drafted another attribute for EBML Element definitions called unknown= sizeallowed (better names welcome). >>> >>> The proposed attribute is not required and I drafted this definition: >>>> A boolean to express if an EBML Element MAY use an Element Data Size t= hat is Unknown (having all VINT\_DATA bits set to 1). The `unknownsizeallow= ed` attribute MAY only be applied to Master-elements. If the `unknownsizeal= lowed` attribute is not used it is assumed that the element not allowed to = use an unknown Element Data Size. >>> >>> With the added definition, I also changed a sentence in the definition = of the Master-element Data Type from: >>>> When EBML is used in transmission or streaming, data that is not part = of an EBML Element is permitted to be present within a Master-element. >>> >>> to >>>> When EBML is used in transmission or streaming, data that is not part = of an EBML Element is permitted to be present within a Master-element if `u= nknownsizeallowed` is enabled within that Master-element's definition. >>> >>> The adjustment presumes that non-EBML junk data is only permitted in Ma= ster-elements with unknown size. Possibly these two qualities could be sepa= rated but I can=E2=80=99t really see a reason to have a Master-element with= a known size also contain junk data. >>> >>> A draft PR is here: https://github.com/Matroska-Org/ebml-specification/= pull/55 >>> >>> Comments? >> >> From the Matrosk point of view, I don't see exactly where this would >> be used, or only to restrict the feature to certain elements. > > From my understanding, most Master-elements are not intended to ever use = an unknown size. For example having an unknown size for the EBML Header or = ChapterTrack or Seek doesn't seem to make sense. Since the use of unknown s= izes increases the challenges to parse the stream, I propose that the EBML = Schema of the docType could specify where the unknown size is allowed. > >> But it >> seems more like a profile (live streaming or not) rather that >> something to set for all Matroska files. For example an archive should >> never allow such unknown sizes. This is bad for error recovery. So >> should we define 2 versions of the specs ? > > This is feasible on another layer, but I'm distinguishing: > - saying that unknown sizes are only valid for certain defined elements (= can be clarified by the element definition) > - recommending not to use unknown sizes in certain circumstances (the rol= e of profiles) You're right. The specs should say where it's allowed (mostly not allowed everywhere) and then profiles could restrict the use even more. So "Allowed" in the name is good. >> Or profiles that allow >> variations on the values? Such elements would be marked in the specs >> with possible/allowed variations. >> >> I understand that some other EBML derivatives may have the use for the >> feature only on specific elements and never some others. >> >>> Also if using this, we=E2=80=99ll have to clarify which Matroska/webm e= lements would use this? I suspect it=E2=80=99s a small percentage of the Ma= ster-elements declared for those document types. >> >> In practice only The Segments and (some) level-1 elements that can't >> be held in memory or need low latency transmission. >> >>> Dave Rice >>> >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 09:02:28 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E8831B29EF for ; Sun, 14 Feb 2016 09:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.888 X-Spam-Level: X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622] autolearn=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 RVRW0uKQ4bsg for ; Sun, 14 Feb 2016 09:02:25 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE6CE1B29EE for ; Sun, 14 Feb 2016 09:02:25 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id k196so92447880vka.0 for ; Sun, 14 Feb 2016 09:02:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=jJCBkTzFlvxXsWDJY/G8ZI7LaYbZUyE5O64/3WhdeSM=; b=npAJHWaeVJAp/l5iPB5nah6reweB3VlcbNjer9vq+3rVzdR1uDSSCLdCXelZXNLbi9 kdDeODPV8eA6FFaBfuA1XcBCham0Ub1K1iIpqznMNBYD/jwPdGo5NLYLTuNrh+bcVqBp crxwlokj6zltT90rPX9xmab8yxNpvdMY3ilfFBhbycQDePSux2a0FvQfdEf4BFCvgklE /giEMg7Dpt0DI7qLGdNcuvG3MhJgWD11pHenj8NxR8gA60Km7NnQDOOEfCQXdMITDIMr J7QAfll8FzJU2u0KoRrya2drDnJJvvDsdQkFili9hzEYbgD007Ffd8k303H0glW8rlpX k2WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jJCBkTzFlvxXsWDJY/G8ZI7LaYbZUyE5O64/3WhdeSM=; b=K6N/8pPD2DcUmtbtw9McCGIAK45ywD6RRwV/0wfU1D2l3QgkUD+JbSWzXd5bgTpVdX kejXTGVjNmGkPMrkxFiC18Tktxsg6ur1M6SaOtbNCGkTEAOv0vYB8QxIJrhX2mAVBgwG 2BGePBgb54eIb0vnmMOlfznZJhfOxsIIYj9GIxeJUJoB4rVUQD851PVfmAXKvlJDoPzN WZCUfyT6cS5fpVVdo6ZaVHbnfaFe9EFMhBE1fwJeTFxFOiKIyKIruxAIDEtrHqIsPXHl Car9mZk0MHRtOmncipakH/rJO4GOSwsXjqG0/yCZ82zUf36YU3OWN5Syhu0jeVereaiM ZDmw== X-Gm-Message-State: AG10YOQDWZhvAT0J4IJA5tFzrj53R7fEFkMzMH4jyHalgRA2vhTzsNHMFKrQi/94RJf4dXHqaX3zkEvNVAWZ2Q== MIME-Version: 1.0 X-Received: by 10.31.41.86 with SMTP id p83mr9879530vkp.157.1455469344851; Sun, 14 Feb 2016 09:02:24 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 09:02:24 -0800 (PST) In-Reply-To: References: Date: Sun, 14 Feb 2016 18:02:24 +0100 Message-ID: From: Steve Lhomme To: Nithin Mathew Kurien Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Dave Rice , cellar@ietf.org Subject: Re: [Cellar] expressing a float in text X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 17:02:27 -0000 2016-02-13 20:24 GMT+01:00 Nithin Mathew Kurien : > Hi, > > Not sure if it is suitable in this context, but C99 supports writing floa= ts > accurately in hexadecimal notation > (http://www.exploringbinary.com/hexadecimal-floating-point-constants/). T= he > advantage of hexadecimal notation is that values can be represented > accurately, unlike representions like 1.67e-3, which will result in round= ing > errors when converted from decimal to the native binary form. With a C99 > compiler like GCC, we can output the hexadecimal form of any float. > > double num =3D 1.55e1; > printf("%a", num); > > would output > > 0x1.fp3 > > which is equal to (1 + 15/16) * 2^3. I agree that since floats are not always bit exact a format that accurately interprets the machine value anytime would be better. Not sure if the C99 representation works for other languages too. We might have a machine representation and text representation for each value so it's easy to read and clean to interpret. > Thanks and regards, > Nithin > > > On Sun, Feb 14, 2016 at 12:20 AM, Dave Rice wrote: >> >> To accommodate the float range expressions in Frank=E2=80=99s color work= , I=E2=80=99m >> expanding the =E2=80=9CExpression of range=E2=80=9D [1] section to accom= modate floats >> (currently it only discusses signed and unsigned integers). Frank=E2=80= =99s use of >> float ranges are quite simple, such as 0.0 to 1.0; however, in defining = a >> method to document a float range, I think the definition should work for= any >> possible float value. >> >> Is there an standard document to point to for how to represent a float >> value as text? i.e. I=E2=80=99m familiar with float values in text such = as 3.88E-4 >> but where it this style of expression defined? >> >> Best Regards, >> Dave Rice >> >> [1] >> https://github.com/Matroska-Org/ebml-specification/blob/master/specifica= tion.markdown#expression-of-range >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar > > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 09:03:44 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34A7F1B2A0D for ; Sun, 14 Feb 2016 09:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 nuIr1aoK1o5b for ; Sun, 14 Feb 2016 09:03:42 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB57C1B2A0C for ; Sun, 14 Feb 2016 09:03:41 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id e185so92110713vkb.1 for ; Sun, 14 Feb 2016 09:03:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=y1WJi/HtCHS2sYF0gxbN8D3XFodita8b0V7ESjnYnJQ=; b=MC63rqknf0xNlbfvjFCu2fYS1dhw3lBoN/2bNhA8nUwchC0nYCFRTYMlHCMJRGDUS9 r8bCe26yNknLmDQ8kBsrBd9QGLRC7fps2EGbnEfNCkK5iIK7o3X3s0TiXgihzE+OFkIr yELCjPu/12nbGDnGkFfwoVizkDKByqaM38sk8+/gnKwhgqMPaayn7gRthH/3rxShwY3C t5zmTODWD/w4/kuuxVvY7ZU0fHAWu9L3Wi6Vu/ldA1eN48Ht8BFiYgziFL01vOHQp5yH rBgO2nXZ3wIc5x/kneUMyR9g203YG0kfQZw4mBOHC7CqLZyFg2TMWFG1lNivKhhSsgzh aJOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=y1WJi/HtCHS2sYF0gxbN8D3XFodita8b0V7ESjnYnJQ=; b=Ho1acFE6dhTYutNcLQLN18j2RvT/x3plkCvk3/2NyCTsTbQmngj4D1FxI3dOz/TYJH FDZvb4HorHSndRVxuuubAerLVa2CHCisssFBlWAnk9k7cUHnTEDMJ1HibY5/iC2bpOzB qqbwhuVLr2KgTH1D9ovTdYQ1/Tcb4gTvkDS7Z43ZObpjSr0ts5ZdQgDe3bb5+8DGnSAE AbeygBSdIivFl9ZOVS+zRT8dtIE9qAkImJR6MSYk4yMkhrtaDsc8owuBEE06+UTA17/+ imWj7DNbtYH0DmjMe9jSY7qu6U3shSxAaCyIpKe9nnGuu+qpaFGJ1QgkKkFCtGTmU4di wKUA== X-Gm-Message-State: AG10YOTplBf52drYJwAF/9A22Pjj/6gJr8I0mRautbK63FL32zNJppN2nfKdioZ1yowuodgSmAmJMurydNqrSA== MIME-Version: 1.0 X-Received: by 10.31.168.76 with SMTP id r73mr9934260vke.117.1455469420860; Sun, 14 Feb 2016 09:03:40 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 09:03:40 -0800 (PST) In-Reply-To: References: Date: Sun, 14 Feb 2016 18:03:40 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] EBML notations X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 17:03:43 -0000 2016-02-13 19:39 GMT+01:00 Dave Rice : > Hi all, > > I created a pull request here: > > It includes adding the RFC2119 boilerplate: https://github.com/Matroska-Org/ebml-specification/pull/53 > >> ## Notation and Conventions >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). > > Any other boilerplate applicable or worthwhile here? > > I also included a new definition for VINTMAX in the Element Date Size section: >> The maximum possible value that can be stored as Element Data Size is referred to as `VINTMAX`. > > > This allows some of the EBML Element Type length definitions to be shortened, such as: >> A binary element may declare any length (including zero) up to the maximum Element Data Size value permitted. > to >> A binary element may declare any length (including zero) to `VINTMAX`. > > Any other suggestions for terminology to define in the EBML spec? Both are fine. But you should do 2 pull requests for such things so that one thing doesn't block the other, as they are unrelated. > And Moritz merged it even before I sent this email :) but comments are still welcome. > > Best Regards, > Dave Rice > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar -- Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 09:07:53 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F2AF1B2A1F for ; Sun, 14 Feb 2016 09:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 jhFWkzg-Nd97 for ; Sun, 14 Feb 2016 09:07:48 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D9701B2A1D for ; Sun, 14 Feb 2016 09:07:48 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:34963 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aV09A-0048Dr-W5; Sun, 14 Feb 2016 12:07:48 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_77CD9E7A-4FF3-4294-906F-3C95692B1644" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Sun, 14 Feb 2016 12:07:48 -0500 Message-Id: <2C8BD209-9699-4A1D-A61B-D1519C2C3646@dericed.com> References: <74651E49-02F2-4BFF-9B91-0C78A169DD5B@dericed.com> <639B3594-4514-4BE7-BA59-8D14C856AFC5@dericed.com> To: Steve Lhomme X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] adding unknownsizeallowed attribute for EBML definitions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 17:07:51 -0000 --Apple-Mail=_77CD9E7A-4FF3-4294-906F-3C95692B1644 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 14, 2016, at 11:47 AM, Steve Lhomme = wrote: >=20 > 2016-02-14 17:41 GMT+01:00 Dave Rice : >>=20 >>> On Feb 14, 2016, at 10:26 AM, Steve Lhomme = wrote: >>>=20 >>> 2016-02-13 22:36 GMT+01:00 Dave Rice : >>>> Current the EBML spec implies that any Master-element may use an = unknown Element Data Size and may contain data that is not part of an = EBML Element. I propose that this should be constrained in EBML Element = definitions. >>>>=20 >>>> I drafted another attribute for EBML Element definitions called = unknownsizeallowed (better names welcome). >>>>=20 >>>> The proposed attribute is not required and I drafted this = definition: >>>>> A boolean to express if an EBML Element MAY use an Element Data = Size that is Unknown (having all VINT\_DATA bits set to 1). The = `unknownsizeallowed` attribute MAY only be applied to Master-elements. = If the `unknownsizeallowed` attribute is not used it is assumed that the = element not allowed to use an unknown Element Data Size. >>>>=20 >>>> With the added definition, I also changed a sentence in the = definition of the Master-element Data Type from: >>>>> When EBML is used in transmission or streaming, data that is not = part of an EBML Element is permitted to be present within a = Master-element. >>>>=20 >>>> to >>>>> When EBML is used in transmission or streaming, data that is not = part of an EBML Element is permitted to be present within a = Master-element if `unknownsizeallowed` is enabled within that = Master-element's definition. >>>>=20 >>>> The adjustment presumes that non-EBML junk data is only permitted = in Master-elements with unknown size. Possibly these two qualities could = be separated but I can=E2=80=99t really see a reason to have a = Master-element with a known size also contain junk data. >>>>=20 >>>> A draft PR is here: = https://github.com/Matroska-Org/ebml-specification/pull/55 >>>>=20 >>>> Comments? >>>=20 >>> =46rom the Matrosk point of view, I don't see exactly where this = would >>> be used, or only to restrict the feature to certain elements. >>=20 >> =46rom my understanding, most Master-elements are not intended to = ever use an unknown size. For example having an unknown size for the = EBML Header or ChapterTrack or Seek doesn't seem to make sense. Since = the use of unknown sizes increases the challenges to parse the stream, I = propose that the EBML Schema of the docType could specify where the = unknown size is allowed. >>=20 >>> But it >>> seems more like a profile (live streaming or not) rather that >>> something to set for all Matroska files. For example an archive = should >>> never allow such unknown sizes. This is bad for error recovery. So >>> should we define 2 versions of the specs ? >>=20 >> This is feasible on another layer, but I'm distinguishing: >> - saying that unknown sizes are only valid for certain defined = elements (can be clarified by the element definition) >> - recommending not to use unknown sizes in certain circumstances (the = role of profiles) >=20 > You're right. The specs should say where it's allowed (mostly not > allowed everywhere) and then profiles could restrict the use even > more. So "Allowed" in the name is good. >=20 >>> Or profiles that allow >>> variations on the values? Such elements would be marked in the = specs >>> with possible/allowed variations. >>>=20 >>> I understand that some other EBML derivatives may have the use for = the >>> feature only on specific elements and never some others. >>>=20 >>>> Also if using this, we=E2=80=99ll have to clarify which = Matroska/webm elements would use this? I suspect it=E2=80=99s a small = percentage of the Master-elements declared for those document types. >>>=20 >>> In practice only The Segments and (some) level-1 elements that can't >>> be held in memory or need low latency transmission. Based on comments from Sebastian and Steve I updated the definition and = force pushed the changes to the pull request at = https://github.com/Matroska-Org/ebml-specification/pull/55/files#diff-01f3= b0f2fbf3e44327e6072f64ddc8a0 = . Here is the updated definition for unknownsizeallowed (note it is = optional, and I suggest that all elements are considered to disallow = unknown-size unless unknownsizeallowed is enabled: > A boolean to express if an EBML Element MAY be used as an = `Unknown-Sized Element` (having all VINT\_DATA bits of Element Data Size = set to 1). The `unknownsizeallowed` attribute MAY only be applied to = Master-elements. If the `unknownsizeallowed` attribute is not used it is = assumed that the element is not allowed to use an unknown Element=20 Also in the section on Element Data Size, I changed this: > The end of a Master-element with unknown size is determined by the = beginning of the next element that is not a valid sub-element of that = Master-element. to > Master-elements MAY only use an unknown size is the unknownsizeallowed = attribute of the EBML Schema is set to true. The end of a Master-element = with unknown size is determined by the beginning of the next element = that is not a valid sub-element of that Master-element. An Element with = an unknown Element Data Size is referred to as an Unknown-Sized Element. When we get to implementing Matroska spec, I can do a survey on what = master-elements have been seen to implement unknown sizes. Data Size.= --Apple-Mail=_77CD9E7A-4FF3-4294-906F-3C95692B1644 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 14, 2016, at 11:47 AM, Steve Lhomme <slhomme@matroska.org> wrote:

2016-02-14 17:41 GMT+01:00 Dave Rice <dave@dericed.com>:

On Feb 14, 2016, at 10:26 AM, Steve Lhomme = <slhomme@matroska.org> wrote:

2016-02-13 22:36 GMT+01:00 Dave Rice <dave@dericed.com>:
Current the EBML spec = implies that any Master-element may use an unknown Element Data Size and = may contain data that is not part of an EBML Element. I propose that = this should be constrained in EBML Element definitions.

I drafted another attribute for EBML Element definitions = called unknownsizeallowed (better names welcome).

The proposed attribute is not required and I drafted this = definition:
A boolean = to express if an EBML Element MAY use an Element Data Size that is = Unknown (having all VINT\_DATA bits set to 1). The `unknownsizeallowed` = attribute MAY only be applied to Master-elements. If the = `unknownsizeallowed` attribute is not used it is assumed that the = element not allowed to use an unknown Element Data Size.

With the added definition, I also = changed a sentence in the definition of the Master-element Data Type = from:
When EBML is = used in transmission or streaming, data that is not part of an EBML = Element is permitted to be present within a Master-element.

to
When EBML is used in transmission or streaming, = data that is not part of an EBML Element is permitted to be present = within a Master-element if `unknownsizeallowed` is enabled within that = Master-element's definition.

The= adjustment presumes that non-EBML junk data is only permitted in = Master-elements with unknown size. Possibly these two qualities could be = separated but I can=E2=80=99t really see a reason to have a = Master-element with a known size also contain junk data.
A draft PR is here: https://github.com/Matroska-Org/ebml-specification/pull/55<= br class=3D"">
Comments?

=46rom the Matrosk point of view, I don't see exactly where = this would
be used, or only to restrict the feature to = certain elements.

=46rom my = understanding, most Master-elements are not intended to ever use an = unknown size. For example having an unknown size for the EBML Header or = ChapterTrack or Seek doesn't seem to make sense. Since the use of = unknown sizes increases the challenges to parse the stream, I propose = that the EBML Schema of the docType could specify where the unknown size = is allowed.

But it
seems more like a profile (live = streaming or not) rather that
something to set for all = Matroska files. For example an archive should
never allow = such unknown sizes. This is bad for error recovery. So
should we define 2 versions of the specs ?

This is feasible on another = layer, but I'm distinguishing:
- saying that unknown sizes = are only valid for certain defined elements (can be clarified by the = element definition)
- recommending not to use unknown = sizes in certain circumstances (the role of profiles)

You're right. The specs should = say where it's allowed (mostly not
allowed everywhere) and = then profiles could restrict the use even
more. So = "Allowed" in the name is good.

Or = profiles that allow
variations on the values? Such = elements would  be marked in the specs
with = possible/allowed variations.

I understand = that some other EBML derivatives may have the use for the
feature only on specific elements and never some others.

Also if = using this, we=E2=80=99ll have to clarify which Matroska/webm elements = would use this? I suspect it=E2=80=99s a small percentage of the = Master-elements declared for those document types.

In practice only The Segments and = (some) level-1 elements that can't
be held in memory or = need low latency transmission.

Based on comments from Sebastian and Steve I = updated the definition and force pushed the changes to the pull request = at https://github.com/Matroska-Org/ebml-specification/pull/55/file= s#diff-01f3b0f2fbf3e44327e6072f64ddc8a0.

Here is the updated definition for = unknownsizeallowed (note it is optional, and I suggest that all elements = are considered to disallow unknown-size unless unknownsizeallowed is = enabled:

A boolean to express if = an EBML Element MAY be used as an `Unknown-Sized Element` (having = all VINT\_DATA bits of Element Data Size set to 1). The = `unknownsizeallowed` attribute MAY only be applied = to Master-elements. If the `unknownsizeallowed` attribute is not = used it is assumed that the element is not allowed to use an = unknown Element 

Also in the section on Element Data = Size, I changed this:
The end of a Master-element with unknown size is determined = by the beginning of the next element that is not a = valid sub-element of = that Master-element.
to
Master-elements MAY only = use an unknown size is the unknownsizeallowed attribute of the = EBML Schema is set to true. The end of a Master-element with = unknown size is determined by the beginning of the next element = that is not a valid sub-element of that Master-element. = An Element with an unknown Element Data Size is referred to as = an Unknown-Sized Element.

When we get to implementing Matroska spec, I can do a survey = on what master-elements have been seen to implement unknown = sizes.

Data = Size.
= --Apple-Mail=_77CD9E7A-4FF3-4294-906F-3C95692B1644-- From nobody Sun Feb 14 09:21:42 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 160791AC39D for ; Sun, 14 Feb 2016 09:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 6CvYDlBrhDJn for ; Sun, 14 Feb 2016 09:21:38 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53BB81A00C5 for ; Sun, 14 Feb 2016 09:21:38 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id e185so92277417vkb.1 for ; Sun, 14 Feb 2016 09:21:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=khDSn3HN6C0DPoSwIzse8rsahOD8B4aGyIt3a1qN9XU=; b=RqN/hu4lvGrqdlRC7V3jBBa+cQIaYf3qOYjaGqcgcCUBC6o4JcQzYghdtB5WVkR1hh p/62uNM3FZj30lkaPjIw4H9ib8z4EHIH4fAmxFu7Y5cx4iA0kM3I8k1YW3GwFhZmWID/ E4dmPKmYPyiJMy3xT2jrlGDEHS7zV0TN2XOg/LoggkDZ22Qe9ySArpV2JH4mnI4qNPA8 dOReRSDEIf+98ADKV99DjDyzZ1O6fxs/gDME4o95Ruw6C6xUgf8uqSNHaDMuSi2dxFcL AgeQwFBYZtbEs+j108vmI9suT9xGMF+dblibg2LWhKoPrTukQnDKY/bbvXePLmgToZko RSRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=khDSn3HN6C0DPoSwIzse8rsahOD8B4aGyIt3a1qN9XU=; b=IgT5RqKmwa8xICxJKxVBD3Asq5DsfdL92bUV+ZFysgHkiZadPVCiH3nxgyo8nErw0W iaCB+dzvWd6bcTV5ty7a6ApIpjpZavanFN1UVKuFNicfVqmvcfDJtcJ7T0Meja4R7cbv NDNMSL9D3j37qe382DegKKzbsscytK+hBDGev1rBI34urVgPQGvsaXgmnS88ngn/q+Mw tOGL4gDqSgcjVCg0tll9TKgIIGi1IBtd/wYR/PV3Zb22NBnwpn/NF6/j/QnYtACOPZv4 G7cfe4l1ujVMMXQGdyxxu0kJB0Wwh6jLCfXgaFHeuufJH8t8mgX2TpUvwNfKmdKkbzjm +XCQ== X-Gm-Message-State: AG10YOQrdyp2S4dU638uJ0pRqXVV6S509JKx/md77STo08CSPhN1LdFIWMa8lUh0lwJMeOmpAPJ/7ASefYWI1A== MIME-Version: 1.0 X-Received: by 10.31.6.209 with SMTP id 200mr10330073vkg.152.1455470497426; Sun, 14 Feb 2016 09:21:37 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 09:21:37 -0800 (PST) In-Reply-To: <56BF5847.7030901@mediaarea.net> References: <568C3CA0.8040300@mediaarea.net> <56B8CD1A.20307@mediaarea.net> <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> <56BF5847.7030901@mediaarea.net> Date: Sun, 14 Feb 2016 18:21:37 +0100 Message-ID: From: Steve Lhomme To: Jerome Martinez Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Dave Rice , cellar@ietf.org, Frank Galligan , Discussion about the current and future development of Matroska Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 17:21:40 -0000 2016-02-13 17:22 GMT+01:00 Jerome Martinez : > On 13/02/2016 02:53, Dave Rice wrote: > > > On Feb 11, 2016, at 1:32 PM, Frank Galligan via Matroska-devel > wrote: > > [...] > > 4: 4:2:1 > - ChromaSubsamplingHorz :1 > - ChromaSubsamplingVert :not set > - CbSubsamplingHorz :1 > - CbSubsamplingVert :not set > - We could remove CbSubsamplingHorz and CbSubsamplingVert if we didn't > care about handling formats where the Cr and Cb channels are different > sizes. > > > I forgot about 4:2:1. That answers my question about CbSubsmaplingHorz > though perhaps we need a narrative section to expand on this with the > examples you have here. > > > I was also disturbed by CbSubsamplingHorz and CbSubsamplingVert because > there is no explaination about Cb and Cr in SubsamplingHorz and > SubsamplingVert. > So maybe we need to add explanation. > SubsamplingHorz and SubsamplingVert are for both Cb and Cr except indicat= ed > otherwise. > CbSubsamplingHorz and CbSubsamplingVert are same as SubsamplingHorz and > SubsamplingVert if not present. > > [...] > > The other issue I want to bring up is the value of "18: ARIB STD-B67 (HLG= )" > in TransferFunction. Unfortunately, in WebM we will need to use this valu= e > sooner than Matroska v4 will be finalized. Should I make this value much > higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17: SMPTE ST 428= -1" > will be standardized across most documents, like 1-15 are. Just not sure = if > 18 will be HLG. > > > I see a few references to ARIB STD-B67 as 18, such as > http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_5.pdf. Perhap= s > we need a caveat that values 1-15 are defined based upon ISO/IEC 23001-8. > > > I don't follow: either we say that the list is the ISO/MPEG one and we ne= ed > to find another way to provide HLG value, or we say that we don't care of > MPEG list. > Looks like we are in the middle (+ trying to use the FFmpeg list). > For example an answer about the reason we keep 0 and 3 as reserved is tha= t > it is in other specs, but we also say that we don't care of other specs. = I > am lost. > > About HLG, my concern is not about Matroska v4 finalization, a bit out of > topic actually (a list would be update without a new version of Matroska) > but about the MPEG list. From document pointed by Dave, looks like ARIB h= as > a deal with MPEG and ISO, or tries to force value 18 for HLG, so I would > also use value 18, hoping that MPEG and ISO and ITU will accept value 18 = for > HLG. > > Then for values 16, 17, and 18 we could add better descriptions and > citations to define it better internally. If (hopefully) a revision to > ISO/IEC 23001-8 adds those values (as expected) then we could update are > description to say all values are defined by ISO/IEC 23001-8. > > > Values 16 and 17 are already in ITU H.265 documentation. I would referenc= e > this document (bonus: it is publicly available) > I would just add a comment about value 18 =3D HLG. > > But as a general view of how we manage the list: how do we plan to manage > it? If we say we try to follow MPEG list, maybe we need to have "temporar= y" > value e.g. >0x1000000 and we wait for an official announcement from > ITU/MPEG/ISO about value 18; if we don't care on any other list, we don't > care of the value for HLG (18 or whatever). > > I think that before freezing the list, we need to clear about what is thi= s > list, if we try to follow another list we need to wait for its maintainer= , > else we need to be coherent e.g. if we don't follow MPEG or FFmpeg list, = why > do we have 0=3Dreserved and 3=3Dreserved and why 2=3Dunspecified when all= other > tags have 0=3Dunspecified and why 4 values (1, 6, 14, 15) for the same > transfer characteristic? I would ask for a reason to have such value in t= he > list or remove it from the list, i.e 0=3Dunspecified, 1=3DITU-R BT.709, 2= =3DITU-R > BT.470M... > And define a method for updating it (and say who is the list maintainer) = if > we are the "owner" of the list. The goal (of Youtube) for now is to have a set of specs that will not change in the future making their files invalid/unreadable. So I think leaving values that are still up in the air is the best strategy for now. Such values can be added later when finalizing the specs (if the other standard bodies come up with something in time). > J=C3=A9r=C3=B4me > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 09:27:40 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 186B71AD0B0 for ; Sun, 14 Feb 2016 09:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 h4rY9bY54uMM for ; Sun, 14 Feb 2016 09:27:37 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5881ACEE7 for ; Sun, 14 Feb 2016 09:27:36 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id e6so92141376vkh.2 for ; Sun, 14 Feb 2016 09:27:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4NzYwx/EDI20sPs9vybVNRu5WbMWcoNrcEkgZ2ar1uE=; b=IH4j2fp6TujYMr+hB9Hg5mQzlMdBpVUUXr/v8KetHRiXhnS2Um6j2Rxf7zucxnwOn2 l79Oa3t099JwlzxRA1RQIuyIIYYKK2mMx5mOeSpdM+IaxVxNnu7UPL/Yh2Ls6E5u3nmM H7L6IpfA0PUzFv/pJXkfU3H/44vWOQHeW1VJA6+vNp229dxinUxY3ptWj9QapnFXS2Yx 9rR6vp4F3pNQDZDTLveAA/gaoSYcUjxKPu7mFrBEkkYKY82AWcJmZj45yk1rBv7frbbn OQAbQLY4kRUvj/77HPHexpc4qsjkX2xYdBWcWoZ3Rky0JZCtCQYj0TIPk9t1lT+BZJo5 o9Tw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=4NzYwx/EDI20sPs9vybVNRu5WbMWcoNrcEkgZ2ar1uE=; b=ZuyYBM/qT4j8uIQ3exMMENhfYfG/JAdH80UR8q4wVK+Rc56qWvWbInOx0HThnnYjMt 3pPMi3uIkQL26Mk6XfNxUks7Y2p1dA4MFhI8pFjjpmejwgfWAQVAMOYMg1Tj9fAUzKGG LsjOkTZKcu2l8ab9q0MxTdr/qvHkRiYB26XyCqpk+O3sEHFSuIbzrBsQKpqjxf9KphTV ykgr5yu8lAGp64CB7mvUBS011lMK9b/DpJEBt6ZeLVzj4tJgDdWjum4uBTpo2hs2bG6X LlSwhLG8EdglejNf7myO3ieo1kjONwk7uJiscVT2IlsS8cPRVDk/rp/Taqk/Tnkd8KD4 I0RA== X-Gm-Message-State: AG10YOR07iCgAwz82ziLB4VHQASlNd9oQdrYEw9JcDF+JGqblI6SZPeeBwSJIQFND1B/tzWZ9LD98M7/bRBS0w== MIME-Version: 1.0 X-Received: by 10.31.166.208 with SMTP id p199mr10100934vke.122.1455470856033; Sun, 14 Feb 2016 09:27:36 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 09:27:35 -0800 (PST) In-Reply-To: <2C8BD209-9699-4A1D-A61B-D1519C2C3646@dericed.com> References: <74651E49-02F2-4BFF-9B91-0C78A169DD5B@dericed.com> <639B3594-4514-4BE7-BA59-8D14C856AFC5@dericed.com> <2C8BD209-9699-4A1D-A61B-D1519C2C3646@dericed.com> Date: Sun, 14 Feb 2016 18:27:35 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] adding unknownsizeallowed attribute for EBML definitions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 17:27:39 -0000 2016-02-14 18:07 GMT+01:00 Dave Rice : > > On Feb 14, 2016, at 11:47 AM, Steve Lhomme wrote: > > 2016-02-14 17:41 GMT+01:00 Dave Rice : > > > On Feb 14, 2016, at 10:26 AM, Steve Lhomme wrote: > > 2016-02-13 22:36 GMT+01:00 Dave Rice : > > Current the EBML spec implies that any Master-element may use an unknown > Element Data Size and may contain data that is not part of an EBML Elemen= t. > I propose that this should be constrained in EBML Element definitions. > > I drafted another attribute for EBML Element definitions called > unknownsizeallowed (better names welcome). > > The proposed attribute is not required and I drafted this definition: > > A boolean to express if an EBML Element MAY use an Element Data Size that= is > Unknown (having all VINT\_DATA bits set to 1). The `unknownsizeallowed` > attribute MAY only be applied to Master-elements. If the How about "only applies to Master-elements" ? And/or "the value MUST be no for elements that are not Master-elements" ? > `unknownsizeallowed` attribute is not used it is assumed that the element > not allowed to use an unknown Element Data Size. > > > With the added definition, I also changed a sentence in the definition of > the Master-element Data Type from: > > When EBML is used in transmission or streaming, data that is not part of = an > EBML Element is permitted to be present within a Master-element. > > > to > > When EBML is used in transmission or streaming, data that is not part of = an > EBML Element is permitted to be present within a Master-element if > `unknownsizeallowed` is enabled within that Master-element's definition. > > > The adjustment presumes that non-EBML junk data is only permitted in > Master-elements with unknown size. Possibly these two qualities could be > separated but I can=E2=80=99t really see a reason to have a Master-elemen= t with a > known size also contain junk data. > > A draft PR is here: > https://github.com/Matroska-Org/ebml-specification/pull/55 > > Comments? > > > From the Matrosk point of view, I don't see exactly where this would > be used, or only to restrict the feature to certain elements. > > > From my understanding, most Master-elements are not intended to ever use = an > unknown size. For example having an unknown size for the EBML Header or > ChapterTrack or Seek doesn't seem to make sense. Since the use of unknown > sizes increases the challenges to parse the stream, I propose that the EB= ML > Schema of the docType could specify where the unknown size is allowed. > > But it > seems more like a profile (live streaming or not) rather that > something to set for all Matroska files. For example an archive should > never allow such unknown sizes. This is bad for error recovery. So > should we define 2 versions of the specs ? > > > This is feasible on another layer, but I'm distinguishing: > - saying that unknown sizes are only valid for certain defined elements (= can > be clarified by the element definition) > - recommending not to use unknown sizes in certain circumstances (the rol= e > of profiles) > > > You're right. The specs should say where it's allowed (mostly not > allowed everywhere) and then profiles could restrict the use even > more. So "Allowed" in the name is good. > > Or profiles that allow > variations on the values? Such elements would be marked in the specs > with possible/allowed variations. > > I understand that some other EBML derivatives may have the use for the > feature only on specific elements and never some others. > > Also if using this, we=E2=80=99ll have to clarify which Matroska/webm ele= ments would > use this? I suspect it=E2=80=99s a small percentage of the Master-element= s declared > for those document types. > > > In practice only The Segments and (some) level-1 elements that can't > be held in memory or need low latency transmission. > > > Based on comments from Sebastian and Steve I updated the definition and > force pushed the changes to the pull request at > https://github.com/Matroska-Org/ebml-specification/pull/55/files#diff-01f= 3b0f2fbf3e44327e6072f64ddc8a0. > > Here is the updated definition for unknownsizeallowed (note it is optiona= l, > and I suggest that all elements are considered to disallow unknown-size > unless unknownsizeallowed is enabled: > > A boolean to express if an EBML Element MAY be used as an `Unknown-Sized > Element` (having all VINT\_DATA bits of Element Data Size set to 1). The > `unknownsizeallowed` attribute MAY only be applied to Master-elements. If > the `unknownsizeallowed` attribute is not used it is assumed that the > element is not allowed to use an unknown Element > > > Also in the section on Element Data Size, I changed this: > > The end of a Master-element with unknown size is determined by the beginn= ing > of the next element that is not a valid sub-element of that Master-elemen= t. > > to > > Master-elements MAY only use an unknown size is the unknownsizeallowed > attribute of the EBML Schema is set to true. The end of a Master-element > with unknown size is determined by the beginning of the next element that= is > not a valid sub-element of that Master-element. An Element with an unknow= n > Element Data Size is referred to as an Unknown-Sized Element. > > > When we get to implementing Matroska spec, I can do a survey on what > master-elements have been seen to implement unknown sizes. > > Data Size. --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 09:33:58 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A98A51B2A47 for ; Sun, 14 Feb 2016 09:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no 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 sWNrCfhLqcq8 for ; Sun, 14 Feb 2016 09:33:54 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498661B2A3E for ; Sun, 14 Feb 2016 09:33:54 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:38398 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aV0YS-000K3R-4i; Sun, 14 Feb 2016 12:33:54 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Sun, 14 Feb 2016 12:33:56 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: cellar@ietf.org X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Steve Lhomme Subject: [Cellar] Constraints to use of Root Elements Was: Matroska SeekHead questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 17:33:55 -0000 > On Jan 26, 2016, at 5:42 AM, Steve Lhomme = wrote: >=20 > 2016-01-24 21:54 GMT+01:00 Dave Rice : >> Hi all, >>=20 >> The current definition of SeekHead is "Contains the position of other = level 1 elements.=E2=80=9D >>=20 >> Is it valid to use the SeekHead to reference Elements that are not = Level 1? >=20 > There's a very good chances no player will use such values. Also > they'd be harder to interpret, since you don't know in which parent > element they belong to. >=20 >> Is there any existing official text about the use of chained = SeekHeads (SeekHeads that link to other SeekHeads)? >>=20 >> In the related section on =E2=80=9CPosition References=E2=80=9D it = says: "The position in some elements refers to the position, in octets, = from the beginning of an element. The reference is the beginning of the = first Segment element (=3D its position + the size of its ID and size = fields).=E2=80=9D Since the Segment Element can occur more than one time = in an EBML Document I wanted to verify how SeekHead works in Matroska = EBML Documents with multiple Segments. For instance in a file structure = like: >>=20 >> >> >> >> >> >> >> >> >> >>=20 >> So if I understand the definition correctly, the SeekPosition values = in all three example Elements reference the offset from the = beginning of the FIRST Segment, correct? >=20 > No, multiple concatenated either come different sources or an original > file that was split. In all cases the SeekHead references the Segment > it belongs to. It works even if you don't have the other segments. >=20 >> Related to the last question, is there a reason for the Segment = element to be multiple. I know an EBML Stream may be = , but is = allowed? If we clarify that = the =E2=80=98multiple/maxOccurs=E2=80=99 value of Level 0 Elements = refers to the occurrence within an EBML Document rather than a file, = could the Segment Element be set to non-multiple? >=20 > IMO is not allowed. And such files > probably don't exist. But we may allow it. It's not that different to > parse than when the EBML header is always preceding the Segment. I propose disallowing multiple level 0 within an EBML Document after the = EBML Header. I think this is consistent with the analogy between EBML = and XML, where XML may have an XML Declaration (equivalent of EBML = Header) and then followed by exactly one top level node. Within the EBML Schema section I suggest adding: "An EBML Schema MUST declare exactly one Element at Level 0 (referred to = as the Root Element) that MUST occur exactly once within an EBML = Document. The Root Element MUST be mandatory and MUST be defined to = occur exactly once. Note that the EBML and Void Elements may also occur = at Level 0 but are not considered to be Root Elements." With this, I also suggest changing both EBML (Header) and Segment in the = Matroska spec to non-multiple. This would mean: invalid (multiple Root Elements) invalid (only header and no Root Element) valid (the usual MKV file) valid (two concatenated EBML Documents) Thoughts? Best Regards, Dave Rice From nobody Sun Feb 14 09:42:34 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03DBE1ACEA5 for ; Sun, 14 Feb 2016 09:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 6m_tSvQ6sX_6 for ; Sun, 14 Feb 2016 09:42:30 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6302B1ACE9E for ; Sun, 14 Feb 2016 09:42:30 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:37081 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aV0gk-000XPv-8q; Sun, 14 Feb 2016 12:42:30 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_6B6363EA-8E2F-42D2-ACD3-0BB7C8CA6075" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Sun, 14 Feb 2016 12:42:30 -0500 Message-Id: <22E28BCA-A679-4B0D-AD99-324CB0CAFC31@dericed.com> References: <74651E49-02F2-4BFF-9B91-0C78A169DD5B@dericed.com> <639B3594-4514-4BE7-BA59-8D14C856AFC5@dericed.com> <2C8BD209-9699-4A1D-A61B-D1519C2C3646@dericed.com> To: Steve Lhomme X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] adding unknownsizeallowed attribute for EBML definitions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 17:42:33 -0000 --Apple-Mail=_6B6363EA-8E2F-42D2-ACD3-0BB7C8CA6075 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 14, 2016, at 12:27 PM, Steve Lhomme = wrote: >=20 > 2016-02-14 18:07 GMT+01:00 Dave Rice : >>=20 >> On Feb 14, 2016, at 11:47 AM, Steve Lhomme = wrote: >>=20 >> 2016-02-14 17:41 GMT+01:00 Dave Rice : >>=20 >>=20 >> On Feb 14, 2016, at 10:26 AM, Steve Lhomme = wrote: >>=20 >> 2016-02-13 22:36 GMT+01:00 Dave Rice : >>=20 >> Current the EBML spec implies that any Master-element may use an = unknown >> Element Data Size and may contain data that is not part of an EBML = Element. >> I propose that this should be constrained in EBML Element = definitions. >>=20 >> I drafted another attribute for EBML Element definitions called >> unknownsizeallowed (better names welcome). >>=20 >> The proposed attribute is not required and I drafted this definition: >>=20 >> A boolean to express if an EBML Element MAY use an Element Data Size = that is >> Unknown (having all VINT\_DATA bits set to 1). The = `unknownsizeallowed` >> attribute MAY only be applied to Master-elements. If the >=20 > How about "only applies to Master-elements" ? And/or "the value MUST > be no for elements that are not Master-elements" ? I used the first suggestion. We already have clarifications that unknown = sizes are only allowed for Master-elements in the Element Data Size = section. Squashed and forced. Updated PR at = https://github.com/Matroska-Org/ebml-specification/pull/55/files = . >> `unknownsizeallowed` attribute is not used it is assumed that the = element >> not allowed to use an unknown Element Data Size. >>=20 >>=20 >> With the added definition, I also changed a sentence in the = definition of >> the Master-element Data Type from: >>=20 >> When EBML is used in transmission or streaming, data that is not part = of an >> EBML Element is permitted to be present within a Master-element. >>=20 >>=20 >> to >>=20 >> When EBML is used in transmission or streaming, data that is not part = of an >> EBML Element is permitted to be present within a Master-element if >> `unknownsizeallowed` is enabled within that Master-element's = definition. >>=20 >>=20 >> The adjustment presumes that non-EBML junk data is only permitted in >> Master-elements with unknown size. Possibly these two qualities could = be >> separated but I can=E2=80=99t really see a reason to have a = Master-element with a >> known size also contain junk data. >>=20 >> A draft PR is here: >> https://github.com/Matroska-Org/ebml-specification/pull/55 >>=20 >> Comments? >>=20 >>=20 >> =46rom the Matrosk point of view, I don't see exactly where this = would >> be used, or only to restrict the feature to certain elements. >>=20 >>=20 >> =46rom my understanding, most Master-elements are not intended to = ever use an >> unknown size. For example having an unknown size for the EBML Header = or >> ChapterTrack or Seek doesn't seem to make sense. Since the use of = unknown >> sizes increases the challenges to parse the stream, I propose that = the EBML >> Schema of the docType could specify where the unknown size is = allowed. >>=20 >> But it >> seems more like a profile (live streaming or not) rather that >> something to set for all Matroska files. For example an archive = should >> never allow such unknown sizes. This is bad for error recovery. So >> should we define 2 versions of the specs ? >>=20 >>=20 >> This is feasible on another layer, but I'm distinguishing: >> - saying that unknown sizes are only valid for certain defined = elements (can >> be clarified by the element definition) >> - recommending not to use unknown sizes in certain circumstances (the = role >> of profiles) >>=20 >>=20 >> You're right. The specs should say where it's allowed (mostly not >> allowed everywhere) and then profiles could restrict the use even >> more. So "Allowed" in the name is good. >>=20 >> Or profiles that allow >> variations on the values? Such elements would be marked in the specs >> with possible/allowed variations. >>=20 >> I understand that some other EBML derivatives may have the use for = the >> feature only on specific elements and never some others. >>=20 >> Also if using this, we=E2=80=99ll have to clarify which Matroska/webm = elements would >> use this? I suspect it=E2=80=99s a small percentage of the = Master-elements declared >> for those document types. >>=20 >>=20 >> In practice only The Segments and (some) level-1 elements that can't >> be held in memory or need low latency transmission. >>=20 >>=20 >> Based on comments from Sebastian and Steve I updated the definition = and >> force pushed the changes to the pull request at >> = https://github.com/Matroska-Org/ebml-specification/pull/55/files#diff-01f3= b0f2fbf3e44327e6072f64ddc8a0. >>=20 >> Here is the updated definition for unknownsizeallowed (note it is = optional, >> and I suggest that all elements are considered to disallow = unknown-size >> unless unknownsizeallowed is enabled: >>=20 >> A boolean to express if an EBML Element MAY be used as an = `Unknown-Sized >> Element` (having all VINT\_DATA bits of Element Data Size set to 1). = The >> `unknownsizeallowed` attribute MAY only be applied to = Master-elements. If >> the `unknownsizeallowed` attribute is not used it is assumed that the >> element is not allowed to use an unknown Element >>=20 >>=20 >> Also in the section on Element Data Size, I changed this: >>=20 >> The end of a Master-element with unknown size is determined by the = beginning >> of the next element that is not a valid sub-element of that = Master-element. >>=20 >> to >>=20 >> Master-elements MAY only use an unknown size is the = unknownsizeallowed >> attribute of the EBML Schema is set to true. The end of a = Master-element >> with unknown size is determined by the beginning of the next element = that is >> not a valid sub-element of that Master-element. An Element with an = unknown >> Element Data Size is referred to as an Unknown-Sized Element. >>=20 >>=20 >> When we get to implementing Matroska spec, I can do a survey on what >> master-elements have been seen to implement unknown sizes. >>=20 >> Data Size. >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman --Apple-Mail=_6B6363EA-8E2F-42D2-ACD3-0BB7C8CA6075 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 14, 2016, at 12:27 PM, Steve Lhomme <slhomme@matroska.org> wrote:

2016-02-14 18:07 GMT+01:00 Dave Rice <dave@dericed.com>:

On Feb = 14, 2016, at 11:47 AM, Steve Lhomme <slhomme@matroska.org> wrote:

2016-02-14 17:41 GMT+01:00 Dave Rice <dave@dericed.com>:


On Feb 14, 2016, at 10:26 AM, = Steve Lhomme <slhomme@matroska.org> wrote:

2016-02-13 22:36 GMT+01:00 Dave Rice <dave@dericed.com>:

Current the EBML spec implies that any = Master-element may use an unknown
Element Data Size and = may contain data that is not part of an EBML Element.
I = propose that this should be constrained in EBML Element definitions.

I drafted another attribute for EBML Element = definitions called
unknownsizeallowed (better names = welcome).

The proposed attribute is not = required and I drafted this definition:

A = boolean to express if an EBML Element MAY use an Element Data Size that = is
Unknown (having all VINT\_DATA bits set to 1). The = `unknownsizeallowed`
attribute MAY only be applied to = Master-elements. If the

How = about "only applies to Master-elements" ? And/or "the value MUST
be no for elements that are not Master-elements" ?

I = used the first suggestion. We already have clarifications that unknown = sizes are only allowed for Master-elements in the Element Data Size = section.


`unknownsizeallowed` attribute is not used it is assumed that = the element
not allowed to use an unknown Element Data = Size.


With the added = definition, I also changed a sentence in the definition of
the Master-element Data Type from:

When EBML is used in transmission or streaming, data that is = not part of an
EBML Element is permitted to be present = within a Master-element.


to
When EBML is used in transmission or = streaming, data that is not part of an
EBML Element is = permitted to be present within a Master-element if
`unknownsizeallowed` is enabled within that Master-element's = definition.


The adjustment = presumes that non-EBML junk data is only permitted in
Master-elements with unknown size. Possibly these two = qualities could be
separated but I can=E2=80=99t really = see a reason to have a Master-element with a
known size = also contain junk data.

A draft PR is = here:
https://github.com/Matroska-Org/ebml-specification/pull/55<= br class=3D"">
Comments?


=46rom the Matrosk point of view, I don't see exactly where = this would
be used, or only to restrict the feature to = certain elements.


=46rom my = understanding, most Master-elements are not intended to ever use an
unknown size. For example having an unknown size for the EBML = Header or
ChapterTrack or Seek doesn't seem to make sense. = Since the use of unknown
sizes increases the challenges to = parse the stream, I propose that the EBML
Schema of the = docType could specify where the unknown size is allowed.
But it
seems more like a profile (live = streaming or not) rather that
something to set for all = Matroska files. For example an archive should
never allow = such unknown sizes. This is bad for error recovery. So
should we define 2 versions of the specs ?


This is feasible on another layer, but I'm = distinguishing:
- saying that unknown sizes are only valid = for certain defined elements (can
be clarified by the = element definition)
- recommending not to use unknown = sizes in certain circumstances (the role
of profiles)


You're right. The specs should = say where it's allowed (mostly not
allowed everywhere) and = then profiles could restrict the use even
more. So = "Allowed" in the name is good.

Or profiles = that allow
variations on the values? Such elements would =  be marked in the specs
with possible/allowed = variations.

I understand that some other = EBML derivatives may have the use for the
feature only on = specific elements and never some others.

Also= if using this, we=E2=80=99ll have to clarify which Matroska/webm = elements would
use this? I suspect it=E2=80=99s a small = percentage of the Master-elements declared
for those = document types.


In practice = only The Segments and (some) level-1 elements that can't
be = held in memory or need low latency transmission.


Based on comments from Sebastian and Steve I = updated the definition and
force pushed the changes to the = pull request at
https://github.com/Matroska-Org/ebml-specification/pull/55/file= s#diff-01f3b0f2fbf3e44327e6072f64ddc8a0.

Here= is the updated definition for unknownsizeallowed (note it is = optional,
and I suggest that all elements are considered = to disallow unknown-size
unless unknownsizeallowed is = enabled:

A boolean to express if an EBML = Element MAY be used as an `Unknown-Sized
Element` (having = all VINT\_DATA bits of Element Data Size set to 1). The
`unknownsizeallowed` attribute MAY only be applied to = Master-elements. If
the `unknownsizeallowed` attribute is = not used it is assumed that the
element is not allowed to = use an unknown Element


Also = in the section on Element Data Size, I changed this:

The end of a Master-element with unknown size is determined = by the beginning
of the next element that is not a valid = sub-element of that Master-element.

to

Master-elements MAY only use an unknown size = is the unknownsizeallowed
attribute of the EBML Schema is = set to true. The end of a Master-element
with unknown size = is determined by the beginning of the next element that is
not a valid sub-element of that Master-element. An Element = with an unknown
Element Data Size is referred to as an = Unknown-Sized Element.


When = we get to implementing Matroska spec, I can do a survey on what
master-elements have been seen to implement unknown sizes.

Data Size.



--
Steve = Lhomme
Matroska association Chairman

= --Apple-Mail=_6B6363EA-8E2F-42D2-ACD3-0BB7C8CA6075-- From nobody Sun Feb 14 09:44:08 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8D871B29CF for ; Sun, 14 Feb 2016 09:44:06 -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 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 8U7HVFQHbpel for ; Sun, 14 Feb 2016 09:44:05 -0800 (PST) Received: from 6.mo4.mail-out.ovh.net (6.mo4.mail-out.ovh.net [188.165.36.253]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2551B29C1 for ; Sun, 14 Feb 2016 09:44:04 -0800 (PST) Received: from mail693.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo4.mail-out.ovh.net (Postfix) with SMTP id 398CA106C1CA for ; Sun, 14 Feb 2016 18:44:03 +0100 (CET) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 14 Feb 2016 19:44:02 +0200 Received: from p5ddb6320.dip0.t-ipconnect.de (HELO ?192.168.2.101?) (jerome@francoallemand.eu@93.219.99.32) by ns0.ovh.net with SMTP; 14 Feb 2016 19:44:01 +0200 To: cellar@ietf.org References: From: Jerome Martinez Message-ID: <56C0BCD2.5080509@mediaarea.net> Date: Sun, 14 Feb 2016 18:43:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 13610159549034336402 X-Ovh-Remote: 93.219.99.32 (p5ddb6320.dip0.t-ipconnect.de) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrfeelucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrfeelgddutddvucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Constraints to use of Root Elements Was: Matroska SeekHead questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 17:44:07 -0000 On 14/02/2016 18:33, Dave Rice wrote: > [...] > This would mean: > > invalid (multiple Root Elements) > > > > I think it would break some files. > > invalid (only header and no Root Element) > > Useless but why invalid? > > valid (the usual MKV file) > > > > > valid (two concatenated EBML Documents) > > > > > I don't see the value added of repeating the EBML. Should be a valid file, but not something mandatory. > > Thoughts? we should authorize EBML header repetition, but not doing it mandatory. Jérôme From nobody Sun Feb 14 09:58:51 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585AA1B2ABD for ; Sun, 14 Feb 2016 09:58:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779] autolearn=no 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 bz404eLAdgZo for ; Sun, 14 Feb 2016 09:58:48 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2C21B2AA6 for ; Sun, 14 Feb 2016 09:58:48 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:39545 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aV0wY-000i0O-HF; Sun, 14 Feb 2016 12:58:48 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <56C0BCD2.5080509@mediaarea.net> Date: Sun, 14 Feb 2016 12:58:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56C0BCD2.5080509@mediaarea.net> To: Jerome Martinez X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Constraints to use of Root Elements Was: Matroska SeekHead questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 17:58:50 -0000 > On Feb 14, 2016, at 12:43 PM, Jerome Martinez = wrote: >=20 > On 14/02/2016 18:33, Dave Rice wrote: >> [...] >> This would mean: >>=20 >> invalid (multiple Root Elements) >>=20 >> >> >> >=20 > I think it would break some files. Example? Even the pgmx files include an EBML Header before every Segment. = http://download1.pegasys-inc.com/download_files/TPXC_materials/elephants_d= ream_rose.pgmx >> invalid (only header and no Root Element) >>=20 >> >=20 > Useless but why invalid? I suppose if someone defines docType=3D'useless' with no other elements = besides the header. But a file with only an EBML-Header would be invalid = as webm and invalid as Matroska (since Segment is mandatory). So yes it = is possible that this could be valid but a docType's EBML Schema would = have to be written to allow it. >> valid (the usual MKV file) >>=20 >> >> >>=20 >> valid (two concatenated EBML Documents) >>=20 >> >> >> >> >=20 > I don't see the value added of repeating the EBML. Should be a valid = file, but not something mandatory. The EBML may in some cases be a repeat by coincidence, but two Segments = may use different MaxIDLengths or different docTypeReadVersions that = need to be documented in their own EBML Header. To clarify, the EBML Schema rules document an EBML Document and not an = EBML Stream (such as the last example): \ EBML Dcoument #1 \ / = \ EBML Stream (comprised of two EBML Documents) \ EBML Document #2 / / = / I'm suggesting that the EBML Schema (which defines EBML Document and not = EBML Stream) restrict to one EBML Header and one Root Element (Segment = in Matroska's case) >> Thoughts? >=20 > we should authorize EBML header repetition, but not doing it = mandatory. I disagree and propose that within an EBML Document that EBML Header = should be mandatory (as read) and not repeat. This structure includes multiple EBML Headers in one EBML Document. I = don't think it makes sense and should be invalid. = This is an example of an EBML Stream comprised of two EBML Documents. = Each EBML Document is constrained to one EBML Header and one Root = Element. = and I think this stream is odd, but should be considered valid. Dave Rice= From nobody Sun Feb 14 10:08:39 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA5BE1B2B1B for ; Sun, 14 Feb 2016 10:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.621 X-Spam-Level: X-Spam-Status: No, score=0.621 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 88ARxbVv_kCl for ; Sun, 14 Feb 2016 10:08:36 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ACF41B2B1A for ; Sun, 14 Feb 2016 10:08:36 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id e6so92505132vkh.2 for ; Sun, 14 Feb 2016 10:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=+QZFEyTUvFJU7nvgvtJoFcTRFOOb8DDcubkT6/IjH8A=; b=xEgC8zwRrBWvNhtBiqNUxshaIUQS4blpSUU7d5iRQvFNnSPydGsMQiwWeCYQPFXLfm qhBZykGb7fKIpDpPJ/rCk1mrqA1+dFewbP9/HrnDNRsw5b0ZPwd2uQRTz1K7++dVyXo3 dbqdmGmK76DhSW6LfSlK+jCiyR64WDEnOk+CRCPlbGG1sn5sIikL4YbvOAtdaNbSvAm9 lvdkU2+m390xIUoKM4WFreUu3qd7ifw6eMoO0NGQeOigcdkwFppizf7VIrjO8LBsyY4p qRPscAMKhvXqkVxmzPFaitz5Hh5DW9J2bA5UN03GkcBiGWf1+SO2y6hrQ+B0f/dtX9RI mRcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=+QZFEyTUvFJU7nvgvtJoFcTRFOOb8DDcubkT6/IjH8A=; b=C7mG/ZJPeB3lgIgzY3Dh/EOhisSJ1dyBAZPwcvwDPTss0rRz6RNSNPFLy6qcOvxzVZ e5VKqIOfGgZmsLVNN5qxnZyJkZ298IvRRjq3nO6deGqNL6Z4YNZq8g4WUKTblzoHm9X0 y9NDczaASH1ytqr0P036lgQUb7iPER9cTVZ4bwv2G1HoEXAhNJW/OV1XBK7YAC7L1Mxa LOvIbZzcKiiQmnWzke9zIbk0U1NMhf0Fp3dJjx8WdvkcjVnEo9gMfiQDmPkLhNg6P+9X tepyrEiEbYR/usnbINq+e8zm+qO902p+6p3LdLcgwxVULO2gHU68YkgYl02y4eWIc/AF b5ww== X-Gm-Message-State: AG10YOQ6LWTJ4sX8AjL7wZhsZcTVimbzwK8FOuGbI1VHYcYL0qTFMy/BX6aIcNko5zev/kSZVRLWCRggy6piIQ== MIME-Version: 1.0 X-Received: by 10.31.5.9 with SMTP id 9mr10131937vkf.109.1455473315361; Sun, 14 Feb 2016 10:08:35 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 10:08:35 -0800 (PST) In-Reply-To: References: Date: Sun, 14 Feb 2016 19:08:35 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Constraints to use of Root Elements Was: Matroska SeekHead questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 18:08:37 -0000 2016-02-14 18:33 GMT+01:00 Dave Rice : > >> On Jan 26, 2016, at 5:42 AM, Steve Lhomme wrote: >> >> 2016-01-24 21:54 GMT+01:00 Dave Rice : >>> Hi all, >>> >>> The current definition of SeekHead is "Contains the position of other l= evel 1 elements.=E2=80=9D >>> >>> Is it valid to use the SeekHead to reference Elements that are not Leve= l 1? >> >> There's a very good chances no player will use such values. Also >> they'd be harder to interpret, since you don't know in which parent >> element they belong to. >> >>> Is there any existing official text about the use of chained SeekHeads = (SeekHeads that link to other SeekHeads)? >>> >>> In the related section on =E2=80=9CPosition References=E2=80=9D it says= : "The position in some elements refers to the position, in octets, from th= e beginning of an element. The reference is the beginning of the first Segm= ent element (=3D its position + the size of its ID and size fields).=E2=80= =9D Since the Segment Element can occur more than one time in an EBML Docum= ent I wanted to verify how SeekHead works in Matroska EBML Documents with m= ultiple Segments. For instance in a file structure like: >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> So if I understand the definition correctly, the SeekPosition values in= all three example Elements reference the offset from the beginn= ing of the FIRST Segment, correct? >> >> No, multiple concatenated either come different sources or an original >> file that was split. In all cases the SeekHead references the Segment >> it belongs to. It works even if you don't have the other segments. >> >>> Related to the last question, is there a reason for the Segment element= to be multiple. I know an EBML Stream may be , but is allowed? If we c= larify that the =E2=80=98multiple/maxOccurs=E2=80=99 value of Level 0 Eleme= nts refers to the occurrence within an EBML Document rather than a file, co= uld the Segment Element be set to non-multiple? >> >> IMO is not allowed. And such files >> probably don't exist. But we may allow it. It's not that different to >> parse than when the EBML header is always preceding the Segment. > > I propose disallowing multiple level 0 within an EBML Document after the = EBML Header. I think this is consistent with the analogy between EBML and X= ML, where XML may have an XML Declaration (equivalent of EBML Header) and t= hen followed by exactly one top level node. As mentioned on the DVD discussion, concatenation is a good way to have different parts that don't have the same Track Info (for instance) but are still tied together in one bigger entitity. There's Segment linking but this makes it easier to pass the file. The various segment (files) could be tar'ed but then you don't know it's a Matroska file until you open the tar and parse what's inside. > Within the EBML Schema section I suggest adding: > > "An EBML Schema MUST declare exactly one Element at Level 0 (referred to = as the Root Element) that MUST occur exactly once within an EBML Document. = The Root Element MUST be mandatory and MUST be defined to occur exactly onc= e. Note that the EBML and Void Elements may also occur at Level 0 but are n= ot considered to be Root Elements." > > With this, I also suggest changing both EBML (Header) and Segment in the = Matroska spec to non-multiple. > > This would mean: > > invalid (multiple Root Elements) > > > > > > invalid (only header and no Root Element) > > > > valid (the usual MKV file) > > > > > valid (two concatenated EBML Documents) > > > > > If that's valid, then it's fine with me. Although it should be noted that in that case the second EBML header is not taken in consideration and only the first one is used. That's to ensure the whole block of concatenanted data can be handled just by knowing the first header. Also that you don't mix different DocType in the same file (or do we want to allow that ?). Meaning could also be valid. > Thoughts? > > Best Regards, > Dave Rice > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 10:10:26 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C761B2B2E for ; Sun, 14 Feb 2016 10:10:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.422 X-Spam-Level: * X-Spam-Status: No, score=1.422 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 9Y3xzxY8o_dn for ; Sun, 14 Feb 2016 10:10:23 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B2B1B2B2C for ; Sun, 14 Feb 2016 10:10:22 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id e185so92708305vkb.1 for ; Sun, 14 Feb 2016 10:10:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ztdgDHKx8pNslMDEmC8Nk4rDdf5qg5JfY7FkHUEvo+w=; b=FWg+BYQRG2EeaMvUuV2IjwMp5b8Q+qUpVMB4iWapBfwL9me+FMANgPSEA4Bfiqqa26 zgkkm5rqhKvIeKn5iI4bk0L8x20UGoMHDu/clEXBLu9mMyIoEC+AKvki4OLIRAKYFgHz GysMP8BE3nqJmxNyz8B8mnPSacajnpNLfpdokTySFFvZPJZNCf70H7FfwWBU1vG5LbYQ Uh0TywizatIprM2YMl/5RIDKqXfWvwlFk1eMUX+LNHlLhRB0qYCPE2Xca/9UhiuvAjPY cIrNixFKTAr9vwi4s93lRUCG6GBPm/ky0GkpjXN4lkVVB977+C0djGSFB7wI5++8glRj imlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ztdgDHKx8pNslMDEmC8Nk4rDdf5qg5JfY7FkHUEvo+w=; b=gir1WSgjdfwmTOHsrnT+5Un7HKs3CrBoYjGkNaVToVhQfGhK0Ic2DjS2jMlRL0uhgp b50Pjo8ACz1t6Tg67On3TSnNsJMuD5VUDfo4a1qGXlb32ftdb1m+VKCe/n9ol9pSJaKK ATaYnIbcvMU82pzZXpMtnXRTq7pWcoeDdFEUE5w0blkxIfndzotXH0fzOXjErRBA95e2 aEJ1jwHnoL9+N5EIcz655qyAZMXpORoS10FO+d3FaCh/ftJJROpCz2H2VQQJq7yu1eCg MaxpFf1zQBhvgFsugr8ARxTqaeSO9futd9FivbJH+fZDIlVQ5VItCVLFJ3DBOFtpQwwx GG/w== X-Gm-Message-State: AG10YORS9sqmHZHtzXSzgkYF3uDm3wAkeOzrRskHBnSx7XmWa23GenpuIHrKklUhvT4zDBdGB/YCvFtgWbzKkQ== MIME-Version: 1.0 X-Received: by 10.31.168.76 with SMTP id r73mr10118204vke.117.1455473422021; Sun, 14 Feb 2016 10:10:22 -0800 (PST) Received: by 10.31.61.204 with HTTP; Sun, 14 Feb 2016 10:10:21 -0800 (PST) In-Reply-To: <22E28BCA-A679-4B0D-AD99-324CB0CAFC31@dericed.com> References: <74651E49-02F2-4BFF-9B91-0C78A169DD5B@dericed.com> <639B3594-4514-4BE7-BA59-8D14C856AFC5@dericed.com> <2C8BD209-9699-4A1D-A61B-D1519C2C3646@dericed.com> <22E28BCA-A679-4B0D-AD99-324CB0CAFC31@dericed.com> Date: Sun, 14 Feb 2016 19:10:21 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] adding unknownsizeallowed attribute for EBML definitions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 18:10:24 -0000 2016-02-14 18:42 GMT+01:00 Dave Rice : > > On Feb 14, 2016, at 12:27 PM, Steve Lhomme wrote: > > 2016-02-14 18:07 GMT+01:00 Dave Rice : > > > On Feb 14, 2016, at 11:47 AM, Steve Lhomme wrote: > > 2016-02-14 17:41 GMT+01:00 Dave Rice : > > > On Feb 14, 2016, at 10:26 AM, Steve Lhomme wrote: > > 2016-02-13 22:36 GMT+01:00 Dave Rice : > > Current the EBML spec implies that any Master-element may use an unknown > Element Data Size and may contain data that is not part of an EBML Elemen= t. > I propose that this should be constrained in EBML Element definitions. > > I drafted another attribute for EBML Element definitions called > unknownsizeallowed (better names welcome). > > The proposed attribute is not required and I drafted this definition: > > A boolean to express if an EBML Element MAY use an Element Data Size that= is > Unknown (having all VINT\_DATA bits set to 1). The `unknownsizeallowed` > attribute MAY only be applied to Master-elements. If the > > > How about "only applies to Master-elements" ? And/or "the value MUST > be no for elements that are not Master-elements" ? > > > I used the first suggestion. We already have clarifications that unknown > sizes are only allowed for Master-elements in the Element Data Size secti= on. > > Squashed and forced. Updated PR at > https://github.com/Matroska-Org/ebml-specification/pull/55/files. > > `unknownsizeallowed` attribute is not used it is assumed that the element > not allowed to use an unknown Element Data Size. > > > With the added definition, I also changed a sentence in the definition of > the Master-element Data Type from: > > When EBML is used in transmission or streaming, data that is not part of = an > EBML Element is permitted to be present within a Master-element. > > > to > > When EBML is used in transmission or streaming, data that is not part of = an > EBML Element is permitted to be present within a Master-element if > `unknownsizeallowed` is enabled within that Master-element's definition. > > > The adjustment presumes that non-EBML junk data is only permitted in > Master-elements with unknown size. Possibly these two qualities could be > separated but I can=E2=80=99t really see a reason to have a Master-elemen= t with a > known size also contain junk data. > > A draft PR is here: > https://github.com/Matroska-Org/ebml-specification/pull/55 > > Comments? Merged. > From the Matrosk point of view, I don't see exactly where this would > be used, or only to restrict the feature to certain elements. > > > From my understanding, most Master-elements are not intended to ever use = an > unknown size. For example having an unknown size for the EBML Header or > ChapterTrack or Seek doesn't seem to make sense. Since the use of unknown > sizes increases the challenges to parse the stream, I propose that the EB= ML > Schema of the docType could specify where the unknown size is allowed. > > But it > seems more like a profile (live streaming or not) rather that > something to set for all Matroska files. For example an archive should > never allow such unknown sizes. This is bad for error recovery. So > should we define 2 versions of the specs ? > > > This is feasible on another layer, but I'm distinguishing: > - saying that unknown sizes are only valid for certain defined elements (= can > be clarified by the element definition) > - recommending not to use unknown sizes in certain circumstances (the rol= e > of profiles) > > > You're right. The specs should say where it's allowed (mostly not > allowed everywhere) and then profiles could restrict the use even > more. So "Allowed" in the name is good. > > Or profiles that allow > variations on the values? Such elements would be marked in the specs > with possible/allowed variations. > > I understand that some other EBML derivatives may have the use for the > feature only on specific elements and never some others. > > Also if using this, we=E2=80=99ll have to clarify which Matroska/webm ele= ments would > use this? I suspect it=E2=80=99s a small percentage of the Master-element= s declared > for those document types. > > > In practice only The Segments and (some) level-1 elements that can't > be held in memory or need low latency transmission. > > > Based on comments from Sebastian and Steve I updated the definition and > force pushed the changes to the pull request at > https://github.com/Matroska-Org/ebml-specification/pull/55/files#diff-01f= 3b0f2fbf3e44327e6072f64ddc8a0. > > Here is the updated definition for unknownsizeallowed (note it is optiona= l, > and I suggest that all elements are considered to disallow unknown-size > unless unknownsizeallowed is enabled: > > A boolean to express if an EBML Element MAY be used as an `Unknown-Sized > Element` (having all VINT\_DATA bits of Element Data Size set to 1). The > `unknownsizeallowed` attribute MAY only be applied to Master-elements. If > the `unknownsizeallowed` attribute is not used it is assumed that the > element is not allowed to use an unknown Element > > > Also in the section on Element Data Size, I changed this: > > The end of a Master-element with unknown size is determined by the beginn= ing > of the next element that is not a valid sub-element of that Master-elemen= t. > > to > > Master-elements MAY only use an unknown size is the unknownsizeallowed > attribute of the EBML Schema is set to true. The end of a Master-element > with unknown size is determined by the beginning of the next element that= is > not a valid sub-element of that Master-element. An Element with an unknow= n > Element Data Size is referred to as an Unknown-Sized Element. > > > When we get to implementing Matroska spec, I can do a survey on what > master-elements have been seen to implement unknown sizes. > > Data Size. > > > > > -- > Steve Lhomme > Matroska association Chairman > > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 14 11:09:17 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806B91B2C37 for ; Sun, 14 Feb 2016 11:09:16 -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 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 iBlfFLffFzcf for ; Sun, 14 Feb 2016 11:09:14 -0800 (PST) Received: from 2.mo4.mail-out.ovh.net (2.mo4.mail-out.ovh.net [46.105.72.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382351B2C31 for ; Sun, 14 Feb 2016 11:09:14 -0800 (PST) Received: from mail693.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo4.mail-out.ovh.net (Postfix) with SMTP id A247F10AC0F3 for ; Sun, 14 Feb 2016 20:09:11 +0100 (CET) Received: from localhost (HELO queueout) (127.0.0.1) by localhost with SMTP; 14 Feb 2016 21:09:11 +0200 Received: from p5ddb6320.dip0.t-ipconnect.de (HELO ?192.168.2.101?) (jerome@francoallemand.eu@93.219.99.32) by ns0.ovh.net with SMTP; 14 Feb 2016 21:09:10 +0200 To: cellar@ietf.org References: From: Jerome Martinez Message-ID: <56C0D0D6.8000005@mediaarea.net> Date: Sun, 14 Feb 2016 20:09:10 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 15048215206060232850 X-Ovh-Remote: 93.219.99.32 (p5ddb6320.dip0.t-ipconnect.de) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-OVH-SPAMSTATE: OK X-OVH-SPAMSCORE: 0 X-OVH-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrfeelucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeekjedrfeelgdduvdduucetufdoteggodftvfcurfhrohhfihhlvgemucfqggfjnecuuegrihhlohhuthemuceftddtnecu Archived-At: Subject: Re: [Cellar] Constraints to use of Root Elements Was: Matroska SeekHead questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 19:09:16 -0000 On 14/02/2016 19:08, Steve Lhomme wrote: > 2016-02-14 18:33 GMT+01:00 Dave Rice : > [...] > >> Within the EBML Schema section I suggest adding: >> >> "An EBML Schema MUST declare exactly one Element at Level 0 (referred to as the Root Element) that MUST occur exactly once within an EBML Document. The Root Element MUST be mandatory and MUST be defined to occur exactly once. Note that the EBML and Void Elements may also occur at Level 0 but are not considered to be Root Elements." >> >> With this, I also suggest changing both EBML (Header) and Segment in the Matroska spec to non-multiple. >> >> This would mean: >> >> invalid (multiple Root Elements) >> >> >> >> >> >> invalid (only header and no Root Element) >> >> >> >> valid (the usual MKV file) >> >> >> >> >> valid (two concatenated EBML Documents) >> >> >> >> >> > If that's valid, then it's fine with me. Although it should be noted > that in that case the second EBML header is not taken in consideration > and only the first one is used. That's to ensure the whole block of > concatenanted data can be handled just by knowing the first header. but if the second EBML header is different, analysis is wrong. So if we say that only the first one EBML header should be read: - we must state that we can concatenate files only if they have the same EBML header (so same Matroska version? I don't the reason we should mandate that Matroska versions are same) - we must state that EBML header must be identical. From my point of view that does not make sense (why do we need to duplicate the EBML header in that case). I am ok for having EBML header before each segment, but in that case the EBML header just before the segment should be considered as having the right info (e.g. Matroska version). I am afraid about such file: EBML header with Matroska v4 (from file 1) Segment conforming to Matroska v4 (from file 1) EBML header with Matroska v5 (from file 2) Segment conforming to Matroska v5 (from file 2) In the case we have first EBML header as the reference header, we parse second segment as Matroska v4 but it is actually v5. > Also that you don't mix different DocType in the same file (or do we > want to allow that ?). Meaning could also > be valid. Is there any reason we don't want different DocType? (and DocTypeReadVersion?) Jérôme From nobody Sun Feb 14 11:11:15 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C161B1ACCF3 for ; Sun, 14 Feb 2016 11:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.746 X-Spam-Level: *** X-Spam-Status: No, score=3.746 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 Bh70J-rqIGoF for ; Sun, 14 Feb 2016 11:11:11 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E066D1A006D for ; Sun, 14 Feb 2016 11:11:11 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:48128 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aV24b-002i0F-B8; Sun, 14 Feb 2016 14:11:11 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_B4825405-E4F9-4DAD-8F83-3173B59C7E3C" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Sun, 14 Feb 2016 14:11:05 -0500 Message-Id: References: To: Nithin Mathew Kurien X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] expressing a float in text X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 19:11:13 -0000 --Apple-Mail=_B4825405-E4F9-4DAD-8F83-3173B59C7E3C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 13, 2016, at 2:24 PM, Nithin Mathew Kurien = wrote: >=20 > Hi, >=20 > Not sure if it is suitable in this context, but C99 supports writing = floats accurately in hexadecimal notation = (http://www.exploringbinary.com/hexadecimal-floating-point-constants/ = ). = The advantage of hexadecimal notation is that values can be represented = accurately, unlike representions like 1.67e-3, which will result in = rounding errors when converted from decimal to the native binary form. = With a C99 compiler like GCC, we can output the hexadecimal form of any = float. >=20 > double num =3D 1.55e1; > printf("%a", num); >=20 > would output >=20 > 0x1.fp3 >=20 > which is equal to (1 + 15/16) * 2^3. For values such as 0.0 and 1.0, wouldn't the C99 notation be different = depending on if the float is expressed as a single or double? Currently = an EBML float could be either 4 or 8 bytes and the choice of float = length is not part of the element definition. If we use C99 notation we = may be implying whether the float is single or double and should = consider saying so in the definition. Dave > Thanks and regards, > Nithin >=20 >=20 > On Sun, Feb 14, 2016 at 12:20 AM, Dave Rice > wrote: > To accommodate the float range expressions in Frank=E2=80=99s color = work, I=E2=80=99m expanding the =E2=80=9CExpression of range=E2=80=9D = [1] section to accommodate floats (currently it only discusses signed = and unsigned integers). Frank=E2=80=99s use of float ranges are quite = simple, such as 0.0 to 1.0; however, in defining a method to document a = float range, I think the definition should work for any possible float = value. >=20 > Is there an standard document to point to for how to represent a float = value as text? i.e. I=E2=80=99m familiar with float values in text such = as 3.88E-4 but where it this style of expression defined? >=20 > Best Regards, > Dave Rice >=20 > [1] = https://github.com/Matroska-Org/ebml-specification/blob/master/specificati= on.markdown#expression-of-range = > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar = >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_B4825405-E4F9-4DAD-8F83-3173B59C7E3C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 13, 2016, at 2:24 PM, Nithin Mathew Kurien <nithinmkurien@gmail.com> wrote:

Hi,

Not = sure if it is suitable in this context, but C99 supports writing floats = accurately in hexadecimal notation (http://www.exploringbinary.com/hexadecimal-floating-point-const= ants/). The advantage of hexadecimal notation is that values can be = represented accurately, unlike representions like 1.67e-3, which will = result in rounding errors when converted from decimal to the native = binary form. With a C99 compiler like GCC, we can output the hexadecimal = form of any float.

double num  =3D 1.55e1;
printf("%a", num);

would output

0x1.fp3

which = is equal to (1 + 15/16) * = 2^3.

For values such as 0.0 and 1.0, wouldn't the C99 = notation be different depending on if the float is expressed as a single = or double? Currently an EBML float could be either 4 or 8 bytes and the = choice of float length is not part of the element definition. If we use = C99 notation we may be implying whether the float is single or double = and should consider saying so in the definition.
Dave

Thanks and = regards,
Nithin


On Sun, = Feb 14, 2016 at 12:20 AM, Dave Rice <dave@dericed.com> wrote:
To accommodate the = float range expressions in Frank=E2=80=99s color work, I=E2=80=99m = expanding the =E2=80=9CExpression of range=E2=80=9D [1] section to = accommodate floats (currently it only discusses signed and unsigned = integers). Frank=E2=80=99s use of float ranges are quite simple, such as = 0.0 to 1.0; however, in defining a method to document a float range, I = think the definition should work for any possible float value.

Is there an standard document to point to for how to represent a float = value as text? i.e. I=E2=80=99m familiar with float values in text such = as 3.88E-4 but where it this style of expression defined?

Best Regards,
Dave Rice

[1] https://github.com/Matroska-Org/ebml-specification/blob/master/= specification.markdown#expression-of-range
_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar
=

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

= --Apple-Mail=_B4825405-E4F9-4DAD-8F83-3173B59C7E3C-- From nobody Sun Feb 14 11:14:46 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD721B2C6C for ; Sun, 14 Feb 2016 11:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no 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 9Rwrq0-Zdv24 for ; Sun, 14 Feb 2016 11:14:44 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568D51B2C6F for ; Sun, 14 Feb 2016 11:14:44 -0800 (PST) Received: from user-387g4ij.cable.mindspring.com ([208.120.18.83]:33799 helo=[10.0.1.4]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aV282-002jsU-4b; Sun, 14 Feb 2016 14:14:44 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: <56C0D0D6.8000005@mediaarea.net> Date: Sun, 14 Feb 2016 14:14:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56C0D0D6.8000005@mediaarea.net> To: Jerome Martinez X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Constraints to use of Root Elements Was: Matroska SeekHead questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 14 Feb 2016 19:14:46 -0000 > On Feb 14, 2016, at 2:09 PM, Jerome Martinez = wrote: >=20 > On 14/02/2016 19:08, Steve Lhomme wrote: >> 2016-02-14 18:33 GMT+01:00 Dave Rice : >> [...] >>=20 >>> Within the EBML Schema section I suggest adding: >>>=20 >>> "An EBML Schema MUST declare exactly one Element at Level 0 = (referred to as the Root Element) that MUST occur exactly once within an = EBML Document. The Root Element MUST be mandatory and MUST be defined to = occur exactly once. Note that the EBML and Void Elements may also occur = at Level 0 but are not considered to be Root Elements." >>>=20 >>> With this, I also suggest changing both EBML (Header) and Segment in = the Matroska spec to non-multiple. >>>=20 >>> This would mean: >>>=20 >>> invalid (multiple Root Elements) >>>=20 >>> >>> >>> >>>=20 >>> invalid (only header and no Root Element) >>>=20 >>> >>>=20 >>> valid (the usual MKV file) >>>=20 >>> >>> >>>=20 >>> valid (two concatenated EBML Documents) >>>=20 >>> >>> >>> >>> >> If that's valid, then it's fine with me. Although it should be noted >> that in that case the second EBML header is not taken in = consideration >> and only the first one is used. That's to ensure the whole block of >> concatenanted data can be handled just by knowing the first header. >=20 > but if the second EBML header is different, analysis is wrong. > So if we say that only the first one EBML header should be read: > - we must state that we can concatenate files only if they have the = same EBML header (so same Matroska version? I don't the reason we should = mandate that Matroska versions are same) > - we must state that EBML header must be identical. >=20 > =46rom my point of view that does not make sense (why do we need to = duplicate the EBML header in that case). >=20 > I am ok for having EBML header before each segment, but in that case = the EBML header just before the segment should be considered as having = the right info (e.g. Matroska version). >=20 > I am afraid about such file: > EBML header with Matroska v4 (from file 1) > Segment conforming to Matroska v4 (from file 1) > EBML header with Matroska v5 (from file 2) > Segment conforming to Matroska v5 (from file 2) >=20 > In the case we have first EBML header as the reference header, we = parse second segment as Matroska v4 but it is actually v5. Just a reminder that our current definition for EBML Stream (a = concatenation of EBML Documents) is: "An EBML Stream is a file that = consists of one or many EBML Documents that are concatenated together. = An occurrence of a Level 0 EBML Header marks the beginning of an EBML = Document." The current definition doesn't include the presumptions that we're = currently discussing. The documentation doesn't prevent a variety of = EBML docTypes could be concatenated and streamed. >> Also that you don't mix different DocType in the same file (or do we >> want to allow that ?). Meaning could also >> be valid. >=20 > Is there any reason we don't want different DocType? (and = DocTypeReadVersion?) >=20 > J=C3=A9r=C3=B4me >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Tue Feb 16 01:01:46 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB5C1A88D4 for ; Tue, 16 Feb 2016 01:01:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 XdYq55BTUnnP for ; Tue, 16 Feb 2016 01:01:43 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1C8E1A8715 for ; Tue, 16 Feb 2016 01:01:43 -0800 (PST) Received: from [192.168.0.14] (chello213047163139.5.15.vie.surfer.at [::ffff:213.47.163.139]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Tue, 16 Feb 2016 10:01:39 +0100 id 000000000000002B.0000000056C2E573.00001BC5 Message-ID: <56C2E573.30701@das-werkstatt.com> Date: Tue, 16 Feb 2016 10:01:39 +0100 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: cellar@ietf.org References: <568C3CA0.8040300@mediaarea.net> <56B8CD1A.20307@mediaarea.net> In-Reply-To: <56B8CD1A.20307@mediaarea.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cellar] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2016 09:01:45 -0000 On 02/08/2016 06:15 PM, Jerome Martinez wrote: > Does anyone plan to transfer from DPX? If yes, we may need to add now > missing elements in the list (e.g. "Printing density") but I am not > expert enough for know which one is worth it. I wouldn't want to rule out the option of transcoding from DPX to FFV1/MKV. But on the other hand, I'm very much in favor of keeping things simple - and not overdoing it. I think being able to handle non-linear color values (as often found in DPX scans) is important, but I wouldn't go as far as putting something like "printing density" into the standard. Anyone more familiar with digital film, please correct or augment my statements, as I'm not so experienced with film. Kind regards, Pb From nobody Tue Feb 16 11:01:45 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7A61B2B55 for ; Tue, 16 Feb 2016 11:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 Qa4X8CQa_12l for ; Tue, 16 Feb 2016 11:01:37 -0800 (PST) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8DA61ACD24 for ; Tue, 16 Feb 2016 11:01:36 -0800 (PST) Received: by mail-ob0-x22d.google.com with SMTP id xk3so272018271obc.2 for ; Tue, 16 Feb 2016 11:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=00APvKner8rVFAvgd0Fa9XhFh8Dp0pCsOSX0tSzh0dM=; b=G1WTg1bv8WG2Sa+98mwnsStlpq8R/yYsYRKrzEoEho4Yue0TLHsJ19B0+k1XKXrAIH DXCoxwJli6M5fLDPqAgjs1ZeW7eI4gYri3BluglymlBGssd72BN2uOcayxG/c00Tdv7l 8V7ikci9v1R94yTPDBhiH9uvqdBB43bI5bw5rRh2SI8vBXo5kL51De79jFnQTA09MvVu qPci7PsETRrPtFI/ZGFKRh4lx4RF/Xd93vAKCq3USpD6xIT+uGsIP/K9ExupaKFjqaim M9lL9rZOIFcUJB1LNVeQvhfQ67/UHWjmMHRQ9i+p+0IZMzch2tngteITTwAe80A0vwAV B8SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=00APvKner8rVFAvgd0Fa9XhFh8Dp0pCsOSX0tSzh0dM=; b=NkY7Ur7hyaxcgtzpGQHpMepNQchLhj+40vT9fhq+Ob3wiupostt04GUo/y5W0N0kM7 yt18HWZY21U4WdHq/NOd4smCjEbDLJK8cmaBe868ZttSoxL3rp/V7hgZqnTmoWUH3WAC UM2sbFk1/nrj6vCSURPc2AGOqcFujJdSNs80SXS9AOPrC/U2iFCEtf7kvxU84vFu6TYJ xK+4Nt2ooS394n4xytOQLelSOJtLootqLlHYdaqgMYfxA0hTG8zNhaT3bOuh6gQkiKbW D48Vlw7+JY/ToCSJ0vu2rgdRaXiP8nQPDdrQnEgsbe/3V+J8o8yOScGqvdvhDNPHKu0z rG7g== X-Gm-Message-State: AG10YOSJYw3v80xU0uVtPOQLS+g3lef3oCYS1AF/HssarFwwpkZthTbYj50lzqdXXpWRTzA0FtDqat91dgIMDA== MIME-Version: 1.0 X-Received: by 10.182.16.233 with SMTP id j9mr19616192obd.9.1455649293953; Tue, 16 Feb 2016 11:01:33 -0800 (PST) Received: by 10.202.59.130 with HTTP; Tue, 16 Feb 2016 11:01:33 -0800 (PST) In-Reply-To: <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> References: <568C3CA0.8040300@mediaarea.net> <56B8CD1A.20307@mediaarea.net> <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> Date: Tue, 16 Feb 2016 11:01:33 -0800 Message-ID: From: Frank Galligan To: Dave Rice Content-Type: multipart/alternative; boundary=001a11c30aa215733d052be7c397 Archived-At: Cc: Jerome Martinez , Discussion about the current and future development of Matroska , cellar@ietf.org Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2016 19:01:43 -0000 --001a11c30aa215733d052be7c397 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 12, 2016 at 5:53 PM, Dave Rice wrote: > Hi, > > > Element Name: Colour > Level: 4 > ID: [55][B0] > Mandatory: - > Multiple: - > Default: - > Type: m > Description: Settings describing the colour format. > > > Element Name: Matrix > > > To align better with ISO/IEC 23001-8, could this be labelled as > MatrixCoefficients? > Done > > Level: 5 > ID: [55][B1] > Mandatory: - > Multiple: - > Default: 2 > Type: u > Description: ColourMatrix of the video. See ISO/IEC 23001-8 for more > information on enumerations. (0: IEC 61966-2-1 (sRGB), 1: > BT709, > 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE > 170M, > 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance, > 10: BT2020 Constant Luminance) > > > Suggested description edit: > The Matrix Coefficients of the video used to derive luma and chroma value= s > from reg, green, and blue color primaries. For clarity, the value and > meanings for MatrixCoefficients are adopted from Table 4 of ISO/IEC > 23001-8:2013/DCOR1. (0: IEC 61966-2-1 (sRGB), 1: BT709, 2: Unspecified, 3= : > Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: YCOCG, 9: > BT2020 Non-constant Luminance, 10: BT2020 Constant Luminance) > Done > > Question: > Value 0 is listed as "IEC 61966-2-1 (sRGB)" but the table for matrix > coefficients in ISO/IEC 23001-8 says "GBR / Typically referred to as RGB"= . > Should value 0 =3D RGB? > I changed it to GBR to match 23001-8. > Add footnote: > [IEC23001-8] ISO/IEC 23001-8:2013/DCOR1, "Coding independent media > description code points", 2013, < > http://standards.iso.org/ittf/PubliclyAvailableStandards/c062088_ISO_IEC_= 23001-8_2013.zip > >. > > Element Name: BitsPerChannel > Level: 5 > ID: [55][B2] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: Number of decoded bits per channel. This number may be less > for > specific channels depending on the Matrix and > ChromaSubsampling. A > value of 0 is unspecified. > > > It may be fine, but I don't understand "This number may be less for > specific channels depending on the Matrix and ChromaSubsampling." Is the > value is less for specific channels, then it seems as if the value would > different among channels, but only one BitsPerChannel is stored for a > multi-channel video. > So we could have separate bits per channel, but then we would have to define rgb and yuv. Most people know what this is. Basically the information needed is, will the decoded video be 8 bits, 10 bits, 12 bits, 16 bits, ... Maybe I was just trying to be a little too pedantic. I'm fine with removing this sentence. if any of the ChromaSubsampling elements are set then that implies that one or more channels will have a different value= . So how about we just remove this sentence? > I suggest changing the last line to: A value of 0 indicates that the > BitsPerChannel is unspecified. > Done > > Element Name: ChromaSubsamplingHorz > Level: 5 > ID: [55][B3] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of chrominance pixels to remove for every > chrominance > pixel not removed horizontally. > > > For these subsampling elements, we may need a statement to say when they > should be used. For instance in QuickTime's TN2162 > https://developer.apple.com/library/mac/technotes/tn2162/_index.html it > mandates the use of many values to better describe uncompressed video. Wh= en > would these chroma subsampling elements be suggested? > I'm not really sure I follow. If any of the Cb or Cr channels are down sized before encoding, then these elements should be set accordingly. > I also suggest including an example; such as "Example: For video with > 4:1:1 chroma subsampling the ChromaSubsamplingHorz should be set to 3. > I added "Example: For video with 4:2:0 chroma subsampling the ChromaSubsamplingHorz should be set to 1." As pretty much most video is 4:4:4 or 4:2:0 nowadays. > Element Name: ChromaSubsamplingVert > Level: 5 > ID: [55][B4] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of chrominance pixels to remove for every > chrominance > pixel not removed vertically. > > Element Name: CbSubsamplingHorz > Level: 5 > ID: [55][B5] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of Cb chrominance pixels to remove for every Cb > chrominance pixel not removed horizontally. This is additive > with > ChromaSubsamplingHorz. > > > I'm confused about the relationship between CbSubsamplingHorz > and ChromaSubsamplingHorz. > These elements are only defined because I was trying to handle 4:2:1. Basically this is an old format where the Cr channel is half the size of the Y channel, and the Cb channel is half the size of the Cr channel. The Cb channel is a quarter the size of the Y channel. The CbSubsampling* elements were a late edition, right before I sent my previous email. At first I didn't have these elements and had text that 4:2:1 was not supported. How about I change the CbSubsamplingHorz element text too: "The amount of pixels to remove in the Cr and Cb channels for every pixel not removed horizontally." And the CbSubsamplingHorz too: "The amount of pixels to remove in the Cb channel for every pixel not removed horizontally. This is additive with ChromaSubsamplingHorz. Example: For video with 4:2:1 chroma subsampling the ChromaSubsamplingHorz should be set to 1 and CbSubsamplingHorz should be set to 1." Does this help the confusion? > Element Name: CbSubsamplingVert > Level: 5 > ID: [55][B6] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of Cb chrominance pixels to remove for every Cb > chrominance pixel not removed vertically. This is additive > with > ChromaSubsamplingVert. > > > Element Name: ChromaSitingHorz > Level: 5 > ID: [55][B7] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: How Chroma is subsampled horizontally. (0: Unspecified, 1: > Left > collocated , 2: Half) > > Element Name: ChromaSitingVert > Level: 5 > ID: [55][B8] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: How Chroma is subsampled vertically. (0: Unspecified, 1: To= p > collocated , 2: Half) > > > Element Name: Range > Level: 5 > ID: [55][B9] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: Clipping of the color ranges. (0: Unspecified, 1: Broadcast > range, > 2: Full range (no clipping), 3: Defined by > Matrix/TransferFunction) > > > Element Name: TransferFunction > > > To align with ISO/IEC 23001-8, could we use TransferCharacteristics? > Done. > > Level: 5 > ID: [55][BA] > Mandatory: - > Multiple: - > Default: 2 > Type: u > Description: Transfer Function. See ISO/IEC 23001-8 for more information > on > enumerations. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, > 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, > 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqr= t, > 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut, > 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, > 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, > 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) > > > Comment: > The table in ISO/IEC 23001-8 for transfer characteristics does not includ= e > values or meaning for 16, 17 and 18 as above. Are these values from > ffmpeg's list? > 16 and 17 is an artifact form the FFmpeg list, but also form looking at FFmpeg CL's I think they are defined in an h265 spec. 18 is a proposed value for HLG. > Suggested description edit: > The transfer characteristics of the video. For clarity, the value and > meanings for TransferCharacteristics are adopted from Table 3 of ISO/IEC > 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: > Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, 7: SMPTE > 240M, 8: Linear, 9: Log, 10: Log Sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.13= 61 > Extended Colour Gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: > ITU-R BT.2020 12 bit) > Done. > > Element Name: Primaries > Level: 5 > Mandatory: - > Multiple: - > ID: [55][BB] > Default: 2 > Type: u > Description: Values that can be represented in the CIE 1931 colour space= . > See > ISO/IEC 23001-8 for more information on enumerations. > (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved, > 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE > 240M, > 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1) > > > Suggested description edit: > The colour primaries of the video. For clarity, the value and meanings fo= r > TransferCharacteristics are adopted from Table 2 of ISO/IEC > 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: > Reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE > 240M, 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1) > Done. > > Note that ISO/IEC 23001-8 also includes a value for 22 for JEDEC P22 > phosphors. Any reason to exclude this? > Added. > > Element Name: MaxCLL > Level: 5 > ID: [55][BC] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: Maximum brightness of a single pixel in candelas per square > meter (cd/m=C2=B2). > > > Suggested: > Maximum brightness of a single pixel (Maximum Content Light Level) in > candelas per square meter (cd/m=C2=B2). > Done > > Element Name: MaxFALL > Level: 5 > ID: [55][BD] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: Maximum brightness of a single full frame in candelas per > square > meter (cd/m=C2=B2). > > > Suggested: > Maximum brightness of a single full frame (Maximum Frame-Average Light > Level) in candelas per square meter (cd/m=C2=B2). > Done > > Element Name: MasteringMetadata > Level: 5 > ID: [55][D0] > Mandatory: - > Multiple: - > Default: - > Type: m > Description: SMPTE 2086 mastering data. > > > Element Name: PrimaryRChromaticityX > Level: 6 > ID: [55][D1] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > > > I think "0.0-1.0" is preferred for float range expressions. > Done > > Default: - > Type: f > Description: Red X chromaticity coordinate as defined by CIE 1931. > > > Element Name: PrimaryRChromaticityY > Level: 6 > ID: [55][D2] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: Red Y chromaticity coordinate as defined by CIE 1931. > > > Element Name: PrimaryGChromaticityX > Level: 6 > ID: [55][D3] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > f > Description: Green X chromaticity coordinate as defined by CIE 1931. > > > Element Name: PrimaryGChromaticityY > Level: 6 > ID: [55][D4] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: Green Y chromaticity coordinate as defined by CIE 1931. > > > Element Name: PrimaryBChromaticityX > Level: 6 > ID: [55][D5] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > f > Description: Blue X chromaticity coordinate as defined by CIE 1931. > > > Element Name: PrimaryBChromaticityY > Level: 6 > ID: [55][D6] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: Blue Y chromaticity coordinate as defined by CIE 1931. > > > Element Name: WhitePointChromaticityX > Level: 6 > ID: [55][D7] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: White point X chromaticity coordinate as defined by CIE > 1931. > > > Element Name: WhitePointChromaticityY > Level: 6 > ID: [55][D8] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 1 > Default: - > Type: f > Description: White point Y chromaticity coordinate as defined by CIE > 1931. > > > Element Name: LuminanceMax > Level: 6 > ID: [55][D9] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 9999.99 > Default: - > Type: f > Description: Maximum luminance. Shall be represented in candelas per > square > meter (cd/m=C2=B2). > > > Element Name: LuminanceMin > Level: 6 > ID: [55][DA] > Mandatory: - > Multiple: - > Range: 0 <=3D f <=3D 999.9999 > Default: - > Type: f > Description: Minimum luminance. Shall be represented in candelas per > square > meter (cd/m=C2=B2). > > > > > I removed ChromaSubsampling and added ChromaSubsamplingHorz, > ChromaSubsamplingVert, CbSubsamplingHorz, and CbSubsamplingVert. > > This is how I think the elements should be written for the different > subsampling types: > 1: 4:4:4 > - ChromaSubsamplingHorz and ChromaSubsamplingVert will not be set as > there should be no chroma subsampling. > > 2: 4:4:0 > - ChromaSubsamplingHorz :not set > - ChromaSubsamplingVert :1 > > 3: 4:2:2 > - ChromaSubsamplingHorz :1 > - ChromaSubsamplingVert :not set > > 4: 4:2:1 > - ChromaSubsamplingHorz :1 > - ChromaSubsamplingVert :not set > - CbSubsamplingHorz :1 > - CbSubsamplingVert :not set > - We could remove CbSubsamplingHorz and CbSubsamplingVert if we didn't > care about handling formats where the Cr and Cb channels are different > sizes. > > > I forgot about 4:2:1. That answers my question about CbSubsmaplingHorz > though perhaps we need a narrative section to expand on this with the > examples you have here. > > 5: 4:2:0 > - ChromaSubsamplingHorz :1 > - ChromaSubsamplingVert :1 > > 6: 4:1:1 > - ChromaSubsamplingHorz :3 > - ChromaSubsamplingVert :not set > > 7: 4:1:0 > - ChromaSubsamplingHorz :3 > - ChromaSubsamplingVert :1 > > 8: 3:1:1 > - ChromaSubsamplingHorz :2 > - ChromaSubsamplingVert :not set > - I'm assuming the luma subsampling can be handled by PixelWidth, and > DisaplyWidth. > > Jerome's vertical subsampling of 4 > - ChromaSubsamplingHorz :not set > - ChromaSubsamplingVert :3 > > > > The other issue I want to bring up is the value of "18: ARIB STD-B67 (HLG= )" > in TransferFunction. Unfortunately, in WebM we will need to use this valu= e > sooner than Matroska v4 will be finalized. Should I make this value much > higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17: SMPTE ST > 428-1" will be standardized across most documents, like 1-15 are. Just > not sure if 18 will be HLG. > > > I see a few references to ARIB STD-B67 as 18, such as > http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_5.pdf. > Perhaps we need a caveat that values 1-15 are defined based upon ISO/IEC > 23001-8. Then for values 16, 17, and 18 we could add better descriptions > and citations to define it better internally. > I'm fine with this. I'm just worried about the case where we diverge from one of the lists. Would be nice to have one canonical list. > If (hopefully) a revision to ISO/IEC 23001-8 adds those values (as > expected) then we could update are description to say all values are > defined by ISO/IEC 23001-8. > Sounds good to me. > Thanks, > Frank > > > Thanks too, > Dave Rice > > > --001a11c30aa215733d052be7c397 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 12, 2016 at 5:53 PM, Dave Rice <dave@dericed.com> wrote:
Hi= ,
=
Element Name:= Colour
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A04
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0[55][B0]
Mandatory: =C2=A0=C2=A0=C2=A0-=
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0m
Descrip= tion: =C2=A0Settings describing the colour format.


Element Name: Matrix
=

To align better with ISO/IEC 23001-8, coul= d this be labelled as MatrixCoefficients?
Done
=C2=A0

Level: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B1]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2= =A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A02
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0u
Description: =C2=A0ColourMatrix of the v= ideo. See ISO/IEC 23001-8 for more
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0information on = enumerations. (0: IEC 61966-2-1 (sRGB), 1: BT709,
=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A07: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A010: BT2020 Constant Luminance)
<= /div>

Suggeste= d description edit:
The Matrix Coefficients of the video used to = derive luma and chroma values from reg, green, and blue color primaries. Fo= r clarity, the value and meanings for MatrixCoefficients are adopted from T= able 4 of ISO/IEC 23001-8:2013/DCOR1. (0: IEC 61966-2-1 (sRGB), 1: BT709, 2= : Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M, 7: SMPTE 240= M, 8: YCOCG, 9: BT2020 Non-constant Luminance, 10: BT2020 Constant Luminanc= e)
Done=C2=A0

Question:
Value 0 is listed as "IEC 61966-2-1 (sRGB)" but the table= for matrix coefficients in ISO/IEC 23001-8 says "GBR / Typically refe= rred to as RGB". Should value 0 =3D RGB?
I changed it to GBR to match 23001-8.


Add foot= note:
[IEC23001-8] ISO/IEC 23001-8:2013/DCOR1, "Coding indep= endent media description code points", 2013, <http://standards.iso.org/ittf/PubliclyAvailableStan= dards/c062088_ISO_IEC_23001-8_2013.zip>.

Element Name: BitsPerChannel
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B= 2]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A00
Type: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0Number= of decoded bits per channel. This number may be less for
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0specific channels depending on the Matrix and ChromaSubsampling. A=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0value of 0 is unspecified.

It may be fine= , but I don't understand "This number may be less for specific cha= nnels depending on the Matrix and ChromaSubsampling." Is the value is = less for specific channels, then it seems as if the value would different a= mong channels, but only one BitsPerChannel is stored for a multi-channel vi= deo.
So we could have separate bits per = channel, but then we would have to define rgb and yuv. Most people know wha= t this is. Basically the information needed is, will the decoded video be 8= bits, 10 bits, 12 bits, 16 bits, ... Maybe I was just trying to be a littl= e too pedantic. I'm fine with removing this sentence. if any of the Chr= omaSubsampling elements are set then that implies that one or more channels= will have a different value.

So how about we just= remove this sentence?


I suggest changing the last l= ine to: A value of 0 indicates that the BitsPerChannel is unspecified.
Done=C2=A0

Element Nam= e: ChromaSubsamplingHorz
Level: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B3]
Mandatory: = =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0= -
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0The amount of chrominance pixels to remove f= or every chrominance
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0pixel not removed horizonta= lly.

For these subsampling elements, we may need a statement to say when t= hey should be used. For instance in QuickTime's=C2=A0TN2162 https://developer.apple.com/library/mac/technotes/tn2162/_inde= x.html=C2=A0it mandates the use of many values to better describe uncom= pressed video. When would these chroma subsampling elements be suggested?
I'm not really sure I follow. If any = of the Cb or Cr channels are down sized before encoding, then these element= s should be set accordingly.=C2=A0


I also suggest in= cluding an example; such as "Example: For video with 4:1:1 chroma subs= ampling the=C2=A0ChromaSubsamplingHorz should be set to 3.
I added "Example: For video with 4:2:0 chroma subsa= mpling the ChromaSubsamplingHorz should be set to 1." As pretty much m= ost video is 4:4:4 or 4:2:0 nowadays.

=

Element Name: ChromaSubsamplingVert
Level:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B4]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: = =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0u
Description: =C2=A0The amount of chro= minance pixels to remove for every chrominance
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0pix= el not removed vertically.

Element Name: CbSub= samplingHorz
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0[55][B5]
Mandatory: =C2=A0=C2=A0= =C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
T= ype: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0The amount of Cb chrominance pixels to remove for every= Cb
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0chrominance pixel not removed horizontally. T= his is additive with
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ChromaSubsamplingHorz.

I&#= 39;m confused about the relationship between=C2=A0CbSubsamplingHorz and=C2= =A0ChromaSubsamplingHorz.
These elements= are only defined because I was trying to handle 4:2:1. Basically this is a= n old format where the Cr channel is half the size of the Y channel, and th= e Cb channel is half the size of the Cr channel. The Cb channel is a quarte= r the size of the Y channel.

The CbSubsampling* el= ements were a late edition, right before I sent my previous email. At first= I didn't have these elements and had text that 4:2:1 was not supported= .

How about I change the CbSubsamplingHorz element= text too: "The amount of pixels to remove in the Cr and Cb channels f= or every pixel not removed horizontally." And the CbSubsamplingHorz to= o: "The amount of pixels to remove in the Cb channel for every pixel n= ot removed horizontally. This is additive with ChromaSubsamplingHorz. Examp= le: For video with 4:2:1 chroma subsampling the ChromaSubsamplingHorz shoul= d be set to 1 and CbSubsamplingHorz should be set to 1." Does this hel= p the confusion?


Element N= ame: CbSubsamplingVert
Level: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B6]
Mandatory: =C2= =A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0The amount of Cb chrominance pixels to remove = for every Cb
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0chrominance pixel not removed vertic= ally. This is additive with
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ChromaSubsamplingVert= .


Element Name: ChromaSitingHorz
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
=
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[5= 5][B7]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A00
Type: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0How= Chroma is subsampled horizontally. (0: Unspecified, 1: Left
<= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0collocated , 2: Half)

Element Name= : ChromaSitingVert
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B8]
Mandatory: =C2=A0= =C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A00
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0How Chroma is subsampled vertically. (0: Unspeci= fied, 1: Top
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0collocated , 2: Half)


Element Name: Range
Level: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B9]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2= =A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A00
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0u
Description: =C2=A0C= lipping of the color ranges. (0: Unspecified, 1: = Broadcast range,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A02: Full range (no clipping), 3: D= efined by
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Matrix/TransferFunction)


Element Name: TransferFunction

To align with ISO/IEC 2= 3001-8, could we use TransferCharacteristics?
Done.=C2=A0

Level: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][BA]
Mandat= ory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0= =C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A02
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
<= span style=3D"font-size:13.3333px;font-family:'Courier New';color:r= gb(34,34,34);font-weight:400;font-style:normal;font-variant:normal;text-dec= oration:none;vertical-align:baseline;white-space:pre-wrap;background-color:= rgb(255,255,255)">Description: =C2=A0Transfer Function. See ISO/IEC 23001-8= for more information on
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0enumerations. (0: Reserv= ed, 1: ITU-R BT.709, 2: Unspecified,
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A03: Reserved,= 4: Gamma 2.2 curve, 5: Gamma 2.8 curve,
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06: SMPTE = 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt,
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A011: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A013: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit,
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A015: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A017: SMPTE ST 428-1 18: ARIB STD-B67 (HLG))
<= /div>

Comment:
= The table in ISO/IEC 23001-8 for transfer characteristics does not include = values or meaning for 16, 17 and 18 as above. Are these values from ffmpeg&= #39;s list?
16 and 17 is an artifact for= m the FFmpeg list, but also form looking at FFmpeg CL's I think they ar= e defined in an h265 spec. 18 is a proposed value for HLG.


=
Suggested description edit:
The transfer characteristics of = the video. For clarity, the value and meanings for=C2=A0TransferCharacteris= tics=C2=A0are adopted from Table 3 of ISO/IEC 23001-8:2013/DCOR1. (0: Reser= ved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved, 4: Gamma 2.2 curve, 5: G= amma 2.8 curve,=C2=A06: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: L= og Sqrt,=C2=A011: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut,= =C2=A013: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit,=C2=A015: ITU-R BT.2020 1= 2 bit)
Done.
=C2=A0

Element Name: Primaries
= Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
M= andatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0= =C2=A0=C2=A0-
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0[55][BB]
Default: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A02
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0Values that = can be represented in the CIE 1931 colour space. See
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0ISO/IEC 23001-8 for more information on enumerations.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0(0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved,=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A04: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7:= SMPTE 240M,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A08: FILM, 9: ITU-R BT.2020, 10: SMPTE= ST 428-1)
Suggested description edit:
The colour primaries of the vide= o. For clarity, the value and meanings for TransferCharacteristics are adop= ted=C2=A0from Table 2 of ISO/IEC 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R= BT.709, 2: Unspecified, 3: Reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, = 6: SMPTE 170M, 7: SMPTE 240M,=C2=A08: FILM, 9: ITU-R BT.2020, 10: SMPTE ST = 428-1)
Done.=C2=A0

Note that ISO/IEC = 23001-8 also includes a value for 22 for JEDEC P22 phosphors. Any reason to= exclude this?
Added.
=C2=A0

Element Name: MaxCLL
Level:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][BC]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: = =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0u
Description: =C2=A0Maximum brightness= of a single pixel in candelas per square
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0meter = (cd/m=C2=B2).
=
Suggested:
Maximum brightness of a single pixel (M= aximum Content Light Level) in candelas per square meter (cd/m=C2=B2).
Done
=C2=A0
=

Element Name: MaxFALL
Level: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][BD]
M= andatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0= =C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-=
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0u
Description: =C2=A0Maximum brightness of a single= full frame in candelas per square
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0meter (cd/m=C2= =B2).

Suggested:
Maximum brightness of a single full frame = (Maximum=C2=A0Frame-Average=C2=A0Light Level) in candelas per square meter = (cd/m=C2=B2).
Done
=C2= =A0

Element Name: MasteringMetadata
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0[55][D0]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0m
Description: =C2=A0= SMPTE 2086 mastering data.


Element Name: P= rimaryRChromaticityX
Level: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D1]
Mandatory: =C2= =A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <= ;=3D f <=3D 1

I think "0.0-1.0" is preferred for float range = expressions.
Done
=C2=A0
=

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
<= span style=3D"font-size:13.3333px;font-family:'Courier New';color:r= gb(34,34,34);font-weight:400;font-style:normal;font-variant:normal;text-dec= oration:none;vertical-align:baseline;white-space:pre-wrap;background-color:= rgb(255,255,255)">Description: =C2=A0Red X chromaticity coordinate as defi= ned by CIE 1931.


Element Name: PrimaryRChr= omaticityY
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0[55][D2]
Mandatory: =C2=A0=C2=A0=C2= =A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
<= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <= =3D 1
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-<= /div>
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
Description: =C2=A0Red Y chromaticity coordinate as define= d by CIE 1931.


Element Name: PrimaryGChrom= aticityX
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0[55][D3]
Mandatory: =C2=A0=C2=A0=C2= =A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
<= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <= =3D 1
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-<= /div>
f
Description: =C2=A0Green X chromatic= ity coordinate as defined by CIE 1931.


E= lement Name: PrimaryGChromaticityY
Level: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D4]
M= andatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0= =C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A00 <=3D f <=3D 1
Default: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0f
Description: =C2=A0Green Y chr= omaticity coordinate as defined by CIE 1931.

<= br>
Element Name: PrimaryBChromaticityX
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06
<= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55= ][D5]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 1
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
f=
Description: =C2=A0Blue X chromaticity coordinate as define= d by CIE 1931.


Element Name: PrimaryBChrom= aticityY
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0[55][D6]
Mandatory: =C2=A0=C2=A0=C2= =A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
<= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <= =3D 1
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-<= /div>
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
Description: =C2=A0Blue Y chromaticity coordinate as defin= ed by CIE 1931.


Element Name: WhitePointCh= romaticityX
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0[55][D7]
Mandatory: =C2=A0=C2=A0= =C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f &l= t;=3D 1
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
<= span style=3D"font-size:13.3333px;font-family:'Courier New';color:r= gb(34,34,34);font-weight:400;font-style:normal;font-variant:normal;text-dec= oration:none;vertical-align:baseline;white-space:pre-wrap;background-color:= rgb(255,255,255)">Description: =C2=A0White point X chromaticity coordinate= as defined by CIE 1931.


Element Name: Whi= tePointChromaticityY
Level: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D8]
Mandatory: =C2= =A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <= ;=3D f <=3D 1
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0f
Description: =C2=A0White point Y chromaticity= coordinate as defined by CIE 1931.


Elemen= t Name: LuminanceMax
Level: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D9]
Mandatory: =C2= =A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <= ;=3D f <=3D 9999.99
Defau= lt: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
Description: =C2= =A0Maximum luminance. Shall be represented in candelas per square
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0meter (cd/m=C2=B2).


Elem= ent Name: LuminanceMin
Level: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][DA]
Mandatory: =C2= =A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <= ;=3D f <=3D 999.9999
Defa= ult: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
Description: = =C2=A0Minimum luminance. Shall be represented in candelas per square=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0meter (cd/m=C2=B2).



I removed ChromaSubsampling and added ChromaSubsamplingHorz, C= hromaSubsamplingVert, CbSubsamplingHorz, and CbSubsamplingVert.
<= br>
This is how I think the elements should be written for the di= fferent subsampling types:
1: 4:4:4
=C2=A0 =C2=A0 = - ChromaSubsamplingHorz and ChromaSubsamplingVert will not be set as there = should be no chroma subsampling.

2: 4:4:0
=C2=A0 - ChromaSubsamplingHorz :not set
=C2=A0 - ChromaSub= samplingVert :1

3: 4:2:2
=C2= =A0 - ChromaSubsamplingHorz :1
=C2=A0 - ChromaSubsamplingVert :no= t set

4: 4:2:1
=C2=A0 - Chrom= aSubsamplingHorz :1
=C2=A0 - ChromaSubsamplingVert :not set
=
=C2=A0 - CbSubsamplingHorz :1
=C2=A0 - CbSubsampl= ingVert :not set
=C2=A0 - We could remove CbSubsamplingHorz= and CbSubsamplingVert if we didn't care about handling formats where t= he Cr and Cb channels are different sizes.

I forgot about 4:2:1. That answers my q= uestion about CbSubsmaplingHorz though perhaps we need a narrative section = to expand on this with the examples you have here.

5: 4:2:0
=C2=A0 - ChromaSubsamplingHorz :1<= /div>
=C2=A0 - ChromaSubsamplingVert :1

6: 4:1= :1
=C2=A0 - ChromaSubsamplingHorz :3
=C2=A0 - Chro= maSubsamplingVert :not set

7: 4:1:0
=C2=A0 - ChromaSubsamplingHorz :3
=C2=A0 - ChromaSubsampli= ngVert :1

8: 3:1:1
=C2= =A0 - ChromaSubsamplingHorz :2
=C2=A0 - ChromaSubsamplingVert :no= t set
=C2=A0 - I'm assuming the luma subsampling can be= handled by PixelWidth, and DisaplyWidth.

Jerome&#= 39;s vertical subsampling of 4
=C2=A0 - ChromaSubsamplingHor= z :not set
=C2=A0 - ChromaSubsamplingVert :3

=


The other issue I want to bring up= is the value of "18: ARIB STD-B67 = (HLG)" in TransferFunction. Unfortunately, in WebM we will need= to use this value sooner than Matroska v4 will be finalized. Should I make= this value much higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17: SMPTE ST 428-1" will be standardized across= most documents, like 1-15 are. Just not sure if 18 will be HLG.

I see a few references = to ARIB STD-B67 as 18, such as=C2=A0http://www.arib.or= .jp/english/html/overview/doc/2-STD-B32v3_5.pdf. Perhaps we need a cave= at that values 1-15 are defined based upon ISO/IEC 23001-8. Then for values= 16, 17, and 18 we could add better descriptions and citations to define it= better internally.
I'm fine with t= his. I'm just worried about the case where we diverge from one of the l= ists. Would be nice to have one canonical list.
=C2=A0
If (hopefully) a = revision to ISO/IEC 23001-8 adds those values (as expected) then we could u= pdate are description to say all values are defined by ISO/IEC 23001-8.
Sounds good to me.


Thanks,
Frank

Thanks too,
Dave Rice

<= br>

--001a11c30aa215733d052be7c397-- From nobody Tue Feb 16 11:15:19 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06D11B3528 for ; Tue, 16 Feb 2016 11:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.046 X-Spam-Level: * X-Spam-Status: No, score=1.046 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FF_IHOPE_YOU_SINK=2.166, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 vokSdhqAkPPd for ; Tue, 16 Feb 2016 11:15:10 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F6A1B351D for ; Tue, 16 Feb 2016 11:15:10 -0800 (PST) Received: from [146.96.19.240] (port=32331 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aVl5R-003Vbu-5K; Tue, 16 Feb 2016 14:15:09 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_A5A73883-2A5E-43CE-BC63-A66FC6373DAA" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Tue, 16 Feb 2016 14:14:59 -0500 Message-Id: <9CE0170E-E63D-411D-AFAF-EE5CBB4B56D7@dericed.com> References: <568C3CA0.8040300@mediaarea.net> <56B8CD1A.20307@mediaarea.net> <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> To: Frank Galligan X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Jerome Martinez , Discussion about the current and future development of Matroska , cellar@ietf.org Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2016 19:15:16 -0000 --Apple-Mail=_A5A73883-2A5E-43CE-BC63-A66FC6373DAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 16, 2016, at 2:01 PM, Frank Galligan = wrote: >=20 >=20 >=20 > On Fri, Feb 12, 2016 at 5:53 PM, Dave Rice > wrote: > Hi, >>=20 >> Element Name: Colour >> Level: 4 >> ID: [55][B0] >> Mandatory: - >> Multiple: - >> Default: - >> Type: m >> Description: Settings describing the colour format. >>=20 >>=20 >> Element Name: Matrix >=20 > To align better with ISO/IEC 23001-8, could this be labelled as = MatrixCoefficients? > Done > =20 >=20 >> Level: 5 >> ID: [55][B1] >> Mandatory: - >> Multiple: - >> Default: 2 >> Type: u >> Description: ColourMatrix of the video. See ISO/IEC 23001-8 for more >> information on enumerations. (0: IEC 61966-2-1 (sRGB), = 1: BT709, >> 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: = SMPTE 170M, >> 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant = Luminance, >> 10: BT2020 Constant Luminance) >=20 > Suggested description edit: > The Matrix Coefficients of the video used to derive luma and chroma = values from reg, green, and blue color primaries. For clarity, the value = and meanings for MatrixCoefficients are adopted from Table 4 of ISO/IEC = 23001-8:2013/DCOR1. (0: IEC 61966-2-1 (sRGB), 1: BT709, 2: Unspecified, = 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: YCOCG, = 9: BT2020 Non-constant Luminance, 10: BT2020 Constant Luminance) > Done=20 >=20 > Question: > Value 0 is listed as "IEC 61966-2-1 (sRGB)" but the table for matrix = coefficients in ISO/IEC 23001-8 says "GBR / Typically referred to as = RGB". Should value 0 =3D RGB? > I changed it to GBR to match 23001-8. >=20 >=20 > Add footnote: > [IEC23001-8] ISO/IEC 23001-8:2013/DCOR1, "Coding independent media = description code points", 2013, = >. >=20 >> Element Name: BitsPerChannel >> Level: 5 >> ID: [55][B2] >> Mandatory: - >> Multiple: - >> Default: 0 >> Type: u >> Description: Number of decoded bits per channel. This number may be = less for=20 >> specific channels depending on the Matrix and = ChromaSubsampling. A >> value of 0 is unspecified. >=20 > It may be fine, but I don't understand "This number may be less for = specific channels depending on the Matrix and ChromaSubsampling." Is the = value is less for specific channels, then it seems as if the value would = different among channels, but only one BitsPerChannel is stored for a = multi-channel video. > So we could have separate bits per channel, but then we would have to = define rgb and yuv. Most people know what this is. Basically the = information needed is, will the decoded video be 8 bits, 10 bits, 12 = bits, 16 bits, ... Maybe I was just trying to be a little too pedantic. = I'm fine with removing this sentence. +1 for removing it. > if any of the ChromaSubsampling elements are set then that implies = that one or more channels will have a different value. Ah, I had been presuming that you meant bits per channel of a channel's = sample, rather than the total of the bits per channel (all = samples/pixels of a frame). > So how about we just remove this sentence? >=20 >=20 > I suggest changing the last line to: A value of 0 indicates that the = BitsPerChannel is unspecified. > Done=20 >=20 >> Element Name: ChromaSubsamplingHorz >> Level: 5 >> ID: [55][B3] >> Mandatory: - >> Multiple: - >> Default: - >> Type: u >> Description: The amount of chrominance pixels to remove for every = chrominance >> pixel not removed horizontally. >=20 > For these subsampling elements, we may need a statement to say when = they should be used. For instance in QuickTime's TN2162 = https://developer.apple.com/library/mac/technotes/tn2162/_index.html = = it mandates the use of many values to better describe uncompressed = video. When would these chroma subsampling elements be suggested? > I'm not really sure I follow. If any of the Cb or Cr channels are down = sized before encoding, then these elements should be set accordingly.=20 I mean that this field is defined as being optional, but there's no = indication to say when it should or when it shouldn't be used. This = probably applies to most of these fields (and much of the matroska = spec). > I also suggest including an example; such as "Example: For video with = 4:1:1 chroma subsampling the ChromaSubsamplingHorz should be set to 3. > I added "Example: For video with 4:2:0 chroma subsampling the = ChromaSubsamplingHorz should be set to 1." As pretty much most video is = 4:4:4 or 4:2:0 nowadays. >=20 >=20 >> Element Name: ChromaSubsamplingVert >> Level: 5 >> ID: [55][B4] >> Mandatory: - >> Multiple: - >> Default: - >> Type: u >> Description: The amount of chrominance pixels to remove for every = chrominance >> pixel not removed vertically. >>=20 >> Element Name: CbSubsamplingHorz >> Level: 5 >> ID: [55][B5] >> Mandatory: - >> Multiple: - >> Default: - >> Type: u >> Description: The amount of Cb chrominance pixels to remove for every = Cb >> chrominance pixel not removed horizontally. This is = additive with >> ChromaSubsamplingHorz. >=20 > I'm confused about the relationship between CbSubsamplingHorz and = ChromaSubsamplingHorz. > These elements are only defined because I was trying to handle 4:2:1. = Basically this is an old format where the Cr channel is half the size of = the Y channel, and the Cb channel is half the size of the Cr channel. = The Cb channel is a quarter the size of the Y channel. >=20 > The CbSubsampling* elements were a late edition, right before I sent = my previous email. At first I didn't have these elements and had text = that 4:2:1 was not supported. Right. Sorry I wrote my comments before considering 4:2:1, since the = fields are quite customized for situations like 4:2:1, perhaps it should = be referenced by name as an example. > How about I change the CbSubsamplingHorz element text too: "The amount = of pixels to remove in the Cr and Cb channels for every pixel not = removed horizontally." And the CbSubsamplingHorz too: "The amount of = pixels to remove in the Cb channel for every pixel not removed = horizontally. This is additive with ChromaSubsamplingHorz. Example: For = video with 4:2:1 chroma subsampling the ChromaSubsamplingHorz should be = set to 1 and CbSubsamplingHorz should be set to 1." Does this help the = confusion? +1 >> Element Name: CbSubsamplingVert >> Level: 5 >> ID: [55][B6] >> Mandatory: - >> Multiple: - >> Default: - >> Type: u >> Description: The amount of Cb chrominance pixels to remove for every = Cb >> chrominance pixel not removed vertically. This is = additive with >> ChromaSubsamplingVert. >>=20 >>=20 >> Element Name: ChromaSitingHorz >> Level: 5 >> ID: [55][B7] >> Mandatory: - >> Multiple: - >> Default: 0 >> Type: u >> Description: How Chroma is subsampled horizontally. (0: Unspecified, = 1: Left=20 >> collocated , 2: Half) >>=20 >> Element Name: ChromaSitingVert >> Level: 5 >> ID: [55][B8] >> Mandatory: - >> Multiple: - >> Default: 0 >> Type: u >> Description: How Chroma is subsampled vertically. (0: Unspecified, = 1: Top >> collocated , 2: Half) >>=20 >>=20 >> Element Name: Range >> Level: 5 >> ID: [55][B9] >> Mandatory: - >> Multiple: - >> Default: 0 >> Type: u >> Description: Clipping of the color ranges. (0: Unspecified, 1: = Broadcast range, >> 2: Full range (no clipping), 3: Defined by >> Matrix/TransferFunction) >>=20 >>=20 >> Element Name: TransferFunction >=20 > To align with ISO/IEC 23001-8, could we use TransferCharacteristics? > Done.=20 >=20 >> Level: 5 >> ID: [55][BA] >> Mandatory: - >> Multiple: - >> Default: 2 >> Type: u >> Description: Transfer Function. See ISO/IEC 23001-8 for more = information on >> enumerations. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified, >> 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, >> 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: = Log Sqrt, >> 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut, >> 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, >> 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, >> 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) >=20 > Comment: > The table in ISO/IEC 23001-8 for transfer characteristics does not = include values or meaning for 16, 17 and 18 as above. Are these values = from ffmpeg's list? > 16 and 17 is an artifact form the FFmpeg list, but also form looking = at FFmpeg CL's I think they are defined in an h265 spec. 18 is a = proposed value for HLG. >=20 >=20 > Suggested description edit: > The transfer characteristics of the video. For clarity, the value and = meanings for TransferCharacteristics are adopted from Table 3 of ISO/IEC = 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: = Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, 7: = SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, 11: IEC 61966-2-4, 12: = ITU-R BT.1361 Extended Colour Gamut, 13: IEC 61966-2-1, 14: ITU-R = BT.2020 10 bit, 15: ITU-R BT.2020 12 bit) > Done. > =20 >=20 >> Element Name: Primaries >> Level: 5 >> Mandatory: - >> Multiple: - >> ID: [55][BB] >> Default: 2 >> Type: u >> Description: Values that can be represented in the CIE 1931 colour = space. See >> ISO/IEC 23001-8 for more information on enumerations. >> (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: = Reserved, >> 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: = SMPTE 240M, >> 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1) >=20 > Suggested description edit: > The colour primaries of the video. For clarity, the value and meanings = for TransferCharacteristics are adopted from Table 2 of ISO/IEC = 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: = Reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE = 240M, 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1) > Done.=20 >=20 > Note that ISO/IEC 23001-8 also includes a value for 22 for JEDEC P22 = phosphors. Any reason to exclude this? > Added. > =20 >=20 >> Element Name: MaxCLL >> Level: 5 >> ID: [55][BC] >> Mandatory: - >> Multiple: - >> Default: - >> Type: u >> Description: Maximum brightness of a single pixel in candelas per = square >> meter (cd/m=C2=B2). >=20 > Suggested: > Maximum brightness of a single pixel (Maximum Content Light Level) in = candelas per square meter (cd/m=C2=B2). > Done > =20 >=20 >> Element Name: MaxFALL >> Level: 5 >> ID: [55][BD] >> Mandatory: - >> Multiple: - >> Default: - >> Type: u >> Description: Maximum brightness of a single full frame in candelas = per square >> meter (cd/m=C2=B2). >=20 > Suggested: > Maximum brightness of a single full frame (Maximum Frame-Average Light = Level) in candelas per square meter (cd/m=C2=B2). > Done > =20 >=20 >> Element Name: MasteringMetadata >> Level: 5 >> ID: [55][D0] >> Mandatory: - >> Multiple: - >> Default: - >> Type: m >> Description: SMPTE 2086 mastering data. >>=20 >>=20 >> Element Name: PrimaryRChromaticityX >> Level: 6 >> ID: [55][D1] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >=20 > I think "0.0-1.0" is preferred for float range expressions. Sorry there's an open discussion elsewhere on Cellar about expressing = float ranges as hexadecimal floating-point literals, so this may be = changed later, but the meaning should still be the same. > Done > =20 >=20 >> Default: - >> Type: f >> Description: Red X chromaticity coordinate as defined by CIE 1931. >>=20 >>=20 >> Element Name: PrimaryRChromaticityY >> Level: 6 >> ID: [55][D2] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >> Default: - >> Type: f >> Description: Red Y chromaticity coordinate as defined by CIE 1931. >>=20 >>=20 >> Element Name: PrimaryGChromaticityX >> Level: 6 >> ID: [55][D3] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >> Default: - >> f >> Description: Green X chromaticity coordinate as defined by CIE 1931. >>=20 >>=20 >> Element Name: PrimaryGChromaticityY >> Level: 6 >> ID: [55][D4] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >> Default: - >> Type: f >> Description: Green Y chromaticity coordinate as defined by CIE 1931. >>=20 >>=20 >> Element Name: PrimaryBChromaticityX >> Level: 6 >> ID: [55][D5] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >> Default: - >> f >> Description: Blue X chromaticity coordinate as defined by CIE 1931. >>=20 >>=20 >> Element Name: PrimaryBChromaticityY >> Level: 6 >> ID: [55][D6] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >> Default: - >> Type: f >> Description: Blue Y chromaticity coordinate as defined by CIE 1931. >>=20 >>=20 >> Element Name: WhitePointChromaticityX >> Level: 6 >> ID: [55][D7] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >> Default: - >> Type: f >> Description: White point X chromaticity coordinate as defined by CIE = 1931. >>=20 >>=20 >> Element Name: WhitePointChromaticityY >> Level: 6 >> ID: [55][D8] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >> Default: - >> Type: f >> Description: White point Y chromaticity coordinate as defined by CIE = 1931. >>=20 >>=20 >> Element Name: LuminanceMax >> Level: 6 >> ID: [55][D9] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 9999.99 >> Default: - >> Type: f >> Description: Maximum luminance. Shall be represented in candelas per = square >> meter (cd/m=C2=B2). >>=20 >>=20 >> Element Name: LuminanceMin >> Level: 6 >> ID: [55][DA] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 999.9999 >> Default: - >> Type: f >> Description: Minimum luminance. Shall be represented in candelas per = square >> meter (cd/m=C2=B2). >=20 >=20 >=20 >> I removed ChromaSubsampling and added ChromaSubsamplingHorz, = ChromaSubsamplingVert, CbSubsamplingHorz, and CbSubsamplingVert. >>=20 >> This is how I think the elements should be written for the different = subsampling types: >> 1: 4:4:4 >> - ChromaSubsamplingHorz and ChromaSubsamplingVert will not be set = as there should be no chroma subsampling. >>=20 >> 2: 4:4:0 >> - ChromaSubsamplingHorz :not set >> - ChromaSubsamplingVert :1 >>=20 >> 3: 4:2:2 >> - ChromaSubsamplingHorz :1 >> - ChromaSubsamplingVert :not set >>=20 >> 4: 4:2:1 >> - ChromaSubsamplingHorz :1 >> - ChromaSubsamplingVert :not set >> - CbSubsamplingHorz :1 >> - CbSubsamplingVert :not set >> - We could remove CbSubsamplingHorz and CbSubsamplingVert if we = didn't care about handling formats where the Cr and Cb channels are = different sizes. >=20 > I forgot about 4:2:1. That answers my question about CbSubsmaplingHorz = though perhaps we need a narrative section to expand on this with the = examples you have here. >=20 >> 5: 4:2:0 >> - ChromaSubsamplingHorz :1 >> - ChromaSubsamplingVert :1 >>=20 >> 6: 4:1:1 >> - ChromaSubsamplingHorz :3 >> - ChromaSubsamplingVert :not set >>=20 >> 7: 4:1:0 >> - ChromaSubsamplingHorz :3 >> - ChromaSubsamplingVert :1 >>=20 >> 8: 3:1:1 >> - ChromaSubsamplingHorz :2 >> - ChromaSubsamplingVert :not set >> - I'm assuming the luma subsampling can be handled by PixelWidth, = and DisaplyWidth. >>=20 >> Jerome's vertical subsampling of 4 >> - ChromaSubsamplingHorz :not set >> - ChromaSubsamplingVert :3 >>=20 >>=20 >>=20 >> The other issue I want to bring up is the value of "18: ARIB STD-B67 = (HLG)" in TransferFunction. Unfortunately, in WebM we will need to use = this value sooner than Matroska v4 will be finalized. Should I make this = value much higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17: = SMPTE ST 428-1" will be standardized across most documents, like 1-15 = are. Just not sure if 18 will be HLG. >=20 > I see a few references to ARIB STD-B67 as 18, such as = http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_5.pdf = . = Perhaps we need a caveat that values 1-15 are defined based upon ISO/IEC = 23001-8. Then for values 16, 17, and 18 we could add better descriptions = and citations to define it better internally. > I'm fine with this. I'm just worried about the case where we diverge = from one of the lists. Would be nice to have one canonical list. > =20 > If (hopefully) a revision to ISO/IEC 23001-8 adds those values (as = expected) then we could update are description to say all values are = defined by ISO/IEC 23001-8. > Sounds good to me. It's a bit risky. Perhaps for now we should clarify that values 1-15 are = defined by ISO/IEC 23001-8 and then give customized definitions for 16, = 17, 18. Dave Rice --Apple-Mail=_A5A73883-2A5E-43CE-BC63-A66FC6373DAA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 16, 2016, at 2:01 PM, Frank Galligan <frankgalligan@gmail.com> wrote:



On Fri, Feb 12, 2016 at 5:53 PM, Dave Rice <dave@dericed.com> wrote:
Hi,

Element Name: = Colour
Level: =        4
ID: =           [55][B0]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         m
Description:  Settings = describing the colour format.


Element Name: = Matrix

To align better with = ISO/IEC 23001-8, could this be labelled as = MatrixCoefficients?
Done
 

Level: =        5
ID: =           [55][B1]
Mandatory: =    -
Multiple: =     -
Default: =      2
Type: =         u
Description: =  ColourMatrix of the video. See ISO/IEC 23001-8 for = more
=             &n= bsp;information on enumerations. (0: IEC 61966-2-1 (sRGB), 1: = BT709,
=             &n= bsp;2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE = 170M,
=             &n= bsp;7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant = Luminance,
=             &n= bsp;10: BT2020 Constant = Luminance)
<= div class=3D"">
Suggested description edit:
The Matrix = Coefficients of the video used to derive luma and chroma values from = reg, green, and blue color primaries. For clarity, the value and = meanings for MatrixCoefficients are adopted from Table 4 of ISO/IEC = 23001-8:2013/DCOR1. (0: IEC 61966-2-1 (sRGB), 1: BT709, 2: Unspecified, = 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: YCOCG, = 9: BT2020 Non-constant Luminance, 10: BT2020 Constant = Luminance)
Done 

Question:
Value 0 is listed as "IEC = 61966-2-1 (sRGB)" but the table for matrix coefficients in ISO/IEC = 23001-8 says "GBR / Typically referred to as RGB". Should value 0 =3D = RGB?
I changed it to GBR = to match 23001-8.


Add footnote:
[IEC23001-8] ISO/IEC = 23001-8:2013/DCOR1, "Coding independent media description code points", = 2013, <http://standards.iso.org/ittf/PubliclyAvailableStandards/c06208= 8_ISO_IEC_23001-8_2013.zip>.

Element Name: = BitsPerChannel
Level: =        5
ID: =           [55][B2]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:  Number of = decoded bits per channel. This number may be less for
=             &n= bsp;specific channels depending on the Matrix and ChromaSubsampling. = A
=             &n= bsp;value of 0 is = unspecified.

It may be fine, = but I don't understand "This number may be less for specific channels = depending on the Matrix and ChromaSubsampling." Is the value is less for = specific channels, then it seems as if the value would different among = channels, but only one BitsPerChannel is stored for a multi-channel = video.
So we could have = separate bits per channel, but then we would have to define rgb and yuv. = Most people know what this is. Basically the information needed is, will = the decoded video be 8 bits, 10 bits, 12 bits, 16 bits, ... Maybe I was = just trying to be a little too pedantic. I'm fine with removing this = sentence.

+1 for removing it.

if any = of the ChromaSubsampling elements are set then that implies that one or = more channels will have a different = value.

Ah, I had been presuming that you meant bits per = channel of a channel's sample, rather than the total of the bits per = channel (all samples/pixels of a frame).

So how = about we just remove this sentence?


I suggest changing the last line to: A value of 0 indicates = that the BitsPerChannel is = unspecified.
Done 

Element Name: ChromaSubsamplingHorz
Level: =        5
ID: =           [55][B3]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount = of chrominance pixels to remove for every chrominance
=             &n= bsp;pixel not removed = horizontally.

For these subsampling = elements, we may need a statement to say when they should be used. For = instance in QuickTime's TN2162 https://developer.apple.com/library/mac/technotes/tn2162/_index= .html it mandates the use of many values to better describe = uncompressed video. When would these chroma subsampling elements be = suggested?
I'm not really = sure I follow. If any of the Cb or Cr channels are down sized before = encoding, then these elements should be set = accordingly. 

I mean that this field is defined as being = optional, but there's no indication to say when it should or when it = shouldn't be used. This probably applies to most of these fields (and = much of the matroska spec).

I also suggest including an = example; such as "Example: For video with 4:1:1 chroma subsampling = the ChromaSubsamplingHorz should be set to = 3.
I added "Example: For = video with 4:2:0 chroma subsampling the ChromaSubsamplingHorz should be = set to 1." As pretty much most video is 4:4:4 or 4:2:0 = nowadays.


Element Name: = ChromaSubsamplingVert
Level: =        5
ID: =           [55][B4]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount = of chrominance pixels to remove for every chrominance
=             &n= bsp;pixel not removed vertically.

Element Name: = CbSubsamplingHorz
Level: =        5
ID: =           [55][B5]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount = of Cb chrominance pixels to remove for every Cb
=             &n= bsp;chrominance pixel not removed horizontally. This is additive = with
=             &n= bsp;ChromaSubsamplingHorz.

I'm = confused about the relationship between CbSubsamplingHorz = and ChromaSubsamplingHorz.
These elements are only defined because I was trying to = handle 4:2:1. Basically this is an old format where the Cr channel is = half the size of the Y channel, and the Cb channel is half the size of = the Cr channel. The Cb channel is a quarter the size of the Y = channel.

The = CbSubsampling* elements were a late edition, right before I sent my = previous email. At first I didn't have these elements and had text that = 4:2:1 was not = supported.

Right. Sorry I wrote my comments before = considering 4:2:1, since the fields are quite customized for situations = like 4:2:1, perhaps it should be referenced by name as an = example.

How about I change the = CbSubsamplingHorz element text too: "The amount of pixels to remove in = the Cr and Cb channels for every pixel not removed horizontally." And = the CbSubsamplingHorz too: "The amount of pixels to remove in the Cb = channel for every pixel not removed horizontally. This is additive with = ChromaSubsamplingHorz. Example: For video with 4:2:1 chroma subsampling = the ChromaSubsamplingHorz should be set to 1 and CbSubsamplingHorz = should be set to 1." Does this help the = confusion?

+1

Element Name: = CbSubsamplingVert
Level: =        5
ID: =           [55][B6]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount = of Cb chrominance pixels to remove for every Cb
=             &n= bsp;chrominance pixel not removed vertically. This is additive = with
=             &n= bsp;ChromaSubsamplingVert.


Element Name: = ChromaSitingHorz
Level: =        5
ID: =           [55][B7]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:  How Chroma = is subsampled horizontally. (0: Unspecified, 1: Left
=             &n= bsp;collocated , 2: Half)

Element Name: = ChromaSitingVert
Level: =        5
ID: =           [55][B8]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description:  How Chroma = is subsampled vertically. (0: Unspecified, 1: Top
=             &n= bsp;collocated , 2: Half)


Element Name: = Range
Level: =        5
ID: =           [55][B9]
Mandatory: =    -
Multiple: =     -
Default: =      0
Type: =         u
Description: =  Clipping of the color ranges. = (0: Unspecified, 1: Broadcast = range,
=             &n= bsp;2: Full range (no clipping), 3: Defined by
=             &n= bsp;Matrix/TransferFunction)


Element Name: = TransferFunction
<= div class=3D"">
To align with = ISO/IEC 23001-8, could we use = TransferCharacteristics?
Done. 

Level: =        5
ID: =           [55][BA]
Mandatory: =    -
Multiple: =     -
Default: =      2
Type: =         u
Description:  Transfer = Function. See ISO/IEC 23001-8 for more information on
=             &n= bsp;enumerations. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified,
=             &n= bsp;3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 = curve,
=             &n= bsp;6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log = Sqrt,
=             &n= bsp;11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut,
=             &n= bsp;13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit,
=             &n= bsp;15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084,
=             &n= bsp;17: SMPTE ST 428-1 18: ARIB STD-B67 = (HLG))

Comment:
The table in ISO/IEC 23001-8 for transfer characteristics = does not include values or meaning for 16, 17 and 18 as above. Are these = values from ffmpeg's list?
16 and 17 is an artifact form the FFmpeg list, but also form = looking at FFmpeg CL's I think they are defined in an h265 spec. 18 is a = proposed value for HLG.


Suggested description edit:
The transfer characteristics of the video. For clarity, the = value and meanings for TransferCharacteristics are adopted = from Table 3 of ISO/IEC 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R = BT.709, 2: Unspecified, 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 = curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log = Sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: ITU-R = BT.2020 12 bit)
Done.
 

Element Name: = Primaries
Level: =        5
Mandatory: =    -
Multiple: =     -
ID: =           [55][BB]
Default: =      2
Type: =         u
Description:  Values = that can be represented in the CIE 1931 colour space. = See
=             &n= bsp;ISO/IEC 23001-8 for more information on = enumerations.
=             &n= bsp;(0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: = Reserved,
=             &n= bsp;4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE = 240M,
=             &n= bsp;8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST = 428-1)

Suggested description = edit:
The colour primaries of the video. For clarity, the = value and meanings for TransferCharacteristics are adopted from = Table 2 of ISO/IEC 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified, 3: Reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE = 170M, 7: SMPTE 240M, 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST = 428-1)
Done. 

Note = that ISO/IEC 23001-8 also includes a value for 22 for JEDEC P22 = phosphors. Any reason to exclude this?
Added.
 

Element Name: = MaxCLL
Level: =        5
ID: =           [55][BC]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  Maximum = brightness of a single pixel in candelas per square
=             &n= bsp;meter = (cd/m=C2=B2).

Suggested:
Maximum brightness of a single pixel (Maximum Content Light = Level) in candelas per square meter = (cd/m=C2=B2).
Done
 

Element Name: = MaxFALL
Level: =        5
ID: =           [55][BD]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  Maximum = brightness of a single full frame in candelas per = square
=             &n= bsp;meter = (cd/m=C2=B2).

Suggested:
Maximum brightness of a = single full frame (Maximum Frame-Average Light Level) in = candelas per square meter = (cd/m=C2=B2).
Done
 

Element Name: = MasteringMetadata
Level: =        5
ID: =           [55][D0]
Mandatory: =    -
Multiple: =     -
Default: =      -
Type: =         m
Description:  SMPTE 2086 = mastering data.


Element Name: = PrimaryRChromaticityX
Level: =        6
ID: =           [55][D1]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D = 1

I think "0.0-1.0" is = preferred for float range = expressions.

Sorry there's an open discussion = elsewhere on Cellar about expressing float ranges as hexadecimal = floating-point literals, so this may be changed later, but the meaning = should still be the same.

Done
 

Default: =      -
Type: =         f
Description: =  Red X chromaticity coordinate as defined by CIE = 1931.


Element Name: = PrimaryRChromaticityY
Level: =        6
ID: =           [55][D2]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 1
Default: =      -
Type: =         f
Description: =  Red Y chromaticity coordinate as defined by CIE = 1931.


Element Name: = PrimaryGChromaticityX
Level: =        6
ID: =           [55][D3]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 1
Default: =      -
f
Description: =  Green X chromaticity coordinate as defined by CIE = 1931.


Element Name: = PrimaryGChromaticityY
Level: =        6
ID: =           [55][D4]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 1
Default: =      -
Type: =         f
Description: =  Green Y chromaticity coordinate as defined by CIE = 1931.


Element Name: = PrimaryBChromaticityX
Level: =        6
ID: =           [55][D5]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 1
Default: =      -
f
Description: =  Blue X chromaticity coordinate as defined by CIE = 1931.


Element Name: = PrimaryBChromaticityY
Level: =        6
ID: =           [55][D6]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 1
Default: =      -
Type: =         f
Description: =  Blue Y chromaticity coordinate as defined by CIE = 1931.


Element Name: = WhitePointChromaticityX
Level: =        6
ID: =           [55][D7]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 1
Default: =      -
Type: =         f
Description: =  White point X chromaticity coordinate as defined by = CIE 1931.


Element Name: = WhitePointChromaticityY
Level: =        6
ID: =           [55][D8]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 1
Default: =      -
Type: =         f
Description: =  White point Y chromaticity coordinate as defined by = CIE 1931.


Element Name: = LuminanceMax
Level: =        6
ID: =           [55][D9]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 9999.99
Default: =      -
Type: =         f
Description:  Maximum = luminance. Shall be represented in candelas per square
=             &n= bsp;meter (cd/m=C2=B2).


Element Name: = LuminanceMin
Level: =        6
ID: =           [55][DA]
Mandatory: =    -
Multiple: =     -
Range: =        0 <=3D f <=3D 999.9999
Default: =      -
Type: =         f
Description:  Minimum = luminance. Shall be represented in candelas per square
=             &n= bsp;meter = (cd/m=C2=B2).



I removed ChromaSubsampling and = added ChromaSubsamplingHorz, ChromaSubsamplingVert, CbSubsamplingHorz, = and CbSubsamplingVert.

This is how I think the elements should be written for the = different subsampling types:
1: = 4:4:4
    - ChromaSubsamplingHorz and = ChromaSubsamplingVert will not be set as there should be no chroma = subsampling.

2: = 4:4:0
  - = ChromaSubsamplingHorz :not set
  - = ChromaSubsamplingVert :1

3: 4:2:2
  - ChromaSubsamplingHorz :1
  = - ChromaSubsamplingVert :not set

4: 4:2:1
  - ChromaSubsamplingHorz :1
  = - ChromaSubsamplingVert :not set
  - CbSubsamplingHorz :1
  - = CbSubsamplingVert :not set
  - We could = remove CbSubsamplingHorz and CbSubsamplingVert if we didn't care about = handling formats where the Cr and Cb channels are different = sizes.
I forgot about 4:2:1. That answers my = question about CbSubsmaplingHorz though perhaps we need a narrative = section to expand on this with the examples you have here.

5: 4:2:0
  - ChromaSubsamplingHorz :1
  = - ChromaSubsamplingVert :1

6: 4:1:1
  - = ChromaSubsamplingHorz :3
  - = ChromaSubsamplingVert :not set

7: 4:1:0
  - ChromaSubsamplingHorz :3
  = - ChromaSubsamplingVert :1

8: 3:1:1
  - ChromaSubsamplingHorz :2
  = - ChromaSubsamplingVert :not set
  - I'm = assuming the luma subsampling can be handled by PixelWidth, and = DisaplyWidth.

Jerome's vertical subsampling of 4
  - ChromaSubsamplingHorz :not set
  - ChromaSubsamplingVert :3



The other issue I want = to bring up is the value of "18: ARIB STD-B67 (HLG)" in TransferFunction. = Unfortunately, in WebM we will need to use this value sooner than = Matroska v4 will be finalized. Should I make this value much higher? Or = leave at 18? I think "16: SMPTE ST 2084" and "17: SMPTE ST 428-1" will be standardized across most = documents, like 1-15 are. Just not sure if 18 will be = HLG.

I see a few references to ARIB STD-B67 = as 18, such as http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_5.p= df. Perhaps we need a caveat that values 1-15 are defined based upon = ISO/IEC 23001-8. Then for values 16, 17, and 18 we could add better = descriptions and citations to define it better internally. =
I'm fine with this. I'm = just worried about the case where we diverge from one of the lists. = Would be nice to have one canonical list.
 
If (hopefully) a revision to = ISO/IEC 23001-8 adds those values (as expected) then we could update are = description to say all values are defined by ISO/IEC = 23001-8.
Sounds good to = me.

It's a bit risky. Perhaps for now we should = clarify that values 1-15 are defined by ISO/IEC 23001-8 and then = give customized definitions for 16, 17, 18.
Dave Rice

= --Apple-Mail=_A5A73883-2A5E-43CE-BC63-A66FC6373DAA-- From nobody Tue Feb 16 11:22:00 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B041B2FFD for ; Tue, 16 Feb 2016 11:21:58 -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, SPF_PASS=-0.001] autolearn=ham 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 Xme3qepmAnBW for ; Tue, 16 Feb 2016 11:21:54 -0800 (PST) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (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 F026E1A7D81 for ; Tue, 16 Feb 2016 11:21:53 -0800 (PST) Received: by mail-ob0-x232.google.com with SMTP id jq7so90595000obb.0 for ; Tue, 16 Feb 2016 11:21:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FIIV/8+6eK+dOLx4FZ5vC5i23Uc7OZ86zgKw+C/6rTc=; b=YHsUThL7fy/EDYGnvNTadd2u1S0okB+STzsqTVkX9F0hL3vr9SbkimMFioqzn5np9v NUkYlMjlYfvez4gS9x5IhbG1hz5dkO3h7v6u898vTh7glZxQt+xqyNxL4via3gyg3cWD 5kIjmAqW/UolfRqaD9QCHWtFxV6PG7aZwnUwC3BIuXk5wRitVNeZLPO0iwmgmLICOVMo AlhVeQtZghJhkObahI9USQILNSCoXhCm7JcQRQwuR9KWpOC1+TtSkaD0nb8Vu4ZRtFWs JaFAe1itfcekRQNxtrdUv6hx5Nt4LCpesrdViyHkpJG4UXpU/a262lB297IbdoJHfb0a cYog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FIIV/8+6eK+dOLx4FZ5vC5i23Uc7OZ86zgKw+C/6rTc=; b=kWkvCAfvUGrOfD/UEwSStw2uS2jM7aTPjGwinr6hAt5YrhFsk5OEuo3KCAJmY0FCsz 0827DBoHcSF8RE9g50WP82IlaezaU1P2J1xvHF4g0R1Honfa1pZh2wDKSLI3k93aEpmF TjPDaNM/06EgMfRkh5IxgN4r8+Zk04ub5+75Wo5q1S4M5vAsM1Yr/PhObxHuyjgEsp/F HQYFYyySArgCqj4jyxGi+bpEzlCD8Sf6J0veleoupjYTYiLIwRDLuk5yNCjntqKRfDaI A061kjLcncTgZhj4o24Mr5Y3epL9vRQCwKPDoO/kxN4ztEWCYxyXskDokEcnT3hJjISh /fIg== X-Gm-Message-State: AG10YOSnYMYSSJOvDgZE6hfg8eJRJeYz3ViD8x3/k3gRD58MZwwi9VG1xsrULeV794N0EqXbcNXL40kg8VT0+A== MIME-Version: 1.0 X-Received: by 10.60.79.102 with SMTP id i6mr18289414oex.4.1455650512748; Tue, 16 Feb 2016 11:21:52 -0800 (PST) Received: by 10.202.59.130 with HTTP; Tue, 16 Feb 2016 11:21:52 -0800 (PST) In-Reply-To: <56BF5847.7030901@mediaarea.net> References: <568C3CA0.8040300@mediaarea.net> <56B8CD1A.20307@mediaarea.net> <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> <56BF5847.7030901@mediaarea.net> Date: Tue, 16 Feb 2016 11:21:52 -0800 Message-ID: From: Frank Galligan To: Jerome Martinez Content-Type: multipart/alternative; boundary=089e0112ce78bac913052be80b80 Archived-At: Cc: Dave Rice , cellar@ietf.org, Discussion about the current and future development of Matroska Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2016 19:21:59 -0000 --089e0112ce78bac913052be80b80 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Feb 13, 2016 at 8:22 AM, Jerome Martinez wrote: > On 13/02/2016 02:53, Dave Rice wrote: > > > On Feb 11, 2016, at 1:32 PM, Frank Galligan via Matroska-devel < > matroska-devel@lists.matroska.org> wrote: > > [...] > > 4: 4:2:1 > - ChromaSubsamplingHorz :1 > - ChromaSubsamplingVert :not set > - CbSubsamplingHorz :1 > - CbSubsamplingVert :not set > - We could remove CbSubsamplingHorz and CbSubsamplingVert if we didn't > care about handling formats where the Cr and Cb channels are different > sizes. > > > I forgot about 4:2:1. That answers my question about CbSubsmaplingHorz > though perhaps we need a narrative section to expand on this with the > examples you have here. > > > I was also disturbed by CbSubsamplingHorz and CbSubsamplingVert because > there is no explaination about Cb and Cr in SubsamplingHorz and > SubsamplingVert. > So maybe we need to add explanation. > SubsamplingHorz and SubsamplingVert are for both Cb and Cr except > indicated otherwise. > CbSubsamplingHorz and CbSubsamplingVert are same as SubsamplingHorz and > SubsamplingVert if not present. > Jerome, check out the text I added to Dave's email and let me know if you think that is better. > > [...] > > The other issue I want to bring up is the value of "18: ARIB STD-B67 (HLG= )" > in TransferFunction. Unfortunately, in WebM we will need to use this valu= e > sooner than Matroska v4 will be finalized. Should I make this value much > higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17: SMPTE ST > 428-1" will be standardized across most documents, like 1-15 are. Just > not sure if 18 will be HLG. > > > I see a few references to ARIB STD-B67 as 18, such as > > http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_5.pdf. > Perhaps we need a caveat that values 1-15 are defined based upon ISO/IEC > 23001-8. > > > I don't follow: either we say that the list is the ISO/MPEG one and we > need to find another way to provide HLG value, or we say that we don't ca= re > of MPEG list. > Looks like we are in the middle (+ trying to use the FFmpeg list). > I think the FFmpeg list is just using the 265 list, which is basically a superset of 23001-8 (or 264 list). For example an answer about the reason we keep 0 and 3 as reserved is that > it is in other specs, but we also say that we don't care of other specs. = I > am lost. > If we forego the other lists, then I agree we should only have one value as unspecified. > > About HLG, my concern is not about Matroska v4 finalization, a bit out of > topic actually (a list would be update without a new version of Matroska) > but about the MPEG list. From document pointed by Dave, looks like ARIB h= as > a deal with MPEG and ISO, or tries to force value 18 for HLG, so I would > also use value 18, hoping that MPEG and ISO and ITU will accept value 18 > for HLG. > > Then for values 16, 17, and 18 we could add better descriptions and > citations to define it better internally. If (hopefully) a revision to > ISO/IEC 23001-8 adds those values (as expected) then we could update are > description to say all values are defined by ISO/IEC 23001-8. > > > Values 16 and 17 are already in ITU H.265 documentation. I would referenc= e > this document (bonus: it is publicly available) > I would just add a comment about value 18 =3D HLG. > If everyone else wants to do this, then I wouldn't object. The only reason I wouldn't want to do this, is that H.265 is a specific codec. I don't want to confuse people that these values are 265 specific. > But as a general view of how we manage the list: how do we plan to manage > it? If we say we try to follow MPEG list, maybe we need to have "temporar= y" > value e.g. >0x1000000 and we wait for an official announcement from > ITU/MPEG/ISO about value 18; if we don't care on any other list, we don't > care of the value for HLG (18 or whatever). > This is what I was trying to get at from the start. Do we want to try and follow another list? It seems like all of the lists try and follow each other, which I guess is good. But what happens when two diverge? > > I think that before freezing the list, we need to clear about what is thi= s > list, if we try to follow another list we need to wait for its maintainer= , > else we need to be coherent e.g. if we don't follow MPEG or FFmpeg list, > why do we have 0=3Dreserved and 3=3Dreserved and why 2=3Dunspecified when= all > other tags have 0=3Dunspecified and why 4 values (1, 6, 14, 15) for the s= ame > transfer characteristic? I would ask for a reason to have such value in t= he > list or remove it from the list, i.e 0=3Dunspecified, 1=3DITU-R BT.709, 2= =3DITU-R > BT.470M... > And define a method for updating it (and say who is the list maintainer) > if we are the "owner" of the list. > I agree if Matroska decides to maintain their own list, we should get rid of any redundant values. But I would rather follow another list (or bunch of lists that follow each other) then try and maintain our own. > > J=C3=A9r=C3=B4me > --089e0112ce78bac913052be80b80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Feb 13, 2016 at 8:22 AM, Jerome Martinez <= jerome@mediaarea.= net> wrote:
=20 =20 =20
On 13/02/2016 02:53, Dave Rice wrote:

On Feb 11, 2016, at 1:32 PM, Frank Galligan via Matroska-devel <matroska-devel@lists.matroska.org> wrote:
[...]

4: 4:2:1
=C2=A0 - ChromaSubsamplingHorz :1
=C2=A0 - ChromaSubsamplingVert :not set
=C2=A0 - CbSubsamplingHorz :1
=C2=A0 - CbSubsamplingVert :not set
=C2=A0 - We could remove CbSubsamplingHorz and CbSubsamplingVert if we didn't care about handling formats where the Cr and Cb channels are different sizes.

I forgot about 4:2:1. That answers my question about CbSubsmaplingHorz though perhaps we need a narrative section to expand on this with the examples you have here.

I was also disturbed by CbSubsamplingHorz and CbSubsamplingVert because there is no explaination about Cb and Cr in SubsamplingHorz and SubsamplingVert.
So maybe we need to add explanation.
SubsamplingHorz and SubsamplingVert are for both Cb and Cr except indicated otherwise.
CbSubsamplingHorz and CbSubsamplingVert are same as SubsamplingHorz and SubsamplingVert if not present.
Jerome, = check out the text I added to Dave's email and let me know if you think= that is better.
=C2=A0

[...]

The other issue I want to bring up is the value of "1= 8: ARIB STD-B67 (HLG)" in TransferFunction. Unfortunately, in WebM we will need to use this value sooner than Matroska v4 will be finalized. Should I make this value much higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17: SMPTE = ST 428-1" will be standardized across most documents, like 1-15 are. Just not sure if 18 will be HLG.

I see a few references to ARIB STD-B67 as 18, such as=C2=A0http://www.arib.or.jp/english/ht= ml/overview/doc/2-STD-B32v3_5.pdf. Perhaps we need a caveat that values 1-15 are defined based upon ISO/IEC 23001-8.

I don't follow: either we say that the list is the ISO/MPEG one and we need to find another way to provide HLG value, or we say that we don't care of MPEG list.
Looks like we are in the middle (+ trying to use the FFmpeg list).
<= /div>
I think the FFmpeg list is just using the 265 list, = which is basically a superset of 23001-8 (or 264 list).

For example an answer about the reason we keep 0 and 3 as reserved is that it is in other specs, but we also say that we don't care of other specs. I am lost.
If we forego the oth= er lists, then I agree we should only have one value as unspecified.
<= div>=C2=A0

About HLG, my concern is not about Matroska v4 finalization, a bit out of topic actually (a list would be update without a new version of Matroska) but about the MPEG list. From document pointed by Dave, looks like ARIB has a deal with MPEG and ISO, or tries to force value 18 for HLG, so I would also use value 18, hoping that MPEG and ISO and ITU will accept value 18 for HLG.=C2=A0

Then for values 16, 17, and 18 we could add better descriptions and citations to define it better internally. If (hopefully) a revision to ISO/IEC 23001-8 adds those values (as expected) then we could update are description to say all values are defined by ISO/IEC 23001-8.

Values 16 and 17 are already in ITU H.265 documentation. I would reference this document (bonus: it is publicly available)
I would just add a comment about value 18 =3D HLG.
If everyone else wants to do this, then I wouldn't object. The o= nly reason I wouldn't want to do this, is that H.265 is a specific code= c. I don't want to confuse people that these values are 265 specific.


But as a general view of how we manage the list: how do we plan to manage it? If we say we try to follow MPEG list, maybe we need to have "temporary" value e.g. >0x1000000 and we wait for an official announcement from ITU/MPEG/ISO about value 18; if we don't care on any other list, we don't care of the value for HLG (18 or whatever).
This is what I was trying to get = at from the start. Do we want to try and follow another list? It seems like= all of the lists try and follow each other, which I guess is good. But wha= t happens when two diverge?
=C2=A0

I think that before freezing the list, we need to clear about what is this list, if we try to follow another list we need to wait for its maintainer, else we need to be coherent e.g. if we don't follow MPEG or FFmpeg list, why do we have 0=3Dreserved and 3=3Dreserved and why 2=3Dunspecified when all other tags have 0=3Dunspecified and why 4 values (1, 6, 14, 15) for the same transfer characteristic? I would ask for a reason to have such value in the list or remove it from the list, i.e 0=3Dunspecified, 1=3DITU-R BT.709, 2=3DITU-R BT.470M... And define a method for updating it (and say who is the list maintainer) if we are the "owner" of the list.
I agree if Matroska decides to maintain their own list, we sho= uld get rid of any redundant values.=C2=A0

But I w= ould rather follow another list (or bunch of lists that follow each other) = then try and maintain our own.

J=C3=A9r=C3=B4me

--089e0112ce78bac913052be80b80-- From nobody Tue Feb 16 11:25:05 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39C31B361D for ; Tue, 16 Feb 2016 11:25:03 -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, SPF_PASS=-0.001] autolearn=ham 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 r6ERNsFtn1d1 for ; Tue, 16 Feb 2016 11:25:00 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8071B35F2 for ; Tue, 16 Feb 2016 11:25:00 -0800 (PST) Received: by mail-ob0-x22f.google.com with SMTP id xk3so273078279obc.2 for ; Tue, 16 Feb 2016 11:25:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=72xv2zvyd5G4EBe2qCetQ57nMmpf5b8hLBVLD/MkJdw=; b=kPmiua0glsr/6fsvajo84mQssNcaDzpdNkw2OcgaQEVYPQr166Uks4a82oAlh1UZIl dm+HI7MIiGeKFeb+isiDLPAc9H8H+MrqysFhVLbcpuoQcZTDRp9GUNeUSq1QAjz8/3Sc ftaxTqFEyVX6iu8+ws53VayYqg31J3yMH4a9xhCGEqgy0KGDcqmxvwOxT2dk6ib9lofR cTiono1EDSkBFORLte/EbJMSguaoOYi/ME0svtHPo2fzeefh6Plr6+KQcDtgIXIjfj9H /RvgQcxUq1PR8HqecPFIqvuazTtjA/GyBI3M46iA74rp338zgnSQ7zYDUCF81YxnwJZu dsLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=72xv2zvyd5G4EBe2qCetQ57nMmpf5b8hLBVLD/MkJdw=; b=banffcoL8Vo28BVSciU8CRB1LxuONbNSKT++v0LvmXpdxy8ptEaO55IYpzZ+dkLM8K ap4arGJoJHfGJRIT3Q5oEkAjDxGE+Zm2m2rbQAip52cJSEkAGyLfMuQd/H7w5yjhpOD0 brM60L4yNUgB5wF1iixzYCyoU7I8Saj29PCAYxNXAPqF6SBM67RYFTwi4ynmjAIW7UPW UzIXRnMVAC4gFIH5QsRphAJ3+/cv3CrG3THwsPJAYa32Z7DAZHvO8aH65Cd7mDTNv66J NviWduz+YQlX7iaTvnBABcDumQtDI9oEk4O2rPznHFdEfCN1lASHl8VlscwPGpiIGNrL BrkQ== X-Gm-Message-State: AG10YOTScL8M4tWkY/f9tpedoS60XcMWLmgyvxz3pgL0LhsDkYXHOfetB62lJGTz7ao1yJcpnYeMav5q5xSX2w== MIME-Version: 1.0 X-Received: by 10.202.74.9 with SMTP id x9mr15823659oia.67.1455650698245; Tue, 16 Feb 2016 11:24:58 -0800 (PST) Received: by 10.202.59.130 with HTTP; Tue, 16 Feb 2016 11:24:58 -0800 (PST) In-Reply-To: References: <568C3CA0.8040300@mediaarea.net> <56B8CD1A.20307@mediaarea.net> <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> <56BF5847.7030901@mediaarea.net> Date: Tue, 16 Feb 2016 11:24:58 -0800 Message-ID: From: Frank Galligan To: Steve Lhomme Content-Type: multipart/alternative; boundary=001a113db2bac93e17052be81633 Archived-At: Cc: Jerome Martinez , Dave Rice , cellar@ietf.org, Discussion about the current and future development of Matroska Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2016 19:25:03 -0000 --001a113db2bac93e17052be81633 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Feb 14, 2016 at 9:21 AM, Steve Lhomme wrote: > 2016-02-13 17:22 GMT+01:00 Jerome Martinez : > > On 13/02/2016 02:53, Dave Rice wrote: > > > > > > On Feb 11, 2016, at 1:32 PM, Frank Galligan via Matroska-devel > > wrote: > > > > [...] > > > > 4: 4:2:1 > > - ChromaSubsamplingHorz :1 > > - ChromaSubsamplingVert :not set > > - CbSubsamplingHorz :1 > > - CbSubsamplingVert :not set > > - We could remove CbSubsamplingHorz and CbSubsamplingVert if we didn'= t > > care about handling formats where the Cr and Cb channels are different > > sizes. > > > > > > I forgot about 4:2:1. That answers my question about CbSubsmaplingHorz > > though perhaps we need a narrative section to expand on this with the > > examples you have here. > > > > > > I was also disturbed by CbSubsamplingHorz and CbSubsamplingVert because > > there is no explaination about Cb and Cr in SubsamplingHorz and > > SubsamplingVert. > > So maybe we need to add explanation. > > SubsamplingHorz and SubsamplingVert are for both Cb and Cr except > indicated > > otherwise. > > CbSubsamplingHorz and CbSubsamplingVert are same as SubsamplingHorz and > > SubsamplingVert if not present. > > > > [...] > > > > The other issue I want to bring up is the value of "18: ARIB STD-B67 > (HLG)" > > in TransferFunction. Unfortunately, in WebM we will need to use this > value > > sooner than Matroska v4 will be finalized. Should I make this value muc= h > > higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17: SMPTE ST > 428-1" > > will be standardized across most documents, like 1-15 are. Just not sur= e > if > > 18 will be HLG. > > > > > > I see a few references to ARIB STD-B67 as 18, such as > > http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_5.pdf. > Perhaps > > we need a caveat that values 1-15 are defined based upon ISO/IEC 23001-= 8. > > > > > > I don't follow: either we say that the list is the ISO/MPEG one and we > need > > to find another way to provide HLG value, or we say that we don't care = of > > MPEG list. > > Looks like we are in the middle (+ trying to use the FFmpeg list). > > For example an answer about the reason we keep 0 and 3 as reserved is > that > > it is in other specs, but we also say that we don't care of other specs= . > I > > am lost. > > > > About HLG, my concern is not about Matroska v4 finalization, a bit out = of > > topic actually (a list would be update without a new version of Matrosk= a) > > but about the MPEG list. From document pointed by Dave, looks like ARIB > has > > a deal with MPEG and ISO, or tries to force value 18 for HLG, so I woul= d > > also use value 18, hoping that MPEG and ISO and ITU will accept value 1= 8 > for > > HLG. > > > > Then for values 16, 17, and 18 we could add better descriptions and > > citations to define it better internally. If (hopefully) a revision to > > ISO/IEC 23001-8 adds those values (as expected) then we could update ar= e > > description to say all values are defined by ISO/IEC 23001-8. > > > > > > Values 16 and 17 are already in ITU H.265 documentation. I would > reference > > this document (bonus: it is publicly available) > > I would just add a comment about value 18 =3D HLG. > > > > But as a general view of how we manage the list: how do we plan to mana= ge > > it? If we say we try to follow MPEG list, maybe we need to have > "temporary" > > value e.g. >0x1000000 and we wait for an official announcement from > > ITU/MPEG/ISO about value 18; if we don't care on any other list, we don= 't > > care of the value for HLG (18 or whatever). > > > > I think that before freezing the list, we need to clear about what is > this > > list, if we try to follow another list we need to wait for its > maintainer, > > else we need to be coherent e.g. if we don't follow MPEG or FFmpeg list= , > why > > do we have 0=3Dreserved and 3=3Dreserved and why 2=3Dunspecified when a= ll other > > tags have 0=3Dunspecified and why 4 values (1, 6, 14, 15) for the same > > transfer characteristic? I would ask for a reason to have such value in > the > > list or remove it from the list, i.e 0=3Dunspecified, 1=3DITU-R BT.709, > 2=3DITU-R > > BT.470M... > > And define a method for updating it (and say who is the list maintainer= ) > if > > we are the "owner" of the list. > > The goal (of Youtube) for now is to have a set of specs that will not > change in the future making their files invalid/unreadable. So I think > leaving values that are still up in the air is the best strategy for > now. Such values can be added later when finalizing the specs (if the > other standard bodies come up with something in time). > > > J=C3=A9r=C3=B4me > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > > > -- > Steve Lhomme > Matroska association Chairman > As Dave mentioned, there are strong indications from other sources that 18 will be used for "ARIB STD-B67 (HLG)". So I think we are OK with that, but we should figure out how we want to handle values in the future. --001a113db2bac93e17052be81633 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Feb 14, 2016 at 9:21 AM, Steve Lhomme <slhomme@matroska.org= > wrote:
2016-02-13 17:22 GMT+01:00 Jerome Martinez <jerome@mediaarea.net>:
> On 13/02/2016 02:53, Dave Rice wrote:
>
>
> On Feb 11, 2016, at 1:32 PM, Frank Galligan via Matroska-devel
> <matroska-deve= l@lists.matroska.org> wrote:
>
> [...]
>
> 4: 4:2:1
>=C2=A0 =C2=A0- ChromaSubsamplingHorz :1
>=C2=A0 =C2=A0- ChromaSubsamplingVert :not set
>=C2=A0 =C2=A0- CbSubsamplingHorz :1
>=C2=A0 =C2=A0- CbSubsamplingVert :not set
>=C2=A0 =C2=A0- We could remove CbSubsamplingHorz and CbSubsamplingVert = if we didn't
> care about handling formats where the Cr and Cb channels are different=
> sizes.
>
>
> I forgot about 4:2:1. That answers my question about CbSubsmaplingHorz=
> though perhaps we need a narrative section to expand on this with the<= br> > examples you have here.
>
>
> I was also disturbed by CbSubsamplingHorz and CbSubsamplingVert becaus= e
> there is no explaination about Cb and Cr in SubsamplingHorz and
> SubsamplingVert.
> So maybe we need to add explanation.
> SubsamplingHorz and SubsamplingVert are for both Cb and Cr except indi= cated
> otherwise.
> CbSubsamplingHorz and CbSubsamplingVert are same as SubsamplingHorz an= d
> SubsamplingVert if not present.
>
> [...]
>
> The other issue I want to bring up is the value of "18: ARIB STD-= B67 (HLG)"
> in TransferFunction. Unfortunately, in WebM we will need to use this v= alue
> sooner than Matroska v4 will be finalized. Should I make this value mu= ch
> higher? Or leave at 18? I think "16: SMPTE ST 2084" and &quo= t;17: SMPTE ST 428-1"
> will be standardized across most documents, like 1-15 are. Just not su= re if
> 18 will be HLG.
>
>
> I see a few references to ARIB STD-B67 as 18, such as
> http://www.arib.or.jp/english/= html/overview/doc/2-STD-B32v3_5.pdf. Perhaps
> we need a caveat that values 1-15 are defined based upon ISO/IEC 23001= -8.
>
>
> I don't follow: either we say that the list is the ISO/MPEG one an= d we need
> to find another way to provide HLG value, or we say that we don't = care of
> MPEG list.
> Looks like we are in the middle (+ trying to use the FFmpeg list).
> For example an answer about the reason we keep 0 and 3 as reserved is = that
> it is in other specs, but we also say that we don't care of other = specs. I
> am lost.
>
> About HLG, my concern is not about Matroska v4 finalization, a bit out= of
> topic actually (a list would be update without a new version of Matros= ka)
> but about the MPEG list. From document pointed by Dave, looks like ARI= B has
> a deal with MPEG and ISO, or tries to force value 18 for HLG, so I wou= ld
> also use value 18, hoping that MPEG and ISO and ITU will accept value = 18 for
> HLG.
>
> Then for values 16, 17, and 18 we could add better descriptions and > citations to define it better internally. If (hopefully) a revision to=
> ISO/IEC 23001-8 adds those values (as expected) then we could update a= re
> description to say all values are defined by ISO/IEC 23001-8.
>
>
> Values 16 and 17 are already in ITU H.265 documentation. I would refer= ence
> this document (bonus: it is publicly available)
> I would just add a comment about value 18 =3D HLG.
>
> But as a general view of how we manage the list: how do we plan to man= age
> it? If we say we try to follow MPEG list, maybe we need to have "= temporary"
> value e.g. >0x1000000 and we wait for an official announcement from=
> ITU/MPEG/ISO about value 18; if we don't care on any other list, w= e don't
> care of the value for HLG (18 or whatever).
>
> I think that before freezing the list, we need to clear about what is = this
> list, if we try to follow another list we need to wait for its maintai= ner,
> else we need to be coherent e.g. if we don't follow MPEG or FFmpeg= list, why
> do we have 0=3Dreserved and 3=3Dreserved and why 2=3Dunspecified when = all other
> tags have 0=3Dunspecified and why 4 values (1, 6, 14, 15) for the same=
> transfer characteristic? I would ask for a reason to have such value i= n the
> list or remove it from the list, i.e 0=3Dunspecified, 1=3DITU-R BT.709= , 2=3DITU-R
> BT.470M...
> And define a method for updating it (and say who is the list maintaine= r) if
> we are the "owner" of the list.

The goal (of Youtube) for now is to have a set of specs that wi= ll not
change in the future making their files invalid/unreadable. So I think
leaving values that are still up in the air is the best strategy for
now. Such values can be added later when finalizing the specs (if the
other standard bodies come up with something in time).

> J=C3=A9r=C3=B4me
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar >



--
Steve Lhomme
Matroska association Chairman

As Dave mentioned, there are strong indications from other sources that = 18 will be used for "ARIB STD-B67 (HLG)". So I think we are OK wi= th that, but we should figure out how we want to handle values in the futur= e.

--001a113db2bac93e17052be81633-- From nobody Tue Feb 16 11:27:12 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9871E1B347F for ; Tue, 16 Feb 2016 11:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 aI1D4n_N7hCl for ; Tue, 16 Feb 2016 11:27:07 -0800 (PST) Received: from smtp-sh2.infomaniak.ch (smtp-sh2.infomaniak.ch [128.65.195.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDC41A87E7 for ; Tue, 16 Feb 2016 11:27:06 -0800 (PST) Received: from smtp4.infomaniak.ch (smtp4.infomaniak.ch [84.16.68.92]) by smtp-sh.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u1GJR4lY011075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 16 Feb 2016 20:27:04 +0100 Received: from Castor.local (85-218-38-132.dclient.lsne.ch [85.218.38.132]) (authenticated bits=0) by smtp4.infomaniak.ch (8.14.5/8.14.5) with ESMTP id u1GJR3en016805 for ; Tue, 16 Feb 2016 20:27:04 +0100 Date: Tue, 16 Feb 2016 20:27:04 +0100 From: Reto Kromer To: cellar@ietf.org X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-Antivirus: Dr.Web (R) for Unix mail servers drweb plugin ver.6.0.2.8 X-Antivirus-Code: 0x100000 Archived-At: Subject: Re: [Cellar] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2016 19:27:10 -0000 Peter B. wrote: >I wouldn't want to rule out the option of transcoding from >DPX to FFV1/MKV. >But on the other hand, I'm very much in favor of keeping >things simple - and not overdoing it. > >I think being able to handle non-linear color values (as >often found in DPX scans) is important, but I wouldn't go >as far as putting something like "printing density" into >the standard. Hmm... To include this possibility would be very interesting to me. To have only one format for the "archival masters" is a very nice idea indeed. Today we store our Y'CbCr 4:2:2 10-bit "masters" as FFV1 and XYZ or RGB 4:4:4 16-bit floating-point "masters" as OpenEXR. Best regards, Reto AV Preservation by reto.ch chemin du Suchet 5 | 1024 Ecublens | Switzerland Web: http://reto.ch | Twitter: @retoch From nobody Tue Feb 16 11:56:23 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A3E41A1A9F for ; Tue, 16 Feb 2016 11:56:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.167 X-Spam-Level: X-Spam-Status: No, score=0.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 dOR4dHbDJH8j for ; Tue, 16 Feb 2016 11:56:13 -0800 (PST) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96B841A8A3A for ; Tue, 16 Feb 2016 11:56:13 -0800 (PST) Received: by mail-ig0-x22f.google.com with SMTP id 5so86756535igt.0 for ; Tue, 16 Feb 2016 11:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZreSqck/qIsZZniKyEkx7CjBSH8E3bJXfjNgk4mLkjo=; b=bBMxh3vIau9C8BmEyysnIjTZE4qIxjSP5K77DAeTXqQsNLSKAKFikn/8xN7BUw7AOM Lrwrdmp9JILaYLtxIalKiMfwBhB9lpZTKWHvT20kW+sOrpVDeWWyQTTqJRdokk4b+0CO 2kKxAP/xbKZo8T4V60SoX7l/kdCHdnawsyuTxgWfn6yvzzDzHvkb7mXJ9QT2naBcrDnv ycy5j7Wwg+yVQAZdt7c+mjDRCeVE00k8KabZMXgBvIiYe6i8p0LH9S7LM3OIUydukPOy fhMfjIMx3KS6CMtex3hl8KIouMthSs1IDq7vuGHjxN5yfUXfzqJduzXIbhnWd2jkWzEH yTtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZreSqck/qIsZZniKyEkx7CjBSH8E3bJXfjNgk4mLkjo=; b=EnWvE/XXTqZR8Aa1XksEzLQ2lsVs98oAZBAN1WHkkQkCDXGVi+OaW9QsYQdwC0xiw/ zcRxQyFsClkzxFIrb/zyRJHY1uSDULdMSrQNaqmRcATD2SHuzg1AwSliAU5gj9BlSOb6 rXrvjBLSN0It5NJ65KiK3SKKqV0Kvvr1HLhiqL+Ufy5Y+3+IVvlmFEsyvbN0L3zkjxb4 IoWcWf1Bjy19MeJGmf9UCWAcODjN1JAj9I/kivg5pwjKjucCU7v0j5/Uns+4ljM0QYpL b5nXqDRrpyE3QvidExYurYXVZuNOcihcJ5p9cag+Q/Av+RMUA2yLo6NHaWRXye5rbwPX HEkA== X-Gm-Message-State: AG10YOR8MX+XLtH/eUQOpADN4xp0CMuGlGwWtuKGkvMXrrf5KB37SoG2vuBnUU5bAlamcpuwD7sOPH1CSbqCwQ== MIME-Version: 1.0 X-Received: by 10.202.59.137 with SMTP id i131mr18293180oia.62.1455652572496; Tue, 16 Feb 2016 11:56:12 -0800 (PST) Received: by 10.202.59.130 with HTTP; Tue, 16 Feb 2016 11:56:12 -0800 (PST) In-Reply-To: <9CE0170E-E63D-411D-AFAF-EE5CBB4B56D7@dericed.com> References: <568C3CA0.8040300@mediaarea.net> <56B8CD1A.20307@mediaarea.net> <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> <9CE0170E-E63D-411D-AFAF-EE5CBB4B56D7@dericed.com> Date: Tue, 16 Feb 2016 11:56:12 -0800 Message-ID: From: Frank Galligan To: Dave Rice Content-Type: multipart/alternative; boundary=001a113cc7f2800bfa052be886f7 Archived-At: Cc: Jerome Martinez , Discussion about the current and future development of Matroska , cellar@ietf.org Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 16 Feb 2016 19:56:20 -0000 --001a113cc7f2800bfa052be886f7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 16, 2016 at 11:14 AM, Dave Rice wrote: > > On Feb 16, 2016, at 2:01 PM, Frank Galligan > wrote: > > > > On Fri, Feb 12, 2016 at 5:53 PM, Dave Rice wrote: > >> Hi, >> >> >> Element Name: Colour >> Level: 4 >> ID: [55][B0] >> Mandatory: - >> Multiple: - >> Default: - >> Type: m >> Description: Settings describing the colour format. >> >> >> Element Name: Matrix >> >> >> To align better with ISO/IEC 23001-8, could this be labelled as >> MatrixCoefficients? >> > Done > > >> >> Level: 5 >> ID: [55][B1] >> Mandatory: - >> Multiple: - >> Default: 2 >> Type: u >> Description: ColourMatrix of the video. See ISO/IEC 23001-8 for more >> information on enumerations. (0: IEC 61966-2-1 (sRGB), 1: >> BT709, >> 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE >> 170M, >> 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance, >> 10: BT2020 Constant Luminance) >> >> >> Suggested description edit: >> The Matrix Coefficients of the video used to derive luma and chroma >> values from reg, green, and blue color primaries. For clarity, the value >> and meanings for MatrixCoefficients are adopted from Table 4 of ISO/IEC >> 23001-8:2013/DCOR1. (0: IEC 61966-2-1 (sRGB), 1: BT709, 2: Unspecified, = 3: >> Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: YCOCG, 9: >> BT2020 Non-constant Luminance, 10: BT2020 Constant Luminance) >> > Done > >> >> Question: >> Value 0 is listed as "IEC 61966-2-1 (sRGB)" but the table for matrix >> coefficients in ISO/IEC 23001-8 says "GBR / Typically referred to as RGB= ". >> Should value 0 =3D RGB? >> > I changed it to GBR to match 23001-8. > > >> Add footnote: >> [IEC23001-8] ISO/IEC 23001-8:2013/DCOR1, "Coding independent media >> description code points", 2013, < >> http://standards.iso.org/ittf/PubliclyAvailableStandards/c062088_ISO_IEC= _23001-8_2013.zip >> >. >> >> Element Name: BitsPerChannel >> Level: 5 >> ID: [55][B2] >> Mandatory: - >> Multiple: - >> Default: 0 >> Type: u >> Description: Number of decoded bits per channel. This number may be les= s >> for >> specific channels depending on the Matrix and >> ChromaSubsampling. A >> value of 0 is unspecified. >> >> >> It may be fine, but I don't understand "This number may be less for >> specific channels depending on the Matrix and ChromaSubsampling." Is the >> value is less for specific channels, then it seems as if the value would >> different among channels, but only one BitsPerChannel is stored for a >> multi-channel video. >> > So we could have separate bits per channel, but then we would have to > define rgb and yuv. Most people know what this is. Basically the > information needed is, will the decoded video be 8 bits, 10 bits, 12 bits= , > 16 bits, ... Maybe I was just trying to be a little too pedantic. I'm fin= e > with removing this sentence. > > > +1 for removing it. > Done > > if any of the ChromaSubsampling elements are set then that implies that > one or more channels will have a different value. > > > Ah, I had been presuming that you meant bits per channel of a channel's > sample, rather than the total of the bits per channel (all samples/pixels > of a frame). > > So how about we just remove this sentence? > > >> I suggest changing the last line to: A value of 0 indicates that the >> BitsPerChannel is unspecified. >> > Done > >> >> Element Name: ChromaSubsamplingHorz >> Level: 5 >> ID: [55][B3] >> Mandatory: - >> Multiple: - >> Default: - >> Type: u >> Description: The amount of chrominance pixels to remove for every >> chrominance >> pixel not removed horizontally. >> >> >> For these subsampling elements, we may need a statement to say when they >> should be used. For instance in QuickTime's TN2162 >> https://developer.apple.com/library/mac/technotes/tn2162/_index.html it >> mandates the use of many values to better describe uncompressed video. W= hen >> would these chroma subsampling elements be suggested? >> > I'm not really sure I follow. If any of the Cb or Cr channels are down > sized before encoding, then these elements should be set accordingly. > > > I mean that this field is defined as being optional, but there's no > indication to say when it should or when it shouldn't be used. This > probably applies to most of these fields (and much of the matroska spec). > Ahh, OK. Yeah I have always been under the impression that you shouldn't be using these elements unless you know what you are doing. Again as you said that pertains to a lot of the elements in the Matroska spec (as well as other specs). We could always expand upon these further in other documents/guides, but for the spec I just want to accurately represent information that will be used. > > I also suggest including an example; such as "Example: For video with >> 4:1:1 chroma subsampling the ChromaSubsamplingHorz should be set to 3. >> > I added "Example: For video with 4:2:0 chroma subsampling the > ChromaSubsamplingHorz should be set to 1." As pretty much most video is > 4:4:4 or 4:2:0 nowadays. > > >> Element Name: ChromaSubsamplingVert >> Level: 5 >> ID: [55][B4] >> Mandatory: - >> Multiple: - >> Default: - >> Type: u >> Description: The amount of chrominance pixels to remove for every >> chrominance >> pixel not removed vertically. >> >> Element Name: CbSubsamplingHorz >> Level: 5 >> ID: [55][B5] >> Mandatory: - >> Multiple: - >> Default: - >> Type: u >> Description: The amount of Cb chrominance pixels to remove for every Cb >> chrominance pixel not removed horizontally. This is additiv= e >> with >> ChromaSubsamplingHorz. >> >> >> I'm confused about the relationship between CbSubsamplingHorz >> and ChromaSubsamplingHorz. >> > These elements are only defined because I was trying to handle 4:2:1. > Basically this is an old format where the Cr channel is half the size of > the Y channel, and the Cb channel is half the size of the Cr channel. The > Cb channel is a quarter the size of the Y channel. > > The CbSubsampling* elements were a late edition, right before I sent my > previous email. At first I didn't have these elements and had text that > 4:2:1 was not supported. > > > Right. Sorry I wrote my comments before considering 4:2:1, since the > fields are quite customized for situations like 4:2:1, perhaps it should = be > referenced by name as an example. > > How about I change the CbSubsamplingHorz element text too: "The amount of > pixels to remove in the Cr and Cb channels for every pixel not removed > horizontally." And the CbSubsamplingHorz too: "The amount of pixels to > remove in the Cb channel for every pixel not removed horizontally. This i= s > additive with ChromaSubsamplingHorz. Example: For video with 4:2:1 chroma > subsampling the ChromaSubsamplingHorz should be set to 1 and > CbSubsamplingHorz should be set to 1." Does this help the confusion? > > > +1 > > Element Name: CbSubsamplingVert >> Level: 5 >> ID: [55][B6] >> Mandatory: - >> Multiple: - >> Default: - >> Type: u >> Description: The amount of Cb chrominance pixels to remove for every Cb >> chrominance pixel not removed vertically. This is additive >> with >> ChromaSubsamplingVert. >> >> >> Element Name: ChromaSitingHorz >> Level: 5 >> ID: [55][B7] >> Mandatory: - >> Multiple: - >> Default: 0 >> Type: u >> Description: How Chroma is subsampled horizontally. (0: Unspecified, 1: >> Left >> collocated , 2: Half) >> >> Element Name: ChromaSitingVert >> Level: 5 >> ID: [55][B8] >> Mandatory: - >> Multiple: - >> Default: 0 >> Type: u >> Description: How Chroma is subsampled vertically. (0: Unspecified, 1: T= op >> collocated , 2: Half) >> >> >> Element Name: Range >> Level: 5 >> ID: [55][B9] >> Mandatory: - >> Multiple: - >> Default: 0 >> Type: u >> Description: Clipping of the color ranges. (0: Unspecified, 1: >> Broadcast range, >> 2: Full range (no clipping), 3: Defined by >> Matrix/TransferFunction) >> >> >> Element Name: TransferFunction >> >> >> To align with ISO/IEC 23001-8, could we use TransferCharacteristics? >> > Done. > >> >> Level: 5 >> ID: [55][BA] >> Mandatory: - >> Multiple: - >> Default: 2 >> Type: u >> Description: Transfer Function. See ISO/IEC 23001-8 for more informatio= n >> on >> enumerations. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified= , >> 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, >> 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log >> Sqrt, >> 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut, >> 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, >> 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, >> 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) >> >> >> Comment: >> The table in ISO/IEC 23001-8 for transfer characteristics does not >> include values or meaning for 16, 17 and 18 as above. Are these values f= rom >> ffmpeg's list? >> > 16 and 17 is an artifact form the FFmpeg list, but also form looking at > FFmpeg CL's I think they are defined in an h265 spec. 18 is a proposed > value for HLG. > > >> Suggested description edit: >> The transfer characteristics of the video. For clarity, the value and >> meanings for TransferCharacteristics are adopted from Table 3 of ISO/IEC >> 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: >> Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, 7: SMPT= E >> 240M, 8: Linear, 9: Log, 10: Log Sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.1= 361 >> Extended Colour Gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: >> ITU-R BT.2020 12 bit) >> > Done. > > >> >> Element Name: Primaries >> Level: 5 >> Mandatory: - >> Multiple: - >> ID: [55][BB] >> Default: 2 >> Type: u >> Description: Values that can be represented in the CIE 1931 colour >> space. See >> ISO/IEC 23001-8 for more information on enumerations. >> (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved, >> 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPT= E >> 240M, >> 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1) >> >> >> Suggested description edit: >> The colour primaries of the video. For clarity, the value and meanings >> for TransferCharacteristics are adopted from Table 2 of ISO/IEC >> 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: >> Reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE >> 240M, 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1) >> > Done. > >> >> Note that ISO/IEC 23001-8 also includes a value for 22 for JEDEC P22 >> phosphors. Any reason to exclude this? >> > Added. > > >> >> Element Name: MaxCLL >> Level: 5 >> ID: [55][BC] >> Mandatory: - >> Multiple: - >> Default: - >> Type: u >> Description: Maximum brightness of a single pixel in candelas per squar= e >> meter (cd/m=C2=B2). >> >> >> Suggested: >> Maximum brightness of a single pixel (Maximum Content Light Level) in >> candelas per square meter (cd/m=C2=B2). >> > Done > > >> >> Element Name: MaxFALL >> Level: 5 >> ID: [55][BD] >> Mandatory: - >> Multiple: - >> Default: - >> Type: u >> Description: Maximum brightness of a single full frame in candelas per >> square >> meter (cd/m=C2=B2). >> >> >> Suggested: >> Maximum brightness of a single full frame (Maximum Frame-Average Light >> Level) in candelas per square meter (cd/m=C2=B2). >> > Done > > >> >> Element Name: MasteringMetadata >> Level: 5 >> ID: [55][D0] >> Mandatory: - >> Multiple: - >> Default: - >> Type: m >> Description: SMPTE 2086 mastering data. >> >> >> Element Name: PrimaryRChromaticityX >> Level: 6 >> ID: [55][D1] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >> >> >> I think "0.0-1.0" is preferred for float range expressions. >> > > Sorry there's an open discussion elsewhere on Cellar about expressing > float ranges as hexadecimal floating-point literals, so this may be chang= ed > later, but the meaning should still be the same. > No problem. I just had it that way for brevity, much like a lot of my other descriptions. I don't want to add to much text to a cell of the Matroska spec table. :) > Done > > >> >> Default: - >> Type: f >> Description: Red X chromaticity coordinate as defined by CIE 1931. >> >> >> Element Name: PrimaryRChromaticityY >> Level: 6 >> ID: [55][D2] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >> Default: - >> Type: f >> Description: Red Y chromaticity coordinate as defined by CIE 1931. >> >> >> Element Name: PrimaryGChromaticityX >> Level: 6 >> ID: [55][D3] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >> Default: - >> f >> Description: Green X chromaticity coordinate as defined by CIE 1931. >> >> >> Element Name: PrimaryGChromaticityY >> Level: 6 >> ID: [55][D4] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >> Default: - >> Type: f >> Description: Green Y chromaticity coordinate as defined by CIE 1931. >> >> >> Element Name: PrimaryBChromaticityX >> Level: 6 >> ID: [55][D5] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >> Default: - >> f >> Description: Blue X chromaticity coordinate as defined by CIE 1931. >> >> >> Element Name: PrimaryBChromaticityY >> Level: 6 >> ID: [55][D6] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >> Default: - >> Type: f >> Description: Blue Y chromaticity coordinate as defined by CIE 1931. >> >> >> Element Name: WhitePointChromaticityX >> Level: 6 >> ID: [55][D7] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >> Default: - >> Type: f >> Description: White point X chromaticity coordinate as defined by CIE >> 1931. >> >> >> Element Name: WhitePointChromaticityY >> Level: 6 >> ID: [55][D8] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 1 >> Default: - >> Type: f >> Description: White point Y chromaticity coordinate as defined by CIE >> 1931. >> >> >> Element Name: LuminanceMax >> Level: 6 >> ID: [55][D9] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 9999.99 >> Default: - >> Type: f >> Description: Maximum luminance. Shall be represented in candelas per >> square >> meter (cd/m=C2=B2). >> >> >> Element Name: LuminanceMin >> Level: 6 >> ID: [55][DA] >> Mandatory: - >> Multiple: - >> Range: 0 <=3D f <=3D 999.9999 >> Default: - >> Type: f >> Description: Minimum luminance. Shall be represented in candelas per >> square >> meter (cd/m=C2=B2). >> >> >> >> >> I removed ChromaSubsampling and added ChromaSubsamplingHorz, >> ChromaSubsamplingVert, CbSubsamplingHorz, and CbSubsamplingVert. >> >> This is how I think the elements should be written for the different >> subsampling types: >> 1: 4:4:4 >> - ChromaSubsamplingHorz and ChromaSubsamplingVert will not be set as >> there should be no chroma subsampling. >> >> 2: 4:4:0 >> - ChromaSubsamplingHorz :not set >> - ChromaSubsamplingVert :1 >> >> 3: 4:2:2 >> - ChromaSubsamplingHorz :1 >> - ChromaSubsamplingVert :not set >> >> 4: 4:2:1 >> - ChromaSubsamplingHorz :1 >> - ChromaSubsamplingVert :not set >> - CbSubsamplingHorz :1 >> - CbSubsamplingVert :not set >> - We could remove CbSubsamplingHorz and CbSubsamplingVert if we didn't >> care about handling formats where the Cr and Cb channels are different >> sizes. >> >> >> I forgot about 4:2:1. That answers my question about CbSubsmaplingHorz >> though perhaps we need a narrative section to expand on this with the >> examples you have here. >> >> 5: 4:2:0 >> - ChromaSubsamplingHorz :1 >> - ChromaSubsamplingVert :1 >> >> 6: 4:1:1 >> - ChromaSubsamplingHorz :3 >> - ChromaSubsamplingVert :not set >> >> 7: 4:1:0 >> - ChromaSubsamplingHorz :3 >> - ChromaSubsamplingVert :1 >> >> 8: 3:1:1 >> - ChromaSubsamplingHorz :2 >> - ChromaSubsamplingVert :not set >> - I'm assuming the luma subsampling can be handled by PixelWidth, and >> DisaplyWidth. >> >> Jerome's vertical subsampling of 4 >> - ChromaSubsamplingHorz :not set >> - ChromaSubsamplingVert :3 >> >> >> >> The other issue I want to bring up is the value of "18: ARIB STD-B67 >> (HLG)" in TransferFunction. Unfortunately, in WebM we will need to use >> this value sooner than Matroska v4 will be finalized. Should I make this >> value much higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17: >> SMPTE ST 428-1" will be standardized across most documents, like 1-15 >> are. Just not sure if 18 will be HLG. >> >> >> I see a few references to ARIB STD-B67 as 18, such as >> http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_5.pdf. >> Perhaps we need a caveat that values 1-15 are defined based upon ISO/IEC >> 23001-8. Then for values 16, 17, and 18 we could add better descriptions >> and citations to define it better internally. >> > I'm fine with this. I'm just worried about the case where we diverge from > one of the lists. Would be nice to have one canonical list. > > >> If (hopefully) a revision to ISO/IEC 23001-8 adds those values (as >> expected) then we could update are description to say all values are >> defined by ISO/IEC 23001-8. >> > Sounds good to me. > > > It's a bit risky. Perhaps for now we should clarify that values 1-15 are > defined by ISO/IEC 23001-8 and then give customized definitions for 16, 1= 7, > 18. > Following Jerome's comment, how about this for TransferCharacteristic: "The transfer characteristics of the video. For clarity, the value and meanings for TransferCharacteristics 1-15 are adopted from Table 3 of ISO/IEC 23001-8:2013/DCOR1. TransferCharacteristics 16-17 are adopted from <265 doc> and 18 is the proposed value of ARIB STD-B67. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG))" Dave Rice > > --001a113cc7f2800bfa052be886f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 16, 2016 at 11:14 AM, Dave Rice <dave@dericed.com> wrote:

On Feb 16, 2016, at 2:01 PM, Frank Gallig= an <frankga= lligan@gmail.com> wrote:



On Fri, Feb 12, 2016 at 5= :53 PM, Dave Rice <dave@dericed.com> wrote:
Hi,

Element Name: Colour
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A04
I= D: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B0]
<= span style=3D"font-size:13.3333px;font-family:'Courier New';color:r= gb(34,34,34);font-weight:400;font-style:normal;font-variant:normal;text-dec= oration:none;vertical-align:baseline;white-space:pre-wrap;background-color:= rgb(255,255,255)">Mandatory: =C2=A0=C2=A0=C2=A0-
Multi= ple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0m
Description: =C2=A0Settings des= cribing the colour format.


Element Name: M= atrix

To align better with ISO/IEC 23001-8, could this be labelled as Matr= ixCoefficients?
Done
=C2=A0

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0[55][B1]
Mandatory: =C2=A0=C2= =A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-<= /div>
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A02
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0ColourMatrix of the video. See ISO/IEC 23001-8 for mo= re
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0information on enumerations. (0: IEC 61966-2-= 1 (sRGB), 1: BT709,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A02: Unspecified, 3: Reserved, 4= : FCC, 5: BT470BG, 6: SMPTE 170M,
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A07: SMPTE 240M, = 8: YCOCG, 9: BT2020 Non-constant Luminance,
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A010: BT= 2020 Constant Luminance)
<= /blockquote>

Suggested description edit:
= The Matrix Coefficients of the video used to derive luma and chroma values = from reg, green, and blue color primaries. For clarity, the value and meani= ngs for MatrixCoefficients are adopted from Table 4 of ISO/IEC 23001-8:2013= /DCOR1. (0: IEC 61966-2-1 (sRGB), 1: BT709, 2: Unspecified, 3: Reserved, 4:= FCC, 5: BT470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-con= stant Luminance, 10: BT2020 Constant Luminance)
Done=C2=A0

Question:
Value 0 is listed as &= quot;IEC 61966-2-1 (sRGB)" but the table for matrix coefficients in IS= O/IEC 23001-8 says "GBR / Typically referred to as RGB". Should v= alue 0 =3D RGB?
I changed it to GBR to m= atch 23001-8.


Add footnote:
[IEC23001-8]= ISO/IEC 23001-8:2013/DCOR1, "Coding independent media description cod= e points", 2013, <http= ://standards.iso.org/ittf/PubliclyAvailableStandards/c062088_ISO_IEC_23001-= 8_2013.zip>.

Element Name: BitsPerChannel
Level: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B2]
Mandat= ory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0= =C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A00
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
<= span style=3D"font-size:13.3333px;font-family:'Courier New';color:r= gb(34,34,34);font-weight:400;font-style:normal;font-variant:normal;text-dec= oration:none;vertical-align:baseline;white-space:pre-wrap;background-color:= rgb(255,255,255)">Description: =C2=A0Number of decoded bits per channel. Th= is number may be less for
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0specific channels dep= ending on the Matrix and ChromaSubsampling. A
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0val= ue of 0 is unspecified.

It may be fine, but I don't understand &= quot;This number may be less for specific channels depending on the Matrix = and ChromaSubsampling." Is the value is less for specific channels, th= en it seems as if the value would different among channels, but only one Bi= tsPerChannel is stored for a multi-channel video.
So we could have separate bits per channel, but then we would hav= e to define rgb and yuv. Most people know what this is. Basically the infor= mation needed is, will the decoded video be 8 bits, 10 bits, 12 bits, 16 bi= ts, ... Maybe I was just trying to be a little too pedantic. I'm fine w= ith removing this sentence.
=
+1 for removing it.
Done<= /div>
=C2=A0
=

if any of the ChromaSubsampling el= ements are set then that implies that one or more channels will have a diff= erent value.

= Ah, I had been presuming that you meant bits per channel of a channel's= sample, rather than the total of the bits per channel (all samples/pixels = of a frame).

So how about we just = remove this sentence?


I suggest changing the last li= ne to: A value of 0 indicates that the BitsPerChannel is unspecified.
=
Done=C2=A0

Element Nam= e: ChromaSubsamplingHorz
Level: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B3]
Mandatory: = =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0= -
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0The amount of chrominance pixels to remove f= or every chrominance
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0pixel not removed horizonta= lly.

For these subsampling elements, we may need a statement to say when t= hey should be used. For instance in QuickTime's=C2=A0TN2162 https://developer.apple.com/library/mac/technotes/tn2162/_inde= x.html=C2=A0it mandates the use of many values to better describe uncom= pressed video. When would these chroma subsampling elements be suggested?
I'm not really sure I follow. If any = of the Cb or Cr channels are down sized before encoding, then these element= s should be set accordingly.=C2=A0

I mean that this field is defined as being optional, = but there's no indication to say when it should or when it shouldn'= t be used. This probably applies to most of these fields (and much of the m= atroska spec).
Ahh, OK. Yeah I have alwa= ys been under the impression that you shouldn't be using these elements= unless you know what you are doing. Again as you said that pertains to a l= ot of the elements in the Matroska spec (as well as other specs).

We could always expand upon these further in other document= s/guides, but for the spec I just want to accurately represent information = that will be used.

I also suggest including an example; such as &quo= t;Example: For video with 4:1:1 chroma subsampling the=C2=A0ChromaSubsampli= ngHorz should be set to 3.
I added "= ;Example: For video with 4:2:0 chroma subsampling the ChromaSubsamplingHorz= should be set to 1." As pretty much most video is 4:4:4 or 4:2:0 nowa= days.


Element Name: Chroma= SubsamplingVert
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0[55][B4]
Mandatory: =C2=A0=C2= =A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-<= /div>
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0The amount of chrominance pixels to remove for every = chrominance
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0pixel not removed vertically.=

Element Name: CbSubsamplingHorz
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
I= D: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B5]
<= span style=3D"font-size:13.3333px;font-family:'Courier New';color:r= gb(34,34,34);font-weight:400;font-style:normal;font-variant:normal;text-dec= oration:none;vertical-align:baseline;white-space:pre-wrap;background-color:= rgb(255,255,255)">Mandatory: =C2=A0=C2=A0=C2=A0-
Multi= ple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0The amount o= f Cb chrominance pixels to remove for every Cb
=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0chr= ominance pixel not removed horizontally. This is additive with
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0ChromaSubsamplingHorz.
=

I'm confused about the relations= hip between=C2=A0CbSubsamplingHorz and=C2=A0ChromaSubsamplingHorz.
These elements are only defined because I was tr= ying to handle 4:2:1. Basically this is an old format where the Cr channel = is half the size of the Y channel, and the Cb channel is half the size of t= he Cr channel. The Cb channel is a quarter the size of the Y channel.
=

The CbSubsampling* elements were a late edition, right = before I sent my previous email. At first I didn't have these elements = and had text that 4:2:1 was not supported.

Right. Sorry I wrote my comments before consi= dering 4:2:1, since the fields are quite customized for situations like 4:2= :1, perhaps it should be referenced by name as an example.

How about I change the CbSubsamplingHorz element t= ext too: "The amount of pixels to remove in the Cr and Cb channels for= every pixel not removed horizontally." And the CbSubsamplingHorz too:= "The amount of pixels to remove in the Cb channel for every pixel not= removed horizontally. This is additive with ChromaSubsamplingHorz. Example= : For video with 4:2:1 chroma subsampling the ChromaSubsamplingHorz should = be set to 1 and CbSubsamplingHorz should be set to 1." Does this help = the confusion?

+1

Element N= ame: CbSubsamplingVert
Level: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B6]
Mandatory: =C2= =A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0The amount of Cb chrominance pixels to remove = for every Cb
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0chrominance pixel not removed vertic= ally. This is additive with
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ChromaSubsamplingVert= .


Element Name: ChromaSitingHorz
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
=
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[5= 5][B7]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A00
Type: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0How= Chroma is subsampled horizontally. (0: Unspecified, 1: Left
<= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0collocated , 2: Half)

Element Name= : ChromaSitingVert
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B8]
Mandatory: =C2=A0= =C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A00
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0How Chroma is subsampled vertically. (0: Unspeci= fied, 1: Top
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0collocated , 2: Half)


Element Name: Range
Level: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B9]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2= =A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A00
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0u
Description: =C2=A0C= lipping of the color ranges. (0: Unspecified, 1: = Broadcast range,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A02: Full range (no clipping), 3: D= efined by
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Matrix/TransferFunction)


Element Name: TransferFunction

To align with ISO/IEC 2= 3001-8, could we use TransferCharacteristics?
Done.=C2=A0

Level: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][BA]
Mandat= ory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0= =C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A02
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
<= span style=3D"font-size:13.3333px;font-family:'Courier New';color:r= gb(34,34,34);font-weight:400;font-style:normal;font-variant:normal;text-dec= oration:none;vertical-align:baseline;white-space:pre-wrap;background-color:= rgb(255,255,255)">Description: =C2=A0Transfer Function. See ISO/IEC 23001-8= for more information on
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0enumerations. (0: Reserv= ed, 1: ITU-R BT.709, 2: Unspecified,
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A03: Reserved,= 4: Gamma 2.2 curve, 5: Gamma 2.8 curve,
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06: SMPTE = 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt,
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A011: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A013: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit,
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A015: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A017: SMPTE ST 428-1 18: ARIB STD-B67 (HLG))
<= /div>

Comment:
= The table in ISO/IEC 23001-8 for transfer characteristics does not include = values or meaning for 16, 17 and 18 as above. Are these values from ffmpeg&= #39;s list?
16 and 17 is an artifact for= m the FFmpeg list, but also form looking at FFmpeg CL's I think they ar= e defined in an h265 spec. 18 is a proposed value for HLG.


=
Suggested description edit:
The transfer characteristics of = the video. For clarity, the value and meanings for=C2=A0TransferCharacteris= tics=C2=A0are adopted from Table 3 of ISO/IEC 23001-8:2013/DCOR1. (0: Reser= ved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved, 4: Gamma 2.2 curve, 5: G= amma 2.8 curve,=C2=A06: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: L= og Sqrt,=C2=A011: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut,= =C2=A013: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit,=C2=A015: ITU-R BT.2020 1= 2 bit)
Done.
=C2=A0

Element Name: Primaries
= Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
M= andatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0= =C2=A0=C2=A0-
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0[55][BB]
Default: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A02
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0Values that = can be represented in the CIE 1931 colour space. See
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0ISO/IEC 23001-8 for more information on enumerations.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0(0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved,=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A04: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7:= SMPTE 240M,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A08: FILM, 9: ITU-R BT.2020, 10: SMPTE= ST 428-1)
Suggested description edit:
The colour primaries of the vide= o. For clarity, the value and meanings for TransferCharacteristics are adop= ted=C2=A0from Table 2 of ISO/IEC 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R= BT.709, 2: Unspecified, 3: Reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, = 6: SMPTE 170M, 7: SMPTE 240M,=C2=A08: FILM, 9: ITU-R BT.2020, 10: SMPTE ST = 428-1)
Done.=C2=A0

Note that ISO/IEC = 23001-8 also includes a value for 22 for JEDEC P22 phosphors. Any reason to= exclude this?
Added.
=C2=A0

Element Name: MaxCLL
Level:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][BC]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: = =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0u
Description: =C2=A0Maximum brightness= of a single pixel in candelas per square
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0meter = (cd/m=C2=B2).
=
Suggested:
Maximum brightness of a single pixel (M= aximum Content Light Level) in candelas per square meter (cd/m=C2=B2).
Done
=C2=A0
=

Element Name: MaxFALL
Level: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][BD]
M= andatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0= =C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-=
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0u
Description: =C2=A0Maximum brightness of a single= full frame in candelas per square
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0meter (cd/m=C2= =B2).

Suggested:
Maximum brightness of a single full frame = (Maximum=C2=A0Frame-Average=C2=A0Light Level) in candelas per square meter = (cd/m=C2=B2).
Done
=C2= =A0

Element Name: MasteringMetadata
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0[55][D0]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0m
Description: =C2=A0= SMPTE 2086 mastering data.


Element Name: P= rimaryRChromaticityX
Level: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D1]
Mandatory: =C2= =A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <= ;=3D f <=3D 1

I think "0.0-1.0" is preferred for float range = expressions.

Sorry there's an open discussion elsewhere on = Cellar about expressing float ranges as=C2=A0hexadecimal floating-point lit= erals, so this may be changed later, but the meaning should still be the sa= me.
No problem. I just had it that way f= or brevity, much like a lot of my other descriptions. I don't want to a= dd to much text to a cell of the Matroska spec table. :)


Done
=C2=A0

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
Descrip= tion: =C2=A0Red X chromaticity coordinate as defined by CIE 1931.


<= /b>
Element Name: PrimaryRChromaticityY
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D= 2]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 1
Type: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
Descrip= tion: =C2=A0Red Y chromaticity coordinate as defined by CIE 1931.


<= /b>
Element Name: PrimaryGChromaticityX
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D= 3]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 1
f
Description: =C2=A0Green X chromaticity coordinate as defined = by CIE 1931.


Element Name: PrimaryGChromat= icityY
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0[55][D4]
Mandatory: =C2=A0=C2=A0=C2=A0-=
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 1=
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
=
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
Description: =C2=A0Green Y chromaticity coordinate as defined b= y CIE 1931.


Elem= ent Name: PrimaryBChromaticityX
Level: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D5]
Mandat= ory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0= =C2=A0-
Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A00 <=3D f <=3D 1
Default: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0-
f
Description: =C2= =A0Blue X chromaticity coordinate as defined by CIE 1931.


Element Name: PrimaryBChromaticityY
L= evel: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06
ID: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D6]=
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple= : =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 1
Default= : =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
Description: =C2= =A0Blue Y chromaticity coordinate as defined by CIE 1931.


Element Name: WhitePointChromaticityX
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06
I= D: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D7]
<= span style=3D"font-size:13.3333px;font-family:'Courier New';color:r= gb(34,34,34);font-weight:400;font-style:normal;font-variant:normal;text-dec= oration:none;vertical-align:baseline;white-space:pre-wrap;background-color:= rgb(255,255,255)">Mandatory: =C2=A0=C2=A0=C2=A0-
Multi= ple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 1
Defa= ult: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
Description: = =C2=A0White point X chromaticity coordinate as defined by CIE 1931.=

Element Name: WhitePointChromaticityY
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06
<= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55= ][D8]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 1
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
Desc= ription: =C2=A0White point Y chromaticity coordinate as defined by CIE 193= 1.


Element Name: LuminanceMax
=
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55= ][D9]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 9999.99
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0f
Description: =C2=A0Maximum luminance. Shall be= represented in candelas per square
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0meter (cd/m= =C2=B2).


Element Name: LuminanceMin=
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0[55][DA]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 999.9999
Default: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0f
Description: =C2=A0Minimum luminance. Sh= all be represented in candelas per square
=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0meter = (cd/m=C2=B2).
=


I removed Chro= maSubsampling and added ChromaSubsamplingHorz, ChromaSubsamplingVert, CbSub= samplingHorz, and CbSubsamplingVert.

This is how I= think the elements should be written for the different subsampling types:<= /div>
1: 4:4:4
=C2=A0 =C2=A0 - ChromaSubsamplingHorz and= ChromaSubsamplingVert will not be set as there should be no chroma subsamp= ling.

2: 4:4:0
=C2=A0 - ChromaSubsa= mplingHorz :not set
=C2=A0 - ChromaSubsamplingVert :1
=

3: 4:2:2
=C2=A0 - ChromaSubsamplingHorz = :1
=C2=A0 - ChromaSubsamplingVert :not set

4: 4:2:1
=C2=A0 - ChromaSubsamplingHorz :1
=C2=A0 - ChromaSubsamplingVert :not set
=C2=A0 - CbS= ubsamplingHorz :1
=C2=A0 - CbSubsamplingVert :not set
=
=C2=A0 - We could remove CbSubsamplingHorz and CbSubsamplingVert if we= didn't care about handling formats where the Cr and Cb channels are di= fferent sizes.

I forgot about 4:2:1. That answers my question about CbSubsmaplingH= orz though perhaps we need a narrative section to expand on this with the e= xamples you have here.

5: 4:2= :0
=C2=A0 - ChromaSubsamplingHorz :1
=C2=A0 - ChromaSub= samplingVert :1

6: 4:1:1
=C2=A0 - C= hromaSubsamplingHorz :3
=C2=A0 - ChromaSubsamplingVert :not set

7: 4:1:0
=C2=A0 - ChromaSubsam= plingHorz :3
=C2=A0 - ChromaSubsamplingVert :1
8: 3:1:1
=C2=A0 - ChromaSubsamplingHorz := 2
=C2=A0 - ChromaSubsamplingVert :not set
=C2=A0 = - I'm assuming the luma subsampling can be handled by PixelWidth, and D= isaplyWidth.

Jerome's vertical subsampling of = 4
=C2=A0 - ChromaSubsamplingHorz :not set
=C2=A0 -= ChromaSubsamplingVert :3


The other issue I want to bring up is the value of "18: ARIB STD-B67 (HLG)" in Transfe= rFunction. Unfortunately, in WebM we will need to use this value sooner tha= n Matroska v4 will be finalized. Should I make this value much higher? Or l= eave at 18? I think "16: SMPTE ST 2= 084" and "17: SMPTE ST = 428-1" will be standardized across most documents, like 1-15 ar= e. Just not sure if 18 will be HLG.

I see a few references to ARIB STD-B67 as 18, such a= s=C2=A0http://www.arib.or.jp/english/html/overview/doc= /2-STD-B32v3_5.pdf. Perhaps we need a caveat that values 1-15 are defin= ed based upon ISO/IEC 23001-8. Then for values 16, 17, and 18 we could add = better descriptions and citations to define it better internally.
I'm fine with this. I'm just worried abo= ut the case where we diverge from one of the lists. Would be nice to have o= ne canonical list.
=C2=A0
If (hopefully) a revision to ISO/IEC 23001-8 a= dds those values (as expected) then we could update are description to say = all values are defined by ISO/IEC 23001-8.
Sounds good to me.

<= div>It's a bit risky. Perhaps for now we should clarify that values 1-1= 5 are defined by=C2=A0ISO/IEC 23001-8 and then give customized definitions = for 16, 17, 18.

Following Jerom= e's comment, =C2=A0how about this for TransferCharacteristic:
"The transfer characteristics of the video. For clarity, the value an= d meanings for TransferCharacteristics 1-15 are adopted from Table 3 of ISO= /IEC 23001-8:2013/DCOR1. TransferCharacteristics 16-17 are adopted from <= ;265 doc> and 18 is the proposed value of ARIB STD-B67. (0: Reserved, 1:= ITU-R BT.709, 2: Unspecified, 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.= 8 curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, 11:= IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut, 13: IEC 61966-2-1,= 14: ITU-R BT.2020 10 bit, 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, 17:= SMPTE ST 428-1 18: ARIB STD-B67 (HLG))"

Dave Rice

--001a113cc7f2800bfa052be886f7-- From nobody Thu Feb 18 07:34:37 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599E01B2A81 for ; Thu, 18 Feb 2016 07:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.167 X-Spam-Level: X-Spam-Status: No, score=0.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 XTpY6_T86Dst for ; Thu, 18 Feb 2016 07:34:34 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5382B1B2A9B for ; Thu, 18 Feb 2016 07:34:30 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id g127so43226115ywf.2 for ; Thu, 18 Feb 2016 07:34:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FcKQ04IZ/msH4gcHQr+ZJ3GQq9OUZHKYZnBuRwG8qNw=; b=GcjnYNXPHb7aAwPKtEkw0MPTgOtn3XqwzLWJdLhJt2cujcB3t6jyPL/DXa3LC7hmNr 0eDTXD48rvmFRuT9nFQNbMm0lcQuFoWm0xre26qCd/acvDXhnbLSH6WrlTJn29AMkPFk pbfET1EO+7+m+rN5I69Z+vQpG10/7A0S9bDB+JSaY4WLWkNfXlS9Tpc/j6Fdl+Npub+8 d3sI88PucdmwDX4QcV79cLQFdd4rbblGNoO/AuCgPYXyFl7ywHn+vygzItB0Cs7vSQ7c 61GvTI7aGNx8+ZSHvJ8RO0GJbt2pnolUE5c0KxHIyiLuC7NkCT03ueRsluyfbzrRnsYM RcCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FcKQ04IZ/msH4gcHQr+ZJ3GQq9OUZHKYZnBuRwG8qNw=; b=fQdMcszU0fhO/85myMYiJsDOFeu+Sr0QaWKBh/w4IRWh8wpoONxl/oZhJpb1qzqFG5 ukqco2th5XPb0k0A5xb/tMwBN5Hhhl4t2oCill1VcvYchJXMiuiRDovHnzDBila4SmM5 35jRhzRXllvKwrX6ewft9uG6L+cymRQnfnVaqNaamnCm7/ADKcIiktGbMbLlGlQ1ahtn BmtNb2JCt/z19bFvQ+ezE8I5rC2ME25whm8YxZ6aQFdRGEj0j8wLBurQR8R+wHJ9Whsf V9M42rL+e50c+nO/Oms8pki6KNkDQoGbzxnANUFDrkmNn9zth9iR39vILV70o7r85V8F y/Fg== X-Gm-Message-State: AG10YOS6cxQ8K2p+JK5DMpba7IPW6eshXJwPywsvrHm1NFJM9xBzmomYeYO8MlnZgsXGfEBj42hMQTFDe5faTQ== MIME-Version: 1.0 X-Received: by 10.129.52.12 with SMTP id b12mr4808849ywa.8.1455809669663; Thu, 18 Feb 2016 07:34:29 -0800 (PST) Received: by 10.13.221.22 with HTTP; Thu, 18 Feb 2016 07:34:29 -0800 (PST) In-Reply-To: References: Date: Thu, 18 Feb 2016 21:04:29 +0530 Message-ID: From: Nithin Mathew Kurien To: Steve Lhomme Content-Type: multipart/alternative; boundary=001a1141b2a638941f052c0d1ac4 Archived-At: Cc: Dave Rice , cellar@ietf.org Subject: Re: [Cellar] expressing a float in text X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2016 15:34:36 -0000 --001a1141b2a638941f052c0d1ac4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This representation is supported in C++, Java and Python too. If compatibility with other languages is a concern, perhaps we can include a small conversion function in libEBML? The strtod() and strtof() functions in the GNU C Library do this conversion. Thanks and regards, Nithin On Sun, Feb 14, 2016 at 10:32 PM, Steve Lhomme wrote= : > 2016-02-13 20:24 GMT+01:00 Nithin Mathew Kurien = : > > Hi, > > > > Not sure if it is suitable in this context, but C99 supports writing > floats > > accurately in hexadecimal notation > > (http://www.exploringbinary.com/hexadecimal-floating-point-constants/). > The > > advantage of hexadecimal notation is that values can be represented > > accurately, unlike representions like 1.67e-3, which will result in > rounding > > errors when converted from decimal to the native binary form. With a C9= 9 > > compiler like GCC, we can output the hexadecimal form of any float. > > > > double num =3D 1.55e1; > > printf("%a", num); > > > > would output > > > > 0x1.fp3 > > > > which is equal to (1 + 15/16) * 2^3. > > I agree that since floats are not always bit exact a format that > accurately interprets the machine value anytime would be better. Not > sure if the C99 representation works for other languages too. > > We might have a machine representation and text representation for > each value so it's easy to read and clean to interpret. > > > Thanks and regards, > > Nithin > > > > > > On Sun, Feb 14, 2016 at 12:20 AM, Dave Rice wrote: > >> > >> To accommodate the float range expressions in Frank=E2=80=99s color wo= rk, I=E2=80=99m > >> expanding the =E2=80=9CExpression of range=E2=80=9D [1] section to acc= ommodate floats > >> (currently it only discusses signed and unsigned integers). Frank=E2= =80=99s use > of > >> float ranges are quite simple, such as 0.0 to 1.0; however, in definin= g > a > >> method to document a float range, I think the definition should work > for any > >> possible float value. > >> > >> Is there an standard document to point to for how to represent a float > >> value as text? i.e. I=E2=80=99m familiar with float values in text suc= h as > 3.88E-4 > >> but where it this style of expression defined? > >> > >> Best Regards, > >> Dave Rice > >> > >> [1] > >> > https://github.com/Matroska-Org/ebml-specification/blob/master/specificat= ion.markdown#expression-of-range > >> _______________________________________________ > >> Cellar mailing list > >> Cellar@ietf.org > >> https://www.ietf.org/mailman/listinfo/cellar > > > > > > > > _______________________________________________ > > Cellar mailing list > > Cellar@ietf.org > > https://www.ietf.org/mailman/listinfo/cellar > > > > > > -- > Steve Lhomme > Matroska association Chairman > --001a1141b2a638941f052c0d1ac4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This representation is supported in C++, Java and Pyt= hon too. If compatibility with other languages is a concern, perhaps we can= include a small conversion function in libEBML? The strtod() and strtof() = functions in the GNU C Library do this conversion.

Thanks and regards,
Nithin

On Sun, Feb 14, 2016 at 10:32 PM, Steve Lho= mme <slhomme@matroska.org> wrote:
2016-02-13 20:24 GMT+01:00 Nithin Mathew Kurien= <nithinmkurien@gmail.com= >:
> Hi,
>
> Not sure if it is suitable in this context, but C99 supports writing f= loats
> accurately in hexadecimal notation
> (http://www.exploringbinary= .com/hexadecimal-floating-point-constants/). The
> advantage of hexadecimal notation is that values can be represented > accurately, unlike representions like 1.67e-3, which will result in ro= unding
> errors when converted from decimal to the native binary form. With a C= 99
> compiler like GCC, we can output the hexadecimal form of any float. >
> double num=C2=A0 =3D 1.55e1;
> printf("%a", num);
>
> would output
>
> 0x1.fp3
>
> which is equal to (1 + 15/16) * 2^3.

I agree that since floats are not always bit exact a format that
accurately interprets the machine value anytime would be better. Not
sure if the C99 representation works for other languages too.

We might have a machine representation and text representation for
each value so it's easy to read and clean to interpret.

> Thanks and regards,
> Nithin
>
>
> On Sun, Feb 14, 2016 at 12:20 AM, Dave Rice <dave@dericed.com> wrote:
>>
>> To accommodate the float range expressions in Frank=E2=80=99s colo= r work, I=E2=80=99m
>> expanding the =E2=80=9CExpression of range=E2=80=9D [1] section to= accommodate floats
>> (currently it only discusses signed and unsigned integers). Frank= =E2=80=99s use of
>> float ranges are quite simple, such as 0.0 to 1.0; however, in def= ining a
>> method to document a float range, I think the definition should wo= rk for any
>> possible float value.
>>
>> Is there an standard document to point to for how to represent a f= loat
>> value as text? i.e. I=E2=80=99m familiar with float values in text= such as 3.88E-4
>> but where it this style of expression defined?
>>
>> Best Regards,
>> Dave Rice
>>
>> [1]
>> https://github.com/Matroska-Org/ebml-specification/blob/maste= r/specification.markdown#expression-of-range
>> _______________________________________________
>> Cellar mailing list
>> Cellar@ietf.org
>> https://www.ietf.org/mailman/listinfo/cellar
>
>
>
> _______________________________________________
> Cellar mailing list
> Cellar@ietf.org
> https://www.ietf.org/mailman/listinfo/cellar >



--
Steve Lhomme
Matroska association Chairman

--001a1141b2a638941f052c0d1ac4-- From nobody Thu Feb 18 07:35:43 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 871151B2AA7 for ; Thu, 18 Feb 2016 07:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.167 X-Spam-Level: X-Spam-Status: No, score=0.167 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 6yxnuohClubs for ; Thu, 18 Feb 2016 07:35:40 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0EF01B2ABD for ; Thu, 18 Feb 2016 07:35:21 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id h129so43195056ywb.1 for ; Thu, 18 Feb 2016 07:35:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=orXrcwW4azQeqae69L+T9+gDJD0wgIbrkL/QZ9G4nUU=; b=TnLP0u0xF0hfesemRU+QAGet4Y43QonGLGt4a34Tjn3a9B91VMqohLKgWtN3IQq9AA jW2q9CfFD8BWf57OcTxKvq8njUtUVWeIw7iDNL5LxJ/hDPg+mmxxcWtoaxTXqHshX1RP 6qIzhs5wttQHoAhoOWauygauWok4tc4mNcZBQIuwuY3TPVUf0Xh64fbCPyIBiZ3Qk2u2 n80ypOgW7BVnyNo3EIgOD/AwZ62YphDIKONJhaqHPr6dIHaMI/sDJ/lwDglfFovQn9+2 K4pQ2SBLsU5jX6e8uCdm0mruv/p6Jelq4qAb98/XcFVmLWhtPD7K4pRkD5W03lYxya7I y0aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=orXrcwW4azQeqae69L+T9+gDJD0wgIbrkL/QZ9G4nUU=; b=DN220ze2lmtbWRgHgn1A0I2wxM/j0q+qXHKqCib2KnzAugGxyfwfUsq0eooEdHbDyy d1UQAe4y/C1rOYQad/Hi5zmhwfI8AFZH54JEbJDMVtw2e7YVXKoF0g15qjY3AsIuw7jP E+W+KCxhDPtzuICwoPAj+Yc/L5gtHinTq8hlNiu5asL4rvGNnZuEeLsmpdzpZw+Tfxn8 hsV2QGfm6rmTniEKWNSDrzgT4TRBPuCnUbpXZoOZzfGicWxX09Qejkbfm9ClufmlMsH4 vKCTlOFIzj21P0hY/9/Xkoaaubh2EKEBwuiYaggniLiA2t+/biNUIxYMiEbw3h6pgclJ W6Pw== X-Gm-Message-State: AG10YOQp2xH7IoH1Td/d66mlxAowEGA2JAiboOZH5cPm2HtDhLuEgMexjgg9HWVO1Zeg47WCKZlotyAOEwbtsA== MIME-Version: 1.0 X-Received: by 10.13.222.1 with SMTP id h1mr4946776ywe.171.1455809721283; Thu, 18 Feb 2016 07:35:21 -0800 (PST) Received: by 10.13.221.22 with HTTP; Thu, 18 Feb 2016 07:35:21 -0800 (PST) In-Reply-To: References: Date: Thu, 18 Feb 2016 21:05:21 +0530 Message-ID: From: Nithin Mathew Kurien To: Dave Rice Content-Type: multipart/alternative; boundary=94eb2c07c4124c3f6f052c0d1df5 Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] expressing a float in text X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2016 15:35:42 -0000 --94eb2c07c4124c3f6f052c0d1df5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Yes, the notations would be different. Single floats would have 6 hexadecimal digits in the mantissa, whereas double floats would have 13. I would suggest defining all EBML floats as doubles, because of the greater range and precision available. Thanks and regards, Nithin On Mon, Feb 15, 2016 at 12:41 AM, Dave Rice wrote: > > On Feb 13, 2016, at 2:24 PM, Nithin Mathew Kurien > wrote: > > Hi, > > Not sure if it is suitable in this context, but C99 supports writing > floats accurately in hexadecimal notation ( > http://www.exploringbinary.com/hexadecimal-floating-point-constants/). > The advantage of hexadecimal notation is that values can be represented > accurately, unlike representions like 1.67e-3, which will result in > rounding errors when converted from decimal to the native binary form. Wi= th > a C99 compiler like GCC, we can output the hexadecimal form of any float. > > double num =3D 1.55e1; > printf("%a", num); > > would output > > 0x1.fp3 > > which is equal to (1 + 15/16) * 2^3. > > > For values such as 0.0 and 1.0, wouldn't the C99 notation be different > depending on if the float is expressed as a single or double? Currently a= n > EBML float could be either 4 or 8 bytes and the choice of float length is > not part of the element definition. If we use C99 notation we may be > implying whether the float is single or double and should consider saying > so in the definition. > Dave > > Thanks and regards, > Nithin > > > On Sun, Feb 14, 2016 at 12:20 AM, Dave Rice wrote: > >> To accommodate the float range expressions in Frank=E2=80=99s color work= , I=E2=80=99m >> expanding the =E2=80=9CExpression of range=E2=80=9D [1] section to accom= modate floats >> (currently it only discusses signed and unsigned integers). Frank=E2=80= =99s use of >> float ranges are quite simple, such as 0.0 to 1.0; however, in defining = a >> method to document a float range, I think the definition should work for >> any possible float value. >> >> Is there an standard document to point to for how to represent a float >> value as text? i.e. I=E2=80=99m familiar with float values in text such = as 3.88E-4 >> but where it this style of expression defined? >> >> Best Regards, >> Dave Rice >> >> [1] >> https://github.com/Matroska-Org/ebml-specification/blob/master/specifica= tion.markdown#expression-of-range >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > > --94eb2c07c4124c3f6f052c0d1df5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes, the notations would be different. Single floats = would have 6 hexadecimal digits in the mantissa, whereas double floats woul= d have 13. I would suggest defining all EBML floats as doubles, because of = the greater range and precision available.

Thanks = and regards,
Nithin

On Mon, Feb 15, 2016 at 12:41 AM, Dave Rice <dave@d= ericed.com> wrote:

On Feb 13, 2016, at 2:24 PM, Nithin Mathew Kurien <nithinmkurien@gmail.com> wrote:

Hi,

Not sur= e if it is suitable in this context, but C99 supports writing floats accura= tely in hexadecimal notation (http://www.exploringb= inary.com/hexadecimal-floating-point-constants/). The advantage of hexa= decimal notation is that values can be represented accurately, unlike repre= sentions like 1.67e-3, which will result in rounding errors when converted = from decimal to the native binary form. With a C99 compiler like GCC, we ca= n output the hexadecimal form of any float.

double= num =C2=A0=3D=C2=A01.55e1;
printf("%a", num);

would output

0x1.fp3

which is equal to (1 + = 15/16) * 2^3.

For values such as 0.0 and 1.0, wouldn't the C99 notation be differe= nt depending on if the float is expressed as a single or double? Currently = an EBML float could be either 4 or 8 bytes and the choice of float length i= s not part of the element definition. If we use C99 notation we may be impl= ying whether the float is single or double and should consider saying so in= the definition.
D= ave

=
Thanks and regards,
Nithin


On Sun, Feb 14, 2016 at 12:20 AM, Dave Rice= <dave@dericed.com> wrote:
= To accommodate the float range expressions in Frank=E2=80=99s color work, I= =E2=80=99m expanding the =E2=80=9CExpression of range=E2=80=9D [1] section = to accommodate floats (currently it only discusses signed and unsigned inte= gers). Frank=E2=80=99s use of float ranges are quite simple, such as 0.0 to= 1.0; however, in defining a method to document a float range, I think the = definition should work for any possible float value.

Is there an standard document to point to for how to represent a float valu= e as text? i.e. I=E2=80=99m familiar with float values in text such as 3.88= E-4 but where it this style of expression defined?

Best Regards,
Dave Rice

[1] https://github.com/Matroska-Org/ebml-specification/blob/master/spe= cification.markdown#expression-of-range
_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar

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


--94eb2c07c4124c3f6f052c0d1df5-- From nobody Thu Feb 18 11:50:43 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8191B3466 for ; Thu, 18 Feb 2016 11:50:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.867 X-Spam-Level: ** X-Spam-Status: No, score=2.867 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FF_IHOPE_YOU_SINK=2.166, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 pSD5XVOItrUm for ; Thu, 18 Feb 2016 11:50:28 -0800 (PST) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E18F1B345E for ; Thu, 18 Feb 2016 11:50:28 -0800 (PST) Received: by mail-ob0-x231.google.com with SMTP id kf7so2402809obb.1 for ; Thu, 18 Feb 2016 11:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=28CIpbtdvWm6zABdT/MDF8T0R9b0B5JpX0qgw8X0C0s=; b=Yral4XEedTjPrTdSxzYSq0uemlkFUfLfqWQnoVRN3roMOu4aCHIFkOVPriXZDJmlVc tzFIzuWx7IO7wpng8P8ZaJUUSthq6bBMqZg/eRYMGUDH6jasO5prSWyljmGOyS+GmuqB fVxrnH0hA12ZCerluAK3OuBpsCLFW5M8Zgm7daGctjEEjh7qCHWvnMypddhuA9/wqILn IQ3dMpuRPrEyVLDcz/hb9diFXru0LqvdLU+gKFwysq49q746lhGzQ7TJxQNOv6vBjaVm c1EpAVCMOFFbNmNyajRuBNELszw0gpi91cn21uhdAJ9ezfKTSqOQmHchN1j39VTmaTE6 X0nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=28CIpbtdvWm6zABdT/MDF8T0R9b0B5JpX0qgw8X0C0s=; b=ScByYYB4aos/taqWPA33EFCp+IWtUVf32xNZxNaAQw+TYJ0CcuEZlyORfkYDfCZwof EEo3GxAkC/K7QCIgOt+GzuTfxL1DIkRIDdiD5PYTyT3XJgPMGl6/7qaJoa8s/SktggTC iRKEgn+PpQyzuMc7cV8DXwhho7SfQFxcxjcdCN8tbLUlAwHXJkfpiNp0p5Rj8SCL1kE9 l+8kP8CoT8eSWxqoWvbn/NE5Vzpuc0fPj8C8gnXBK3u1/LBbVEAF2Zz1YtY/O7eydq1m 9bb5OaJ/0N9MNyH43XN9GsVXoniLkmPZel0OkSwH/5inKLikPMA+sicf6ZX764ZJfdeo +yoA== X-Gm-Message-State: AG10YOSBTfC66zn03S2Qiz4IRutVKlMR7cd9a9F6xczwe483nJR9utkeEyFQlKi39wHHp0LTdjVsulO1q3f90g== MIME-Version: 1.0 X-Received: by 10.202.188.134 with SMTP id m128mr7914495oif.4.1455825027681; Thu, 18 Feb 2016 11:50:27 -0800 (PST) Received: by 10.202.59.130 with HTTP; Thu, 18 Feb 2016 11:50:27 -0800 (PST) In-Reply-To: References: <568C3CA0.8040300@mediaarea.net> <56B8CD1A.20307@mediaarea.net> <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> <9CE0170E-E63D-411D-AFAF-EE5CBB4B56D7@dericed.com> Date: Thu, 18 Feb 2016 11:50:27 -0800 Message-ID: From: Frank Galligan To: Dave Rice Content-Type: multipart/alternative; boundary=001a113dcc82a15718052c10ad98 Archived-At: Cc: Jerome Martinez , Discussion about the current and future development of Matroska , cellar@ietf.org Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 18 Feb 2016 19:50:42 -0000 --001a113dcc82a15718052c10ad98 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Here is the current proposal, minus the reference to the 265 doc. The parent element would be Video [E0]. Element Name: Colour Level: 4 ID: [55][B0] Mandatory: - Multiple: - Default: - Type: m Description: Settings describing the colour format. Element Name: MatrixCoefficients Level: 5 ID: [55][B1] Mandatory: - Multiple: - Default: 2 Type: u Description: The Matrix Coefficients of the video used to derive luma and chroma values from reg, green, and blue color primaries. For clarity, the value and meanings for MatrixCoefficients are adopted from Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0:GBR, 1: BT709, 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M= , 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance, 10: BT2020 Constant Luminance) Element Name: BitsPerChannel Level: 5 ID: [55][B2] Mandatory: - Multiple: - Default: 0 Type: u Description: Number of decoded bits per channel. A value of 0 indicates that the BitsPerChannel is unspecified. Element Name: ChromaSubsamplingHorz Level: 5 ID: [55][B3] Mandatory: - Multiple: - Default: - Type: u Description: The amount of pixels to remove in the Cr and Cb channels for every pixel not removed horizontally. Example: For video with 4:2:0 chroma subsampling, the ChromaSubsamplingHorz should be set to 1. Element Name: ChromaSubsamplingVert Level: 5 ID: [55][B4] Mandatory: - Multiple: - Default: - Type: u Description: The amount of pixels to remove in the Cr and Cb channels for every pixel not removed vertically. Example: For video with 4:2:0 chroma subsampling, the ChromaSubsamplingVert should be set to 1. Element Name: CbSubsamplingHorz Level: 5 ID: [55][B5] Mandatory: - Multiple: - Default: - Type: u Description: The amount of pixels to remove in the Cb channel for every pixel not removed horizontally. This is additive with ChromaSubsamplingHorz. Example: For video with 4:2:1 chroma subsampling, the ChromaSubsamplingHorz should be set to 1 and CbSubsamplingHorz should be set to 1. Element Name: CbSubsamplingVert Level: 5 ID: [55][B6] Mandatory: - Multiple: - Default: - Type: u Description: The amount of pixels to remove in the Cb channel for every pixel not removed vertically. This is additive with ChromaSubsamplingVert. Element Name: ChromaSitingHorz Level: 5 ID: [55][B7] Mandatory: - Multiple: - Default: 0 Type: u Description: How Chroma is subsampled horizontally. (0: Unspecified, 1: Left collocated , 2: Half) Element Name: ChromaSitingVert Level: 5 ID: [55][B8] Mandatory: - Multiple: - Default: 0 Type: u Description: How Chroma is subsampled vertically. (0: Unspecified, 1: Top collocated , 2: Half) Element Name: Range Level: 5 ID: [55][B9] Mandatory: - Multiple: - Default: 0 Type: u Description: Clipping of the color ranges. (0: Unspecified, 1: Broadcast range, 2: Full range (no clipping), 3: Defined by MatrixCoefficients/TransferCharacteristics) Element Name: TransferCharacteristics Level: 5 ID: [55][BA] Mandatory: - Multiple: - Default: 2 Type: u Description: The transfer characteristics of the video. For clarity, the value and meanings for TransferCharacteristics 1-15 are adopted from Table 3 of ISO/IEC 23001-8:2013/DCOR1. TransferCharacteristics 16-17 are adopted from <265 doc> and 18 is the proposed value of ARIB STD-B67. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, 17: SMPTE ST 428-= 1 18: ARIB STD-B67 (HLG)) Element Name: Primaries Level: 5 Mandatory: - Multiple: - ID: [55][BB] Default: 2 Type: u Description: The colour primaries of the video. For clarity, the value and meanings for Primaries are adopted from Table 2 of ISO/IEC 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1, 22: JEDEC P22 phosphors) Element Name: MaxCLL Level: 5 ID: [55][BC] Mandatory: - Multiple: - Default: - Type: u Description: Maximum brightness of a single pixel (Maximum Content Light Level) in candelas per square meter (cd/m=C2=B2). Element Name: MaxFALL Level: 5 ID: [55][BD] Mandatory: - Multiple: - Default: - Type: u Description: Maximum brightness of a single full frame (Maximum Frame-Average Light Level) in candelas per square meter (cd/m=C2=B2). Element Name: MasteringMetadata Level: 5 ID: [55][D0] Mandatory: - Multiple: - Default: - Type: m Description: SMPTE 2086 mastering data. Element Name: PrimaryRChromaticityX Level: 6 ID: [55][D1] Mandatory: - Multiple: - Range: 0.0 <=3D f <=3D 1.0 Default: - Type: f Description: Red X chromaticity coordinate as defined by CIE 1931. Element Name: PrimaryRChromaticityY Level: 6 ID: [55][D2] Mandatory: - Multiple: - Range: 0.0 <=3D f <=3D 1.0 Default: - Type: f Description: Red Y chromaticity coordinate as defined by CIE 1931. Element Name: PrimaryGChromaticityX Level: 6 ID: [55][D3] Mandatory: - Multiple: - Range: 0.0 <=3D f <=3D 1.0 Default: - f Description: Green X chromaticity coordinate as defined by CIE 1931. Element Name: PrimaryGChromaticityY Level: 6 ID: [55][D4] Mandatory: - Multiple: - Range: 0.0 <=3D f <=3D 1.0 Default: - Type: f Description: Green Y chromaticity coordinate as defined by CIE 1931. Element Name: PrimaryBChromaticityX Level: 6 ID: [55][D5] Mandatory: - Multiple: - Range: 0.0 <=3D f <=3D 1.0 Default: - Type: f Description: Blue X chromaticity coordinate as defined by CIE 1931. Element Name: PrimaryBChromaticityY Level: 6 ID: [55][D6] Mandatory: - Multiple: - Range: 0.0 <=3D f <=3D 1.0 Default: - Type: f Description: Blue Y chromaticity coordinate as defined by CIE 1931. Element Name: WhitePointChromaticityX Level: 6 ID: [55][D7] Mandatory: - Multiple: - Range: 0.0 <=3D f <=3D 1.0 Default: - Type: f Description: White point X chromaticity coordinate as defined by CIE 1931. Element Name: WhitePointChromaticityY Level: 6 ID: [55][D8] Mandatory: - Multiple: - Range: 0.0 <=3D f <=3D 1.0 Default: - Type: f Description: White point Y chromaticity coordinate as defined by CIE 1931. Element Name: LuminanceMax Level: 6 ID: [55][D9] Mandatory: - Multiple: - Range: 0.0 <=3D f <=3D 9999.99 Default: - Type: f Description: Maximum luminance. Shall be represented in candelas per squar= e meter (cd/m=C2=B2). Element Name: LuminanceMin Level: 6 ID: [55][DA] Mandatory: - Multiple: - Range: 0.0 <=3D f <=3D 999.9999 Default: - Type: f Description: Minimum luminance. Shall be represented in candelas per squar= e meter (cd/m=C2=B2). [IEC23001-8] ISO/IEC 23001-8:2013/DCOR1, "Coding independent media description code points", 2013, < http://standards.iso.org/ittf/PubliclyAvailableStandards/c062088_ISO_IEC_23= 001-8_2013.zip >. wrote: > > > On Tue, Feb 16, 2016 at 11:14 AM, Dave Rice wrote: > >> >> On Feb 16, 2016, at 2:01 PM, Frank Galligan >> wrote: >> >> >> >> On Fri, Feb 12, 2016 at 5:53 PM, Dave Rice wrote: >> >>> Hi, >>> >>> >>> Element Name: Colour >>> Level: 4 >>> ID: [55][B0] >>> Mandatory: - >>> Multiple: - >>> Default: - >>> Type: m >>> Description: Settings describing the colour format. >>> >>> >>> Element Name: Matrix >>> >>> >>> To align better with ISO/IEC 23001-8, could this be labelled as >>> MatrixCoefficients? >>> >> Done >> >> >>> >>> Level: 5 >>> ID: [55][B1] >>> Mandatory: - >>> Multiple: - >>> Default: 2 >>> Type: u >>> Description: ColourMatrix of the video. See ISO/IEC 23001-8 for more >>> information on enumerations. (0: IEC 61966-2-1 (sRGB), 1: >>> BT709, >>> 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE >>> 170M, >>> 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance, >>> 10: BT2020 Constant Luminance) >>> >>> >>> Suggested description edit: >>> The Matrix Coefficients of the video used to derive luma and chroma >>> values from reg, green, and blue color primaries. For clarity, the valu= e >>> and meanings for MatrixCoefficients are adopted from Table 4 of ISO/IEC >>> 23001-8:2013/DCOR1. (0: IEC 61966-2-1 (sRGB), 1: BT709, 2: Unspecified,= 3: >>> Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M, 7: SMPTE 240M, 8: YCOCG, 9= : >>> BT2020 Non-constant Luminance, 10: BT2020 Constant Luminance) >>> >> Done >> >>> >>> Question: >>> Value 0 is listed as "IEC 61966-2-1 (sRGB)" but the table for matrix >>> coefficients in ISO/IEC 23001-8 says "GBR / Typically referred to as RG= B". >>> Should value 0 =3D RGB? >>> >> I changed it to GBR to match 23001-8. >> >> >>> Add footnote: >>> [IEC23001-8] ISO/IEC 23001-8:2013/DCOR1, "Coding independent media >>> description code points", 2013, < >>> http://standards.iso.org/ittf/PubliclyAvailableStandards/c062088_ISO_IE= C_23001-8_2013.zip >>> >. >>> >>> Element Name: BitsPerChannel >>> Level: 5 >>> ID: [55][B2] >>> Mandatory: - >>> Multiple: - >>> Default: 0 >>> Type: u >>> Description: Number of decoded bits per channel. This number may be >>> less for >>> specific channels depending on the Matrix and >>> ChromaSubsampling. A >>> value of 0 is unspecified. >>> >>> >>> It may be fine, but I don't understand "This number may be less for >>> specific channels depending on the Matrix and ChromaSubsampling." Is th= e >>> value is less for specific channels, then it seems as if the value woul= d >>> different among channels, but only one BitsPerChannel is stored for a >>> multi-channel video. >>> >> So we could have separate bits per channel, but then we would have to >> define rgb and yuv. Most people know what this is. Basically the >> information needed is, will the decoded video be 8 bits, 10 bits, 12 bit= s, >> 16 bits, ... Maybe I was just trying to be a little too pedantic. I'm fi= ne >> with removing this sentence. >> >> >> +1 for removing it. >> > Done > > >> >> if any of the ChromaSubsampling elements are set then that implies that >> one or more channels will have a different value. >> >> >> Ah, I had been presuming that you meant bits per channel of a channel's >> sample, rather than the total of the bits per channel (all samples/pixel= s >> of a frame). >> >> So how about we just remove this sentence? >> >> >>> I suggest changing the last line to: A value of 0 indicates that the >>> BitsPerChannel is unspecified. >>> >> Done >> >>> >>> Element Name: ChromaSubsamplingHorz >>> Level: 5 >>> ID: [55][B3] >>> Mandatory: - >>> Multiple: - >>> Default: - >>> Type: u >>> Description: The amount of chrominance pixels to remove for every >>> chrominance >>> pixel not removed horizontally. >>> >>> >>> For these subsampling elements, we may need a statement to say when the= y >>> should be used. For instance in QuickTime's TN2162 >>> https://developer.apple.com/library/mac/technotes/tn2162/_index.html it >>> mandates the use of many values to better describe uncompressed video. = When >>> would these chroma subsampling elements be suggested? >>> >> I'm not really sure I follow. If any of the Cb or Cr channels are down >> sized before encoding, then these elements should be set accordingly. >> >> >> I mean that this field is defined as being optional, but there's no >> indication to say when it should or when it shouldn't be used. This >> probably applies to most of these fields (and much of the matroska spec)= . >> > Ahh, OK. Yeah I have always been under the impression that you shouldn't > be using these elements unless you know what you are doing. Again as you > said that pertains to a lot of the elements in the Matroska spec (as well > as other specs). > > We could always expand upon these further in other documents/guides, but > for the spec I just want to accurately represent information that will be > used. > >> >> I also suggest including an example; such as "Example: For video with >>> 4:1:1 chroma subsampling the ChromaSubsamplingHorz should be set to 3. >>> >> I added "Example: For video with 4:2:0 chroma subsampling the >> ChromaSubsamplingHorz should be set to 1." As pretty much most video is >> 4:4:4 or 4:2:0 nowadays. >> >> >>> Element Name: ChromaSubsamplingVert >>> Level: 5 >>> ID: [55][B4] >>> Mandatory: - >>> Multiple: - >>> Default: - >>> Type: u >>> Description: The amount of chrominance pixels to remove for every >>> chrominance >>> pixel not removed vertically. >>> >>> Element Name: CbSubsamplingHorz >>> Level: 5 >>> ID: [55][B5] >>> Mandatory: - >>> Multiple: - >>> Default: - >>> Type: u >>> Description: The amount of Cb chrominance pixels to remove for every C= b >>> chrominance pixel not removed horizontally. This is >>> additive with >>> ChromaSubsamplingHorz. >>> >>> >>> I'm confused about the relationship between CbSubsamplingHorz >>> and ChromaSubsamplingHorz. >>> >> These elements are only defined because I was trying to handle 4:2:1. >> Basically this is an old format where the Cr channel is half the size of >> the Y channel, and the Cb channel is half the size of the Cr channel. Th= e >> Cb channel is a quarter the size of the Y channel. >> >> The CbSubsampling* elements were a late edition, right before I sent my >> previous email. At first I didn't have these elements and had text that >> 4:2:1 was not supported. >> >> >> Right. Sorry I wrote my comments before considering 4:2:1, since the >> fields are quite customized for situations like 4:2:1, perhaps it should= be >> referenced by name as an example. >> >> How about I change the CbSubsamplingHorz element text too: "The amount o= f >> pixels to remove in the Cr and Cb channels for every pixel not removed >> horizontally." And the CbSubsamplingHorz too: "The amount of pixels to >> remove in the Cb channel for every pixel not removed horizontally. This = is >> additive with ChromaSubsamplingHorz. Example: For video with 4:2:1 chrom= a >> subsampling the ChromaSubsamplingHorz should be set to 1 and >> CbSubsamplingHorz should be set to 1." Does this help the confusion? >> >> >> +1 >> >> Element Name: CbSubsamplingVert >>> Level: 5 >>> ID: [55][B6] >>> Mandatory: - >>> Multiple: - >>> Default: - >>> Type: u >>> Description: The amount of Cb chrominance pixels to remove for every C= b >>> chrominance pixel not removed vertically. This is additive >>> with >>> ChromaSubsamplingVert. >>> >>> >>> Element Name: ChromaSitingHorz >>> Level: 5 >>> ID: [55][B7] >>> Mandatory: - >>> Multiple: - >>> Default: 0 >>> Type: u >>> Description: How Chroma is subsampled horizontally. (0: Unspecified, 1= : >>> Left >>> collocated , 2: Half) >>> >>> Element Name: ChromaSitingVert >>> Level: 5 >>> ID: [55][B8] >>> Mandatory: - >>> Multiple: - >>> Default: 0 >>> Type: u >>> Description: How Chroma is subsampled vertically. (0: Unspecified, 1: >>> Top >>> collocated , 2: Half) >>> >>> >>> Element Name: Range >>> Level: 5 >>> ID: [55][B9] >>> Mandatory: - >>> Multiple: - >>> Default: 0 >>> Type: u >>> Description: Clipping of the color ranges. (0: Unspecified, 1: >>> Broadcast range, >>> 2: Full range (no clipping), 3: Defined by >>> Matrix/TransferFunction) >>> >>> >>> Element Name: TransferFunction >>> >>> >>> To align with ISO/IEC 23001-8, could we use TransferCharacteristics? >>> >> Done. >> >>> >>> Level: 5 >>> ID: [55][BA] >>> Mandatory: - >>> Multiple: - >>> Default: 2 >>> Type: u >>> Description: Transfer Function. See ISO/IEC 23001-8 for more >>> information on >>> enumerations. (0: Reserved, 1: ITU-R BT.709, 2: Unspecifie= d, >>> 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, >>> 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log >>> Sqrt, >>> 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut= , >>> 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, >>> 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, >>> 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG)) >>> >>> >>> Comment: >>> The table in ISO/IEC 23001-8 for transfer characteristics does not >>> include values or meaning for 16, 17 and 18 as above. Are these values = from >>> ffmpeg's list? >>> >> 16 and 17 is an artifact form the FFmpeg list, but also form looking at >> FFmpeg CL's I think they are defined in an h265 spec. 18 is a proposed >> value for HLG. >> >> >>> Suggested description edit: >>> The transfer characteristics of the video. For clarity, the value and >>> meanings for TransferCharacteristics are adopted from Table 3 of ISO/IE= C >>> 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: >>> Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, 7: SMP= TE >>> 240M, 8: Linear, 9: Log, 10: Log Sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.= 1361 >>> Extended Colour Gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: >>> ITU-R BT.2020 12 bit) >>> >> Done. >> >> >>> >>> Element Name: Primaries >>> Level: 5 >>> Mandatory: - >>> Multiple: - >>> ID: [55][BB] >>> Default: 2 >>> Type: u >>> Description: Values that can be represented in the CIE 1931 colour >>> space. See >>> ISO/IEC 23001-8 for more information on enumerations. >>> (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved= , >>> 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: >>> SMPTE 240M, >>> 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1) >>> >>> >>> Suggested description edit: >>> The colour primaries of the video. For clarity, the value and meanings >>> for TransferCharacteristics are adopted from Table 2 of ISO/IEC >>> 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: >>> Reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE >>> 240M, 8: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1) >>> >> Done. >> >>> >>> Note that ISO/IEC 23001-8 also includes a value for 22 for JEDEC P22 >>> phosphors. Any reason to exclude this? >>> >> Added. >> >> >>> >>> Element Name: MaxCLL >>> Level: 5 >>> ID: [55][BC] >>> Mandatory: - >>> Multiple: - >>> Default: - >>> Type: u >>> Description: Maximum brightness of a single pixel in candelas per squa= re >>> meter (cd/m=C2=B2). >>> >>> >>> Suggested: >>> Maximum brightness of a single pixel (Maximum Content Light Level) in >>> candelas per square meter (cd/m=C2=B2). >>> >> Done >> >> >>> >>> Element Name: MaxFALL >>> Level: 5 >>> ID: [55][BD] >>> Mandatory: - >>> Multiple: - >>> Default: - >>> Type: u >>> Description: Maximum brightness of a single full frame in candelas per >>> square >>> meter (cd/m=C2=B2). >>> >>> >>> Suggested: >>> Maximum brightness of a single full frame (Maximum Frame-Average Light >>> Level) in candelas per square meter (cd/m=C2=B2). >>> >> Done >> >> >>> >>> Element Name: MasteringMetadata >>> Level: 5 >>> ID: [55][D0] >>> Mandatory: - >>> Multiple: - >>> Default: - >>> Type: m >>> Description: SMPTE 2086 mastering data. >>> >>> >>> Element Name: PrimaryRChromaticityX >>> Level: 6 >>> ID: [55][D1] >>> Mandatory: - >>> Multiple: - >>> Range: 0 <=3D f <=3D 1 >>> >>> >>> I think "0.0-1.0" is preferred for float range expressions. >>> >> >> Sorry there's an open discussion elsewhere on Cellar about expressing >> float ranges as hexadecimal floating-point literals, so this may be chan= ged >> later, but the meaning should still be the same. >> > No problem. I just had it that way for brevity, much like a lot of my > other descriptions. I don't want to add to much text to a cell of the > Matroska spec table. :) > > >> Done >> >> >>> >>> Default: - >>> Type: f >>> Description: Red X chromaticity coordinate as defined by CIE 1931. >>> >>> >>> Element Name: PrimaryRChromaticityY >>> Level: 6 >>> ID: [55][D2] >>> Mandatory: - >>> Multiple: - >>> Range: 0 <=3D f <=3D 1 >>> Default: - >>> Type: f >>> Description: Red Y chromaticity coordinate as defined by CIE 1931. >>> >>> >>> Element Name: PrimaryGChromaticityX >>> Level: 6 >>> ID: [55][D3] >>> Mandatory: - >>> Multiple: - >>> Range: 0 <=3D f <=3D 1 >>> Default: - >>> f >>> Description: Green X chromaticity coordinate as defined by CIE 1931. >>> >>> >>> Element Name: PrimaryGChromaticityY >>> Level: 6 >>> ID: [55][D4] >>> Mandatory: - >>> Multiple: - >>> Range: 0 <=3D f <=3D 1 >>> Default: - >>> Type: f >>> Description: Green Y chromaticity coordinate as defined by CIE 1931. >>> >>> >>> Element Name: PrimaryBChromaticityX >>> Level: 6 >>> ID: [55][D5] >>> Mandatory: - >>> Multiple: - >>> Range: 0 <=3D f <=3D 1 >>> Default: - >>> f >>> Description: Blue X chromaticity coordinate as defined by CIE 1931. >>> >>> >>> Element Name: PrimaryBChromaticityY >>> Level: 6 >>> ID: [55][D6] >>> Mandatory: - >>> Multiple: - >>> Range: 0 <=3D f <=3D 1 >>> Default: - >>> Type: f >>> Description: Blue Y chromaticity coordinate as defined by CIE 1931. >>> >>> >>> Element Name: WhitePointChromaticityX >>> Level: 6 >>> ID: [55][D7] >>> Mandatory: - >>> Multiple: - >>> Range: 0 <=3D f <=3D 1 >>> Default: - >>> Type: f >>> Description: White point X chromaticity coordinate as defined by CIE >>> 1931. >>> >>> >>> Element Name: WhitePointChromaticityY >>> Level: 6 >>> ID: [55][D8] >>> Mandatory: - >>> Multiple: - >>> Range: 0 <=3D f <=3D 1 >>> Default: - >>> Type: f >>> Description: White point Y chromaticity coordinate as defined by CIE >>> 1931. >>> >>> >>> Element Name: LuminanceMax >>> Level: 6 >>> ID: [55][D9] >>> Mandatory: - >>> Multiple: - >>> Range: 0 <=3D f <=3D 9999.99 >>> Default: - >>> Type: f >>> Description: Maximum luminance. Shall be represented in candelas per >>> square >>> meter (cd/m=C2=B2). >>> >>> >>> Element Name: LuminanceMin >>> Level: 6 >>> ID: [55][DA] >>> Mandatory: - >>> Multiple: - >>> Range: 0 <=3D f <=3D 999.9999 >>> Default: - >>> Type: f >>> Description: Minimum luminance. Shall be represented in candelas per >>> square >>> meter (cd/m=C2=B2). >>> >>> >>> >>> >>> I removed ChromaSubsampling and added ChromaSubsamplingHorz, >>> ChromaSubsamplingVert, CbSubsamplingHorz, and CbSubsamplingVert. >>> >>> This is how I think the elements should be written for the different >>> subsampling types: >>> 1: 4:4:4 >>> - ChromaSubsamplingHorz and ChromaSubsamplingVert will not be set a= s >>> there should be no chroma subsampling. >>> >>> 2: 4:4:0 >>> - ChromaSubsamplingHorz :not set >>> - ChromaSubsamplingVert :1 >>> >>> 3: 4:2:2 >>> - ChromaSubsamplingHorz :1 >>> - ChromaSubsamplingVert :not set >>> >>> 4: 4:2:1 >>> - ChromaSubsamplingHorz :1 >>> - ChromaSubsamplingVert :not set >>> - CbSubsamplingHorz :1 >>> - CbSubsamplingVert :not set >>> - We could remove CbSubsamplingHorz and CbSubsamplingVert if we didn'= t >>> care about handling formats where the Cr and Cb channels are different >>> sizes. >>> >>> >>> I forgot about 4:2:1. That answers my question about CbSubsmaplingHorz >>> though perhaps we need a narrative section to expand on this with the >>> examples you have here. >>> >>> 5: 4:2:0 >>> - ChromaSubsamplingHorz :1 >>> - ChromaSubsamplingVert :1 >>> >>> 6: 4:1:1 >>> - ChromaSubsamplingHorz :3 >>> - ChromaSubsamplingVert :not set >>> >>> 7: 4:1:0 >>> - ChromaSubsamplingHorz :3 >>> - ChromaSubsamplingVert :1 >>> >>> 8: 3:1:1 >>> - ChromaSubsamplingHorz :2 >>> - ChromaSubsamplingVert :not set >>> - I'm assuming the luma subsampling can be handled by PixelWidth, and >>> DisaplyWidth. >>> >>> Jerome's vertical subsampling of 4 >>> - ChromaSubsamplingHorz :not set >>> - ChromaSubsamplingVert :3 >>> >>> >>> >>> The other issue I want to bring up is the value of "18: ARIB STD-B67 >>> (HLG)" in TransferFunction. Unfortunately, in WebM we will need to use >>> this value sooner than Matroska v4 will be finalized. Should I make thi= s >>> value much higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17: >>> SMPTE ST 428-1" will be standardized across most documents, like 1-15 >>> are. Just not sure if 18 will be HLG. >>> >>> >>> I see a few references to ARIB STD-B67 as 18, such as >>> http://www.arib.or.jp/english/html/overview/doc/2-STD-B32v3_5.pdf. >>> Perhaps we need a caveat that values 1-15 are defined based upon ISO/IE= C >>> 23001-8. Then for values 16, 17, and 18 we could add better description= s >>> and citations to define it better internally. >>> >> I'm fine with this. I'm just worried about the case where we diverge fro= m >> one of the lists. Would be nice to have one canonical list. >> >> >>> If (hopefully) a revision to ISO/IEC 23001-8 adds those values (as >>> expected) then we could update are description to say all values are >>> defined by ISO/IEC 23001-8. >>> >> Sounds good to me. >> >> >> It's a bit risky. Perhaps for now we should clarify that values 1-15 are >> defined by ISO/IEC 23001-8 and then give customized definitions for 16, = 17, >> 18. >> > > Following Jerome's comment, how about this for TransferCharacteristic: > "The transfer characteristics of the video. For clarity, the value and > meanings for TransferCharacteristics 1-15 are adopted from Table 3 of > ISO/IEC 23001-8:2013/DCOR1. TransferCharacteristics 16-17 are adopted fro= m > <265 doc> and 18 is the proposed value of ARIB STD-B67. (0: Reserved, 1: > ITU-R BT.709, 2: Unspecified, 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2= .8 > curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt, 11: > IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour Gamut, 13: IEC 61966-2-1= , > 14: ITU-R BT.2020 10 bit, 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, 17= : > SMPTE ST 428-1 18: ARIB STD-B67 (HLG))" > > Dave Rice >> >> > --001a113dcc82a15718052c10ad98 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Here is the current proposal, minus the reference to the 2= 65 doc.

The parent ele= ment would be Video [E0].



Element Name: Colour

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A04

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0[55][B0]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0m

Descr= iption: =C2=A0Settings describing the colour format.



Element Name: MatrixCoefficients

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A05

ID: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B1]

Mandatory: =C2=A0=C2=A0=C2=A0-=

Multiple: =C2=A0=C2=A0=C2=A0=C2= =A0-

Default: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A02

Ty= pe: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0The Matrix Coefficients of the vide= o used to derive luma and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0chroma values from reg, green, and blue color pr= imaries. For

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0clarity, the value and meanings for MatrixCoefficients are adop= ted

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0from Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0:GBR, 1: BT709,

=

= =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A02: Unspec= ified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 170M,

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A07: SMPTE 240M, 8: YCO= CG, 9: BT2020 Non-constant Luminance,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A010: BT2020 Constant Luminance)



Element Name: BitsPerChannel

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A05

ID: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B2]

Mandatory: =C2=A0=C2=A0=C2=A0-

=

= Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-=

Default: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A00

Type: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0Number of decoded bits per chan= nel. A v= alue of 0 indicates that

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0the BitsPerChannel is unspecified.



Element Name: ChromaSubsamplingHorz

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05=

ID: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B3]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0-

Type: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0The amount of pixels to remove in the Cr and= Cb channels for every

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0pixel not removed horizontally. Example: For video = with 4:2:0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0chroma subsampling, the ChromaSubsamplingHorz should be set to = 1.



Element Name: = ChromaSubsamplingVert

Lev= el: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0[55][B4]

Mand= atory: =C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0u

Description: = =C2=A0Th= e amount of pixels to remove in the Cr and Cb channels for every

=

= =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0pixel not= removed vertically. Example: For video with 4:2:0 chroma

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0subsampling, th= e ChromaSubsamplingVert should be set to 1.


Eleme= nt Name: CbSubsamplingHorz

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0[55][B5]

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0u

Descript= ion: =C2=A0The amount of pixels to remove in the Cb channel for every pixel<= /p>

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0not re= moved horizontally. This is additive with

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ChromaSubsamplingHorz. Example: F= or video with 4:2:1 chroma

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0subsampling, the ChromaSubsamplingHorz should be= set to 1 and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0CbSubsamplingHorz should be set to 1.



Element Name: CbSubsamplingVert<= /p>

Level: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A05

ID: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B6]=

Mandatory: =C2=A0=C2=A0=C2=A0-<= /span>

Multiple: =C2=A0=C2=A0=C2= =A0=C2=A0-

Default: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0The amount of pixels to remov= e in the Cb channel for every pixel

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0not removed vertically. This is additiv= e with

.=



Element Name: Ch= romaSitingHorz

Level: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0[55][B7]

Mandatory:= =C2=A0=C2=A0=C2=A0-

Mult= iple: =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A00

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0u

Description: =C2=A0H= ow Chroma is subsampled horizontally. (0: Unspecified, 1: Left

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:13.3333px;font-family:'Courier New';vertica= l-align:baseline;white-space:pre-wrap"> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0collocated , 2: Half)

Element Name: ChromaSitingVer= t

Level: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B8= ]

Mandatory: =C2=A0=C2=A0= =C2=A0-

Multiple: =C2=A0= =C2=A0=C2=A0=C2=A0-

Defau= lt: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A00

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0How Chroma is = subsampled vertically. (0: Unspecified, 1: Top

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0collocated , 2: Half)



Element Name: Range

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A05

ID: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B9]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A00

Type: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0Clipping of the color ranges. (0: Unspecified, 1: Broadcast range,

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A02: Full range (no clippi= ng), 3: Defined by

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= MatrixCo= efficients/TransferCharacteristics)



Element Name: TransferCharacteristics

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A05

ID: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][BA]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0= -

Default: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A02

Type:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0The transfer characteristics of the vi= deo. For clarity, the value

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0and meanings for TransferCharacteristics 1-15 ar= e adopted from

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0Table 3 of ISO/IEC 23001-8:2013/DCOR1. TransferCharacteristi= cs

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A016-17 are adopted from <265 doc> and 18 is the proposed value of

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= ARIB STD-B67. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A03: Reserved, 4:= Gamma 2.2 curve, 5: Gamma 2.8 curve,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06: SMPTE 170M, 7: SMPTE 240M, 8: Lin= ear, 9: Log, 10: Log Sqrt,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A011: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Co= lour Gamut,

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A013: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit,

=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A015: ITU-R BT.20= 20 12 bit, 16: SMPTE ST 2084, 17: SMPTE ST 428-1

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A018: ARIB STD-B67 (HLG))



Element Name: Primar= ies

Level: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0[55][BB]

D= efault: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A02

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0The colour primari= es of the video. For clarity, the value and

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0meanings for Primaries are ado= pted from Table 2 of

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0ISO/IEC 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.= 709,

= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A02: Unspecified, 3: Reserved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG,

=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06: = SMPTE 170M, 7: SMPTE 240M, 8: FILM, 9: ITU-R BT.2020,

=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A010: SMPTE ST 428-1, 2= 2: JEDEC P22 phosphors)



Element Name: MaxCLL

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0[55][BC]

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0u

Descript= ion: =C2=A0Maximum brightness of a single pixel (Maximum Content Light Level)

=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0in can= delas per square meter (cd/m=C2=B2).



Element Name: MaxFALL

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05<= /p>

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][BD]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-<= /span>

Type: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u

Description: =C2=A0Maximum brightness of a single full frame (Maximum Frame-= Average

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0Light Level) in candelas per square meter (cd/m=C2=B2).

=

Element Name: MasteringMeta= data

Level: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A05

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55]= [D0]

Mandatory: =C2=A0=C2= =A0=C2=A0-

Multiple: =C2= =A0=C2=A0=C2=A0=C2=A0-

De= fault: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0m

Description: =C2=A0SMPTE 2086 = mastering data.



E= lement Name: PrimaryRChromaticityX

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D1]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A00.0 <=3D f <=3D 1.0

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0f

Descr= iption: =C2=A0Red X chromaticity coordinate as defined by= CIE 1931.



Elemen= t Name: PrimaryRChromaticityY

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0[55][D2]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00.0 <=3D f <=3D 1.0

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0f

Description= : =C2=A0Red Y chromaticity coordinate as defined by CIE 1= 931.



Element Name= : PrimaryGChromaticityX

L= evel: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0[55][D3]

M= andatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00.0 <=3D f <=3D 1.0

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

f

Green X chromaticity coordinate as d= efined by CIE 1931.



Element Name: PrimaryGChromaticityY

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

=

= ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D4]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A00.0 <=3D f <=3D 1.0

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0f

De= scription: =C2=A0Green Y chromaticity coordinate as defin= ed by CIE 1931.


Element Name: PrimaryBChromat= icityX

Level: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[= 55][D5]

Mandatory: =C2=A0= =C2=A0=C2=A0-

Multiple: = =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00.0 <= ;=3D f <=3D 1.0

Defaul= t: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

Description: =C2=A0Blue X chromaticity coordinate as defined by CIE 1931.


Element Name: PrimaryBChromaticity= Y

Level: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D6= ]

Mandatory: =C2=A0=C2=A0= =C2=A0-

Multiple: =C2=A0= =C2=A0=C2=A0=C2=A0-

Range= : =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00.0 <=3D f= <=3D 1.0

Default: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

Description: =C2=A0Blu= e Y chromaticity coordinate as defined by CIE 1931.



Element Name: WhitePointChromaticityX

Level: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D7]

Mandatory: =C2=A0=C2=A0=C2= =A0-

Multiple: =C2=A0=C2= =A0=C2=A0=C2=A0-

Range: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00.0 <=3D f &= lt;=3D 1.0

Default: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

Description: =C2=A0Whi= te point X chromaticity coordinate as defined by CIE 1931.


Element Name: WhitePointChromatic= ityY

Level: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55]= [D8]

Mandatory: =C2=A0=C2= =A0=C2=A0-

Multiple: =C2= =A0=C2=A0=C2=A0=C2=A0-

Ra= nge: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00.0 <= =3D f <=3D 1.0

Default= : =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

=

= Description: =C2=A0White point Y chromaticity coordinate as defined by CIE 1931.

<= br>

Element Name: LuminanceMax

Level: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D9]

Mandatory: =C2=A0=C2=A0=C2= =A0-

Multiple: =C2=A0=C2= =A0=C2=A0=C2=A0-

Range: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00.0 <=3D f &= lt;=3D 9999.99

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0-

Type: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

Description: =C2=A0Maximum luminance. Shall be represented in = candelas per square

=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= meter (cd/m=C2=B2).



Element Name: LuminanceMin

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06

ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0[55][DA]

Mandatory: =C2=A0=C2=A0=C2=A0-

Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-

Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00.0 <=3D f <=3D 999.9999

Default:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-

Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:13.3333px;font-family:'Courier New';vertica= l-align:baseline;white-space:pre-wrap">Description: =C2=A0Minimum luminance= . Shall be represented in candelas per square

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0meter (cd/m=C2=B2).


[IEC23= 001-8] ISO/IEC 23001-8:2013/DCOR1, "Coding independent media descripti= on code points", 2013, <http://standards.iso.org/ittf/PubliclyAvailableStandards/c062088_I= SO_IEC_23001-8_2013.zip>.


<reference to h265 doc)


=

On Tu= e, Feb 16, 2016 at 11:56 AM, Frank Galligan <frankgalligan@gmail.c= om> wrote:


On Tue, Feb = 16, 2016 at 11:14 AM, Dave Rice <dave@dericed.com> wrote:
=

On Feb 16, 2016, at 2:01 PM, Frank Galligan <frankgalligan@gmail.c= om> wrote:



On Fri, Feb 12, 2016 at 5:53 PM, Dave R= ice <dave@dericed.com> wrote:
Hi,

Element Name: Colour
Level: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A04
ID: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B0]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2= =A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0m
Description: =C2=A0Settings describing the col= our format.


Element Name: Matrix

To align= better with ISO/IEC 23001-8, could this be labelled as MatrixCoefficients?=
Done
=C2=A0

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
= ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0[55][B1]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
D= efault: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A02
Type: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Descriptio= n: =C2=A0ColourMatrix of the video. See ISO/IEC 23001-8 for more
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0information on enumerations. (0: IEC 61966-2-1 (sRGB), 1: BT= 709,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A02: Unspecified, 3: Reserved, 4: FCC, 5: BT470= BG, 6: SMPTE 170M,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A07: SMPTE 240M, 8: YCOCG, 9: BT= 2020 Non-constant Luminance,
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A010: BT2020 Constant L= uminance)

Suggested description edit:
The Matrix Coef= ficients of the video used to derive luma and chroma values from reg, green= , and blue color primaries. For clarity, the value and meanings for MatrixC= oefficients are adopted from Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0: IEC= 61966-2-1 (sRGB), 1: BT709, 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470B= G, 6: SMPTE 170M, 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance= , 10: BT2020 Constant Luminance)
D= one=C2=A0

Question:
Value 0 is listed as "IEC 61966-= 2-1 (sRGB)" but the table for matrix coefficients in ISO/IEC 23001-8 s= ays "GBR / Typically referred to as RGB". Should value 0 =3D RGB?=
I changed it to GBR to match 23001-8.


Add footnote:
[IEC23001-8] ISO/IEC 23001-8:= 2013/DCOR1, "Coding independent media description code points", 2= 013, <http://standards.iso.= org/ittf/PubliclyAvailableStandards/c062088_ISO_IEC_23001-8_2013.zip>= ;.

Element Name: Bi= tsPerChannel
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0[55][B2]
Mandatory: =C2=A0=C2=A0= =C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A00
T= ype: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0Number of decoded bits per channel. This number may be = less for
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0specific channels depending on the Matr= ix and ChromaSubsampling. A
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0value of 0 is unspeci= fied.
It may be fine, but I don't understand "This number m= ay be less for specific channels depending on the Matrix and ChromaSubsampl= ing." Is the value is less for specific channels, then it seems as if = the value would different among channels, but only one BitsPerChannel is st= ored for a multi-channel video.
So we co= uld have separate bits per channel, but then we would have to define rgb an= d yuv. Most people know what this is. Basically the information needed is, = will the decoded video be 8 bits, 10 bits, 12 bits, 16 bits, ... Maybe I wa= s just trying to be a little too pedantic. I'm fine with removing this = sentence.

+1 = for removing it.
Done
=C2=A0

if any of the ChromaSubsampling elements are set the= n that implies that one or more channels will have a different value.
=

Ah, I had been pre= suming that you meant bits per channel of a channel's sample, rather th= an the total of the bits per channel (all samples/pixels of a frame).
=
So how about we just remove this senten= ce?


I suggest changing the last line to: A value of = 0 indicates that the BitsPerChannel is unspecified.
Done=C2=A0

Element Name: ChromaSubsampling= Horz
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 5
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0[55][B3]
Mandatory: =C2=A0=C2=A0=C2=A0-
= Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Descriptio= n: =C2=A0The amount of chrominance pixels to remove for every chrominance
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0pixel not removed horizontally.
=

For these subsampl= ing elements, we may need a statement to say when they should be used. For = instance in QuickTime's=C2=A0TN2162 https://dev= eloper.apple.com/library/mac/technotes/tn2162/_index.html=C2=A0it manda= tes the use of many values to better describe uncompressed video. When woul= d these chroma subsampling elements be suggested?
I'm not really sure I follow. If any of the Cb or Cr channels= are down sized before encoding, then these elements should be set accordin= gly.=C2=A0

I = mean that this field is defined as being optional, but there's no indic= ation to say when it should or when it shouldn't be used. This probably= applies to most of these fields (and much of the matroska spec).
Ahh, OK. Yeah I have always been under the impres= sion that you shouldn't be using these elements unless you know what yo= u are doing. Again as you said that pertains to a lot of the elements in th= e Matroska spec (as well as other specs).

We could= always expand upon these further in other documents/guides, but for the sp= ec I just want to accurately represent information that will be used.
=

I also suggest including an example; such as "Example: For video wit= h 4:1:1 chroma subsampling the=C2=A0ChromaSubsamplingHorz should be set to = 3.
I added "Example: For video with= 4:2:0 chroma subsampling the ChromaSubsamplingHorz should be set to 1.&quo= t; As pretty much most video is 4:4:4 or 4:2:0 nowadays.


Element Name: ChromaSubsamplingVert
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[= 55][B4]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0= The amount of chrominance pixels to remove for every chrominance
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0pixel not removed vertically.

E= lement Name: CbSubsamplingHorz
Level: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B5]
Mandat= ory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0= =C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
<= span style=3D"font-size:13.3333px;font-family:'Courier New';color:r= gb(34,34,34);font-weight:400;font-style:normal;font-variant:normal;text-dec= oration:none;vertical-align:baseline;white-space:pre-wrap;background-color:= rgb(255,255,255)">Description: =C2=A0The amount of Cb chrominance pixels to= remove for every Cb
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0chrominance pixel not remov= ed horizontally. This is additive with
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ChromaSub= samplingHorz.
=
I'm confused about the relationship between=C2=A0CbSubsa= mplingHorz and=C2=A0ChromaSubsamplingHorz.
These elements are only defined because I was trying to handle 4:2:1. Ba= sically this is an old format where the Cr channel is half the size of the = Y channel, and the Cb channel is half the size of the Cr channel. The Cb ch= annel is a quarter the size of the Y channel.

The = CbSubsampling* elements were a late edition, right before I sent my previou= s email. At first I didn't have these elements and had text that 4:2:1 = was not supported.

Right. Sorry I wrote my comments before considering 4:2:1, since the = fields are quite customized for situations like 4:2:1, perhaps it should be= referenced by name as an example.

=
How about I change the CbSubsamplingHorz element text too: "The amoun= t of pixels to remove in the Cr and Cb channels for every pixel not removed= horizontally." And the CbSubsamplingHorz too: "The amount of pix= els to remove in the Cb channel for every pixel not removed horizontally. T= his is additive with ChromaSubsamplingHorz. Example: For video with 4:2:1 c= hroma subsampling the ChromaSubsamplingHorz should be set to 1 and CbSubsam= plingHorz should be set to 1." Does this help the confusion?

+1

=
Element Name: CbSubsamplingVert
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0[55][B6]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Defau= lt: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2= =A0The amount of Cb chrominance pixels to remove for every Cb
<= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0chrominance pixel not removed vertically. This is additive with=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0ChromaSubsamplingVert.


<= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">Element Name: ChromaSitingHorz
Level: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][B7]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2= =A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A00
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0u
Description: =C2=A0How Chroma is subsampled ho= rizontally. (0: Unspecified, 1: Left
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0collocated ,= 2: Half)

Element Name: ChromaSitingVert
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0[55][B8]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default:= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A00
Type: =C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0= How Chroma is subsampled vertically. (0: Unspecified, 1: Top
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0collocated , 2: Half)


Element = Name: Range
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0[55][B9]
Mandatory: =C2=A0=C2=A0= =C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A00
T= ype: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0Clipping of the color ranges.= (0: Unspecified, 1: Broadcast range,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A02: Full range (no clipping), 3: Defined by
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0Matrix/TransferFunction)


Element = Name: TransferFunction

To align with ISO/IEC 23001-8, could we use Transfe= rCharacteristics?
Done.=C2=A0

Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= 5
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0[55][BA]
Mandatory: =C2=A0=C2=A0=C2=A0-
= Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A02
Type: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Descriptio= n: =C2=A0Transfer Function. See ISO/IEC 23001-8 for more information on
<= span style=3D"font-size:13.3333px;font-family:'Courier New';color:r= gb(34,34,34);font-weight:400;font-style:normal;font-variant:normal;text-dec= oration:none;vertical-align:baseline;white-space:pre-wrap;background-color:= rgb(255,255,255)"> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0enumerations. (0: Reserved, 1: ITU-R BT.709, 2: Uns= pecified,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A03: Reserved, 4: Gamma 2.2 curve, 5: Gam= ma 2.8 curve,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06: SMPTE 170M, 7: SMPTE 240M, 8: Lin= ear, 9: Log, 10: Log Sqrt,
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A011: IEC 61966-2-4, 12= : ITU-R BT.1361 Extended Colour Gamut,
=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A013: IEC 6= 1966-2-1, 14: ITU-R BT.2020 10 bit,
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A015: ITU-R BT= .2020 12 bit, 16: SMPTE ST 2084,
=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A017: SMPTE ST 42= 8-1 18: ARIB STD-B67 (HLG))

Comment:
The table in ISO/IEC 23001-= 8 for transfer characteristics does not include values or meaning for 16, 1= 7 and 18 as above. Are these values from ffmpeg's list?
16 and 17 is an artifact form the FFmpeg list, but also= form looking at FFmpeg CL's I think they are defined in an h265 spec. = 18 is a proposed value for HLG.


Suggested description = edit:
The transfer characteristics of the video. For clarity, the= value and meanings for=C2=A0TransferCharacteristics=C2=A0are adopted from = Table 3 of ISO/IEC 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Un= specified, 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve,=C2=A06: SMP= TE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log Sqrt,=C2=A011: IEC 61966= -2-4, 12: ITU-R BT.1361 Extended Colour Gamut,=C2=A013: IEC 61966-2-1, 14: = ITU-R BT.2020 10 bit,=C2=A015: ITU-R BT.2020 12 bit)
Done.
=C2=A0

Level: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A05
Mandatory: =C2=A0=C2=A0=C2=A0-<= /span>
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][BB]=
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A02
=
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0Values that can be represented in the CIE 193= 1 colour space. See
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ISO/IEC 23001-8 for more infor= mation on enumerations.
=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0(0: Reserved, 1: ITU-R B= T.709, 2: Unspecified, 3: Reserved,
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A04: ITU-R BT.= 470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A08: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1)

Suggested description= edit:
The colour primaries of the video. For clarity, the value and mea= nings for TransferCharacteristics are adopted=C2=A0from Table 2 of ISO/IEC = 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reser= ved, 4: ITU-R BT.470M, 5: ITU-R BT.470BG, 6: SMPTE 170M, 7: SMPTE 240M,=C2= =A08: FILM, 9: ITU-R BT.2020, 10: SMPTE ST 428-1)
Done.=C2=A0

Note that ISO/IEC 23001-8 also includes a value fo= r 22 for JEDEC P22 phosphors. Any reason to exclude this?
Added.
=C2=A0

Eleme= nt Name: MaxCLL
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0[55][BC]
Mandatory: =C2=A0=C2= =A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-<= /div>
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2=A0Maximum brightness of a single pixel in candelas per = square
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0meter (cd/m=C2=B2).

Suggested:
= Maximum brightness of a single pixel (Maximum Content Light Level) in cande= las per square meter (cd/m=C2=B2).
Done<= /div>
=C2=A0
=

Element Name: MaxFALL
= Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0[55][BD]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Defau= lt: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u
Description: =C2= =A0Maximum brightness of a single full frame in candelas per square<= /div>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0meter (cd/m=C2=B2).
=

Suggested:
Maximum br= ightness of a single full frame (Maximum=C2=A0Frame-Average=C2=A0Light Leve= l) in candelas per square meter (cd/m=C2=B2).
Done
=C2=A0

Element= Name: MasteringMetadata
Level: =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A05
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D0]
Mandatory: = =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0= -
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0m
Description: =C2=A0SMPTE 2086 mastering data.


Element Name: PrimaryRChromaticityX
L= evel: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06
ID: = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D1]=
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple= : =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 1

I think "0.0-1.0"= is preferred for float range expressions.

Sorry there's an= open discussion elsewhere on Cellar about expressing float ranges as=C2=A0= hexadecimal floating-point literals, so this may be changed later, but the = meaning should still be the same.
No pro= blem. I just had it that way for brevity, much like a lot of my other descr= iptions. I don't want to add to much text to a cell of the Matroska spe= c table. :)


Done
=C2=A0

Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
= Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f<= /span>
Description: =C2=A0Red X chromaticity coordinate as d= efined by CIE 1931.


Element Name: PrimaryR= ChromaticityY
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0[55][D2]
Mandatory: =C2=A0=C2=A0= =C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f &l= t;=3D 1
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
<= span style=3D"font-size:13.3333px;font-family:'Courier New';color:r= gb(34,34,34);font-weight:400;font-style:normal;font-variant:normal;text-dec= oration:none;vertical-align:baseline;white-space:pre-wrap;background-color:= rgb(255,255,255)">Description: =C2=A0Red Y chromaticity coordinate as defi= ned by CIE 1931.


Element Name: PrimaryGChr= omaticityX
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0[55][D3]
Mandatory: =C2=A0=C2=A0=C2= =A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
<= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <= =3D 1
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-<= /div>
f
Description: =C2=A0Green X chromatic= ity coordinate as defined by CIE 1931.


E= lement Name: PrimaryGChromaticityY
Level: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D4]
M= andatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0= =C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A00 <=3D f <=3D 1
Default: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0f
Description: =C2=A0Green Y chr= omaticity coordinate as defined by CIE 1931.

<= br>
Element Name: PrimaryBChromaticityX
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A06
<= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55= ][D5]
Mandatory: =C2=A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <=3D 1
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
f=
Description: =C2=A0Blue X chromaticity coordinate as define= d by CIE 1931.


Element Name: PrimaryBChrom= aticityY
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0[55][D6]
Mandatory: =C2=A0=C2=A0=C2= =A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
<= div style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt">Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f <= =3D 1
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-<= /div>
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
Description: =C2=A0Blue Y chromaticity coordinate as defin= ed by CIE 1931.


Element Name: WhitePointCh= romaticityX
Level: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0[55][D7]
Mandatory: =C2=A0=C2=A0= =C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <=3D f &l= t;=3D 1
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
<= span style=3D"font-size:13.3333px;font-family:'Courier New';color:r= gb(34,34,34);font-weight:400;font-style:normal;font-variant:normal;text-dec= oration:none;vertical-align:baseline;white-space:pre-wrap;background-color:= rgb(255,255,255)">Description: =C2=A0White point X chromaticity coordinate= as defined by CIE 1931.


Element Name: Whi= tePointChromaticityY
Level: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D8]
Mandatory: =C2= =A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <= ;=3D f <=3D 1
Default: =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0-
Type: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0f
Description: =C2=A0White point Y chromaticity= coordinate as defined by CIE 1931.


Elemen= t Name: LuminanceMax
Level: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][D9]
Mandatory: =C2= =A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <= ;=3D f <=3D 9999.99
Defau= lt: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
Description: =C2= =A0Maximum luminance. Shall be represented in candelas per square
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0meter (cd/m=C2=B2).


Elem= ent Name: LuminanceMin
Level: =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A06
ID: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0[55][DA]
Mandatory: =C2= =A0=C2=A0=C2=A0-
Multiple: =C2=A0=C2=A0=C2=A0=C2=A0-
Range: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A00 <= ;=3D f <=3D 999.9999
Defa= ult: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0-
Type: =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0f
Description: = =C2=A0Minimum luminance. Shall be represented in candelas per square=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0meter (cd/m=C2=B2).



I removed ChromaSubsampling and added ChromaSubsamplingHorz, C= hromaSubsamplingVert, CbSubsamplingHorz, and CbSubsamplingVert.
<= br>
This is how I think the elements should be written for the di= fferent subsampling types:
1: 4:4:4
=C2=A0 =C2=A0 = - ChromaSubsamplingHorz and ChromaSubsamplingVert will not be set as there = should be no chroma subsampling.

2: 4:4:0
=C2=A0 - ChromaSubsamplingHorz :not set
=C2=A0 - ChromaSub= samplingVert :1

3: 4:2:2
=C2= =A0 - ChromaSubsamplingHorz :1
=C2=A0 - ChromaSubsamplingVert :no= t set

4: 4:2:1
=C2=A0 - Chrom= aSubsamplingHorz :1
=C2=A0 - ChromaSubsamplingVert :not set
=
=C2=A0 - CbSubsamplingHorz :1
=C2=A0 - CbSubsampl= ingVert :not set
=C2=A0 - We could remove CbSubsamplingHorz= and CbSubsamplingVert if we didn't care about handling formats where t= he Cr and Cb channels are different sizes.

I forgot about 4:2:1. That answers my q= uestion about CbSubsmaplingHorz though perhaps we need a narrative section = to expand on this with the examples you have here.

5: 4:2:0
=C2=A0 - ChromaSubsamplingHorz :1<= /div>
=C2=A0 - ChromaSubsamplingVert :1

6: 4:1= :1
=C2=A0 - ChromaSubsamplingHorz :3
=C2=A0 - Chro= maSubsamplingVert :not set

7: 4:1:0
=C2=A0 - ChromaSubsamplingHorz :3
=C2=A0 - ChromaSubsampli= ngVert :1

8: 3:1:1
=C2= =A0 - ChromaSubsamplingHorz :2
=C2=A0 - ChromaSubsamplingVert :no= t set
=C2=A0 - I'm assuming the luma subsampling can be= handled by PixelWidth, and DisaplyWidth.

Jerome&#= 39;s vertical subsampling of 4
=C2=A0 - ChromaSubsamplingHor= z :not set
=C2=A0 - ChromaSubsamplingVert :3

=


The other issue I want to bring up= is the value of "18: ARIB STD-B67 = (HLG)" in TransferFunction. Unfortunately, in WebM we will need= to use this value sooner than Matroska v4 will be finalized. Should I make= this value much higher? Or leave at 18? I think "16: SMPTE ST 2084" and "17: SMPTE ST 428-1" will be standardized across= most documents, like 1-15 are. Just not sure if 18 will be HLG.

I see a few references = to ARIB STD-B67 as 18, such as=C2=A0http://www.arib.or= .jp/english/html/overview/doc/2-STD-B32v3_5.pdf. Perhaps we need a cave= at that values 1-15 are defined based upon ISO/IEC 23001-8. Then for values= 16, 17, and 18 we could add better descriptions and citations to define it= better internally.
I'm fine with t= his. I'm just worried about the case where we diverge from one of the l= ists. Would be nice to have one canonical list.
=C2=A0
If (hopefully) a = revision to ISO/IEC 23001-8 adds those values (as expected) then we could u= pdate are description to say all values are defined by ISO/IEC 23001-8.
Sounds good to me.
<= /div>
It's a bit risky. Perhaps for now we s= hould clarify that values 1-15 are defined by=C2=A0ISO/IEC 23001-8 and then= give customized definitions for 16, 17, 18.
<= br>
Following Jerome's comment, =C2=A0how about this for Tran= sferCharacteristic:
"The transfer characteristics of the vid= eo. For clarity, the value and meanings for TransferCharacteristics 1-15 ar= e adopted from Table 3 of ISO/IEC 23001-8:2013/DCOR1. TransferCharacteristi= cs 16-17 are adopted from <265 doc> and 18 is the proposed value of A= RIB STD-B67. (0: Reserved, 1: ITU-R BT.709, 2: Unspecified, 3: Reserved, 4:= Gamma 2.2 curve, 5: Gamma 2.8 curve, 6: SMPTE 170M, 7: SMPTE 240M, 8: Line= ar, 9: Log, 10: Log Sqrt, 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Col= our Gamut, 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, 15: ITU-R BT.2020 1= 2 bit, 16: SMPTE ST 2084, 17: SMPTE ST 428-1 18: ARIB STD-B67 (HLG))"<= /div>

Dave Rice



--001a113dcc82a15718052c10ad98-- From nobody Fri Feb 19 11:59:55 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A0D1B34B8 for ; Fri, 19 Feb 2016 11:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 3emcq4cUzrFS for ; Fri, 19 Feb 2016 11:59:49 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF191B34B5 for ; Fri, 19 Feb 2016 11:59:49 -0800 (PST) Received: from [146.96.19.240] (port=13636 helo=[10.10.202.53]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aWrDL-0034EL-K6; Fri, 19 Feb 2016 14:59:49 -0500 Content-Type: multipart/alternative; boundary="Apple-Mail=_937C5588-2630-44C5-A7B6-2E10CB8DC323" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Fri, 19 Feb 2016 14:59:41 -0500 Message-Id: References: <568C3CA0.8040300@mediaarea.net> <56B8CD1A.20307@mediaarea.net> <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> <9CE0170E-E63D-411D-AFAF-EE5CBB4B56D7@dericed.com> To: FFmpeg development discussions and patches , libav development X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org, Frank Galligan Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2016 19:59:53 -0000 --Apple-Mail=_937C5588-2630-44C5-A7B6-2E10CB8DC323 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, Working with the IETF Cellar Working Group, = https://datatracker.ietf.org/wg/cellar/charter/, Frank Galligan has = drafted a proposal for the management of metadata in Matroska to = accommodate information on color, full/broadcast range, HDR metadata, = chroma subsampling patterns and other information. I'm forwarding it to = ffmpeg-devel and libav-devel to encourage any additional comments. The = background discussion thus far is visible at = https://mailarchive.ietf.org/arch/search/?email_list=3Dcellar&gbt=3D1&q=3D= Colour+Format+proposal = . For context, the structure for Matroska element = definitions is currently in draft here: = https://github.com/Matroska-Org/ebml-specification/blob/master/specificati= on.markdown#ebml-schema-element-attributes = . > Begin forwarded message: >=20 > From: Frank Galligan > Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal > Date: February 18, 2016 at 2:50:27 PM EST > To: Dave Rice > Cc: Jerome Martinez , Discussion about the = current and future development of Matroska = , cellar@ietf.org >=20 > Here is the current proposal, minus the reference to the 265 doc. >=20 > The parent element would be Video [E0]. >=20 >=20 > Element Name: Colour > Level: 4 > ID: [55][B0] > Mandatory: - > Multiple: - > Default: - > Type: m > Description: Settings describing the colour format. >=20 >=20 > Element Name: MatrixCoefficients > Level: 5 > ID: [55][B1] > Mandatory: - > Multiple: - > Default: 2 > Type: u > Description: The Matrix Coefficients of the video used to derive luma = and > chroma values from reg, green, and blue color primaries. = For > clarity, the value and meanings for MatrixCoefficients = are adopted > from Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0:GBR, 1: = BT709, > 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: = SMPTE 170M, > 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant = Luminance, > 10: BT2020 Constant Luminance)=20 >=20 >=20 > Element Name: BitsPerChannel > Level: 5 > ID: [55][B2] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: Number of decoded bits per channel. A value of 0 = indicates that > the BitsPerChannel is unspecified. >=20 >=20 > Element Name: ChromaSubsamplingHorz > Level: 5 > ID: [55][B3] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of pixels to remove in the Cr and Cb channels = for every > pixel not removed horizontally. Example: For video with = 4:2:0 > chroma subsampling, the ChromaSubsamplingHorz should be = set to 1. >=20 >=20 > Element Name: ChromaSubsamplingVert > Level: 5 > ID: [55][B4] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of pixels to remove in the Cr and Cb channels = for every > pixel not removed vertically. Example: For video with = 4:2:0 chroma > subsampling, the ChromaSubsamplingVert should be set to = 1. >=20 > Element Name: CbSubsamplingHorz > Level: 5 > ID: [55][B5] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of pixels to remove in the Cb channel for = every pixel > not removed horizontally. This is additive with > ChromaSubsamplingHorz. Example: For video with 4:2:1 = chroma > subsampling, the ChromaSubsamplingHorz should be set to = 1 and > CbSubsamplingHorz should be set to 1. >=20 >=20 > Element Name: CbSubsamplingVert > Level: 5 > ID: [55][B6] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: The amount of pixels to remove in the Cb channel for = every pixel > not removed vertically. This is additive with > ChromaSubsamplingVert. >=20 >=20 > Element Name: ChromaSitingHorz > Level: 5 > ID: [55][B7] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: How Chroma is subsampled horizontally. (0: Unspecified, = 1: Left=20 > collocated , 2: Half) >=20 > Element Name: ChromaSitingVert > Level: 5 > ID: [55][B8] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: How Chroma is subsampled vertically. (0: Unspecified, 1: = Top > collocated , 2: Half) >=20 >=20 > Element Name: Range > Level: 5 > ID: [55][B9] > Mandatory: - > Multiple: - > Default: 0 > Type: u > Description: Clipping of the color ranges. (0: Unspecified, 1: = Broadcast range, > 2: Full range (no clipping), 3: Defined by > MatrixCoefficients/TransferCharacteristics) >=20 >=20 > Element Name: TransferCharacteristics > Level: 5 > ID: [55][BA] > Mandatory: - > Multiple: - > Default: 2 > Type: u > Description: The transfer characteristics of the video. For clarity, = the value > and meanings for TransferCharacteristics 1-15 are = adopted from > Table 3 of ISO/IEC 23001-8:2013/DCOR1. = TransferCharacteristics > 16-17 are adopted from <265 doc> and 18 is the proposed = value of > ARIB STD-B67. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified, > 3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 curve, > 6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log = Sqrt, > 11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut, > 13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit, > 15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, 17: SMPTE = ST 428-1 > 18: ARIB STD-B67 (HLG)) >=20 >=20 > Element Name: Primaries > Level: 5 > Mandatory: - > Multiple: - > ID: [55][BB] > Default: 2 > Type: u > Description: The colour primaries of the video. For clarity, the = value and > meanings for Primaries are adopted from Table 2 of > ISO/IEC 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R = BT.709, > 2: Unspecified, 3: Reserved, 4: ITU-R BT.470M, 5: ITU-R = BT.470BG, > 6: SMPTE 170M, 7: SMPTE 240M, 8: FILM, 9: ITU-R BT.2020, > 10: SMPTE ST 428-1, 22: JEDEC P22 phosphors) >=20 >=20 > Element Name: MaxCLL > Level: 5 > ID: [55][BC] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: Maximum brightness of a single pixel (Maximum Content = Light Level) > in candelas per square meter (cd/m=C2=B2). >=20 >=20 > Element Name: MaxFALL > Level: 5 > ID: [55][BD] > Mandatory: - > Multiple: - > Default: - > Type: u > Description: Maximum brightness of a single full frame (Maximum = Frame-Average > Light Level) in candelas per square meter (cd/m=C2=B2). >=20 >=20 > Element Name: MasteringMetadata > Level: 5 > ID: [55][D0] > Mandatory: - > Multiple: - > Default: - > Type: m > Description: SMPTE 2086 mastering data. >=20 >=20 > Element Name: PrimaryRChromaticityX > Level: 6 > ID: [55][D1] > Mandatory: - > Multiple: - > Range: 0.0 <=3D f <=3D 1.0 > Default: - > Type: f > Description: Red X chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: PrimaryRChromaticityY > Level: 6 > ID: [55][D2] > Mandatory: - > Multiple: - > Range: 0.0 <=3D f <=3D 1.0 > Default: - > Type: f > Description: Red Y chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: PrimaryGChromaticityX > Level: 6 > ID: [55][D3] > Mandatory: - > Multiple: - > Range: 0.0 <=3D f <=3D 1.0 > Default: - > f > Description: Green X chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: PrimaryGChromaticityY > Level: 6 > ID: [55][D4] > Mandatory: - > Multiple: - > Range: 0.0 <=3D f <=3D 1.0 > Default: - > Type: f > Description: Green Y chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: PrimaryBChromaticityX > Level: 6 > ID: [55][D5] > Mandatory: - > Multiple: - > Range: 0.0 <=3D f <=3D 1.0 > Default: - > Type: f > Description: Blue X chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: PrimaryBChromaticityY > Level: 6 > ID: [55][D6] > Mandatory: - > Multiple: - > Range: 0.0 <=3D f <=3D 1.0 > Default: - > Type: f > Description: Blue Y chromaticity coordinate as defined by CIE 1931. >=20 >=20 > Element Name: WhitePointChromaticityX > Level: 6 > ID: [55][D7] > Mandatory: - > Multiple: - > Range: 0.0 <=3D f <=3D 1.0 > Default: - > Type: f > Description: White point X chromaticity coordinate as defined by CIE = 1931. >=20 >=20 > Element Name: WhitePointChromaticityY > Level: 6 > ID: [55][D8] > Mandatory: - > Multiple: - > Range: 0.0 <=3D f <=3D 1.0 > Default: - > Type: f > Description: White point Y chromaticity coordinate as defined by CIE = 1931. >=20 >=20 > Element Name: LuminanceMax > Level: 6 > ID: [55][D9] > Mandatory: - > Multiple: - > Range: 0.0 <=3D f <=3D 9999.99 > Default: - > Type: f > Description: Maximum luminance. Shall be represented in candelas per = square > meter (cd/m=C2=B2). >=20 >=20 > Element Name: LuminanceMin > Level: 6 > ID: [55][DA] > Mandatory: - > Multiple: - > Range: 0.0 <=3D f <=3D 999.9999 > Default: - > Type: f > Description: Minimum luminance. Shall be represented in candelas per = square > meter (cd/m=C2=B2). >=20 > =20 > [IEC23001-8] ISO/IEC 23001-8:2013/DCOR1, "Coding independent media = description code points", 2013, = >. >=20 > . Best Regards, Dave Rice --Apple-Mail=_937C5588-2630-44C5-A7B6-2E10CB8DC323 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

Working = with the IETF Cellar Working Group, https://datatracker.ietf.org/wg/cellar/charter/, Frank = Galligan has drafted a proposal for the management of metadata in = Matroska to accommodate information on color, full/broadcast range, HDR = metadata, chroma subsampling patterns and other information. I'm = forwarding it to ffmpeg-devel and libav-devel to encourage any = additional comments. The background discussion thus far is visible = at https://mailarchive.ietf.org/arch/search/?email_list=3Dcellar&a= mp;gbt=3D1&q=3DColour+Format+proposal. For context, the = structure for Matroska element definitions is currently in draft = here: https://github.com/Matroska-Org/ebml-specification/blob/master/= specification.markdown#ebml-schema-element-attributes.

Begin forwarded message:

From: Frank Galligan <frankgalligan@gmail.com>
Subject: Re: [Cellar] [Matroska-devel] = Colour Format proposal
Date: February 18, 2016 at 2:50:27 PM EST
To: Dave Rice <dave@dericed.com>
Cc: Jerome Martinez <jerome@mediaarea.net>, Discussion about the current = and future development of Matroska <matroska-devel@lists.matroska.org>, cellar@ietf.org

Here is the current proposal, minus the reference to the 265 = doc.

The parent element would be Video [E0].


Element Name: Colour
Level: =        4
ID: =           [55][B0]
Mandatory:    -
Multiple: =     -
Default: =      -
Type: =         m
Description:  Settings describing the colour = format.


Element Name: = MatrixCoefficients
Level: =        5
ID: =           [55][B1]
Mandatory:    -
Multiple: =     -
Default: =      2
Type: =         u
Description:  The Matrix = Coefficients of the video used to derive luma and
=             &n= bsp;chroma values from reg, green, and blue color primaries. = For
=             &n= bsp;clarity, the value and meanings for MatrixCoefficients are = adopted
=             &n= bsp;from Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0:GBR, 1: = BT709,
=             &n= bsp;2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE = 170M,
=             &n= bsp;7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant = Luminance,
=             &n= bsp;10: BT2020 Constant Luminance)


Element Name: BitsPerChannel
Level: =        5
ID: =           [55][B2]
Mandatory:    -
Multiple: =     -
Default: =      0
Type: =         u
Description:  Number of decoded bits per channel. = A value of 0 indicates that
=             &n= bsp;the BitsPerChannel is unspecified.


Element Name: = ChromaSubsamplingHorz
Level: =        5
ID: =           [55][B3]
Mandatory:    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount of pixels = to remove in the Cr and Cb channels for every
=             &n= bsp;pixel not removed horizontally. Example: For video with = 4:2:0
=             &n= bsp;chroma subsampling, the ChromaSubsamplingHorz should be set to = 1.


Element Name: = ChromaSubsamplingVert
Level: =        5
ID: =           [55][B4]
Mandatory:    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount of pixels = to remove in the Cr and Cb channels for every
=             &n= bsp;pixel not removed vertically. Example: For video with 4:2:0 = chroma
=             &n= bsp;subsampling, the ChromaSubsamplingVert should be set to = 1.

Element Name: = CbSubsamplingHorz
Level: =        5
ID: =           [55][B5]
Mandatory:    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount of pixels = to remove in the Cb channel for every pixel
=             &n= bsp;not removed horizontally. This is additive with
=             &n= bsp;ChromaSubsamplingHorz. Example: For video with 4:2:1 = chroma
=             &n= bsp;subsampling, the ChromaSubsamplingHorz should be set to 1 = and
=             &n= bsp;CbSubsamplingHorz should be set to 1.


Element Name: CbSubsamplingVert
Level: =        5
ID: =           [55][B6]
Mandatory:    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  The amount of pixels = to remove in the Cb channel for every pixel
=             &n= bsp;not removed vertically. This is additive with
=             &n= bsp;ChromaSubsamplingVert.


Element = Name: ChromaSitingHorz
Level: =        5
ID: =           [55][B7]
Mandatory:    -
Multiple: =     -
Default: =      0
Type: =         u
Description:  How Chroma is subsampled horizontally. (0: = Unspecified, 1: Left
=             &n= bsp;collocated , 2: Half)

Element Name: = ChromaSitingVert
Level: =        5
ID: =           [55][B8]
Mandatory:    -
Multiple: =     -
Default: =      0
Type: =         u
Description:  How Chroma is subsampled vertically. (0: = Unspecified, 1: Top
=             &n= bsp;collocated , 2: Half)


Element = Name: Range
Level: =        5
ID: =           [55][B9]
Mandatory:    -
Multiple: =     -
Default: =      0
Type: =         u
Description:  Clipping of the color = ranges. (0: Unspecified, 1: Broadcast range,
=             &n= bsp;2: Full range (no clipping), 3: Defined by
=             &n= bsp;MatrixCoefficients/TransferCharacteristics)


Element Name: TransferCharacteristics
Level: =        5
ID: =           [55][BA]
Mandatory:    -
Multiple: =     -
Default: =      2
Type: =         u
Description:  The transfer = characteristics of the video. For clarity, the value
=             &n= bsp;and meanings for TransferCharacteristics 1-15 are adopted = from
=             &n= bsp;Table 3 of ISO/IEC 23001-8:2013/DCOR1. = TransferCharacteristics
=             &n= bsp;16-17 are adopted from <265 doc> and 18 is the proposed value = of
=             &n= bsp;ARIB STD-B67. (0: Reserved, 1: ITU-R BT.709, 2: = Unspecified,
=             &n= bsp;3: Reserved, 4: Gamma 2.2 curve, 5: Gamma 2.8 = curve,
=             &n= bsp;6: SMPTE 170M, 7: SMPTE 240M, 8: Linear, 9: Log, 10: Log = Sqrt,
=             &n= bsp;11: IEC 61966-2-4, 12: ITU-R BT.1361 Extended Colour = Gamut,
=             &n= bsp;13: IEC 61966-2-1, 14: ITU-R BT.2020 10 bit,
=             &n= bsp;15: ITU-R BT.2020 12 bit, 16: SMPTE ST 2084, 17: SMPTE ST = 428-1
=             &n= bsp;18: ARIB STD-B67 (HLG))


Element = Name: Primaries
Level: =        5
Mandatory: =    -
Multiple: =     -
ID: =           [55][BB]
Default:      2
Type: =         u
Description:  The colour primaries = of the video. For clarity, the value and
=             &n= bsp;meanings for Primaries are adopted from Table 2 of
=             &n= bsp;ISO/IEC 23001-8:2013/DCOR1. (0: Reserved, 1: ITU-R = BT.709,
=             &n= bsp;2: Unspecified, 3: Reserved, 4: ITU-R BT.470M, 5: ITU-R = BT.470BG,
=             &n= bsp;6: SMPTE 170M, 7: SMPTE 240M, 8: FILM, 9: ITU-R = BT.2020,
=             &n= bsp;10: SMPTE ST 428-1, 22: JEDEC P22 phosphors)


Element Name: MaxCLL
Level: =        5
ID: =           [55][BC]
Mandatory:    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  Maximum brightness of = a single pixel (Maximum Content Light Level)
=             &n= bsp;in candelas per square meter (cd/m=C2=B2).


Element Name: MaxFALL
Level: =        5
ID: =           [55][BD]
Mandatory:    -
Multiple: =     -
Default: =      -
Type: =         u
Description:  Maximum brightness of = a single full frame (Maximum Frame-Average
=             &n= bsp;Light Level) in candelas per square meter (cd/m=C2=B2).

Element Name: MasteringMetadata
Level: =        5
ID: =           [55][D0]
Mandatory:    -
Multiple: =     -
Default: =      -
Type: =         m
Description:  SMPTE 2086 mastering data.


Element Name: = PrimaryRChromaticityX
Level: =        6
ID: =           [55][D1]
Mandatory:    -
Multiple: =     -
Range: =        0.0 <=3D f <=3D = 1.0
Default: =      -
Type: =         f
Description:  Red X chromaticity coordinate as defined by CIE = 1931.


Element Name: = PrimaryRChromaticityY
Level: =        6
ID: =           [55][D2]
Mandatory:    -
Multiple: =     -
Range: =        0.0 <=3D f <=3D = 1.0
Default: =      -
Type: =         f
Description:  Red Y chromaticity coordinate as defined by CIE = 1931.


Element Name: = PrimaryGChromaticityX
Level: =        6
ID: =           [55][D3]
Mandatory:    -
Multiple: =     -
Range: =        0.0 <=3D f <=3D = 1.0
Default: =      -
f
Description:  Green X chromaticity coordinate as defined by = CIE 1931.


Element Name: = PrimaryGChromaticityY
Level: =        6
ID: =           [55][D4]
Mandatory:    -
Multiple: =     -
Range: =        0.0 <=3D f <=3D = 1.0
Default: =      -
Type: =         f
Description:  Green Y chromaticity coordinate as defined by = CIE 1931.


Element Name: = PrimaryBChromaticityX
Level: =        6
ID: =           [55][D5]
Mandatory:    -
Multiple: =     -
Range: =        0.0 <=3D f <=3D = 1.0
Default: =      -
Type: =         f
Description:  Blue X chromaticity coordinate as defined by CIE = 1931.


Element Name: = PrimaryBChromaticityY
Level: =        6
ID: =           [55][D6]
Mandatory:    -
Multiple: =     -
Range: =        0.0 <=3D f <=3D = 1.0
Default: =      -
Type: =         f
Description:  Blue Y chromaticity coordinate as defined by CIE = 1931.


Element Name: = WhitePointChromaticityX
Level: =        6
ID: =           [55][D7]
Mandatory:    -
Multiple: =     -
Range: =        0.0 <=3D f <=3D = 1.0
Default: =      -
Type: =         f
Description:  White point X chromaticity coordinate as defined = by CIE 1931.


Element Name: = WhitePointChromaticityY
Level: =        6
ID: =           [55][D8]
Mandatory:    -
Multiple: =     -
Range: =        0.0 <=3D f <=3D = 1.0
Default: =      -
Type: =         f
Description:  White point Y chromaticity coordinate as defined = by CIE 1931.


Element Name: = LuminanceMax
Level: =        6
ID: =           [55][D9]
Mandatory:    -
Multiple: =     -
Range: =        0.0 <=3D f <=3D = 9999.99
Default: =      -
Type: =         f
Description:  Maximum luminance. Shall be represented in = candelas per square
=             &n= bsp;meter (cd/m=C2=B2).


Element = Name: LuminanceMin
Level: =        6
ID: =           [55][DA]
Mandatory:    -
Multiple: =     -
Range: =        0.0 <=3D f <=3D = 999.9999
Default: =      -
Type: =         f
Description:  Minimum luminance. Shall be represented in = candelas per square
=             &n= bsp;meter (cd/m=C2=B2).

=

[IEC23001-8] ISO/IEC = 23001-8:2013/DCOR1, "Coding independent media description code points", = 2013, <http://standards.iso.org/ittf/PubliclyAvailableStandards/c06208= 8_ISO_IEC_23001-8_2013.zip>.

<reference to h265 = doc)

[...]

Those = interested in standardization efforts for EBML, Matroska, and FFV1 are = encouraged to join the CELLAR Working Group. https://datatracker.ietf.org/wg/cellar/charter/.
=
Best Regards,
Dave = Rice

= --Apple-Mail=_937C5588-2630-44C5-A7B6-2E10CB8DC323-- From nobody Fri Feb 19 13:46:18 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6557B1ACDC9 for ; Fri, 19 Feb 2016 13:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham 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 8l3jqnHbjYVh for ; Fri, 19 Feb 2016 13:46:15 -0800 (PST) Received: from relay2-d.mail.gandi.net (relay2-d.mail.gandi.net [217.70.183.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B271ACD91 for ; Fri, 19 Feb 2016 13:46:14 -0800 (PST) Received: from mfilter31-d.gandi.net (mfilter31-d.gandi.net [217.70.178.162]) by relay2-d.mail.gandi.net (Postfix) with ESMTP id 6483BC5A49; Fri, 19 Feb 2016 22:46:13 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at mfilter31-d.gandi.net Received: from relay2-d.mail.gandi.net ([IPv6:::ffff:217.70.183.194]) by mfilter31-d.gandi.net (mfilter31-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id OxD7NacQy6Sg; Fri, 19 Feb 2016 22:46:11 +0100 (CET) X-Originating-IP: 213.47.64.66 Received: from localhost (chello213047064066.6.14.vie.surfer.at [213.47.64.66]) (Authenticated sender: michael@niedermayer.cc) by relay2-d.mail.gandi.net (Postfix) with ESMTPSA id 019A2C5A5F; Fri, 19 Feb 2016 22:46:10 +0100 (CET) Date: Fri, 19 Feb 2016 22:45:38 +0100 From: Michael Niedermayer To: Frank Galligan Message-ID: <20160219214538.GL4557@nb4> References: <56B8CD1A.20307@mediaarea.net> <6852A8C0-B1D1-40F9-BE5F-5A7E956C4C42@dericed.com> <9CE0170E-E63D-411D-AFAF-EE5CBB4B56D7@dericed.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4e5ZDkbgLEOfWmLx" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Cc: Jerome Martinez , Dave Rice , cellar@ietf.org, Discussion about the current and future development of Matroska Subject: Re: [Cellar] [Matroska-devel] Colour Format proposal X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 19 Feb 2016 21:46:17 -0000 --4e5ZDkbgLEOfWmLx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi On Thu, Feb 18, 2016 at 11:50:27AM -0800, Frank Galligan wrote: > Here is the current proposal, minus the reference to the 265 doc. >=20 > The parent element would be Video [E0]. >=20 >=20 > Element Name: Colour >=20 > Level: 4 >=20 > ID: [55][B0] >=20 > Mandatory: - >=20 > Multiple: - >=20 > Default: - >=20 > Type: m >=20 > Description: Settings describing the colour format. >=20 >=20 > Element Name: MatrixCoefficients >=20 > Level: 5 >=20 > ID: [55][B1] >=20 > Mandatory: - >=20 > Multiple: - >=20 > Default: 2 >=20 > Type: u >=20 > Description: The Matrix Coefficients of the video used to derive luma and >=20 > chroma values from reg, green, and blue color primaries. For >=20 > clarity, the value and meanings for MatrixCoefficients are > adopted >=20 > from Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0:GBR, 1: BT709, >=20 > 2: Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6: SMPTE 17= 0M, >=20 > 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant Luminance, >=20 > 10: BT2020 Constant Luminance) >=20 >=20 > Element Name: BitsPerChannel >=20 > Level: 5 >=20 > ID: [55][B2] >=20 > Mandatory: - >=20 > Multiple: - >=20 > Default: 0 >=20 > Type: u >=20 > Description: Number of decoded bits per channel. A value of 0 indicates > that >=20 > the BitsPerChannel is unspecified. >=20 what would this be set to for old 16bit rgb, that is 5 bit red 6 bit green, 5 bit blue rawvideo. This maybe does not matter and iam not strongly suggesting to add it, rather i want to point it out so its not unintentionally forgotten [...] > Element Name: CbSubsamplingHorz >=20 > Level: 5 >=20 > ID: [55][B5] >=20 > Mandatory: - >=20 > Multiple: - >=20 > Default: - >=20 > Type: u >=20 > Description: The amount of pixels to remove in the Cb channel for every > pixel >=20 > not removed horizontally. This is additive with >=20 > ChromaSubsamplingHorz. Example: For video with 4:2:1 chroma >=20 > subsampling, the ChromaSubsamplingHorz should be set to 1 and >=20 > CbSubsamplingHorz should be set to 1. >=20 >=20 > Element Name: CbSubsamplingVert >=20 > Level: 5 >=20 > ID: [55][B6] >=20 > Mandatory: - >=20 > Multiple: - >=20 > Default: - >=20 > Type: u >=20 > Description: The amount of pixels to remove in the Cb channel for every > pixel >=20 > not removed vertically. This is additive with >=20 > ChromaSubsamplingVert. What if Cr is subsampled more than Cb ? That too is rather obscure, but theres code in FFmpeg to handle such jpegs, so i suspect this case while very rare is not entirely non existent ... >=20 >=20 > Element Name: ChromaSitingHorz >=20 > Level: 5 >=20 > ID: [55][B7] >=20 > Mandatory: - >=20 > Multiple: - >=20 > Default: 0 >=20 > Type: u >=20 > Description: How Chroma is subsampled horizontally. (0: Unspecified, 1: > Left >=20 > collocated , 2: Half) >=20 > Element Name: ChromaSitingVert >=20 > Level: 5 >=20 > ID: [55][B8] >=20 > Mandatory: - >=20 > Multiple: - >=20 > Default: 0 >=20 > Type: u >=20 > Description: How Chroma is subsampled vertically. (0: Unspecified, 1: Top >=20 > collocated , 2: Half) >=20 iam not sure this is enough to specify all variants for 4:2:0 alone there are a few different variants theres mpeg1 style mpeg2 progressive and interlaced the mpeg2/mpeg4 style also differs from itself if the image is fliped right= -left cropping 1 or 2 lines of the top of mpeg2 yuv420 also results in different variants [...] --=20 Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire --4e5ZDkbgLEOfWmLx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlbHjQIACgkQYR7HhwQLD6vNFQCffIh6Lj4yFAcq7W+V+XT9+goh ROwAn03eebNnZFHZIr0/wcgHb/rZRpG4 =3FzX -----END PGP SIGNATURE----- --4e5ZDkbgLEOfWmLx-- From nobody Tue Feb 23 16:57:22 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBA51B3380 for ; Tue, 23 Feb 2016 16:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 Je8CK_4myLtT for ; Tue, 23 Feb 2016 16:57:20 -0800 (PST) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2767C1B30BD for ; Tue, 23 Feb 2016 16:57:20 -0800 (PST) Received: by mail-pf0-x22a.google.com with SMTP id q63so2236955pfb.0 for ; Tue, 23 Feb 2016 16:57:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=JPeWSz1ziqrWVKNslk+jYXDk9pVuvz8ka7tJmlUMDcI=; b=E9la4cUC2wosCbuAqp/aZp4tfhjc4z3eU6E650P4Y/SI2NyotroZYoOy3Iep/jYyKy WSLnZ/5EnuTH991pujhC+9q3asTdf9Mb6iSBCdnzcJLVhRaiSxV3Hm5ZdG7Ht6gpvzOW yF5iHtNQp+smvuLcJ2IOyEL0AdX6mGmmygROVLvw13NpUzF2+9Cu1+Jlymu1fJxTlUlZ xUZa7/3j9toaqLoZH5kEVGcPVPPholwN2BGOpLbDmB2lruwGulqYcnWZLBJ4k7sv4Atn ViIF1hnrZFQ2h1CT2Z7f3UrcXnS5A3VQB/T9icXqrNu84SGeoUul9HWfs1T43bq9bblN rT2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=JPeWSz1ziqrWVKNslk+jYXDk9pVuvz8ka7tJmlUMDcI=; b=Mh11omDJ6DBZ+ADGCFJ8hdikE5T5rKhag1JVfZVXW6aGrJK/WhsoPa5GaYGPGT8SEg zAA0aXxKdH5UoN8mb81Gk4X8rLTCQXSoSnYNJvDJzEASkWbrJO06wPYp11o26iN4/Ec4 EukSDXm+9wgDJ5aBMXpju2ZVivAjDG8ml871R9kfqWc1qA4JxskRbcBm9usdjE7+n9+r QcYrP1wk4x4q+5kaUejVQNykl+IjlMbVTKyYaXx4RDUh5KvfVc2Ttuk3v2M/fP+/2GM3 Sr8JxA+7EJcfCd+kMfU6dbuFW3afb4zIDotbTwAcnuzgzVFPk43Tia86bRz0xNBm0+13 9Prg== X-Gm-Message-State: AG10YOQafjvXdPlfpQ/KXpEJrok+CXl9vOJA407Ck4j1Z2gNegyNkGbij68LOk5OTgKvslHt/qBW4q/m4r9TE1rN X-Received: by 10.98.69.155 with SMTP id n27mr50645226pfi.68.1456275439788; Tue, 23 Feb 2016 16:57:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.66.156.197 with HTTP; Tue, 23 Feb 2016 16:57:00 -0800 (PST) From: Michael Bradshaw Date: Tue, 23 Feb 2016 16:57:00 -0800 Message-ID: To: cellar@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0b911248edf4052c798c8d Archived-At: Subject: [Cellar] Is there a way for a Block to indicate it contains a keyframe? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 00:57:21 -0000 --94eb2c0b911248edf4052c798c8d Content-Type: text/plain; charset=UTF-8 SimpleBlock has a flag that, if set, indicates it is a keyframe. Block, however, does not have that flag. Unless I'm missing something, I don't see any way for a Block (or BlockGroup) to indicate it is a keyframe. Please correct me if I'm wrong, though. I'd like for Block/BlockGroup to be able to indicate if it is a keyframe. The two options I see is either: 1) Use bit 0 in Block's flags to indicate if it's a keyframe (just like SimpleBlock). 2) Introduce a new element into BlockGroup. Are there any thoughts/opinions from others? --Michael --94eb2c0b911248edf4052c798c8d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
SimpleBlock has a flag that, if set, indicates it is a key= frame. Block, however, does not have that flag. Unless I'm missing some= thing, I don't see any way for a Block (or BlockGroup) to indicate it i= s a keyframe. Please correct me if I'm wrong, though.

I'd like for Block/BlockGroup to be able to indicate if it is a keyfr= ame. The two options I see is either:

1) Use bit 0= in Block's flags to indicate if it's a keyframe (just like SimpleB= lock).
2) Introduce a new element into BlockGroup.

=
Are there any thoughts/opinions from others?

--Michael
--94eb2c0b911248edf4052c798c8d-- From nobody Wed Feb 24 20:23:38 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2418D1B2F06 for ; Wed, 24 Feb 2016 20:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.944 X-Spam-Level: ** X-Spam-Status: No, score=2.944 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FF_IHOPE_YOU_SINK=2.166, SPF_NEUTRAL=0.779] autolearn=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 xWDGUkIe8c96 for ; Wed, 24 Feb 2016 20:23:35 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FDA91B2EEE for ; Wed, 24 Feb 2016 20:23:35 -0800 (PST) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:47496 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aYnSd-003GMf-Tl; Wed, 24 Feb 2016 23:23:34 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Wed, 24 Feb 2016 23:23:28 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <44C63F61-1867-4F93-98D5-CBC728F67811@dericed.com> References: <0A176C1B-19D5-4579-8447-4A5075B8D94B@dericed.com> To: cellar@ietf.org X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Moritz Bunkus , Steve Lhomme Subject: Re: [Cellar] EBML Security Considerations section X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 04:23:37 -0000 > On Feb 14, 2016, at 11:29 AM, Steve Lhomme = wrote: >=20 > 2016-02-14 17:23 GMT+01:00 Dave Rice : >>=20 >>> On Feb 14, 2016, at 10:11 AM, Steve Lhomme = wrote: >>>=20 >>> 2016-02-13 22:04 GMT+01:00 Dave Rice : >>>> Here is a draft Security Considerations section for the EBML spec. = The section is based off Moritz=E2=80=99s comment here = https://github.com/Matroska-Org/ebml-specification/issues/6#issuecomment-9= 9937237 with some minor re-wording. >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> ## Security Considerations >>>>=20 >>>> EBML itself does not offer any kind of security. It has nothing to = do with authentication, it dose not provide confidentiality, only = marginally useful and effective data integrity options (CRC elements). >>>>=20 >>>> EBML does not provide any kind of authorization. >>>>=20 >>>> Even if the semantic layer offers and kind of encryption EBML = itself leaks information, at the least the sematic layer used via the = DocType element, but also certain information about the structure from = the elements (you can derive the presence of EBML elements even with an = unknown semantic layer with a heuristic approach; not without errors, of = course, but with a certain degree of confidence). >>>>=20 >>>> Attacks on an EBML reader may include: >>>> - Invalid Element IDs that are longer than the limit stated in the = EBMLMaxIDLength Element of the EBML Header. >>>=20 >>> It could also be an invalid size, like 13 for floats. >>=20 >> Not sure I understand. The Element Data Size is only expressed in = VINT and the Floats of EBML are only within Elements defined as float. = For instance is Matroska;Duration is expressed as a float value of 13, = it is invalid, but is this a security issue? >=20 > My bad. That comment was for the Element Size, not the Element ID. >=20 >>>> - Invalid Element IDs that not encoded in the shortest-possible = way. >>>=20 >>> Missing *is* >>=20 >> Fixed locally. >>=20 >>>> - Invalid Element Ids comprised of reserved values. >>>> - Invalid Element Data Size values that are longer than the limit = stated in the EBMLMaxSizeLength Element of the EBML Header. >>>> - Invalid Element Data Size values (e.g. extending the length of = the Element beyond the scope of the Parent Element; possibly triggering = access-out-of-bounds issues). >=20 > As said above. For elements with only a set of bounds you may not > extend the size. For example one could write a float of size 1. >=20 >>>> - Very high lengths in order to force out-of-memory situations = resulting in a denial of service, access-out-of-bounds issues etc. >>>> - Missing Elements that are mandatory and have no declared default = value. >>>> - Usage of 0x00 octets in EBML Elements with a string type. >>>> - Usage of invalid UTF-8 encoding in EBML Elements of UTF-8 type = (e.g. in order to trigger acces-out-of-bounds or buffer overflow = issues). >>>> - Usage of invalid data in EBML Elements with a date type. >>>>=20 >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>=20 >>>> Of the points, I don=E2=80=99t quite understand a few.. >>>>=20 >>>> Originally Moritz wrote: >>>>> Usage of \0 characters in EbmlString elements >>>> I changed it to >>>>> - Usage of 0x00 octets in EBML Elements with a string type. >>>> but the string elements are allowed to be terminated with one or = many 0x00 octets. What is an example of a null terminated EBML string = that is a security consideration. >>>>=20 >>>> Regarding: >>>>> - Usage of invalid data in EBML Elements with a date type. >>>>=20 >>>>=20 >>>> Any 0 or 8 octet date value is valid, right? Other lengths are = already invalid for date elements, so is this necessary to include? >>>>=20 >>>> A PR of the draft Security Considerations section is here: = https://github.com/Matroska-Org/ebml-specification/pull/54. Here is the latest draft of the Security Consideration section. Thanks = for the many suggestions in the mailing list and the pull request at = https://github.com/Matroska-Org/ebml-specification/pull/54. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ## Security Considerations EBML itself does not offer any kind of security. It has nothing to do = with authentication; it does not provide confidentiality and offers only = marginally useful and effective data integrity options (CRC elements). EBML does not provide any kind of authorization. Even if the semantic layer offers any kind of encryption, EBML itself = may leak information at either the semantic layer (as declared via the = DocType element) or within the EBML structure (you can derive the = presence of EBML elements even with an unknown semantic layer with a = heuristic approach; not without errors, of course, but with a certain = degree of confidence). Attacks on an EBML reader may include: - Invalid Element IDs that are longer than the limit stated in the = EBMLMaxIDLength Element of the EBML Header. - Invalid Element IDs that are not encoded in the shortest-possible way. - Invalid Element IDs comprised of reserved values. - Invalid Element Data Size values that aren't allowed for the Element = type (e.g. a length of 1 byte for an `EbmlFloat` element) - Invalid Element Data Size values (e.g. extending the length of the = Element beyond the scope of the Parent Element; possibly triggering = access-out-of-bounds issues). - Very high lengths in order to force out-of-memory situations resulting = in a denial of service, access-out-of-bounds issues etc. - Missing Elements that are mandatory and have no declared default = value. - Usage of 0x00 octets in EBML Elements with a string type. - Usage of invalid UTF-8 encoding in EBML Elements of UTF-8 type (e.g. = in order to trigger access-out-of-bounds or buffer overflow issues). - Usage of invalid data in EBML Elements with a date type. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Best Regards, Dave Rice= From nobody Fri Feb 26 03:28:00 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44D461B29DC for ; Fri, 26 Feb 2016 03:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.968 X-Spam-Level: * X-Spam-Status: No, score=1.968 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 bgncto3gPPfe for ; Fri, 26 Feb 2016 03:27:57 -0800 (PST) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9296B1B29CB for ; Fri, 26 Feb 2016 03:27:57 -0800 (PST) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id BB648814FF for ; Fri, 26 Feb 2016 12:27:54 +0100 (CET) Received: from [127.0.0.1] (HSI-KBW-46-237-252-214.hsi.kabel-badenwuerttemberg.de [46.237.252.214]) by mailix ; Fri, 26 Feb 2016 12:27:54 +0100 To: cellar@ietf.org From: Tobias Rapp Organization: NOA GmbH Message-ID: <56D036BA.9000603@noa-archive.com> Date: Fri, 26 Feb 2016 12:27:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-PPP-Message-ID: <20160226112754.25747.49885@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com Archived-At: Subject: [Cellar] Display area clarification question X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 26 Feb 2016 11:27:59 -0000 Hello, when archiving SD material lines of the vertical blanking interval (VBI) are sometimes stored at the top of the frame. For PAL the typical stored size is 608x720 pixels with the bottom 576x720 area containing the actual image content. From looking at the Matroska specs this can be mapped into: PixelWidth = 720 PixelHeight = 608 PixelCropBottom = 0 PixelCropTop = 32 PixelCropLeft = 0 PixelCropRight = 0 I guess that the definition of the display area (DisplayWidth, DisplayHeight) applies to the pixel frame size *after* cropping? In that case it would be great if this would be made more explicit in the documentation of DisplayWidth and DisplayHeight. Also the defaults should reflect that (i.e. default DisplayWidth = PixelWidth - PixelCropLeft - PixelCropRight). Best regards, Tobias From nobody Fri Feb 26 07:42:27 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1C61A90A0 for ; Fri, 26 Feb 2016 07:42:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.792 X-Spam-Level: X-Spam-Status: No, score=0.792 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 GvEhI0BzHoH6 for ; Fri, 26 Feb 2016 07:42:25 -0800 (PST) Received: from liselle.bunkus.org (liselle.bunkus.org [IPv6:2a01:4f8:151:7310::105:1]) (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 4E37E1A9028 for ; Fri, 26 Feb 2016 07:42:25 -0800 (PST) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 4DB6F14C9A9E; Fri, 26 Feb 2016 16:42:22 +0100 (CET) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id EBCE714C9A8F for ; Fri, 26 Feb 2016 16:42:20 +0100 (CET) Received: by sweet-chili.local (Postfix, from userid 1000) id 5924FAE7F52; Fri, 26 Feb 2016 16:42:20 +0100 (CET) Date: Fri, 26 Feb 2016 16:42:20 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20160226154219.GB19798@bunkus.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3uo+9/B/ebqu+fSQ" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] Is there a way for a Block to indicate it contains a keyframe? X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 26 Feb 2016 15:42:26 -0000 --3uo+9/B/ebqu+fSQ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hey, a BlockGroup contains a key frame if it doesn't contain any ReferenceBlock elements. If it contains one ReferenceBlock then it's a P frame; with two ReferenceBlock elements it's a B frame. Kind regards, mosu --3uo+9/B/ebqu+fSQ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJW0HJbAAoJEHSvAK3y4yyFJasQAJj35rnnaoS+4dpwOYB8Xe8j x12VfGdgtLyR63lLJGq7qkzscDM2AP3od3KXSuL5vK7UM8hWYQ6kNOc0CYjdQifM 0RCJgiCLuGnf622Ax7tjas+QLf9W1gy4WuNqX/N8vJbg2oMWdqyQ1UyCet48Pqvh C226ZeeS9+1aR8Mklq+DAN/6AClAAdZdawlRs+goNksyMD9/fXXNzW5qPYllTZIt 0IT91v6hxXlZFVzPdAfFGnaaiRdYhBrHghmFj3z56gcHjoLNOtzcFlGxvk2AuYt0 QBLp7INJSPaoBRfuwaeHaAO4z0J6TGI2SD9vKw2flRwunt2eBTSnNYkakwzJ88xo awT36HJriOx/nGMJWi2KSPm9GzFodNdLkV1wUy8/53xdXTbqAUXXkkBAgmydQnUi YJbP3pcqLV2UYLkuxJO2Goksf+N1KbOqzmxaPhtpIrDSQa6RRoxUHWxqR/Ge/81h j1StSiKbhqDU9vb4+93SOW6PoUHbIhGQrMjKntS2ZBz50CvdYxwRsGBhjr2zSlNr kVE+SaykYhAJZxKJP7Nzu4cmafTXvkH7xDywRkjpW9EVSDEB/yca0nr602a7A7M9 hNjxVS8sV7D4YBtT6eT1iC/oHfKuBFcYwlYHN/tqwFiX0w/aWQfOf++pWcn9T59J 9oKvN+BSH+pFyGz0fOUb =AS9F -----END PGP SIGNATURE----- --3uo+9/B/ebqu+fSQ-- From nobody Sat Feb 27 13:02:20 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B01B1B2A60 for ; Sat, 27 Feb 2016 13:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.58 X-Spam-Level: * X-Spam-Status: No, score=1.58 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=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 TQo-SlUigbut for ; Sat, 27 Feb 2016 13:02:16 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A8101B2A5F for ; Sat, 27 Feb 2016 13:02:16 -0800 (PST) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:40912 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aZm0D-001UZO-Ci for cellar@ietf.org; Sat, 27 Feb 2016 16:02:16 -0500 From: Dave Rice Content-Type: multipart/alternative; boundary="Apple-Mail=_4AD2A008-3371-480E-99EC-43C7E828CC1C" Message-Id: <1687ED1D-AF44-4BC5-B1E5-89F2CD7440E7@dericed.com> Date: Sat, 27 Feb 2016 16:02:10 -0500 To: cellar@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 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 Ordering Guidelines X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 27 Feb 2016 21:02:18 -0000 --Apple-Mail=_4AD2A008-3371-480E-99EC-43C7E828CC1C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, I'm reviewing the documentation at = https://matroska.org/technical/order/index.html = and have some = questions and comments. The Order Guidelines say > Matroska only needs a few level 1 elements to be playable: Segment = Info, Track Info, Clusters. These elements have to be present in a = Matroska file. However, the specdata.xml lists Info as the only mandatory Level 1 = Matroska Element. =46rom specdata.xml it appears that a Matroska can be = valid even without Tracks or Clusters Level 1 Elements. So are Level 1 = Track and Cluster elements mandatory or not. Should there be a = distinction between a =E2=80=9Cplayable Matroska=E2=80=9D and a = =E2=80=9Cnon-playable Matroksa=E2=80=9D? This sentence: > All the other elements can be omitted although Cues (index) improve = the playback experience greatly. seems far too broad. I suspect that it should be "All the other Level 1 = elements...". Regarding, > After a Matroska file has been created it may still be edited. For = example chapters, tags or cover art attachments can be added. To do that = the Meta Seek needs to be updated and also some elements may be voided = or extended. These sentences imply that if Chapters, Tags, or Attachments are aded = then MetaSeek is mandatory, but is this true? Also IIRC MetaSeek doesn't = need to reference all Level 1 elements, so Attachments could be added = without creating or updating MetaSeek? Regarding, > When 1 Meta Seek Head is present, it should be the first element in a = Segment=E2=80=A6 Is this true? If MetaSeek is present a MetaSeek element MUST be the = first element of the Segment? This conflicts with the rules for CRC = which must also be first. Regarding: > The second Meta Seek is placed at the end and contains a lengthy list = of all Clusters (and not the other level 1 elements). To clarify if a second MetaSeek is used under Segment than it must be = the last element of the Segment? If the second MetaSeek is used it can = only reference Clusters and not any other level 1 element? I thought = that a second MetaSeek could be used to list any other type of level 1 = element that didn't fit in the first existing MetaSeek to avoid = rewrites. Which is true? Also is a third or greater MetaSeek element = ever allowed? Regarding > Placing the first Meta Seek Head other than the first position of the = Segment would make it a lot less useful So it must be the first = element of a Cluster. I think this should read "be the first element of a Cluster=E2=80=9D, = right? Regarding: > So the Cues should always be written after the Clusters. = However the Cues could also appear at the = front. I'm confused by the way this is written. In what cases should Cues be = written before or after Cluster? Overall the documentation seems to suggest that multiple different = elements all belong at the "end". Does the "end" mean "the last Level 1 = element" or simply "after the last Cluster element=E2=80=9D? Best Regards, Dave Rice= --Apple-Mail=_4AD2A008-3371-480E-99EC-43C7E828CC1C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi all,
I'm reviewing the documentation at https://matroska.org/technical/order/index.html and = have some questions and comments.

The = Order Guidelines say
Matroska only needs a few level 1 elements to be playable: = Segment Info, Track Info, Clusters. These elements have to be present in = a Matroska file.
However, the = specdata.xml lists Info as the only mandatory Level 1 Matroska Element. = =46rom specdata.xml it appears that a Matroska can be valid even without = Tracks or Clusters Level 1 Elements. So are Level 1 Track and Cluster = elements mandatory or not. Should there be a distinction between a = =E2=80=9Cplayable Matroska=E2=80=9D and a =E2=80=9Cnon-playable = Matroksa=E2=80=9D?

This= sentence:
All = the other elements can be omitted although Cues (index) improve the = playback experience greatly.
seems far = too broad. I suspect that it should be "All the other Level 1 = elements...".

Regarding,
After a Matroska file has been created it may still be = edited. For example chapters, tags or cover art attachments can be = added. To do that the Meta Seek needs to be updated and also some = elements may be voided or extended.
These sentences imply that if Chapters, Tags, or Attachments = are aded then MetaSeek is mandatory, but is this true? Also IIRC = MetaSeek doesn't need to reference all Level 1 elements, so Attachments = could be added without creating or updating MetaSeek?

Regarding,
When 1 Meta Seek Head is = present, it should be the first element in a = Segment=E2=80=A6
Is this true? If = MetaSeek is present a MetaSeek element MUST be the first element of the = Segment? This conflicts with the rules for CRC which must also be = first.

Regarding:
The second Meta Seek is placed at the end and contains a = lengthy list of all Clusters (and not the other level 1 = elements).
To clarify if a second = MetaSeek is used under Segment than it must be the last element of the = Segment? If the second MetaSeek is used it can only reference Clusters = and not any other level 1 element? I thought that a second MetaSeek = could be used to list any other type of level 1 element that didn't fit = in the first existing MetaSeek to avoid rewrites. Which is true? Also is = a third or greater MetaSeek element ever allowed?

Regarding
Placing the first Meta = Seek Head other than the first position of the Segment would make it a = lot less useful So it <em>must</em> be the first element of = a Cluster.
I think this should read = "be the first element of a Cluster=E2=80=9D, right?

Regarding:
So the Cues = <em>should</em> always be written after the Clusters. = However the <a href=3D"#cues_front">Cues could also appear at the = front</a>.
I'm confused by the = way this is written. In what cases should Cues be written before or = after Cluster?

Overall = the documentation seems to suggest that multiple different elements all = belong at the "end". Does the "end" mean "the last Level 1 element" or = simply "after the last Cluster element=E2=80=9D?

Best Regards,
Dave = Rice
= --Apple-Mail=_4AD2A008-3371-480E-99EC-43C7E828CC1C-- From nobody Sat Feb 27 13:09:56 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E4DB1B2AF5 for ; Sat, 27 Feb 2016 13:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no 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 MR93wTcIwVH7 for ; Sat, 27 Feb 2016 13:09:54 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D851B2AEB for ; Sat, 27 Feb 2016 13:09:53 -0800 (PST) Received: from cpe-74-71-131-9.nyc.res.rr.com ([74.71.131.9]:33907 helo=[10.0.1.3]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aZm7b-002DH2-DU; Sat, 27 Feb 2016 16:09:53 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Dave Rice In-Reply-To: Date: Sat, 27 Feb 2016 16:09:48 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <14EEDF97-8DFC-4147-863E-5142129C6D6A@dericed.com> References: <56C0D0D6.8000005@mediaarea.net> To: cellar@ietf.org X-Mailer: Apple Mail (2.3112) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: Jerome Martinez , Steve Lhomme Subject: Re: [Cellar] Constraints to use of Root Elements Was: Matroska SeekHead questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 27 Feb 2016 21:09:55 -0000 Hi all, > On Feb 14, 2016, at 2:14 PM, Dave Rice wrote: >=20 >> On Feb 14, 2016, at 2:09 PM, Jerome Martinez = wrote: >>=20 >> On 14/02/2016 19:08, Steve Lhomme wrote: >>> 2016-02-14 18:33 GMT+01:00 Dave Rice : >>> [...] >>>=20 >>>> Within the EBML Schema section I suggest adding: >>>>=20 >>>> "An EBML Schema MUST declare exactly one Element at Level 0 = (referred to as the Root Element) that MUST occur exactly once within an = EBML Document. The Root Element MUST be mandatory and MUST be defined to = occur exactly once. Note that the EBML and Void Elements may also occur = at Level 0 but are not considered to be Root Elements." >>>>=20 >>>> With this, I also suggest changing both EBML (Header) and Segment = in the Matroska spec to non-multiple. >>>>=20 >>>> This would mean: >>>>=20 >>>> invalid (multiple Root Elements) >>>>=20 >>>> >>>> >>>> >>>>=20 >>>> invalid (only header and no Root Element) >>>>=20 >>>> >>>>=20 >>>> valid (the usual MKV file) >>>>=20 >>>> >>>> >>>>=20 >>>> valid (two concatenated EBML Documents) >>>>=20 >>>> >>>> >>>> >>>> >>> If that's valid, then it's fine with me. Although it should be noted >>> that in that case the second EBML header is not taken in = consideration >>> and only the first one is used. That's to ensure the whole block of >>> concatenanted data can be handled just by knowing the first header. >>=20 >> but if the second EBML header is different, analysis is wrong. >> So if we say that only the first one EBML header should be read: >> - we must state that we can concatenate files only if they have the = same EBML header (so same Matroska version? I don't the reason we should = mandate that Matroska versions are same) >> - we must state that EBML header must be identical. >>=20 >> =46rom my point of view that does not make sense (why do we need to = duplicate the EBML header in that case). >>=20 >> I am ok for having EBML header before each segment, but in that case = the EBML header just before the segment should be considered as having = the right info (e.g. Matroska version). >>=20 >> I am afraid about such file: >> EBML header with Matroska v4 (from file 1) >> Segment conforming to Matroska v4 (from file 1) >> EBML header with Matroska v5 (from file 2) >> Segment conforming to Matroska v5 (from file 2) >>=20 >> In the case we have first EBML header as the reference header, we = parse second segment as Matroska v4 but it is actually v5. >=20 > Just a reminder that our current definition for EBML Stream (a = concatenation of EBML Documents) is: "An EBML Stream is a file that = consists of one or many EBML Documents that are concatenated together. = An occurrence of a Level 0 EBML Header marks the beginning of an EBML = Document." >=20 > The current definition doesn't include the presumptions that we're = currently discussing. The documentation doesn't prevent a variety of = EBML docTypes could be concatenated and streamed. >=20 >>> Also that you don't mix different DocType in the same file (or do we >>> want to allow that ?). Meaning could = also >>> be valid. >>=20 >> Is there any reason we don't want different DocType? (and = DocTypeReadVersion?) The issues within this thread are still open. To re-state the = conversation I think these questions are unresolved: - Can an EBML Document contain more than one Root Element? ie is this = structure valid or invalid as an EBML Document? Related to the above question, the =E2=80=9CSegment=E2=80=9D element is = currently allowed to repeat within an EBML Document. Should it be set to = non-repeat? When multiple EBML Documents are concatenated together it is considered = an EBML Stream, like this: \ EBML Document #1 \ / \ EBML Stream #1 \EBML Dcoument #2 / / / When there is more than one EBML Document within an EBML Stream, MUST = all the EBML Headers be identical? ie is it valid to stream webm and = matroska together or stream matroska v2 and matroska v4 together? Best Regards, Dave Rice From nobody Sun Feb 28 03:08:37 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854CB1B3432 for ; Sun, 28 Feb 2016 03:08:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.792 X-Spam-Level: X-Spam-Status: No, score=0.792 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 nOSmd2m8hm4C for ; Sun, 28 Feb 2016 03:08:34 -0800 (PST) Received: from liselle.bunkus.org (liselle.bunkus.org [IPv6:2a01:4f8:151:7310::105:1]) (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 E91BB1B3430 for ; Sun, 28 Feb 2016 03:08:33 -0800 (PST) Received: by liselle.bunkus.org (Postfix, from userid 1002) id DE2F61573AE1; Sun, 28 Feb 2016 12:08:30 +0100 (CET) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 531851573AD0 for ; Sun, 28 Feb 2016 12:08:28 +0100 (CET) Received: by sweet-chili.local (Postfix, from userid 1000) id A6BF5AEF81F; Sun, 28 Feb 2016 12:08:27 +0100 (CET) Date: Sun, 28 Feb 2016 12:08:27 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20160228110826.GC25696@bunkus.org> References: <56C0D0D6.8000005@mediaarea.net> <14EEDF97-8DFC-4147-863E-5142129C6D6A@dericed.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="B4IIlcmfBL/1gGOG" Content-Disposition: inline In-Reply-To: <14EEDF97-8DFC-4147-863E-5142129C6D6A@dericed.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] Constraints to use of Root Elements Was: Matroska SeekHead questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2016 11:08:35 -0000 --B4IIlcmfBL/1gGOG Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, I haven't replied to this yet as I'm unsure myself. I also don't think we've ever really talked about those points. We wanted to (maybe) allow files created by binary concatenation to be valid =E2=80=93 however, we nev= er wanted to require players to support such files. Meaning this might be OK (though I'm not in favor of it anymore, see below): We've never talked about using EBML Documents of differeing DocTypes in the same file, though. I'm also unsure whether or not we've ever talked about having multiple segments in the same file. We've only ever talked about linking segments that are located in different files via mechanisms like NextUID/PrevUID/SegmentUID for thinks like menu systems etc. > The issues within this thread are still open. To re-state the > conversation I think these questions are unresolved: > > - Can an EBML Document contain more than one Root Element? ie is this > structure valid or invalid as an EBML Document? > > > I'd prefer this to be invalid, mostly in order to keep required complexity in readers/players low. > Related to the above question, the =E2=80=9CSegment=E2=80=9D element is c= urrently > allowed to repeat within an EBML Document. Should it be set to > non-repeat? Following my wish above: ues, it should be set to non-repeat. > When multiple EBML Documents are concatenated together it is > considered an EBML Stream, like this: > \ EBML Document #1 \ > / \ EBML Stream #1 > \EBML Dcoument #2 / > / / A tougher decision. I also consider such files (and binary concatenation of files in general) to be a travesty that only increases the complexity of requirements for players a lot. There's also no real advantage to using both EBML Documents in the same file instead of two separate files. Therefore I'd vote for not allowing this either. > When there is more than one EBML Document within an EBML Stream, MUST > all the EBML Headers be identical? ie is it valid to stream webm and > matroska together or stream matroska v2 and matroska v4 together? Yeah, exactly=E2=80=A6 One of the reasons why I don't like this. It creates= all kinds of ambiguity, complexity, which in turn leads to more code paths that must be tested, and as such files are super rare those won't be tested a lot if at all. Drawbacks on top of drawbacks. Kind regards, mosu --B4IIlcmfBL/1gGOG Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJW0tUqAAoJEHSvAK3y4yyFi9gQALbmZHJ2xbiQgoliCQt8c7TZ GiICuQdOdfGYUzn53zE5WysUPGU8ZbLVqTiqqeyEiB7jTuAhwOGBJkrkdp0UoaBr jNTW+g9Db589DiVO6NPuiIwBJt7/kzvmJwqNgGCX5JIT1AWReL2PafuHHBKVcfYp SiMEmy++7UCCY9aVaz8KGDINkcxBOFfEDqfEYljdH9773reFwXaCptxLiDQxUMQW D8ryTQt8XzC0skRlASAu9zgXnxCTifAFi1ydtLz1DrVmr02t2GwsOBKfaUWgdrhl RzZyIY38KIiRfE86cz3I2mG6Bha0cD8KALiMFejDz/8Woi+z6zZzfPjajICSt5fL 5cSCRB7LDf1iogKBNFnWowQqvf8nEu/0+7d8VyJQmQojMPA5sx+j1+gvEng1iBof zzX2sJvv42oNKZ/nkCdqdXKSST4cYO8vJPsUe87B76YR6qwk47DbraT4idxBHG9P UIItAWN2tR459q/QA7Ht/lwlZCgHCAwxMr9IiZ7vwgn2JD5hp+GOF9//kFrIutjI EX8avAQtpnitctvEDjGSdebfHMPapQksAdW9Wa4JSyl7gsnvuJGnE/EdynlGhby8 ZZagYiHieROFfZc+FkfM7sCKqNXP4vvGZMdTdxJUv8QSt2XvJjQ1VNLrmiXlX7yH nbGbmpF8aZ+JGbJ4B6/5 =6onz -----END PGP SIGNATURE----- --B4IIlcmfBL/1gGOG-- From nobody Sun Feb 28 03:11:24 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47AF21B343A for ; Sun, 28 Feb 2016 03:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 wmbYSLfzIxrD for ; Sun, 28 Feb 2016 03:11:22 -0800 (PST) Received: from liselle.bunkus.org (liselle.bunkus.org [176.9.119.9]) (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 C86401B3438 for ; Sun, 28 Feb 2016 03:11:21 -0800 (PST) Received: by liselle.bunkus.org (Postfix, from userid 1002) id F21671573D20; Sun, 28 Feb 2016 12:11:19 +0100 (CET) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 77DF81573D09 for ; Sun, 28 Feb 2016 12:11:18 +0100 (CET) Received: by sweet-chili.local (Postfix, from userid 1000) id 039F5AEF860; Sun, 28 Feb 2016 12:11:17 +0100 (CET) Date: Sun, 28 Feb 2016 12:11:17 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20160228111117.GD25696@bunkus.org> References: <56D036BA.9000603@noa-archive.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="AbQceqfdZEv+FvjW" Content-Disposition: inline In-Reply-To: <56D036BA.9000603@noa-archive.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] Display area clarification question X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2016 11:11:23 -0000 --AbQceqfdZEv+FvjW Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hey, it's true that we've never clarified this. I'm not even sure whether or not we've had a consensus on how to interpret the values. For me PixelCrop* applies directly to the PixelWidth/Height values. And Display* determines the intended size for displaying the video after the cropping parameters have been applied. So yes, your interpretation is the one I'm favoring as well. Kind regards, mosu --AbQceqfdZEv+FvjW Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJW0tXVAAoJEHSvAK3y4yyFjrsQAL9duraw5K/T09i05vtVR9ui pkmdYLY8H3HUbms3hVhJ683pD9eTN89/7ZWodm/hJX+lf/ImKopFrGVt3kI6xsRD m7xKhF2Ot+N27kkYYr34kfJD5KpX8zFSY6gjjiECzatqt0soYEQ8T1e1iQcoE8NF ffa7W25mmopOZbOlPPdgATiD2a+aqbVtMT1Ix3UnSWvsBlNagHvbVjq9nMbL2T8A h06P4+WMRRMJ+XJW4nACxZWZSdH/JK8eQmMmEgzCOSRlD4wtPDPbglFtQ42RX1Fn rYVl+UI8xXZx2SWQvbtntx1rMlm3llQiUDwtm2Oq4P1LV5iwItTo1oRcnp8ciDai TIQBadN1kSTELrVeQH/h7UJSuzYP7aob8RtdZURKiWqv735ynWQO+QzkQG4Vt/m2 0OczrUgTU9XQ2DSiuo2ryavBtTa5gJiqQspZVn4K3+B8AiV3lUwxzcsB3n+wdMHU UMDg7Yyq6j76vyn0ktmOb5Jusbqyzxh8/PuqtzV0K58tYIzsPvO9LyJ6F/98ui8u UoFNNUXnduFy0mcF/TwhYQewJPuvxBFR+eQv+EhYVlUkp04LBFH5K9eDv7jes0+5 hzZ7P7z+WUYY4ENP2IG4ZMx7eyICAgxn644yyU27Kr/rBbW01UJYcHkguaph/vAC sB+cf0QjQGzbT7hxyQld =vmGc -----END PGP SIGNATURE----- --AbQceqfdZEv+FvjW-- From nobody Sun Feb 28 03:28:10 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F38EC1B347B for ; Sun, 28 Feb 2016 03:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 TslfjqKwUSRz for ; Sun, 28 Feb 2016 03:28:07 -0800 (PST) Received: from liselle.bunkus.org (liselle.bunkus.org [176.9.119.9]) (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 B3AD11B347A for ; Sun, 28 Feb 2016 03:28:06 -0800 (PST) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 5FF5C15764F2; Sun, 28 Feb 2016 12:28:04 +0100 (CET) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id 9FB8115764D2 for ; Sun, 28 Feb 2016 12:28:00 +0100 (CET) Received: by sweet-chili.local (Postfix, from userid 1000) id 278BAAEF8BF; Sun, 28 Feb 2016 12:28:00 +0100 (CET) Date: Sun, 28 Feb 2016 12:28:00 +0100 From: Moritz Bunkus To: cellar@ietf.org Message-ID: <20160228112759.GE25696@bunkus.org> References: <1687ED1D-AF44-4BC5-B1E5-89F2CD7440E7@dericed.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PGNNI9BzQDUtgA2J" Content-Disposition: inline In-Reply-To: <1687ED1D-AF44-4BC5-B1E5-89F2CD7440E7@dericed.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] Matroska Ordering Guidelines X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2016 11:28:10 -0000 --PGNNI9BzQDUtgA2J Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hey, > I'm reviewing the documentation at > https://matroska.org/technical/order/index.html > and have some > questions and comments. Great, thanks! Keep in mind that these guidelines have never meant to be read with the usual RFC terms regarding SHOULD, MUST, MAY etc. > The Order Guidelines say > > Matroska only needs a few level 1 elements to be playable: Segment > > Info, Track Info, Clusters. These elements have to be present in a > > Matroska file. Well, the focus was on something that can be played back. Files without Tracks and Clusters are valid, though, e.g. a file that only contains chapters. It cannot be played back but it may be used as an additional resource when playing other files or as an intermediate result during muxing operations. I don't want different requirements for =C2=BBplayable Matroska=C2=AB and =C2=BBnon-playable Matroska=C2=AB. Having Info mandatory and the rest not i= s as it should be. The guidelines should be re-worked considerably to reflect that. > This sentence: > > All the other elements can be omitted although Cues (index) improve > > the playback experience greatly. > > seems far too broad. I suspect that it should be "All the other Level > 1 elements...". True. > Regarding, > > After a Matroska file has been created it may still be edited. For > > example chapters, tags or cover art attachments can be added. To do > > that the Meta Seek needs to be updated and also some elements may be > > voided or extended. > > These sentences imply that if Chapters, Tags, or Attachments are aded > then MetaSeek is mandatory, but is this true? Also IIRC MetaSeek > doesn't need to reference all Level 1 elements, so Attachments could > be added without creating or updating MetaSeek? No, a MetaSeek is not required in the sense that it MUST be present. The sentence is a vague description of the process an editor implements so that a player can always find the new or modified resources. For example: if all attachments, chapters, tags are located before the first cluster then no MetaSeek element is required at all. A player that reads from the start to the first cluster can already find all important level 1 elements without seeking. If a MetaSeek element is present pointing to an already existing Attachments element and that Attachments element is relocated then, however, the editor MUST update the exiting entry in the MetaSeek element to reflect the new position. Another example. We only require players to be able to find elements in two ways: 1. By reading linearly from start to the first cluster and using all elements found in the process (no seeking) 2. By using the information in all MetaSeek elements found by the method described in 1. (limitation: a player only has to follow one level of MetaSeek-to-MetaSeek link, no more). We don't have similar requirements on editors, but what an editor usually has to do in order for the elements to be found by players derives directly from the requirements for players. So an editor can write Attachments at the end of the file and not include them in a MetaSeek. So far, so good. But it cannot expect all players to find them in such a situation. > Regarding, > > When 1 Meta Seek Head is present, it should be the first element in > > a Segment=E2=80=A6 > > Is this true? If MetaSeek is present a MetaSeek element MUST be the > first element of the Segment? This conflicts with the rules for CRC > which must also be first. Think of it more along the lines of =C2=BBshould be the first level 1 element in a segment=C2=AB. The intention is that all level 1 elements can = be found reading as few bytes as possible. > Regarding: > > The second Meta Seek is placed at the end and contains a lengthy > > list of all Clusters (and not the other level 1 elements). > > To clarify if a second MetaSeek is used under Segment than it must be > the last element of the Segment? Nope. =C2=BBAt the end=C2=AB simply behinds =C2=BBafter the clusters=C2=AB = which is usually somewhere within the vicinity of the actual end of the file. The simple reason is that it isn't known in advance how big such a MetaSeek element will become. Therefore it doesn't make sense to reserve arbitrary amounts of space before the clusters for this list. The same applies to the Cues. > If the second MetaSeek is used it can only reference Clusters and not > any other level 1 element? Nope, but that's usually how it's done. Remember, guidelines, not hard rules. This is not a hard rule. For example, mkvpropedit or my GUI's header editor will write MetaSeek elements somewhere at the end referencing Attachments, Tracks etc. in certain situations if it cannot place such a bit MetaSeek before the clusters. In that case a minimal MetaSeek element is written before the clusters pointing to that MetaSeek element behind the clusters. That's OK =E2=80=93 it's also a situation that an editor may find itself in (modify only a few bytes of an existing file), but not usually a muxer which can reserve enough space before the clusters (it re-writes the whole file anyway). > Regarding > > Placing the first Meta Seek Head other than the first position of > > the Segment would make it a lot less useful So it must be > > the first element of a Cluster. > > I think this should read "be the first element of a Cluster=E2=80=9D, rig= ht? You mean =C2=BBSegment=C2=AB, I guess ;) Yes, =C2=BBCluster=C2=AB is simply= wrong in the original sentence. > > So the Cues should always be written after the > > Clusters. However the Cues could also appear > > at the front. > I'm confused by the way this is written. In what cases should Cues be > written before or after Cluster? As I've said above Cues can become arbitrarily large and are therefore often written at the end so that a muxer doesn't have to reserve huge amounts of space at the front. However, you can create a program that re-writes and optimizes a Matroska file. In that case it already knows how many Cues there will be and how much space is required for them. It can write the Cues at the start. > Overall the documentation seems to suggest that multiple different > elements all belong at the "end". Does the "end" mean "the last Level > 1 element" or simply "after the last Cluster element=E2=80=9D? The latter, =C2=BBafter the last Cluster element=C2=AB. Kind regards, mosu --PGNNI9BzQDUtgA2J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJW0tm/AAoJEHSvAK3y4yyFbqMP/0aDkx6tcGXgUh1Y/AQqb13h J9dfzxuWsG0ae/IslkbBkMG49vMRPTdi+8zmJApKlUgIBP6GN+FQyANrJj20fS05 45YH2XZ6LebAlKvgucKa+rjVDnCdklxLqHk7UZfvNN87iZ8tme4NHEPc3P+ie2jI xQUe6OR7L/THhd9MQ4oIikjMpvnfx/P6wQk8ZiSSRdmqQYTMbM/dYR7An6pODLRt +N+BmtEXdTVq17h89qenw/i2b8fSzzW3kD0xy5/VFwSKJAyCDJ5IrY1HAv80nvvL qbzl9cUYUjeu1EUYF0PXOUTHRY7Q0TnMaf7O0gSlKjn40haLrQM2BkK/VRL9zEpg MTW/pW9K6TyKvRSMpHkNscXNjSPs0NGujy5BiokeT9fPv1SwXBdjWzic5K+gJY9b e/gukHoG2GTinxymGY+TC+U/7jcw10kmMezD1gBBbXOG3N8/HYRGg9+cEQuxYAi7 L+qeI0tdeinyJy7/krwH3eQK8tbL0mIh+OBQ9m8GjrzjxHv3E/NiHKF+rfM67QDL MaAPM5670lFO/C5ojibngaiT1dIMuVT/1uocqFOibpPvEgPW2pQFcEnq3h5VYWoZ QQCCkzpl4kXn4mkXQbvppzzEsXzZMXaMSKnjTwBL/nKullziJaxpbEz+YWQCQG3F I2kMZWKRHIUI/hwWJh5t =shBC -----END PGP SIGNATURE----- --PGNNI9BzQDUtgA2J-- From nobody Sun Feb 28 06:14:46 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A14F1B36D1 for ; Sun, 28 Feb 2016 06:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.888 X-Spam-Level: X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622] autolearn=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 7XCaSaBDtH30 for ; Sun, 28 Feb 2016 06:14:44 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0221B36D0 for ; Sun, 28 Feb 2016 06:14:44 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id k196so113829160vka.0 for ; Sun, 28 Feb 2016 06:14:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=PKT52pvokrBQ61pf+KgEJB5+H1hVN8hZzGV7KLYiN+E=; b=hszAfsAaUo9DRPIXKrWUQhXQ3QV7UZg1szpiRwIuqNQfBL5q4glshP1PlKkPQ8Gzv6 hHHn8ovZXK2B+fD3TN6i+ABvi/mOu5DYP8+cxyx3N+YngA2PvD0tEPbsMxgb9a0h9efp GaMRFJOl6hi+0oe0IHzAI6pt8DjwJnWfzqgsm+8ule2OfKF4uBJznbyX+SUU2sksWRti 7PCezTiiznQES2ZYFHBnTxwqEswc80bpFVDjWrF8nYNiFHl+8eti1daHI17DozjN/3+i o3+kqifGQnda0KaJG8BnGKjT+14mOe+HunJpAmO3evFLlJYuM+OWw/CuNQ8HJ1dwVDhJ kXCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=PKT52pvokrBQ61pf+KgEJB5+H1hVN8hZzGV7KLYiN+E=; b=GUlkB96LSnHlFIqtGTLoSoghReVp9d1z5VR0PoCVIHKJbRwPUN3eAlcQElafxRBcSE vLbFT1QTevZqrYwXzAV70VEzJB4EBIUbKAE068tHuECZFh3IRY5VhoLSgSYKEmaJz7Mo wYjl5PLf6QNR0QEHWUJpXol3RtQqXA8UZLhgRgg7cdcUMr6Zmg2Xq5zG1yEYlvEwAz04 CvdEW2ihVB2xwa1pQkW+DUIpuxEg36YVmI6K7lmZ78/aeRIXW5rGUJDSlFy61xaR8f/Y LeK2s76imOVOjNH/dMXx4ZQvUwrIaZxbDyCBYyPrsuY4yowQnk7H5RL6DmXgUtvBdrfM 3FMg== X-Gm-Message-State: AD7BkJKkK8sVEsCjMd+zS7b4HpZb/7TPwT7iPkuyz22u8dWThfGkHdWcH7zU1pRle0x9D8+yGWLeVBO4k/uNEA== MIME-Version: 1.0 X-Received: by 10.31.132.140 with SMTP id g134mr8253185vkd.94.1456668883586; Sun, 28 Feb 2016 06:14:43 -0800 (PST) Received: by 10.176.66.134 with HTTP; Sun, 28 Feb 2016 06:14:43 -0800 (PST) In-Reply-To: References: Date: Sun, 28 Feb 2016 15:14:43 +0100 Message-ID: From: Steve Lhomme To: Nithin Mathew Kurien Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Dave Rice , cellar@ietf.org Subject: Re: [Cellar] expressing a float in text X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2016 14:14:46 -0000 2016-02-18 16:35 GMT+01:00 Nithin Mathew Kurien : > Yes, the notations would be different. Single floats would have 6 > hexadecimal digits in the mantissa, whereas double floats would have 13. = I > would suggest defining all EBML floats as doubles, because of the greater > range and precision available. Since Matroska floating point numbers can be double precision, a program handling Matroska has to work in double-precision (or lose some accuracy with floats). So I think it's ok to assume that floats are defined as double-precision in the specs. Also, do we allow NaN as a possible default value ? > Thanks and regards, > Nithin > > On Mon, Feb 15, 2016 at 12:41 AM, Dave Rice wrote: >> >> >> On Feb 13, 2016, at 2:24 PM, Nithin Mathew Kurien >> wrote: >> >> Hi, >> >> Not sure if it is suitable in this context, but C99 supports writing >> floats accurately in hexadecimal notation >> (http://www.exploringbinary.com/hexadecimal-floating-point-constants/). = The >> advantage of hexadecimal notation is that values can be represented >> accurately, unlike representions like 1.67e-3, which will result in roun= ding >> errors when converted from decimal to the native binary form. With a C99 >> compiler like GCC, we can output the hexadecimal form of any float. >> >> double num =3D 1.55e1; >> printf("%a", num); >> >> would output >> >> 0x1.fp3 >> >> which is equal to (1 + 15/16) * 2^3. >> >> >> For values such as 0.0 and 1.0, wouldn't the C99 notation be different >> depending on if the float is expressed as a single or double? Currently = an >> EBML float could be either 4 or 8 bytes and the choice of float length i= s >> not part of the element definition. If we use C99 notation we may be >> implying whether the float is single or double and should consider sayin= g so >> in the definition. >> Dave >> >> Thanks and regards, >> Nithin >> >> >> On Sun, Feb 14, 2016 at 12:20 AM, Dave Rice wrote: >>> >>> To accommodate the float range expressions in Frank=E2=80=99s color wor= k, I=E2=80=99m >>> expanding the =E2=80=9CExpression of range=E2=80=9D [1] section to acco= mmodate floats >>> (currently it only discusses signed and unsigned integers). Frank=E2=80= =99s use of >>> float ranges are quite simple, such as 0.0 to 1.0; however, in defining= a >>> method to document a float range, I think the definition should work fo= r any >>> possible float value. >>> >>> Is there an standard document to point to for how to represent a float >>> value as text? i.e. I=E2=80=99m familiar with float values in text such= as 3.88E-4 >>> but where it this style of expression defined? >>> >>> Best Regards, >>> Dave Rice >>> >>> [1] >>> https://github.com/Matroska-Org/ebml-specification/blob/master/specific= ation.markdown#expression-of-range >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >> >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >> >> > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 28 06:22:15 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 422531A0019 for ; Sun, 28 Feb 2016 06:22:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 J9sY-WE8CyvP for ; Sun, 28 Feb 2016 06:22:13 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C401A0015 for ; Sun, 28 Feb 2016 06:22:12 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id e6so112859400vkh.2 for ; Sun, 28 Feb 2016 06:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=Z8cZhSe/SD3VZOPmYYy/rX8xOESl4YTQilFEaKyXC7c=; b=Asz3jjvN3L47oQqEEhgnQEJre99YftL4VN0cGBBnaSKMuVVEdhvD95qErgNUVORBNY kuiJn3fO+eKAW4AB3YJ9a6FZfXJrDfn90EDi9tG6r4r+AQEMBkT/+aQ0AnQqZ6n3v0u8 GRB7u6uSkCQoE/eH36SaFZCevT5BzzcEjzuPCS4y2SQy0db4+orIFmUSe7ZshoYAN0z3 qBmtRYtz0AOGDITM5+FwWxnaM/rFh9UN754RNTINlH2cNHJBq4ARxCQz1GbN1u5cFYXq 1vbixflkYBRYmf3sep3Ilbo91kjp9WWjrrfiL7unJuRefhcm3gkP/50QL+z7ONTmNOJK sR0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=Z8cZhSe/SD3VZOPmYYy/rX8xOESl4YTQilFEaKyXC7c=; b=HeGnNcQS7JlRthD6vCThQFHvmjr8JbHTPoMFWzXIKufPKnaBlL+ofgwyAyeKuaiXIk QxNx/8dlDedwvcroSXKyFe6MlJEayF6QLKBxX34SdvT4EvrN3Kg/7hgu+pJ4xcIaANWa 08WfkXvmvPtQGK8BBbpFzXlOjQ60cQ9uwZrvb8qYLrMTgwXaSmzorMOhnyuahQI2pC/N w91JQN5fwauWAPJDwjHAzGvcoKavW6E70tPTQO64R8mJ6xhhbjHMyuSiOxVkAzxDKO1p S5MrcvJjel//r5RIU10vlnj2oRKkLMHuSmvRz0LkfI1uvwl74ZSF+ox1Gwa4j1kErHiu PFkg== X-Gm-Message-State: AD7BkJI9wEQHO3Q3zsW30R33UIvNyz8hTAyVjjlbTb7n2mnGl8ePDzagznnXhxGq2c96a5jxngys8WBh4hu/Yg== MIME-Version: 1.0 X-Received: by 10.31.179.146 with SMTP id c140mr6584206vkf.50.1456669331979; Sun, 28 Feb 2016 06:22:11 -0800 (PST) Received: by 10.176.66.134 with HTTP; Sun, 28 Feb 2016 06:22:11 -0800 (PST) In-Reply-To: <56C0D0D6.8000005@mediaarea.net> References: <56C0D0D6.8000005@mediaarea.net> Date: Sun, 28 Feb 2016 15:22:11 +0100 Message-ID: From: Steve Lhomme To: Jerome Martinez Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Constraints to use of Root Elements Was: Matroska SeekHead questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2016 14:22:14 -0000 2016-02-14 20:09 GMT+01:00 Jerome Martinez : > On 14/02/2016 19:08, Steve Lhomme wrote: >> >> 2016-02-14 18:33 GMT+01:00 Dave Rice : >> [...] >> >>> Within the EBML Schema section I suggest adding: >>> >>> "An EBML Schema MUST declare exactly one Element at Level 0 (referred t= o >>> as the Root Element) that MUST occur exactly once within an EBML Docume= nt. >>> The Root Element MUST be mandatory and MUST be defined to occur exactly >>> once. Note that the EBML and Void Elements may also occur at Level 0 bu= t are >>> not considered to be Root Elements." >>> >>> With this, I also suggest changing both EBML (Header) and Segment in th= e >>> Matroska spec to non-multiple. >>> >>> This would mean: >>> >>> invalid (multiple Root Elements) >>> >>> >>> >>> >>> >>> invalid (only header and no Root Element) >>> >>> >>> >>> valid (the usual MKV file) >>> >>> >>> >>> >>> valid (two concatenated EBML Documents) >>> >>> >>> >>> >>> >> >> If that's valid, then it's fine with me. Although it should be noted >> that in that case the second EBML header is not taken in consideration >> and only the first one is used. That's to ensure the whole block of >> concatenanted data can be handled just by knowing the first header. > > > but if the second EBML header is different, analysis is wrong. > So if we say that only the first one EBML header should be read: > - we must state that we can concatenate files only if they have the same > EBML header (so same Matroska version? I don't the reason we should manda= te > that Matroska versions are same) > - we must state that EBML header must be identical. > > From my point of view that does not make sense (why do we need to duplica= te > the EBML header in that case). > > I am ok for having EBML header before each segment, but in that case the > EBML header just before the segment should be considered as having the ri= ght > info (e.g. Matroska version). > > I am afraid about such file: > EBML header with Matroska v4 (from file 1) > Segment conforming to Matroska v4 (from file 1) > EBML header with Matroska v5 (from file 2) > Segment conforming to Matroska v5 (from file 2) I think we need more precision on the way compatible Doctypes can be handled. It may be per format and not a rule set for all EBML documents. For example mixing Matroska v1, v2 and v3 is fine as long as you know beforehand you need v3 compatibility (so maybe it's ok only if it appears first). You could also mix WebM and Matroska Doctypes in the real world and still be okay. IMO at the EBML level (not knowing semantics) there's no reason to restrict mismatching Doctypes. The thing we should restrict is whether there's always an EBML header before an EBML content. IMO that should be mandatory. > In the case we have first EBML header as the reference header, we parse > second segment as Matroska v4 but it is actually v5. > > >> Also that you don't mix different DocType in the same file (or do we >> want to allow that ?). Meaning could also >> be valid. > > > Is there any reason we don't want different DocType? (and > DocTypeReadVersion?) > > J=C3=A9r=C3=B4me > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 28 06:27:56 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EBBE1A004E for ; Sun, 28 Feb 2016 06:27:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 mnw7CPK6jjSr for ; Sun, 28 Feb 2016 06:27:54 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D081A004D for ; Sun, 28 Feb 2016 06:27:54 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id e6so112921183vkh.2 for ; Sun, 28 Feb 2016 06:27:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=5ZnzSul9sHyZz3Ks0E07zlcvDSOOzSNEjlzv3o6TAjc=; b=XIXOzKQLJbc0LxoXi6FfgHOZkSQUQUubrvy3G8Ugz+ohyShVndAGhrYfWuX5FzFkuj 0ZlAuDa63cocg3UHsqheSCmyUrmCdbwyb+iwQC1dXX4R0DPS5Z1WdyyRi3q5NrzCvjUa x7s/VKwUttx3okUrmWbCRosBsh6+C9goHb7ZYknAArSEjWzFdBA+VvUjp6KtD6JIJxW6 jXi6ZluujNSLNcE1oTvX7qDnLNdcSEgRRGGMWeXMlpnepTzwcoNoJHuMfQViuqUrqUAS CagvsGzGt6jZMHM92lkUwO2cjolGQ2op7rYRG7Z4Gi1v25Witq3UY4Gab2O9xSAGxI0j XeBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=5ZnzSul9sHyZz3Ks0E07zlcvDSOOzSNEjlzv3o6TAjc=; b=A/DdUeqiJMDxhETT3LbpWogPP5ATyYGSu26AdYTwkGD19+5/tUqCrQ0T0wkp3Ua7aB te0UOQoVNWLKTgSfL1+GwdA77lI4rbW9GdgqWA2DLSj21l5F6Rnp3xNf/cVl/fGAxN0v apP5dR0pCTOPksTvSQNxclxgXqnxuMnNCysKcLXH+M3duWJU6H8W/VPoPsA//DWEQ032 +RGuq/9PDr7i8nV003794Ua168xQ8+rmQ2QqfhN0Up8KGJ4TzE8YePfAUmvfVCtgxtC1 7Z3dXgYHwxaMfkwFGsFfw/FZuv9Q5eJIPl20+NViEX1+rIbOzDvIaa9YCIouZrcY1FNG Y8Vg== X-Gm-Message-State: AD7BkJIkjekasYERm4d4XZXUZGFOZ6TfcXik0OFuLolteqy2OkPHX+1J7iA1HgoYmq0c3dBxAle8jbSultvKNg== MIME-Version: 1.0 X-Received: by 10.31.158.204 with SMTP id h195mr8138030vke.147.1456669673273; Sun, 28 Feb 2016 06:27:53 -0800 (PST) Received: by 10.176.66.134 with HTTP; Sun, 28 Feb 2016 06:27:53 -0800 (PST) In-Reply-To: <20160228110826.GC25696@bunkus.org> References: <56C0D0D6.8000005@mediaarea.net> <14EEDF97-8DFC-4147-863E-5142129C6D6A@dericed.com> <20160228110826.GC25696@bunkus.org> Date: Sun, 28 Feb 2016 15:27:53 +0100 Message-ID: From: Steve Lhomme To: Moritz Bunkus Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Constraints to use of Root Elements Was: Matroska SeekHead questions X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2016 14:27:55 -0000 2016-02-28 12:08 GMT+01:00 Moritz Bunkus : > Hey, > > I haven't replied to this yet as I'm unsure myself. I also don't think > we've ever really talked about those points. We wanted to (maybe) allow > files created by binary concatenation to be valid =E2=80=93 however, we n= ever > wanted to require players to support such files. > > Meaning this might be OK (though I'm not in favor of it anymore, see > below): > > > > > > > We've never talked about using EBML Documents of differeing DocTypes in > the same file, though. > > I'm also unsure whether or not we've ever talked about having multiple > segments in the same file. We've only ever talked about linking segments > that are located in different files via mechanisms like > NextUID/PrevUID/SegmentUID for thinks like menu systems etc. > >> The issues within this thread are still open. To re-state the >> conversation I think these questions are unresolved: >> >> - Can an EBML Document contain more than one Root Element? ie is this >> structure valid or invalid as an EBML Document? >> >> >> > > I'd prefer this to be invalid, mostly in order to keep required > complexity in readers/players low. > >> Related to the above question, the =E2=80=9CSegment=E2=80=9D element is = currently >> allowed to repeat within an EBML Document. Should it be set to >> non-repeat? > > Following my wish above: ues, it should be set to non-repeat. > >> When multiple EBML Documents are concatenated together it is >> considered an EBML Stream, like this: > >> \ EBML Document #1 \ >> / \ EBML Stream #1 >> \EBML Dcoument #2 / >> / / > > A tougher decision. I also consider such files (and binary concatenation > of files in general) to be a travesty that only increases the complexity > of requirements for players a lot. There's also no real advantage to > using both EBML Documents in the same file instead of two separate > files. I can see advantages when transmitting some complex presentation (linked segments, menus, etc). It's easier to send one file over dropbox or on/to your phone rather than download and manage a bunch of files that you always have to make sure to keep together. Dealing with folders or RARs/TARs on phone is not exactly easy and very prone to errors. Another advantage, as seen above is that we can enforce some rules of what segments are allowed to be tied together. There's also no naming or ordering issues. They appear in the concatenation in the most logical order. > Therefore I'd vote for not allowing this either. > >> When there is more than one EBML Document within an EBML Stream, MUST >> all the EBML Headers be identical? ie is it valid to stream webm and >> matroska together or stream matroska v2 and matroska v4 together? > > Yeah, exactly=E2=80=A6 One of the reasons why I don't like this. It creat= es all > kinds of ambiguity, complexity, which in turn leads to more code paths > that must be tested, and as such files are super rare those won't be > tested a lot if at all. Drawbacks on top of drawbacks. > > 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 Feb 28 06:31:14 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE641A009B for ; Sun, 28 Feb 2016 06:31:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 wo3S6gVcyFqS for ; Sun, 28 Feb 2016 06:31:12 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1D01A0098 for ; Sun, 28 Feb 2016 06:31:12 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id e185so113063326vkb.1 for ; Sun, 28 Feb 2016 06:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=IDKm7SLUCCaGk7zmu1H34Cj8BK0HkobGWO7pshGL0Uw=; b=lUyAFIBznSpjZ6n66+10ogPPmDC8UrDqrkMvNQw15YOImbFI18qKilpqjIYWYDsYQ1 KngfPoQKcLt/mB2ekHblQmgsubcVE7Ph+15I4WIlqvxwQ8+xbmiiWb/RIG3mBG4H9Z/G J/j906CEEmh0c+GH8XJfP9eeFntISh0xCxYS4P2hqe6HHfwSZ5PYseoz7raJGIEHKx3s 74UK2fELFIkzu14jZOAyCz9ISQsjcuWvAP4RTvHekk40dId96c10Xoluaxwg1e5Ir3/Y EdJaOPElV/892iGEmKk2KKmVPwEzOZIzAQUk1Ja+15DJDEEjGgv3Po2fpoyKbFTgxEzM xWAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=IDKm7SLUCCaGk7zmu1H34Cj8BK0HkobGWO7pshGL0Uw=; b=mxdcbghdjzT0IWnsuvMyJolBvyiBtzD6n2RgSEHLBfCFcEO4p2qUgLtCetGjtcrgdu ueydtwtPAXaAxCisj7CwwqdutKY+4IStGO/QUoIct3H0PoUhjJ7HbayLhYqr2bDZHmY9 ttCIRqfC2mGBS/r4gxqcbvs0j9LPDyaEG1N6q1UGsC325iN46i/lkV96PMcx5e1eoPpr lO03AADrUu3SEpb3BGSxFFbZuisfn1q7lPiy1bJ+4qbXBq2zd6BPwvleM1SIYrT7FBCm BYXZKJ+bU5lI5t7+Cmp0tbKHwM7NlmTa2fxWW2af36Z6RLeKntKWE5egVReS6+2Hb2Bl H55g== X-Gm-Message-State: AD7BkJI6nfFJKQpXO8OoTUYJB5+DX/hABWX8Yo+3RqWFKLrOCK98tNP5TwQhf6AEdhJXuCvYL/dEoQSU7kGMkA== MIME-Version: 1.0 X-Received: by 10.31.166.200 with SMTP id p191mr8031658vke.53.1456669871489; Sun, 28 Feb 2016 06:31:11 -0800 (PST) Received: by 10.176.66.134 with HTTP; Sun, 28 Feb 2016 06:31:11 -0800 (PST) In-Reply-To: <20160228111117.GD25696@bunkus.org> References: <56D036BA.9000603@noa-archive.com> <20160228111117.GD25696@bunkus.org> Date: Sun, 28 Feb 2016 15:31:11 +0100 Message-ID: From: Steve Lhomme To: Moritz Bunkus Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Display area clarification question X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2016 14:31:13 -0000 2016-02-28 12:11 GMT+01:00 Moritz Bunkus : > Hey, > > it's true that we've never clarified this. I'm not even sure whether or > not we've had a consensus on how to interpret the values. Correct, but trust me, it was in my head the whole time ;) Although the name PixelCrop* imply that it happens on Pixel*, unlike Display* values. > For me PixelCrop* applies directly to the PixelWidth/Height values. And > Display* determines the intended size for displaying the video after the > cropping parameters have been applied. So yes, your interpretation is > the one I'm favoring as well. Yes, the cropping happens on the pixels, the display size are just how to display those remaining pixels. > Kind regards, > mosu > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > -- Steve Lhomme Matroska association Chairman From nobody Sun Feb 28 06:49:10 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 779AF1A0102 for ; Sun, 28 Feb 2016 06:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.745 X-Spam-Level: *** X-Spam-Status: No, score=3.745 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FF_IHOPE_YOU_SINK=2.166, SPF_NEUTRAL=0.779] autolearn=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 M1mwb2B5BwpX for ; Sun, 28 Feb 2016 06:49:06 -0800 (PST) Received: from s172.web-hosting.com (s172.web-hosting.com [68.65.122.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B55C1A00FF for ; Sun, 28 Feb 2016 06:49:06 -0800 (PST) Received: from [172.56.34.154] (port=61174 helo=[100.185.153.57]) by server172.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1aa2ee-002uK6-Es; Sun, 28 Feb 2016 09:49:06 -0500 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Dave Rice X-Mailer: iPhone Mail (13A452) In-Reply-To: Date: Sun, 28 Feb 2016 09:49:02 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Steve Lhomme X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Cc: cellar@ietf.org, Nithin Mathew Kurien Subject: Re: [Cellar] expressing a float in text X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2016 14:49:08 -0000 > On Feb 28, 2016, at 9:14 AM, Steve Lhomme wrote: >=20 > 2016-02-18 16:35 GMT+01:00 Nithin Mathew Kurien := >> Yes, the notations would be different. Single floats would have 6 >> hexadecimal digits in the mantissa, whereas double floats would have 13. I= >> would suggest defining all EBML floats as doubles, because of the greater= >> range and precision available. >=20 > Since Matroska floating point numbers can be double precision, a > program handling Matroska has to work in double-precision (or lose > some accuracy with floats). So I think it's ok to assume that floats > are defined as double-precision in the specs. I don't think any existing MKV floats are defined as single or double precis= ion. The element definitions just label them as 'float' and in the context o= f EBML a float can mean either 0, 4, or 8 bytes. Is there reason to refine the specs to define elements as particular types o= f floats? > Also, do we allow NaN as a possible default value ? I don't think so. Nitpicky, but do you have a sentence or reference to defin= e what NaN signifies. Dave >> Thanks and regards, >> Nithin >>=20 >>> On Mon, Feb 15, 2016 at 12:41 AM, Dave Rice wrote: >>>=20 >>>=20 >>> On Feb 13, 2016, at 2:24 PM, Nithin Mathew Kurien >>> wrote: >>>=20 >>> Hi, >>>=20 >>> Not sure if it is suitable in this context, but C99 supports writing >>> floats accurately in hexadecimal notation >>> (http://www.exploringbinary.com/hexadecimal-floating-point-constants/). T= he >>> advantage of hexadecimal notation is that values can be represented >>> accurately, unlike representions like 1.67e-3, which will result in roun= ding >>> errors when converted from decimal to the native binary form. With a C99= >>> compiler like GCC, we can output the hexadecimal form of any float. >>>=20 >>> double num =3D 1.55e1; >>> printf("%a", num); >>>=20 >>> would output >>>=20 >>> 0x1.fp3 >>>=20 >>> which is equal to (1 + 15/16) * 2^3. >>>=20 >>>=20 >>> For values such as 0.0 and 1.0, wouldn't the C99 notation be different >>> depending on if the float is expressed as a single or double? Currently a= n >>> EBML float could be either 4 or 8 bytes and the choice of float length i= s >>> not part of the element definition. If we use C99 notation we may be >>> implying whether the float is single or double and should consider sayin= g so >>> in the definition. >>> Dave >>>=20 >>> Thanks and regards, >>> Nithin >>>=20 >>>=20 >>>> On Sun, Feb 14, 2016 at 12:20 AM, Dave Rice wrote: >>>>=20 >>>> To accommodate the float range expressions in Frank=E2=80=99s color wor= k, I=E2=80=99m >>>> expanding the =E2=80=9CExpression of range=E2=80=9D [1] section to acco= mmodate floats >>>> (currently it only discusses signed and unsigned integers). Frank=E2=80= =99s use of >>>> float ranges are quite simple, such as 0.0 to 1.0; however, in defining= a >>>> method to document a float range, I think the definition should work fo= r any >>>> possible float value. >>>>=20 >>>> Is there an standard document to point to for how to represent a float >>>> value as text? i.e. I=E2=80=99m familiar with float values in text such= as 3.88E-4 >>>> but where it this style of expression defined? >>>>=20 >>>> Best Regards, >>>> Dave Rice >>>>=20 >>>> [1] >>>> https://github.com/Matroska-Org/ebml-specification/blob/master/specific= ation.markdown#expression-of-range >>>> _______________________________________________ >>>> Cellar mailing list >>>> Cellar@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cellar >>>=20 >>>=20 >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >>=20 >>=20 >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar From nobody Sun Feb 28 06:58:24 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CB81A0178 for ; Sun, 28 Feb 2016 06:58:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 8jy6S-IUnsIQ for ; Sun, 28 Feb 2016 06:58:20 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366981A016E for ; Sun, 28 Feb 2016 06:58:20 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id c3so113357074vkb.3 for ; Sun, 28 Feb 2016 06:58:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=N7nG9U5PnGVUHxzVDWkIpbNUzNtr1aYIYVhGBMVmvJ0=; b=hpCVck7Vh+eKdQIKck5yTfrBFBCk5JufxwaTw2dSUS6BNvA/iYmJleTQkLjYt5LgRU X9+wh2dwKm9FNb6Xjrdl18kT0CHQoA4ojIip/Qf8Xqt38yNn1xNVjCzRLl5hI/Z2c/Gb rMo+OcaFlsgahhcXdgi2nb/udoVjAeAnlikyGmdqVmNkUkBCCE4S08g2kGhjJZU17cZJ 16RvN/vmRAY0gZHB9qFIf808pSOKIwrcYd73d95FxtzdDs3HRBxgykXpdvh3VxiQ2pFY WupcIcTunSIX33phYVx22XCJcDteAnA1tco8EyV+2qcbXxc8j2LglE2aFFIzwQIT8/x9 b0zA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=N7nG9U5PnGVUHxzVDWkIpbNUzNtr1aYIYVhGBMVmvJ0=; b=l0kyFxK6jj817EOPxh+iZJpn31RUYpFkl1FJaHAyrSn78ivMAdSxiqfp8HfdOqYZBB 0TbBnvSFLJhVeoaWJD7ppOj0frAu8cZO1APv+UGOi14jpGGJIoCf2/IvvKD3U6KUmBXv VZOtvvcVn2SqZLu9/G2A3UP48t+EQ9m0JV+mr9XveQ/ansLRlQhQGuczEiDKgc0t3m1F fpjnFv+Ktn8JXo2GuWzsxnh3k3Pf0+mL88XSulNodt507Ejw6G6wXpKOrtrDF/qMemnU ptkZfp7DCUY/nR94xm4GZE3coaiExrLOgyS2j7gaiqc6Tu25V7jUmR/YdDSsvzzikWhC Bc8w== X-Gm-Message-State: AD7BkJI/W1xl9c3MmIaVvuGrcuQJC6Wt7yTWbyNMFTUWM57yZxA5+JChWp7gVAa99vVTqpOuk37z+u+TJT0j4A== MIME-Version: 1.0 X-Received: by 10.31.166.200 with SMTP id p191mr8102558vke.53.1456671499273; Sun, 28 Feb 2016 06:58:19 -0800 (PST) Received: by 10.176.66.134 with HTTP; Sun, 28 Feb 2016 06:58:19 -0800 (PST) In-Reply-To: <20160228112759.GE25696@bunkus.org> References: <1687ED1D-AF44-4BC5-B1E5-89F2CD7440E7@dericed.com> <20160228112759.GE25696@bunkus.org> Date: Sun, 28 Feb 2016 15:58:19 +0100 Message-ID: From: Steve Lhomme To: Moritz Bunkus Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org Subject: Re: [Cellar] Matroska Ordering Guidelines X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2016 14:58:22 -0000 2016-02-28 12:28 GMT+01:00 Moritz Bunkus : > Hey, > >> I'm reviewing the documentation at >> https://matroska.org/technical/order/index.html >> and have some >> questions and comments. > > Great, thanks! Keep in mind that these guidelines have never meant to be > read with the usual RFC terms regarding SHOULD, MUST, MAY etc. > >> The Order Guidelines say >> > Matroska only needs a few level 1 elements to be playable: Segment >> > Info, Track Info, Clusters. These elements have to be present in a >> > Matroska file. > > Well, the focus was on something that can be played back. Files without > Tracks and Clusters are valid, though, e.g. a file that only contains > chapters. It cannot be played back but it may be used as an additional > resource when playing other files or as an intermediate result during > muxing operations. > > I don't want different requirements for =C2=BBplayable Matroska=C2=AB and > =C2=BBnon-playable Matroska=C2=AB. Having Info mandatory and the rest not= is as it > should be. The guidelines should be re-worked considerably to reflect > that. > >> This sentence: >> > All the other elements can be omitted although Cues (index) improve >> > the playback experience greatly. >> >> seems far too broad. I suspect that it should be "All the other Level >> 1 elements...". > > True. Some are better than others. Tags are not going to improve much of your playback experience. >> Regarding, >> > After a Matroska file has been created it may still be edited. For >> > example chapters, tags or cover art attachments can be added. To do >> > that the Meta Seek needs to be updated and also some elements may be >> > voided or extended. >> >> These sentences imply that if Chapters, Tags, or Attachments are aded >> then MetaSeek is mandatory, but is this true? Also IIRC MetaSeek >> doesn't need to reference all Level 1 elements, so Attachments could >> be added without creating or updating MetaSeek? > > No, a MetaSeek is not required in the sense that it MUST be present. The > sentence is a vague description of the process an editor implements so > that a player can always find the new or modified resources. > > For example: if all attachments, chapters, tags are located before the > first cluster then no MetaSeek element is required at all. A player > that reads from the start to the first cluster can already find all > important level 1 elements without seeking. > > If a MetaSeek element is present pointing to an already existing > Attachments element and that Attachments element is relocated then, > however, the editor MUST update the exiting entry in the MetaSeek > element to reflect the new position. *existing. Yes, it must be updated, but only if it exists. MetaSeek is not mandatory. > Another example. We only require players to be able to find elements in > two ways: > > 1. By reading linearly from start to the first cluster and using all > elements found in the process (no seeking) > > 2. By using the information in all MetaSeek elements found by the > method described in 1. (limitation: a player only has to follow one > level of MetaSeek-to-MetaSeek link, no more). > > We don't have similar requirements on editors, but what an editor > usually has to do in order for the elements to be found by players > derives directly from the requirements for players. > > So an editor can write Attachments at the end of the file and not > include them in a MetaSeek. So far, so good. But it cannot expect all > players to find them in such a situation. > >> Regarding, >> > When 1 Meta Seek Head is present, it should be the first element in >> > a Segment=E2=80=A6 >> >> Is this true? If MetaSeek is present a MetaSeek element MUST be the >> first element of the Segment? This conflicts with the rules for CRC >> which must also be first. > > Think of it more along the lines of =C2=BBshould be the first level 1 > element in a segment=C2=AB. The intention is that all level 1 elements ca= n be > found reading as few bytes as possible. Yes, that's the first Matroska element. EBML parts obviously come first. >> Regarding: >> > The second Meta Seek is placed at the end and contains a lengthy >> > list of all Clusters (and not the other level 1 elements). >> >> To clarify if a second MetaSeek is used under Segment than it must be >> the last element of the Segment? > > Nope. =C2=BBAt the end=C2=AB simply behinds =C2=BBafter the clusters=C2= =AB which is usually > somewhere within the vicinity of the actual end of the file. The simple > reason is that it isn't known in advance how big such a MetaSeek element > will become. Therefore it doesn't make sense to reserve arbitrary > amounts of space before the clusters for this list. > > The same applies to the Cues. > >> If the second MetaSeek is used it can only reference Clusters and not >> any other level 1 element? > > Nope, but that's usually how it's done. Remember, guidelines, not hard > rules. This is not a hard rule. This raises a question. Do we want to enforce stricter rules in the future ? If Matroska v5 has proper validator it may be a good opportunity to add more "meta-rules" like these to ensure only nice files are produced. > For example, mkvpropedit or my GUI's header editor will write MetaSeek > elements somewhere at the end referencing Attachments, Tracks etc. in > certain situations if it cannot place such a bit MetaSeek before the > clusters. In that case a minimal MetaSeek element is written before the > clusters pointing to that MetaSeek element behind the clusters. > > That's OK =E2=80=93 it's also a situation that an editor may find itself = in > (modify only a few bytes of an existing file), but not usually a muxer > which can reserve enough space before the clusters (it re-writes the > whole file anyway). > >> Regarding >> > Placing the first Meta Seek Head other than the first position of >> > the Segment would make it a lot less useful So it must be >> > the first element of a Cluster. >> >> I think this should read "be the first element of a Cluster=E2=80=9D, ri= ght? > > You mean =C2=BBSegment=C2=AB, I guess ;) Yes, =C2=BBCluster=C2=AB is simp= ly wrong in the > original sentence. > >> > So the Cues should always be written after the >> > Clusters. However the Cues could also appear >> > at the front. > >> I'm confused by the way this is written. In what cases should Cues be >> written before or after Cluster? > > As I've said above Cues can become arbitrarily large and are therefore > often written at the end so that a muxer doesn't have to reserve huge > amounts of space at the front. > > However, you can create a program that re-writes and optimizes a > Matroska file. In that case it already knows how many Cues there will be > and how much space is required for them. It can write the Cues at the > start. mkclean can do that. But most of the time muxers write Cues at the end. For file streaming (via HTTP for example) it's better if it's at the front as seeking is an expensive/slow operation (not so true in HTTP 2.0). But for a muxer it's hard to do it in one pass and there are many 2-pass muxers... I suppose for archival you have the same kind of dilmena: do you want to create your files faster or do you want future playback to be a tiny bit faster ? >> Overall the documentation seems to suggest that multiple different >> elements all belong at the "end". Does the "end" mean "the last Level >> 1 element" or simply "after the last Cluster element=E2=80=9D? You put at the end the things you can't predict when starting muxing. The muxing "ending" after all audio/video data are done. > The latter, =C2=BBafter the last Cluster element=C2=AB. > > 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 Feb 28 07:04:33 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE971A0197 for ; Sun, 28 Feb 2016 07:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.888 X-Spam-Level: X-Spam-Status: No, score=0.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FF_IHOPE_YOU_SINK=2.166, FM_FORGED_GMAIL=0.622] autolearn=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 r5cU5_zOOjP9 for ; Sun, 28 Feb 2016 07:04:31 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0395A1A0194 for ; Sun, 28 Feb 2016 07:04:30 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id k196so114377201vka.0 for ; Sun, 28 Feb 2016 07:04:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=atrPzrOO2S4vVVOnDfqbHdOlUgtthHH3VaLmsYLSi6M=; b=JaXW+OUTmox1nzR8T0xWQsZTPP7BsgTCB80GQV5FXkQBTCVjsbCg/iX+3FtkAwtR/X tJ0j5eSVCiCufSJbQqyiVv4u4ks4LJFxw8U0rAKbp1qC+9Wif64waPoK7vIuae1iv74q SNQf8nM77ePHvOgqZb0lkrrUo5ZPbbde9eeobEQff6oOZ1fRrZvpPbXDSstzXLaGyPV0 PjLJMVEMcSS7fGJeL3I/4GGAF6NcWdqfw7QFigacndq/jF6TyjMPuCVXOJS0GngmSo+W 1RLSHC4uja+3B+WiJT6cvKsZRylOA6J3Kku8+6EheW9zDfikvpXaSiq9Yt0e/6Fm46oE HMtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=atrPzrOO2S4vVVOnDfqbHdOlUgtthHH3VaLmsYLSi6M=; b=cKXmAgJMbLVlEd5EVb1V+wuQU5tx40ueNPVhR9/EY/kkjOVHqXLWFOUz+ra82bsXUu WTFx2VSTsDF4/qFT4F3cnqoyZpHHa11UUohLx+DBkZhptUorekDMBa1F+ibSnmm55Efc JrudcXSx7BKGroiILV6+86oTuqC7GM3yoHfTkajZLTJoZ82a08nWE4b/gDH88cwGw8yN Cods5uESkI7x0G8/PHTjMaPrRFZITQDTgrVwQawPzAT25ZIsMYtGyadhHUEdrk05tnnX S/T0IqlrQyaihU/wqGVzPqMfyq+yUBwZK192SOiZLjPVdx3EtYV9tcH0nQdYgshqjjMJ 3Qbw== X-Gm-Message-State: AD7BkJI0xVVujOyrbWb2nU4cUFp9aKRTAWjPXJz/gwqcJ+w6Zoo2rJ/gkZl0i8prACz9aH2vvgXQG7D4nKmkZw== MIME-Version: 1.0 X-Received: by 10.31.158.204 with SMTP id h195mr8235969vke.147.1456671870023; Sun, 28 Feb 2016 07:04:30 -0800 (PST) Received: by 10.176.66.134 with HTTP; Sun, 28 Feb 2016 07:04:29 -0800 (PST) In-Reply-To: References: Date: Sun, 28 Feb 2016 16:04:29 +0100 Message-ID: From: Steve Lhomme To: Dave Rice Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: cellar@ietf.org, Nithin Mathew Kurien Subject: Re: [Cellar] expressing a float in text X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 28 Feb 2016 15:04:33 -0000 2016-02-28 15:49 GMT+01:00 Dave Rice : > >> On Feb 28, 2016, at 9:14 AM, Steve Lhomme wrote: >> >> 2016-02-18 16:35 GMT+01:00 Nithin Mathew Kurien : >>> Yes, the notations would be different. Single floats would have 6 >>> hexadecimal digits in the mantissa, whereas double floats would have 13= . I >>> would suggest defining all EBML floats as doubles, because of the great= er >>> range and precision available. >> >> Since Matroska floating point numbers can be double precision, a >> program handling Matroska has to work in double-precision (or lose >> some accuracy with floats). So I think it's ok to assume that floats >> are defined as double-precision in the specs. > > I don't think any existing MKV floats are defined as single or double pre= cision. The element definitions just label them as 'float' and in the conte= xt of EBML a float can mean either 0, 4, or 8 bytes. That's the way they are stored. But when handling the data in the processor, you either use double or float (or both if you don't like reusing code) that the processor uses. I'd assume that implies using double-precision as it's the most demanding case. So if there's a binary format representation in addition to the text one, it should probably be a double precision one. > Is there reason to refine the specs to define elements as particular type= s of floats? > >> Also, do we allow NaN as a possible default value ? > > I don't think so. Nitpicky, but do you have a sentence or reference to de= fine what NaN signifies. No. In the context of EBML it may not be needed as not putting a default value means it's undefined anyway. For math data storage (not in the context of Matroska) it may make sense though. It's fine to have a variable Nan. We may also allow =E2=88=9E and -=E2=88=9E. Not sure h= ow I would code that in libebml though... > Dave > >>> Thanks and regards, >>> Nithin >>> >>>> On Mon, Feb 15, 2016 at 12:41 AM, Dave Rice wrote: >>>> >>>> >>>> On Feb 13, 2016, at 2:24 PM, Nithin Mathew Kurien >>>> wrote: >>>> >>>> Hi, >>>> >>>> Not sure if it is suitable in this context, but C99 supports writing >>>> floats accurately in hexadecimal notation >>>> (http://www.exploringbinary.com/hexadecimal-floating-point-constants/)= . The >>>> advantage of hexadecimal notation is that values can be represented >>>> accurately, unlike representions like 1.67e-3, which will result in ro= unding >>>> errors when converted from decimal to the native binary form. With a C= 99 >>>> compiler like GCC, we can output the hexadecimal form of any float. >>>> >>>> double num =3D 1.55e1; >>>> printf("%a", num); >>>> >>>> would output >>>> >>>> 0x1.fp3 >>>> >>>> which is equal to (1 + 15/16) * 2^3. >>>> >>>> >>>> For values such as 0.0 and 1.0, wouldn't the C99 notation be different >>>> depending on if the float is expressed as a single or double? Currentl= y an >>>> EBML float could be either 4 or 8 bytes and the choice of float length= is >>>> not part of the element definition. If we use C99 notation we may be >>>> implying whether the float is single or double and should consider say= ing so >>>> in the definition. >>>> Dave >>>> >>>> Thanks and regards, >>>> Nithin >>>> >>>> >>>>> On Sun, Feb 14, 2016 at 12:20 AM, Dave Rice wrote: >>>>> >>>>> To accommodate the float range expressions in Frank=E2=80=99s color w= ork, I=E2=80=99m >>>>> expanding the =E2=80=9CExpression of range=E2=80=9D [1] section to ac= commodate floats >>>>> (currently it only discusses signed and unsigned integers). Frank=E2= =80=99s use of >>>>> float ranges are quite simple, such as 0.0 to 1.0; however, in defini= ng a >>>>> method to document a float range, I think the definition should work = for any >>>>> possible float value. >>>>> >>>>> Is there an standard document to point to for how to represent a floa= t >>>>> value as text? i.e. I=E2=80=99m familiar with float values in text su= ch as 3.88E-4 >>>>> but where it this style of expression defined? >>>>> >>>>> Best Regards, >>>>> Dave Rice >>>>> >>>>> [1] >>>>> https://github.com/Matroska-Org/ebml-specification/blob/master/specif= ication.markdown#expression-of-range >>>>> _______________________________________________ >>>>> Cellar mailing list >>>>> Cellar@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/cellar >>>> >>>> >>>> _______________________________________________ >>>> Cellar mailing list >>>> Cellar@ietf.org >>>> https://www.ietf.org/mailman/listinfo/cellar >>> >>> >>> _______________________________________________ >>> Cellar mailing list >>> Cellar@ietf.org >>> https://www.ietf.org/mailman/listinfo/cellar >> >> >> >> -- >> Steve Lhomme >> Matroska association Chairman >> >> _______________________________________________ >> Cellar mailing list >> Cellar@ietf.org >> https://www.ietf.org/mailman/listinfo/cellar --=20 Steve Lhomme Matroska association Chairman From nobody Sun Feb 28 23:51:11 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B071B2D73 for ; Sun, 28 Feb 2016 23:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 RDhsxq9MNFnb for ; Sun, 28 Feb 2016 23:51:07 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50411B2D74 for ; Sun, 28 Feb 2016 23:51:07 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id e185so125986590vkb.1 for ; Sun, 28 Feb 2016 23:51:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=LnMkImLb2GIN3VMgwlmGI5qID0J1haO25rNLNy5oxm8=; b=QCvKnaGDQcqkucJyiz2JrjaQMqQdacgIXNpAK3ohuTx0a1uJf9HfVYPdwkTc7hoo8G B2OIPU5V9gWt6+j/iPMxreUkbRnHbyXq+E9tOJhaoxPkA7nGLeDWs3Wj+9G4mpFeyI2S vyA/fFgK/Av/Kxvm9Bka6V7lAfTTBcIUdnt061+H5/sYVDO762SFw0xiU71vmEHUMBPM IRKJs5xkH+P58q3kof1Zd9U/miHhCScSb99YKnO/o/QQOu/OcVbNmspS93wOmIu/U54+ LMZLLrx0bJnEJnQN/FREgdGtXZsPG1LKRSY2HjVZq5UAyYFCdaFLcJaZMYNrOlNMi1Ip n8wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=LnMkImLb2GIN3VMgwlmGI5qID0J1haO25rNLNy5oxm8=; b=VXoQfKLBOuUsamOOLBnXDGPJXLrBtXgutH22Mcq6BrjganN95OWL7AyKbF0+QjdrfJ kNOdQMkk0XeOnOxI+8saDOFuD+GZkMslOt8iahB84qjU02uxN1PHjNFBnpXuHMOXlh/p pprDZ4Prfc4vrvaSnrHndBCj1U6EsZFbwJTVQ8IvBprbI5KF3nKYSkQfnqGosyHRHYpw Ub+0SEBxB6F4yFVwA6pNpKkNcmN75bjG/jn1/zIioeR4QirUFgGJSPZOJtsYcr2aDBqr CGb+6LNThSvTHG+yBglh8zWz8dZASPxWTZMsKsOwcSIec4V221t6032S92kp7BB8hrl2 J8jQ== X-Gm-Message-State: AD7BkJIOfDflbw/Fl/Ym9ySIJfpKwdQMUd2z+sMO773/EpoAR39sHFm8f0Zpznl+NYn8iLzM+B8uAKISslEyvA== MIME-Version: 1.0 X-Received: by 10.31.133.7 with SMTP id h7mr10242467vkd.32.1456732266823; Sun, 28 Feb 2016 23:51:06 -0800 (PST) Received: by 10.176.66.134 with HTTP; Sun, 28 Feb 2016 23:51:06 -0800 (PST) In-Reply-To: References: Date: Mon, 29 Feb 2016 08:51:06 +0100 Message-ID: From: Steve Lhomme To: madshi Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Discussion about the current and future development of Matroska , cellar@ietf.org, Nithin Mathew Kurien , Hendrik Leppkes Subject: Re: [Cellar] [Matroska-devel] Depth offsets for subtitles in case of 3D MVC tracks in MKV files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 29 Feb 2016 07:51:09 -0000 2016-02-28 23:12 GMT+01:00 madshi : > 2016-02-14 15:50 GMT+01:00 Steve Lhomme : >> 2016-01-26 14:39 GMT+01:00 Nithin Mathew Kurien : >>> Hi, >>> >>> It's like this. Suppose the MVC video track has 8 frames. Also suppose it >>> has 5 Offset Metadata Sequences embedded in it at the time of encoding. >>> (Sequence entries are in pixels, positive if in front of the screen, and >>> negative if behind.) >>> >>> Frame 1 2 3 4 5 6 7 8 >>> Seq1 5 1 -8 -2 -9 1 -3 -1 >>> Seq2 8 1 0 8 -4 -5 4 -1 >>> Seq3 -2 8 -3 -5 7 5 -5 -4 >>> Seq4 9 0 0 -5 -2 1 -4 -1 >>> Seq5 -9 3 -2 -4 -6 0 -3 6 >>> >>> If the M2TS container has 2 subtitle tracks P1, P2 and 1 menu track I1, then >>> a mapping can be defined in the M2TS container like this: >>> P1 : Seq1 >>> P2 : Seq3 >>> I1 : Seq4 >> >> OK, so it seems it's both in the header and in the track (the GOP is >> part of the stream, I think). > > Yes. As Nithin Mathew explained (thanks!), there are SEI 3D depth info > blocks inside of the video stream. We don't need to do anything about them. > But there's additional data in the Blu-Ray playlist file(s) which > assigns specific > subtitle tracks to an "array index" in the SEI 3D depth info block. > > In the meanwhile nevcairiel and I have already added full support for all > this 3D depth offset stuff to LAV Splitter/Video decoder and madVR, when > playing back original Blu-Rays. But for Matroska there's no full solution > possible yet, because the information in the playlist cannot be properly > stored yet. > > It would be great if we could get an official solution for this soon, because > we'd like to implement it "now", and we have the MakeMKV devs on board > for this now, too. > > Basically I think what we need is one additional item for each subtitle > track which simply assigns one SEI 3D depth array index to the subtitle > track. E.g. something like "stereo_subtitle_offset_id", or whatever. The > name is not important to me. Possible values I think are between 0..31 > for 3D Blu-Rays. That seems to be heavily relying on the Blu-ray specs. I'd favor a solution that is more generic and doesn't have to go through "codec specific" lookup tables. Otherwise if the codec used for Blu-Rays subtitles is already specific, we could just use the CodecState to store the SEI value when it changes. https://matroska.org/technical/specs/index.html#CodecState That means custom made text subtitles will not work properly with 3D Blu-ray content because it doesn't use the same codec. If we want the general case to work we may introduce an element at the same level as CodecState that defines the Z-order for the Block. That means it would have to translate the lookup index in the SEI to the actual z-order value (if I understand correctly how it works). We need to define if it's like the CodecState, ie it only changes from scene to scene, not Block by Block. So it would be a State that needs to be remembered when needed and only written when it changes. What is the range of depth allowed in Blu-Rays ? Are they discrete value or floating values ? > One additional piece of information would be which array indexes of the > SEI 3D depth info block are assigned to IG (interactive graphics). This > could be used by media players or video renderers to decide at which > 3D depth to draw the user interface (GUI/OSD). FWIW, it could be none, > one or multiple array indexes. So the information field in the MKV header > would have to be some sort of list/array. Logically this info would > probably belong to the video track. This is less important than the > subtitle assignment, though. But would still be nice to have. > > Best regards, madshi. -- Steve Lhomme Matroska association Chairman From nobody Mon Feb 29 00:25:04 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DEE1B2DEB for ; Mon, 29 Feb 2016 00:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 2oTwDVfGsZqP for ; Mon, 29 Feb 2016 00:25:02 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7D091B2DE9 for ; Mon, 29 Feb 2016 00:25:01 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id c3so126660969vkb.3 for ; Mon, 29 Feb 2016 00:25:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=5Km5GCmNSJbT8eTLEqEfvEyRCBMPW2/8iwWt2Sj5jTA=; b=UOM7CVrc82byExSHE1in291Y2Jio71JXIPaLeJluvsYQUR+syCTo1+BrCSSBqEVIkb TaV+ugvJLMCsQUlAp+hgZdEdUdf1BCpVZojUtsxq2BEvr99pVZLnOI1BaKcQkZIeAFP8 qR6B56PDlBdWO8WYh2T3QTk0QzUHk7aGbmIIDSX9Zu8arvUbMwkjZ1xUj9595mP2icac Q4nzCN1S9/aUiMGziGtihfNpNCn7PYUYErWEgMNcCZb4Kukn+txuJU/2AN/Chixm95yh 1L/obX5Y2as5pjAM2Q9H4WtZHX++1nXBLscIuB5zjj5T52Dc1uI32oWqiALbDSIT6dIb e7rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=5Km5GCmNSJbT8eTLEqEfvEyRCBMPW2/8iwWt2Sj5jTA=; b=S2Oe+ZT3K4en92KwdToqFYCrqFYLOiSdadIOkogQU5LfKiXoOGj1hgqt/FsXrSUwCH 1E12BlG2EwQeky/vkJ98943mvsffkVKJdI7mn21YJlBAyZIh5v9SU/AIIiz2m85gux/c VjjlFPwGDHZB20JGIws0GytDyxwl/8WlxX1Ku3U1uNu7CaCF3swnLtyGcy1qJ6suPmuh kB427dk0W6Kzk1F+qItOGWYlXtWx+m0s0kclSsvDg8xG6vp4l4VNLRNbbJDv7m/7Eowx m01qCQ3py7EIr3h+7dDXyuTMtRBiFgIvL8DpS0G2Ab8XM2FBoRkDN+oizw2Um+n7PLTr nr/g== X-Gm-Message-State: AD7BkJIpdh1DoZgMU/rse6A1rZl55o2TyyOhuyN72hStML4fvsgmNvEXDBE2Mdse/dPMFuSqiIVWBzR1pBMzdg== MIME-Version: 1.0 X-Received: by 10.31.133.7 with SMTP id h7mr10321270vkd.32.1456734301132; Mon, 29 Feb 2016 00:25:01 -0800 (PST) Received: by 10.176.66.134 with HTTP; Mon, 29 Feb 2016 00:25:01 -0800 (PST) In-Reply-To: References: Date: Mon, 29 Feb 2016 09:25:01 +0100 Message-ID: From: Steve Lhomme To: cellar@ietf.org, Matroska Devel Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [Cellar] Fwd: [Matroska-devel] Depth offsets for subtitles in case of 3D MVC tracks in MKV files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 29 Feb 2016 08:25:03 -0000 FW answer ---------- Forwarded message ---------- From: Steve Lhomme Date: 2016-02-29 9:24 GMT+01:00 Subject: Re: [Matroska-devel] [Cellar] Depth offsets for subtitles in case of 3D MVC tracks in MKV files To: Hendrik Leppkes 2016-02-29 9:17 GMT+01:00 Hendrik Leppkes : > On Mon, Feb 29, 2016 at 8:51 AM, Steve Lhomme wrote: >> >> What is the range of depth allowed in Blu-Rays ? Are they discrete >> value or floating values ? >> > > The "depth" is defined in discrete pixel values in the BD SEI, ie. the > offset to move it left/right for each eye, so it doesn't have a direct > meaning of "depth", but just instructions on how to render it. Ah, interresting. We could still use a z-order value, because that's what 3D is about. But then it would probably be a float to actually translate to a wide range of possibilities. But, as seen with the rare float values in Matroska, in the case where it's actually used (this case) it would just lead to approximate values of the original format. > Note that the way this is implemented on Blu-rays, the depth can > change from frame to frame. Every GOP has a new SEI block which > includes one offset for every frame in the SEI, so its controlled on a > frame level, not a scene/GOP level. So I think we should go with the CodecState approach. Meaning we need a specific codec ID for such Blu-Ray subtitles. We should not write the CodecState if the values are the same as the time it was previously written. This is also assuming the subtitles are always key frames, so the (de)coding order is also the display order. -- Steve Lhomme Matroska association Chairman -- Steve Lhomme Matroska association Chairman From nobody Mon Feb 29 00:57:28 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9500D1B2E5B for ; Mon, 29 Feb 2016 00:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622] autolearn=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 CK5RXQb7dEl5 for ; Mon, 29 Feb 2016 00:57:25 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EBAE1B2E57 for ; Mon, 29 Feb 2016 00:57:25 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id e6so127151713vkh.2 for ; Mon, 29 Feb 2016 00:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=matroska-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to; bh=rfUojhyq7pSZO0+z+ZDXztF4NJXuAK8/V71WOcxzBQg=; b=L7bjBpJxijPLAaj1/gMDJ7QrJobqv8MdvBXvn6bH1UYUUg+XUgeW6Y0AJhqsJlKusS GBynwxEWhJIPNTM0V8kD4sOg9bo2rAXw3IMLWs6RHrxNO80eBZN7eMWT+ZIKYwy6UWtB mJ/U+bjOcBRJd2ukhD7T+06R+L+i1POJJh3I2D5DILhmUPoK45nmP6U6QxsSMXNg1SkH MO+HdovvM4jA8F5QeHDwqZ+otU67/vFRMLOgjaMtyLTwrJgLAgDB4ZyWUalTgb3cVLK2 dUpky70oMny63rLjdvAIcTm/z7ld337/quJFf2yGx5JIsKYfO18hX7tYT9XLfljsY9W1 cJIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to; bh=rfUojhyq7pSZO0+z+ZDXztF4NJXuAK8/V71WOcxzBQg=; b=RDw909sH7S1i7gjmHZDxnmtLgkHyEbHSQFX6HpO3QwMjR2FcTm9p/uflZUvTIltACo ci7torhNRltCfQ7VtQbnR9U8XfpetWfDKK/QD4+Ll6UMqfoRh5nStCwdWdDXP/I8p1pU 4/T5oSmmE6M5G/t+hfucTCZebf0B49hyBGbuvjpXt+bMhttvqCXHcNZvv2xD+qdsP/Jw ZH9Fbz5xGgrdRKmr2YZ8qo7mbVG3XxD252KYNxn6ACMjOeSVXnCkRKD3qR+yoCVnPFsk FgRzhVX0I0e+gkn0lrYm/zFy1kOzifSMJarSafLSUCC6XW8l9yCG3lsrrxPN9DOM/uu3 b7Mg== X-Gm-Message-State: AD7BkJKYgDw/B4XuIuFj242KsM8BK5Ygc6+o3w6DgDIUeIiOrN22kh/W11ciwgev+A413ojEOromUZuomWZLSg== MIME-Version: 1.0 X-Received: by 10.31.163.68 with SMTP id m65mr10376507vke.85.1456736244357; Mon, 29 Feb 2016 00:57:24 -0800 (PST) Received: by 10.176.66.134 with HTTP; Mon, 29 Feb 2016 00:57:24 -0800 (PST) In-Reply-To: References: Date: Mon, 29 Feb 2016 09:57:24 +0100 Message-ID: From: Steve Lhomme To: cellar@ietf.org, Matroska Devel Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [Cellar] [Matroska-devel] Depth offsets for subtitles in case of 3D MVC tracks in MKV files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 29 Feb 2016 08:57:26 -0000 > From: Steve Lhomme > Date: 2016-02-29 9:24 GMT+01:00 > Subject: Re: [Matroska-devel] [Cellar] Depth offsets for subtitles in > case of 3D MVC tracks in MKV files > To: Hendrik Leppkes > > > 2016-02-29 9:17 GMT+01:00 Hendrik Leppkes : >> On Mon, Feb 29, 2016 at 8:51 AM, Steve Lhomme wrote: >>> >>> What is the range of depth allowed in Blu-Rays ? Are they discrete >>> value or floating values ? >>> >> >> The "depth" is defined in discrete pixel values in the BD SEI, ie. the >> offset to move it left/right for each eye, so it doesn't have a direct >> meaning of "depth", but just instructions on how to render it. > > Ah, interresting. We could still use a z-order value, because that's > what 3D is about. But then it would probably be a float to actually > translate to a wide range of possibilities. But, as seen with the rare > float values in Matroska, in the case where it's actually used (this > case) it would just lead to approximate values of the original format. > >> Note that the way this is implemented on Blu-rays, the depth can >> change from frame to frame. Every GOP has a new SEI block which >> includes one offset for every frame in the SEI, so its controlled on a >> frame level, not a scene/GOP level. > > So I think we should go with the CodecState approach. Meaning we need > a specific codec ID for such Blu-Ray subtitles. We should not write > the CodecState if the values are the same as the time it was > previously written. Alternatively if the values are expected to change a lot BlockAdditional could be used. The data are left to interpretation by the codec, just like CodecState but doesn't require the blocks to be added to the Seek entries. https://matroska.org/technical/specs/index.html#BlockAdditional > This is also assuming the subtitles are always key frames, so the > (de)coding order is also the display order. > > -- > Steve Lhomme > Matroska association Chairman -- Steve Lhomme Matroska association Chairman From nobody Mon Feb 29 01:04:32 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5031B2E65 for ; Mon, 29 Feb 2016 01:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 U1LlksCFtEj3 for ; Mon, 29 Feb 2016 01:04:29 -0800 (PST) Received: from liselle.bunkus.org (liselle.bunkus.org [176.9.119.9]) (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 510171B2E64 for ; Mon, 29 Feb 2016 01:04:29 -0800 (PST) Received: by liselle.bunkus.org (Postfix, from userid 1002) id 25C611631236; Mon, 29 Feb 2016 10:04:27 +0100 (CET) Received: from sweet-chili.local (unknown [10.55.4.6]) by liselle.bunkus.org (Postfix) with ESMTPS id F12B4163122E; Mon, 29 Feb 2016 10:04:25 +0100 (CET) Received: by sweet-chili.local (Postfix, from userid 1000) id 5E865180D6B; Mon, 29 Feb 2016 10:04:25 +0100 (CET) Date: Mon, 29 Feb 2016 10:04:25 +0100 From: Moritz Bunkus To: matroska-devel@lists.matroska.org, CELLAR list Message-ID: <20160229090425.GK4466@bunkus.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="EMQjp+MvU6EBGjHc" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-Virus-Scanned: clamav-milter 0.98.7 at liselle X-Virus-Status: Clean Archived-At: Subject: Re: [Cellar] [Matroska-devel] Fwd: Depth offsets for subtitles in case of 3D MVC tracks in MKV files X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 29 Feb 2016 09:04:30 -0000 --EMQjp+MvU6EBGjHc Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Hey, > CodecState is per Cluster, though, not per Track, This is wrong. CodecState is a child element of BlockGroup. It's effect as it's been meant to be understood so far is to replace CodecPrivate for that track from that BlockGroup onwards (until another BlockGroup with CodecState comes along). So it _could_ be used for changing Z-depth values for individual subtitle frames. However, as it's supposed to replace CodecPrivate I don't think it would be a good fit for Z-depth data as Z-depth data is additional data that changes on a frame-by-frame basis; it doesn't invalidate the existing CodecPrivate data. CodecState was meant for situations in which e.g. a whole new set of SEIs/PPSs come along. I'd prefer new elements, or maybe BlockAddition. Kind regards, mosu --EMQjp+MvU6EBGjHc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIcBAABCgAGBQJW1AmYAAoJEHSvAK3y4yyFNbsP/37Xdp7zddqmlnuHt0sZkGHf /BpYvl5d4X1WO9DZxskfTgDGt+Nk2prUzUlxbAzAQnv361Xty8yd6SMISz55MmT/ kvnXBna7MU1g+JPux352KKkihoG9Os2CYKBs4EgwG6yuGmV70dMnbOOEtShZCoRq wGObsUFumCDUFs6cAdw1oMuiI1o49CSPYTUcJ/khC5baQnDKXW6quRO8nQIeg11h 6gTSFJK0SGJNKpeu4iDAB4Usf9v0hDbh4sbQbGGpclAg5XfeH/1G/Uedr37gZt6n HnjT0TLsgagvkJKhzYpYbQSrpxmIAo3W8ukYqd76P8E+cFQ2MypMsDzVzxvOMdFT eBJ8t53UjWWQq3coTyetTLjoDvKjTgZlcDbw9t/SH4w9yACj14dqMMTKQKM9PYRS 3RuX9Ci/TQ+yS+QOygml+MmbH6wLl0DjFe3vFvA8pbxljv6JU1OB+I1C++KoJnJJ kntgNYq7vJ+Ty5aODLhwPOq0kmfPOQxs/HmI4zjh0eC7i9oIHkv3trDEZTUWrnjT 7dSldXw6zXKzN6lrfD9LzPVFbBIEIp3GClc911pqbt2kdLPtU25ALz+VA/luZpJx KgsF0h/Awvnhmvg64Vp4xxGO2u1k5+rnmR8gBMmNKX6cbUElNK0P+thesZ31koid oFWzAYWlanIVyVXkX/a8 =38Pk -----END PGP SIGNATURE----- --EMQjp+MvU6EBGjHc-- From nobody Mon Feb 29 06:27:35 2016 Return-Path: X-Original-To: cellar@ietfa.amsl.com Delivered-To: cellar@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69ACB1B3238 for ; Mon, 29 Feb 2016 06:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.032 X-Spam-Level: X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 VoKevms9Qc19 for ; Mon, 29 Feb 2016 06:27:31 -0800 (PST) Received: from p1002.netstorage.at (p1002.netstorage.at [89.207.146.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F4371B3235 for ; Mon, 29 Feb 2016 06:27:30 -0800 (PST) Received: from mailix (noaport.de [46.237.252.213]) by p1002.netstorage.at (Postfix) with ESMTPA id 96CE080E9D for ; Mon, 29 Feb 2016 15:27:28 +0100 (CET) Received: from [127.0.0.1] (HSI-KBW-46-237-252-214.hsi.kabel-badenwuerttemberg.de [46.237.252.214]) by mailix ; Mon, 29 Feb 2016 15:27:28 +0100 To: cellar@ietf.org References: <56D036BA.9000603@noa-archive.com> <20160228111117.GD25696@bunkus.org> From: Tobias Rapp Organization: NOA GmbH Message-ID: <56D4554F.9040308@noa-archive.com> Date: Mon, 29 Feb 2016 15:27:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------070905050800070907040001" X-PPP-Message-ID: <20160229142728.6255.99705@p1002.netstorage.at> X-PPP-Vhost: noa-archive.com Archived-At: Subject: Re: [Cellar] Display area clarification question X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.15 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, 29 Feb 2016 14:27:34 -0000 This is a multi-part message in MIME format. --------------070905050800070907040001 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 28.02.2016 15:31, Steve Lhomme wrote: > 2016-02-28 12:11 GMT+01:00 Moritz Bunkus : >> Hey, >> >> it's true that we've never clarified this. I'm not even sure whether or >> not we've had a consensus on how to interpret the values. > > Correct, but trust me, it was in my head the whole time ;) Although > the name PixelCrop* imply that it happens on Pixel*, unlike Display* > values. One could (in theory) invent similar DisplayCrop* elements that apply on top of DisplayWidth/Height values which could be used to describe letterboxed/pillarboxed material. This would be somehow similar to the AFD flag [1] in MPEG but globally on the stream/track. >> For me PixelCrop* applies directly to the PixelWidth/Height values. And >> Display* determines the intended size for displaying the video after the >> cropping parameters have been applied. So yes, your interpretation is >> the one I'm favoring as well. > > Yes, the cropping happens on the pixels, the display size are just how > to display those remaining pixels. OK, have tried to make a patch, see attached file. Note that I have changed the default value of DisplayWidth/Height to take the cropping into regard. Not sure how critical this is regarding backwards compatibility. It affects files which have at least one PixelCrop* element value > 0 and no DisplayWidth/Height element. Best regards, Tobias Links: [1] https://en.wikipedia.org/wiki/Active_Format_Description --------------070905050800070907040001 Content-Type: text/x-patch; name="0001-Clarify-processing-order-of-PixelCrop-elements.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-Clarify-processing-order-of-PixelCrop-elements.patch" >From 29ae82f471e52f3cd8dd21141fdc6d17560de22c Mon Sep 17 00:00:00 2001 From: Tobias Rapp Date: Mon, 29 Feb 2016 15:12:46 +0100 Subject: [PATCH] Clarify processing order of PixelCrop elements --- spectool/specdata.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/spectool/specdata.xml b/spectool/specdata.xml index 59557e6..edd6fbe 100644 --- a/spectool/specdata.xml +++ b/spectool/specdata.xml @@ -118,8 +118,8 @@ between two successive fields at the output of the decoding process (see The number of video pixels to remove at the top of the image. The number of video pixels to remove on the left of the image. The number of video pixels to remove on the right of the image. - Width of the video frames to display. The default value is only valid when DisplayUnit is 0. - Height of the video frames to display. The default value is only valid when DisplayUnit is 0. + Width of the video frames to display. Applies to the video frame after cropping (PixelCrop* elements). The default value is only valid when DisplayUnit is 0. + Height of the video frames to display. Applies to the video frame after cropping (PixelCrop* elements). The default value is only valid when DisplayUnit is 0. How DisplayWidth & DisplayHeight should be interpreted (0: pixels, 1: centimeters, 2: inches, 3: Display Aspect Ratio). Specify the possible modifications to the aspect ratio (0: free resizing, 1: keep aspect ratio, 2: fixed). Same value as in AVI (32 bits). -- 1.9.1 --------------070905050800070907040001--