-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/05/15 11:29, Michael Niedermayer wrote: > On Thu, May 21, 2015 at 08:20:48AM +0100, tim nicholson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On 19/05/15 16:50, Michael Niedermayer wrote: >>> On Tue, May 19, 2015 at 03:35:42PM +0100, tim nicholson wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>> On 19/05/15 14:11, Michael Niedermayer wrote: >>>>> On Tue, May 19, 2015 at 12:07:24PM +0100, tim nicholson wrote: >>>>>> On 19/05/15 01:33, Michael Niedermayer wrote: >>>>>>> [...] >>>>> the avchroma locations are explained by the ascii art above the en um >> : >>>>> * X X 3 4 X X are luma samples, >>>>> * 1 2 1-6 are possible chroma positions >>>>> * X X 5 6 X 0 is undefined/unknown position >>>>> >>>>> and from this the english directions are exactly where the chroma >>>>> samples are located, this also matches how H264 defines chroma >>>>> locations. >>>> >>>> I cannot get the ascii art to make sense to me at all, it just does n' >> t >>>> click. I do no see how you can represent "co-siting" in ascii art w it >> h a >>>> single character and the "3" position certainly doesn't do it for m e! >>> >>> ascii art improved >>> does it make sense now ? >>> >> >> Better, but I still cannot see the difference between say 3 and 4, or 1 >> and 2. >> >>> [...] >> >> My understanding of S377 using 2/3 ascii chars/pixel is:- >> >> 00h:- >> >> YC Y- YC -Y- >> YC Y- YC -Y- >> YC Y- YC -Y- > > S377-2009 speaks about the first sample of the image only > "The first luma sample of the image is co-sited with the first color d ifference sample(s), as in ITU-R Rec > 601, SMPTE 314M 4:1:1 or MPEG-2 4:2:2." >
...and ITU-R Rec 601 dicates "Orthogonal, line, field and frame repetitive. CR and CB samples co-sited with odd (1st, 3rd, 5th, etc.) Y samples in each line" > Your ASCII art matches my interpretation of this though 00h can be > more than 4:2:2, it explicitly also lists 4:1:1 agreed. > > >> >> 01h:- >> >> Y- C- Y- C- Y- >> Y- C- Y- C- Y- >> Y- C- Y- C- Y- > > This implies 4:4:4 I was indicating sample sites, which I then qualified with a:- "Not all samples are retained dependening upon the subsampling scheme." > > > Y- C- Y- Y- C- Y- > Y- C- Y- Y- C- Y- > Y- C- Y- Y- C- Y- > > would be possible too > not to mention the mxf text for 01h > "The color sample is sited at the point horizontally midway between th e luma sample on each line." > does not say which luma samples are used for the midpoint > also it speaks about "color sample" while 00h speaks about > "color difference sample(s)" > color samples would be RGB, difference Cb Cr. the MXF spec isnt > really wording this very unambigously > > >> >> 03h:- >> >> Y- Y- >> - -- C- -- >> Y- Y- > > This ascii art seems to be faulty in some form it looks like > chroma had more positions than luma horizontally > Seems to have picked up an extra dash from what I wrote... 1 c to 2 Y horizontally and vertically > >> >> 05h:- >> >> YCr Y- YCr >> YCb Y- YCb >> YCr Y- YCr >> > >> 06h:- >> >> >> Y- Y- Y- Y- >> C- C- C- C- >> Y- Y- Y- Y- > > The text from the spec is > "The color sample is sited at the point vertically midway between the luma sample on each column, as in > MPEG-2 4:2:0." > > i think your ascii art matches how i would interpet it for 4:4:0 or > 4:4:4, not sure if you intended this to be not 4:2:0 I refer to my previous qualification:- "Not all samples are retained dependening upon the subsampling scheme." Which matches how S413m tries to explain it by showing all sample sites even though some are discarded. Not withstanding any of this don't let it hold up the patch, I twas not my intention to bikeshed just trying to get my head around whats right. > > > [...] > > - -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBAgAGBQJVXeJhAAoJEAwL/ESLC/yDLXAIALtpwEEHV/FdM+ClziRTjSEu pVL5pIMvBnR1V/QpXv6n00gFcGdYUBWOTH2HrKgcW+3gY64ofyhukm0k4vTaV5HE zoSbne33QKaoN/x9LSiiCLPn5oMmtOLQornhLLUxHp8aXMGl66ejlUJzJSQTfxHL ME4tV1+bZz7HOJlfFOWPI9+2DNI3eroRqguNHr4S8HMVY3NhH8ysuCueOcqLNoAQ zWGI/tPsuirTrvRt0iGC/iJhoh6PknVnndYoiMlYOzZs3/0294i9V3qEaQMgLmmr 9dD0XHUkTdo0Y7CP2zZZYDwz6KfWhP7sjmwZ6eIyI7wUkthsVKBFLD+x1tfIU/M= =KFhi -----END PGP SIGNATURE----- _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
