[FFmpeg-devel] [RFC] Interlaced material, pix_fmt change, auto-inserted scaler

[Michael Niedermayer]

On Mon, Jul 25, 2011 at 06:12:25PM +0100, Mark Himsley wrote:
> Sorry for a very long rational for a very short patch.
>
> Cutting to the chase: What do you think of the attached patch?
>
>
> Basically: I have been getting some strange colour artefacts when I  
> convert from yuv420p to yuv422p on interlaced material.
>
> Here is a demonstration clip:
> http://commondatastorage.googleapis.com/himslm01/976_0003_01.AVI
>
> The clip is an original DV25 clip created in a camera. The important  
> part is the first 200 frames where there is a whip-pan across a bright  
> green light switch.
>
> If I convert that clip to a 422 format, I've chosen DV50 for ease of  
> this demonstration but I have also created IMX30 MPEG 2 video and it  
> shows the same issue I'm trying to describe:
>
> ffmpeg -loglevel debug -i 976_0003_01.AVI -vcodec dvvideo -pix_fmt  
> yuv422p -acodec pcm_s16le 976_0003_01.DV50.avi
>
> (full output of that command is below)
>
> If I look at the 422 output at field rate (for instance in a video  
> editor) then I can see that something is wrong with the chroma.
>
> I think I can also demonstrate that using FFmpeg by using the yadif  
> video filter on the original 420 and the new 422 copy:
>
> ffmpeg -loglevel debug -i 976_0003_01.DV50.avi -vframes 200 -vf yadif=1  
> -r 50 -f image2 422%04d.png
>
> frame 122 is a good one to compare,
>
> png taken from original footage:
> http://commondatastorage.googleapis.com/himslm01/orig0122.png
>
> png taken from conversion to 422:
> http://commondatastorage.googleapis.com/himslm01/4220122.png
>
> You can see the big difference.
>
>
> But I noticed that if I specifically add an interlaced aware scale in  
> the video filter, the chroma is correct.
>
> ffmpeg -loglevel debug -i 976_0003_01.AVI -vcodec dvvideo -pix_fmt  
> yuv422p -acodec pcm_s16le -vf scale=0:0:interl=-1 976_0003_01.DV50-vf.avi
>
>
> The attached patch makes scale default to being interlaced aware. Is  
> that a bad thing?
>
>
> If you feel this patch will be ok I'll send it again along with updated  
> documentation with no training white space.

it should be ok

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20110726/bb2c127c/attachment.asc>