[FFmpeg-user] Questions about w3fdif deinterlacing
adf.lists at gmail.com
Sun Jan 19 12:48:08 CET 2014
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:
>> 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
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
> -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
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
How many frames with -
ffmpeg -i prog-int.ts -vf yadif=1:deint=interlaced -f null /dev/null
frame= 1924 fps=129 q=0.0 Lsize=N/A time=00:00:47.66 bitrate=N/A
seems right -
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
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
[Parsed_idet_0 @ 0x2446580] Multi frame detection: TFF:689 BFF:0
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
[Parsed_idet_0 @ 0x2946480] Multi frame detection: TFF:689 BFF:0
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.
More information about the ffmpeg-user