On Thu, Nov 06, 2003 at 10:18:18PM +0100, Stefan Lucke wrote:
> On Thursday 06 November 2003 20:56, Roman Shaposhnick wrote:
> > On Wed, Nov 05, 2003 at 11:32:06PM +0100, Stefan Lucke wrote:
> > >
> > > It would be interesting to read a comment form one with
> > > IEC 61834 PAL specs.
> > Here's what Adam Wilt says about this stuff:
> > http://www.adamwilt.com/pix-sampling.html:
> > "Co-sited 4:2:0 sampling is used in 625/50 ("PAL") DV and DVCAM formats. Cr and
> > Cb samples are on alternate lines in each field (a frame view would show two lines of
> > YCr,Y pairs, then two lines of YCb,Y pairs). Note that this is different from the 4:2:0
> > chroma sample positioning in JPEG, MPEG, and H.261 formats!"
> Thats the part I do not understand.
It's a bit confusing to me as well. Here's a letter I've sent to
ffmpeg-devel regarding this issue, but haven't got any response yet.
Can you comment on it if there's anything wrong with what I stated,
please ? [ I probably should've crospot it, in the first place... oh well!]
From: Roman Shaposhnick <Roman.Shaposhnick@...>
Subject: [Ffmpeg-devel] DV 4:2:0 is not YUV420 ?
A week or so ago our friendly neighbors from libdv discovered
that libdv mishandles chroma information when sampling is 4:2:0.
The problem boiled down to the fact that in DV chroma is
filed-based as opposed to frame-based one. Here's how Adam
Wilt describes it: http://www.adamwilt.com/pix-sampling.html
"Co-sited 4:2:0 sampling is used in 625/50 ("PAL") DV and DVCAM formats. Cr and
Cb samples are on alternate lines in each field (a frame view would show two lines of
YCr,Y pairs, then two lines of YCb,Y pairs). Note that this is different from the 4:2:0
chroma sample positioning in JPEG, MPEG, and H.261 formats!"
Now, obviously ffmpeg's DV codec does things on a frame-based level
as opposed to a field based one, thus when codec processes Y and Cr/b
blocks it does this:
freshly composite sampling plane
uncompressed Cr data for one frame (2 interlaced fields)
r00 r01 r02 r03 r04 r05 r06 r07 (y00, r00) y01 (y02, r01) y03 .....
r10 r11 r12 r13 r14 r15 r16 r17 (y10, b00) y11 (y12, b01) y13 .....
............ ---> (y20, r10) y21 (y22, r11) y23 .....
^ (y30, b10) y31 (y32, b11) y33 .....
uncompressed Cb data /
b00 b01 b02 b03 b04 b05 b06 b07
b10 b11 b12 b13 b14 b15 b16 b17
Where the correct one for DV should look like this:
(y00, r00) y01 (y02, r01) y03 .....
(y10, r10) y11 (y12, r11) y13 .....
(y20, b00) y21 (y22, b01) y23 .....
(y30, b10) y31 (y32, b11) y33 .....
Of course this doesn't seem to be a YUV420 sampling pattern ffmpeg is used
to deal with.
Thus my questions:
1. Does all of what I said above make any sense ?
2. If it does, is DV the only one to use this sort of twisted yuv420 sampling ?
3. What would be the best way to fix it in ffmpeg, I'd imagine introducing
something like YUV402 (pun intended ;-)).
P.S. Here's the original e-mail for your reference:
From: Mike Grant <mgg@...>
Subject: Re: [libdv-dev] libdv produces strange interlaced frames
Dan Dennedy wrote:
> Then, perhaps the DV chroma subsampling is field-based and libdv is
> treating it frame-based.
Actually, I'm embarrassed to say we've known about this for a long time,
but never quite got around to mailing the list about it. A student
(Karl Sharman) at the University here found it and fixed it. I believe
the error was indeed due to libdv applying the chroma across two lines
from separate fields. You can find a sample PAL DV file and several
pictures highlighting the problem at:
The important one is
where it is clear that the orange of the ball is being incorrectly used
on the white of the background. Compare with
which is our fixed version. There's also some pictures from Sony and
Pinnacle codecs for comparison.
If you wish to use it, his change description is at
but I believe they do things in a different fashion to the original. It
also changes several other parts of libdv that may be worth examining
(I've not looked at it in detail, or I'd probably have actually managed
to mail the list about it..).
I can also make a diff of our current source tree if that would be
helpful (it has some bits to make a Win32 port easier and some Python
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
Ffmpeg-devel mailing list