[FFmpeg-user] Questions about w3fdif deinterlacing

[Andy Furniss]

Christian Ebert wrote:
> * Carl Eugen Hoyos on Saturday, January 18, 2014 at 19:45:33 +0000
>> Christian Ebert <blacktrash <at> gmx.net> writes:
>>> Doesn't yadif have its own detection:
>>> yadif=deint=interlaced
>>> ?
>>
>> No, it does not have detection.
>>
>> MPEG-2 streams contain information about interlaced /
>> non-interlaced which is used by yadif if you set it so.
>> The problem is that (where I live, and - I suspect -
>> where you live) *all* dvb streams are marked as
>> "interlaced" (because they are encoded with the
>> hardware encoder set to "interlaced"), no matter if
>> they are progressive (imagine a movie or soap) or
>> interlaced (sports, news).
>
> This sounds like deint=interlaced reacts to a global flag whereas
> the manual makes it sound like to work on a frame by frame basis:
>
> 1, interlaced
>      only deinterlace frames marked as interlaced

"hardware encoder set to interlaced" does not mean a single global flag 
- it's on every frame whether it's interlaced or not, this is the 
general rule for DVB broadcast.

Of course there are exceptions that prove rules :-)

67 meg indirect link

http://www.datafilehost.com/d/1293ad4e

I post this because it lets you answer your questions by black box testing.

> In practice this means that I just run idet before yadif in the
> filter chain:
> -vf idet,yadif
> and yadif will deinterlace (or not) on a frame by frame basis?
>
> Or what is the difference between
>
> -vf yadif=deint=interlaced
>
> and
>
> -vf idet,yadif

Some tests on my mixed stream with yadif=1 which like w3fdif will make 
50fps from 25i but in this test sometimes only on some frames.

analyse sample with ffprobe -

how many frames -

ffprobe -show_frames prog-int.ts 2>/dev/null | grep video | wc -l

1164

what are the flags (on older ffprobe it was -A 17)

ffprobe -show_frames  prog-int.ts 2>/dev/null | grep video -A 19 | grep 
interlac | uniq -c

     404 interlaced_frame=0
     760 interlaced_frame=1

How many frames with -

ffmpeg -i prog-int.ts -vf yadif=1:deint=interlaced -f null /dev/null
<snip>
frame= 1924 fps=129 q=0.0 Lsize=N/A time=00:00:47.66 bitrate=N/A

seems right -

echo $[404+760+760]
1924

Test -vf idet,yadif=1

 From this thread we already know this will correct parity - although 
the sample provided was 100% detected correctly.

I don't know what would happen if the detection was less clear (but then 
I suppose you may not notice even if the parity was wrong on still frame 
runs)

ffmpeg -i prog-int.ts -vf idet,yadif=1 -f null /dev/null

frame= 2326 fps= 58 q=0.0 Lsize=N/A time=00:00:47.50 bitrate=N/A

[Parsed_idet_0 @ 0x2446580] Single frame detection: TFF:599 BFF:0 
Progressive:444 Undetermined:120
[Parsed_idet_0 @ 0x2446580] Multi frame detection: TFF:689 BFF:0 
Progressive:474 Undetermined:0

echo $[1164+1164]
2328

so apart from a 2 frame diff looks like all are deinterlaced and the 
detection does well but different (it may be more accurate than the 
flags WRT screen content for this sample)

next test -vf idet,yadif=1:deint=interlaced

ffmpeg -i prog-int.ts -vf idet,yadif=1:deint=interlaced -f null /dev/null

frame= 1852 fps= 54 q=0.0 Lsize=N/A time=00:00:47.50 bitrate=N/A

[Parsed_idet_0 @ 0x2946480] Single frame detection: TFF:599 BFF:0 
Progressive:444 Undetermined:120
[Parsed_idet_0 @ 0x2946480] Multi frame detection: TFF:689 BFF:0 
Progressive:474 Undetermined:0

echo $[474+689+689]
1852

So it looks like idet does control the result here.

Of course as Carl Eugen said if you know the content then using idet to 
control may not be the best thing.

For example I don't know what happens to Undetermined as they are 0 here.