Re: [Cellar] Colour Format proposal
Dave Rice via Matroska-devel <[email protected]> Tue, 17 May 2016 13:52:56 -0400
| Newsgroups | gmane.comp.multimedia.matroska.devel |
|---|---|
| Message-ID | <[email protected]> |
--===============0710887007492830230== Content-Type: multipart/alternative; boundary="Apple-Mail=_6DD19FD8-762E-42A1-B5F1-714BE26639ED" --Apple-Mail=_6DD19FD8-762E-42A1-B5F1-714BE26639ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Steve, Frank, Reto, and all, > On Apr 18, 2016, at 4:29 AM, Steve Lhomme via Matroska-devel = <[email protected]> wrote: >=20 > Following the Videolan Colorimetry workshop from this week-end, I have > a better understanding of this whole subject. I wanted to bump this conversation and topic. I'm curious to hear more = of what came out of the Videolan Coloimetry workshop, but I also see = that the color format proposed elements are now integrated into = https://matroska.org/technical/specs/index.html = <https://matroska.org/technical/specs/index.html>, as well as in process = in Libav and FFmpeg, and the webm project. I don't mean to rush the = specification work but wanted to note that the proposed color elements = are in use. I suggest that we give this work a status to say if it is = complete or needs more work (and if so, identify what work remains). > I think it's good if we can have as much information in Matroska as we > can. But they probably should be split between elements that are > necessary for accurate playback (list to be defined) and the other > information like how the content was captured on camera. The first > group should be in the TrackInfo while the others should be just tags > (so with string names) that target the whole file or some chapters > (each scene probably has different capture characteristics). >=20 > =46rom Frank's list I would put those in the TrackInfo: > - MatrixCoefficients > - Range > - TransferFunction > - Primaries >=20 > - BitsPerChannel > - ChromaSubsamplingHorz / ChromaSubsamplingVert > - CbSubsamplingHorz / CbSubsamplingVert >=20 > I'm not sure about the Luminance min/max but maybe it's needed for HDR = ? > Not sure either about arbitrary RGB chromacity values of the > primaries. Are people deviating from the few norms that are available > ? And have tools for playback ? That seems to provide the same > information as the "Primaries" field and it's never good to have 2 > different set of values describing the same thing. You never know if > you have to write both and which to use for playback especially when > you need 8 values to make one set to compare... I'm interested in hearing about the use cases for these (ping to Reto). = Are we certain that the "Primaries" element overlaps semantically with = the Primary[R|G|B]Chromaticity[X|Y] elements? Perhaps we should define = one to overrule the other. > Are MaxCLL and MaxFALL exclusive ? Are they needed for HDR playback ? >=20 > I think MasteringMetadata is not needed for playback. >=20 > For list of possible values, we shouldn't follow lists from standards > that are not freely available. We should also have the default value > be 0 when possible. For much of the semantics used in the proposed colour elements, '2' = rather than '0' has been used to express an 'undetermined' state whereas = '0' has a specific meaning. I think it's consistent to keep it this way = as it better aligns with existing specification (even if non-free) and = existing implementations (free and not free). > And no "reserved" values. Same comment as above. If we are deriving a vocabulary from an = established existing standard then I think adopting traditional reserved = values is okay. Best Regards, Dave Rice > 2016-03-29 19:12 GMT+02:00 Hendrik Leppkes via Matroska-devel > <[email protected]>: >> On Tue, Mar 29, 2016 at 6:11 PM, Frank Galligan via Matroska-devel >> <[email protected]> wrote: >>>=20 >>>=20 >>> On Mon, Mar 28, 2016 at 5:05 AM, Steve Lhomme <[email protected]> = wrote: >>>>=20 >>>> 2016-03-17 5:46 GMT+01:00 Frank Galligan <[email protected]>: >>>>> OK really no comments for a long time. >>>>>=20 >>>>> On Fri, Feb 19, 2016 at 1:45 PM, Michael Niedermayer >>>>> <[email protected]> wrote: >>>>>>=20 >>>>>> Hi >>>>>>=20 >>>>>> 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 >>>>>>> 170M, >>>>>>>=20 >>>>>>> 7: SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant >>>>>>> Luminance, >>>>>>>=20 >>>>>>> 10: BT2020 Constant Luminance) >>>>>>>=20 >>>>>>>=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 >>>>>>=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 >>>>>=20 >>>>>=20 >>>>> I didn't get into RGB here. As you said 565, 551, there are a good >>>>> amount of >>>>> combinations. I think DirectShow (or maybe it was DirectDraw) that = had >>>>> R,G,B, and A masks to show which bits belonged to which channel. I = also >>>>> worked with formats like RGBBGR repeating. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> [...] >>>>>>=20 >>>>>>> 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. >>>>>>=20 >>>>>> 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 >>>>> I guess we can add that as well if more people really want it. = Actually >>>>> I >>>>> didn't even have CbSubsampling* elements at first. I only added = that to >>>>> support the 4:2:1 format that was defined in the first enum. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>>=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 >>>>>>=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 >>>>>=20 >>>>>=20 >>>>> I also didn't get into interlaced. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> I don't think we should add enough elements to support every = format that >>>>> was >>>>> ever produced. Opinions? >>>>=20 >>>> For archival (one of the main goal here) I think we should. >>>>=20 >>>>> I think we should probably strive to support 99% of what is = currently >>>>> produced today. Opinions? >>>>=20 >>>> The problem is that when you leave 1% out, you need to be sure it's >>>> possible to integrate it later. Usually the best approach is to = know >>>> beforehand how you're going to do it. So in the end it's just like >>>> covering it. That's just a general remark though. >>>=20 >>> I don't want to exclude anything in the future, but I also don't = want to >>> make something overly complex/over specified to support a format = that will >>> barely see any use. >>>=20 >>> I want to move forward with this, so how about we make a list and = then vote >>> on what we think should be added to the sepc? >>> 1. Raw RGB >>> 2. Raw YUV >>> 3. Interlaced >>> 4. mpeg1 style >>> 5. mpeg2 pogessive >>> 6. mpeg2 interlaced >>> 7. image flipped right-left >>> 8. jpeg Cr subsampled more than Cb >>> 9. non-linear color values (DPX scans) >>>=20 >>> Anything else we should add? >>>=20 >>=20 >> Just my 2 cents, but if you want to support everything and the = kitchen >> sink, you should use string fields that can be arbitrarily expanded, >> instead of integer enumerations. >>=20 >> - Hendrik >> _______________________________________________ >> Matroska-devel mailing list >> [email protected] >> http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel >> Read Matroska-Devel on GMane: = http://dir.gmane.org/gmane.comp.multimedia.matroska.devel >=20 >=20 >=20 > --=20 > Steve Lhomme > Matroska association Chairman > _______________________________________________ > Matroska-devel mailing list > [email protected] > https://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=_6DD19FD8-762E-42A1-B5F1-714BE26639ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D""><div class=3D"">Hi Steve, Frank, Reto, and all,</div><br = class=3D""><div><blockquote type=3D"cite" class=3D""><div class=3D"">On = Apr 18, 2016, at 4:29 AM, Steve Lhomme via Matroska-devel <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:</div><br = class=3D"Apple-interchange-newline"><div class=3D""><div = class=3D"">Following the Videolan Colorimetry workshop from this = week-end, I have<br class=3D"">a better understanding of this whole = subject.<br class=3D""></div></div></blockquote><div><br = class=3D""></div><div>I wanted to bump this conversation and topic. I'm = curious to hear more of what came out of the Videolan Coloimetry = workshop, but I also see that the color format proposed elements are now = integrated into <a = href=3D"https://matroska.org/technical/specs/index.html" = class=3D"">https://matroska.org/technical/specs/index.html</a>, as well = as in process in Libav and FFmpeg, and the webm project. I don't mean to = rush the specification work but wanted to note that the proposed color = elements are in use. I suggest that we give this work a status to say if = it is complete or needs more work (and if so, identify what work = remains).</div><br class=3D""><blockquote type=3D"cite" class=3D""><div = class=3D""><div class=3D"">I think it's good if we can have as much = information in Matroska as we<br class=3D"">can. But they probably = should be split between elements that are<br class=3D"">necessary for = accurate playback (list to be defined) and the other<br = class=3D"">information like how the content was captured on camera. The = first<br class=3D"">group should be in the TrackInfo while the others = should be just tags<br class=3D"">(so with string names) that target the = whole file or some chapters<br class=3D"">(each scene probably has = different capture characteristics).<br class=3D""><br class=3D"">=46rom = Frank's list I would put those in the TrackInfo:<br class=3D"">- = MatrixCoefficients<br class=3D"">- Range<br class=3D"">- = TransferFunction<br class=3D"">- Primaries<br class=3D""><br class=3D"">- = BitsPerChannel<br class=3D"">- ChromaSubsamplingHorz / = ChromaSubsamplingVert<br class=3D"">- CbSubsamplingHorz / = CbSubsamplingVert<br class=3D""><br class=3D"">I'm not sure about the = Luminance min/max but maybe it's needed for HDR ?<br class=3D"">Not sure = either about arbitrary RGB chromacity values of the<br = class=3D"">primaries. Are people deviating from the few norms that are = available<br class=3D"">? And have tools for playback ? That seems to = provide the same<br class=3D"">information as the "Primaries" field and = it's never good to have 2<br class=3D"">different set of values = describing the same thing. You never know if<br class=3D"">you have to = write both and which to use for playback especially when<br class=3D"">you= need 8 values to make one set to compare...<br = class=3D""></div></div></blockquote><div><br class=3D""></div><div>I'm = interested in hearing about the use cases for these (ping to Reto). Are = we certain that the "Primaries" element overlaps semantically with the = Primary[R|G|B]Chromaticity[X|Y] elements? Perhaps we should define one = to overrule the other.</div><br class=3D""><blockquote type=3D"cite" = class=3D""><div class=3D""><div class=3D"">Are MaxCLL and MaxFALL = exclusive ? Are they needed for HDR playback ?<br class=3D""><br = class=3D"">I think MasteringMetadata is not needed for playback.<br = class=3D""><br class=3D"">For list of possible values, we shouldn't = follow lists from standards<br class=3D"">that are not freely available. = We should also have the default value<br class=3D"">be 0 when = possible.</div></div></blockquote><div><br class=3D""></div><div>For = much of the semantics used in the proposed colour elements, '2' rather = than '0' has been used to express an 'undetermined' state whereas '0' = has a specific meaning. I think it's consistent to keep it this way as = it better aligns with existing specification (even if non-free) and = existing implementations (free and not free).</div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = class=3D"">And no "reserved" values.<br = class=3D""></div></div></blockquote><div><br class=3D""></div><div>Same = comment as above. If we are deriving a vocabulary from an established = existing standard then I think adopting traditional reserved values is = okay.</div><div>Best Regards,</div><div>Dave Rice</div><br = class=3D""><blockquote type=3D"cite" class=3D""><div class=3D""><div = class=3D"">2016-03-29 19:12 GMT+02:00 Hendrik Leppkes via = Matroska-devel<br class=3D""><<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>>:<br = class=3D""><blockquote type=3D"cite" class=3D"">On Tue, Mar 29, 2016 at = 6:11 PM, Frank Galligan via Matroska-devel<br class=3D""><<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:<br = class=3D""><blockquote type=3D"cite" class=3D""><br class=3D""><br = class=3D"">On Mon, Mar 28, 2016 at 5:05 AM, Steve Lhomme <<a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:<br class=3D""><blockquote = type=3D"cite" class=3D""><br class=3D"">2016-03-17 5:46 GMT+01:00 Frank = Galligan <<a href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>>:<br class=3D""><blockquote = type=3D"cite" class=3D"">OK really no comments for a long time.<br = class=3D""><br class=3D"">On Fri, Feb 19, 2016 at 1:45 PM, Michael = Niedermayer<br class=3D""><<a href=3D"mailto:[email protected]" = class=3D"">[email protected]</a>> wrote:<br class=3D""><blockquote= type=3D"cite" class=3D""><br class=3D"">Hi<br class=3D""><br = class=3D"">On Thu, Feb 18, 2016 at 11:50:27AM -0800, Frank Galligan = wrote:<br class=3D""><blockquote type=3D"cite" class=3D"">Here is the = current proposal, minus the reference to the 265 doc.<br class=3D""><br = class=3D"">The parent element would be Video [E0].<br class=3D""><br = class=3D""><br class=3D"">Element Name: Colour<br class=3D""><br = class=3D"">Level: 4<br = class=3D""><br class=3D"">ID: = [55][B0]<br = class=3D""><br class=3D"">Mandatory: -<br class=3D""><br= class=3D"">Multiple: -<br class=3D""><br = class=3D"">Default: -<br class=3D""><br = class=3D"">Type: m<br = class=3D""><br class=3D"">Description: Settings describing the = colour format.<br class=3D""><br class=3D""><br class=3D"">Element Name: = MatrixCoefficients<br class=3D""><br class=3D"">Level: = 5<br class=3D""><br = class=3D"">ID: = [55][B1]<br = class=3D""><br class=3D"">Mandatory: -<br class=3D""><br= class=3D"">Multiple: -<br class=3D""><br = class=3D"">Default: 2<br class=3D""><br = class=3D"">Type: u<br = class=3D""><br class=3D"">Description: The Matrix Coefficients of = the video used to derive<br class=3D"">luma<br class=3D"">and<br = class=3D""><br class=3D""> = ch= roma values from reg, green, and blue color primaries.<br = class=3D"">For<br class=3D""><br class=3D""> = cl= arity, the value and meanings for MatrixCoefficients<br class=3D"">are<br = class=3D"">adopted<br class=3D""><br class=3D""> = fr= om Table 4 of ISO/IEC 23001-8:2013/DCOR1. (0:GBR, 1:<br = class=3D"">BT709,<br class=3D""><br class=3D""> = 2:= Unspecified, 3: Reserved, 4: FCC, 5: BT470BG, 6:<br class=3D"">SMPTE<br = class=3D"">170M,<br class=3D""><br class=3D""> = 7:= SMPTE 240M, 8: YCOCG, 9: BT2020 Non-constant<br class=3D"">Luminance,<br = class=3D""><br class=3D""> = 10= : BT2020 Constant Luminance)<br class=3D""><br class=3D""><br = class=3D""></blockquote><br class=3D""><blockquote type=3D"cite" = class=3D"">Element Name: BitsPerChannel<br class=3D""><br = class=3D"">Level: 5<br = class=3D""><br class=3D"">ID: = [55][B2]<br = class=3D""><br class=3D"">Mandatory: -<br class=3D""><br= class=3D"">Multiple: -<br class=3D""><br = class=3D"">Default: 0<br class=3D""><br = class=3D"">Type: u<br = class=3D""><br class=3D"">Description: Number of decoded bits per = channel. A value of 0<br class=3D"">indicates<br class=3D"">that<br = class=3D""><br class=3D""> = th= e BitsPerChannel is unspecified.<br class=3D""><br = class=3D""></blockquote><br class=3D"">what would this be set to for old = 16bit rgb, that is 5 bit red<br class=3D"">6 bit green, 5 bit blue = rawvideo.<br class=3D"">This maybe does not matter and iam not strongly = suggesting to add it,<br class=3D"">rather i want to point it out so its = not unintentionally forgotten<br class=3D""></blockquote><br = class=3D""><br class=3D"">I didn't get into RGB here. As you said 565, = 551, there are a good<br class=3D"">amount of<br class=3D"">combinations. = I think DirectShow (or maybe it was DirectDraw) that had<br = class=3D"">R,G,B, and A masks to show which bits belonged to which = channel. I also<br class=3D"">worked with formats like RGBBGR = repeating.<br class=3D""><blockquote type=3D"cite" class=3D""><br = class=3D""><br class=3D""><br class=3D"">[...]<br class=3D""><br = class=3D""><blockquote type=3D"cite" class=3D"">Element Name: = CbSubsamplingHorz<br class=3D""><br class=3D"">Level: = 5<br class=3D""><br = class=3D"">ID: = [55][B5]<br = class=3D""><br class=3D"">Mandatory: -<br class=3D""><br= class=3D"">Multiple: -<br class=3D""><br = class=3D"">Default: -<br class=3D""><br = class=3D"">Type: u<br = class=3D""><br class=3D"">Description: The amount of pixels to = remove in the Cb channel for<br class=3D"">every<br class=3D"">pixel<br = class=3D""><br class=3D""> = no= t removed horizontally. This is additive with<br class=3D""><br = class=3D""> = Ch= romaSubsamplingHorz. Example: For video with 4:2:1<br class=3D"">chroma<br= class=3D""><br class=3D""> = su= bsampling, the ChromaSubsamplingHorz should be set to<br class=3D"">1<br = class=3D"">and<br class=3D""><br class=3D""> = Cb= SubsamplingHorz should be set to 1.<br class=3D""><br class=3D""><br = class=3D"">Element Name: CbSubsamplingVert<br class=3D""><br = class=3D"">Level: 5<br = class=3D""><br class=3D"">ID: = [55][B6]<br = class=3D""><br class=3D"">Mandatory: -<br class=3D""><br= class=3D"">Multiple: -<br class=3D""><br = class=3D"">Default: -<br class=3D""><br = class=3D"">Type: u<br = class=3D""><br class=3D"">Description: The amount of pixels to = remove in the Cb channel for<br class=3D"">every<br class=3D"">pixel<br = class=3D""><br class=3D""> = no= t removed vertically. This is additive with<br class=3D""><br class=3D""> = Ch= romaSubsamplingVert.<br class=3D""></blockquote><br class=3D"">What if = Cr is subsampled more than Cb ?<br class=3D"">That too is rather = obscure, but theres code in FFmpeg to handle such<br class=3D"">jpegs, = so i suspect this case while very rare is not entirely non<br = class=3D"">existent ...<br class=3D""></blockquote><br class=3D""><br = class=3D"">I guess we can add that as well if more people really want = it. Actually<br class=3D"">I<br class=3D"">didn't even have = CbSubsampling* elements at first. I only added that to<br = class=3D"">support the 4:2:1 format that was defined in the first = enum.<br class=3D""><blockquote type=3D"cite" class=3D""><br = class=3D""><br class=3D""><br class=3D""><blockquote type=3D"cite" = class=3D""><br class=3D""><br class=3D"">Element Name: = ChromaSitingHorz<br class=3D""><br class=3D"">Level: = 5<br class=3D""><br = class=3D"">ID: = [55][B7]<br = class=3D""><br class=3D"">Mandatory: -<br class=3D""><br= class=3D"">Multiple: -<br class=3D""><br = class=3D"">Default: 0<br class=3D""><br = class=3D"">Type: u<br = class=3D""><br class=3D"">Description: How Chroma is subsampled = horizontally. (0: Unspecified,<br class=3D"">1:<br class=3D"">Left<br = class=3D""><br class=3D""> = co= llocated , 2: Half)<br class=3D""><br class=3D"">Element Name: = ChromaSitingVert<br class=3D""><br class=3D"">Level: = 5<br class=3D""><br = class=3D"">ID: = [55][B8]<br = class=3D""><br class=3D"">Mandatory: -<br class=3D""><br= class=3D"">Multiple: -<br class=3D""><br = class=3D"">Default: 0<br class=3D""><br = class=3D"">Type: u<br = class=3D""><br class=3D"">Description: How Chroma is subsampled = vertically. (0: Unspecified,<br class=3D"">1:<br class=3D"">Top<br = class=3D""><br class=3D""> = co= llocated , 2: Half)<br class=3D""><br class=3D""></blockquote><br = class=3D"">iam not sure this is enough to specify all variants<br = class=3D"">for 4:2:0 alone there are a few different variants<br = class=3D"">theres mpeg1 style<br class=3D"">mpeg2 progressive and = interlaced<br class=3D"">the mpeg2/mpeg4 style also differs from itself = if the image is fliped<br class=3D"">right-left<br class=3D"">cropping 1 = or 2 lines of the top of mpeg2 yuv420 also results in<br = class=3D"">different variants<br class=3D""></blockquote><br = class=3D""><br class=3D""><br class=3D"">I also didn't get into = interlaced.<br class=3D""><br class=3D""><br class=3D""><br class=3D"">I = don't think we should add enough elements to support every format = that<br class=3D"">was<br class=3D"">ever produced. Opinions?<br = class=3D""></blockquote><br class=3D"">For archival (one of the main = goal here) I think we should.<br class=3D""><br class=3D""><blockquote = type=3D"cite" class=3D"">I think we should probably strive to support = 99% of what is currently<br class=3D"">produced today. Opinions?<br = class=3D""></blockquote><br class=3D"">The problem is that when you = leave 1% out, you need to be sure it's<br class=3D"">possible to = integrate it later. Usually the best approach is to know<br = class=3D"">beforehand how you're going to do it. So in the end it's just = like<br class=3D"">covering it. That's just a general remark though.<br = class=3D""></blockquote><br class=3D"">I don't want to exclude anything = in the future, but I also don't want to<br class=3D"">make something = overly complex/over specified to support a format that will<br = class=3D"">barely see any use.<br class=3D""><br class=3D"">I want to = move forward with this, so how about we make a list and then vote<br = class=3D"">on what we think should be added to the sepc?<br class=3D"">1. = Raw RGB<br class=3D"">2. Raw YUV<br class=3D"">3. Interlaced<br = class=3D"">4. mpeg1 style<br class=3D"">5. mpeg2 pogessive<br = class=3D"">6. mpeg2 interlaced<br class=3D"">7. image flipped = right-left<br class=3D"">8. jpeg Cr subsampled more than Cb<br = class=3D"">9. non-linear color values (DPX scans)<br class=3D""><br = class=3D"">Anything else we should add?<br class=3D""><br = class=3D""></blockquote><br class=3D"">Just my 2 cents, but if you want = to support everything and the kitchen<br class=3D"">sink, you should use = string fields that can be arbitrarily expanded,<br class=3D"">instead of = integer enumerations.<br class=3D""><br class=3D"">- Hendrik<br = class=3D"">_______________________________________________<br = class=3D"">Matroska-devel mailing list<br class=3D""><a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a><br = class=3D"">http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-dev= el<br class=3D"">Read Matroska-Devel on GMane: = http://dir.gmane.org/gmane.comp.multimedia.matroska.devel<br = class=3D""></blockquote><br class=3D""><br class=3D""><br class=3D"">-- = <br class=3D"">Steve Lhomme<br class=3D"">Matroska association = Chairman<br class=3D"">_______________________________________________<br = class=3D"">Matroska-devel mailing list<br class=3D""><a = href=3D"mailto:[email protected]" = class=3D"">[email protected]</a><br = class=3D"">https://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-de= vel<br class=3D"">Read Matroska-Devel on GMane: = http://dir.gmane.org/gmane.comp.multimedia.matroska.devel</div></div></blo= ckquote></div><br class=3D""></body></html>= --Apple-Mail=_6DD19FD8-762E-42A1-B5F1-714BE26639ED-- --===============0710887007492830230== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWF0cm9za2Et ZGV2ZWwgbWFpbGluZyBsaXN0Ck1hdHJvc2thLWRldmVsQGxpc3RzLm1hdHJvc2thLm9yZwpodHRw czovL2xpc3RzLm1hdHJvc2thLm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vbWF0cm9za2Et ZGV2ZWwKUmVhZCBNYXRyb3NrYS1EZXZlbCBvbiBHTWFuZTogaHR0cDovL2Rpci5nbWFuZS5vcmcv Z21hbmUuY29tcC5tdWx0aW1lZGlhLm1hdHJvc2thLmRldmVs --===============0710887007492830230==--