[MPlayer-users] Comparison of different deinterlace and denoise filters

[D Richard Felker III]

On Wed, Oct 22, 2003 at 05:05:47PM +0200, Matthias Wieser wrote:
> [Automatic answer: RTFM (read DOCS, FAQ), also read DOCS/bugreports.html]
> Am Mittwoch, 22. Oktober 2003 05:38 schrieb D Richard Felker III:
> 
> > > Strange: when recorded without anything, it's interlaced (two pixel
> > > wide lines: two from frame one, two from frame 2, two from frame
> > > one,...), but produced the mentioned artifacts.
> >
> > Yes, this is the only correct way to store interlaced video in 4:2:0
> > format. Unfortunately it's displayed totally wrong, but that's life...
> 
> I have found the reason for the wrong chroma:
> I used
> 
> mplayer /big/Medien/Video/videotest/raw_ntv.avi -ss 00:00:07 -vf 
> crop=680:528:20:22,pp=md -frames 15 -forceidx -vo png -nosound -z 6
> 
> to create the test frames. I crop 22 lines away. If I use
> 
> mplayer /big/Medien/Video/videotest/raw_ntv.avi -ss 00:00:07 -vf 
> crop=680:528:20:24,pp=md -frames 15 -forceidx -vo png -nosound -z 6
> 
> everything is ok! (crop has to be crop=680:528:20:(4*n) )

Yes, that definitely explains it!

> > Once you have interlaced 4:2:0 video like this, you can display it
> > properly (still interlaced) with -vf ilpack.
> 
> When exactly do I need -vf ilpack?
> When I don't deinterlace it (for example grab a kino film as mpeg4) then I 
> think I don't need ilpack.

Only for converting interlaced 4:2:0 (yv12) to interlaced yuy2.
Normally the only purpost of this would be to watch it without
deinterlacing without it looking so horrible.

> > And of course it's ready
> > for deinterlacing or inverse telecine.
> 
> And I don't need lipack for deinterlacing with lb, md or fd.
> 
> Is it right to say, I need ilpack only if I crop n*4+2 lines away?

No. You will ALWAYS ruin the video if your crop offset is not a
multiple of 4. After making a mistake like this, the only way to fix
it is to crop more lines until the combined offset is again a multiple
of 4 (or expand to add black lines).

> > What format are you recording it in? Could you tell me the command
> > lines that gave you the different results?
> 
> Of course:
> mencoder tv:// -tv driver=v4l2:width=720:height=576:\ 
> alsa:brightness=5:contrast=0:saturation=20:volume=40\
> -ovc copy \
> -oac mp3lame -lameopts cbr:br=128 \
> -o Video-`date +%d.%m.-%H%MUhr`.avi -endpos 00:00:10 -v
> 
> for the standard (YV12) video.
> 
> mencoder tv:// -tv driver=v4l2:width=720:height=576:\ 
> alsa:brightness=5:contrast=0:saturation=20:volume=40:outfmt=yuy2 \
> -ovc copy \
> -oac mp3lame -lameopts cbr:br=128 \
> -o Video-`date +%d.%m.-%H%MUhr`-yuy2.avi -endpos 00:00:10 -v
> 
> for the yuv2 video.
> 
> To put it in a nutshell:
> 
> - Yuv2 video produced by a saa7134 card does never give chroma errors. But
>   realtime capture to mpeg4 is slow.

It's slow because it's scaling (converting 4:2:2 to 4:2:0 is a scaling
operation in the chroma planes), and this necessarily ruins the
interlacing. You DO have chroma errors; you just don't know what
you're looking for. There is no possible way to avoid ruining the
chroma with your above yuy2 command line.

> - YV12 video produced by a saa7134 card does only give chroma errors when
>   clipped by not (n*4) lines. You can crop a former recorded YV12 rawvideo

Right.

> - YV12 video produced by a bttv card does give chroma errors except for
>    using "-tv outfmt=yuy2 -vf il=d:d,scale,format=yv12,il=i:i,..."

Yes.

Rich