[FFmpeg-devel] [PATCH] avfilter: add framerate video filter

Andy Furniss adf.lists at gmail.com
Sun Aug 30 23:29:54 CEST 2015


Robert Krüger wrote:
> On Sun, Aug 30, 2015 at 1:45 PM, Andy Furniss <adf.lists at gmail.com>
> wrote:
>
>> Carl Eugen Hoyos wrote:
>>
>>> Robert Krüger <krueger <at> lesspain.de> writes:
>>>
>>> The only other thing I noticed was that the stream seams to be
>>>> marked as interlaced when it comes out of the first il filter,
>>>> which causes warnings like these:
>>>>
>>>> [Parsed_framerate_1  <at>  0x7fa4e3426080] Interlaced frame
>>>> found - the output will not be correct.
>>>>
>>>
>>> This sounds like an issue to me but we probably need an option
>>> for il to disable changing the interlaced flag if another usecase
>>> for the filter was found.
>>>
>>
>> Isn't fields being marked as interlaced correct though?
>>
>> I mean it's not progressive video that is produced, as each field
>> is offset by one line and anything that could process correctly,
>> still needs to know whether a field is top or bottom.
>>
>> I don't know whether the framerate filter can handle fields or not,
>> if it can, there should be code that takes account of top/bottom.
>> If there isn't that code then I guess it really does need
>> de-interlaced progressive full height frames as input.
>>
>>
> I guess the point is that the signal can be viewed as progressive
> after the il filter in deinterleave mode as it has the fields stacked
> on top of each other in each half of the picture. I thought that's
> the whole point of il, to apply filters that were not written with
> interlacing in mind and by this trick (deinterleave, process each
> field like a progressive picture, reinterleave) get some things done
> that would not be possible otherwise. Of course that's not really
> true with respect to picture timing but all progressive spatial
> filters should work using this approach (not taking into account
> potential quality side effects that the broadcast guys know best). I
> think the il filter signaling a progressive picture after
> deinterleaving would be more correct than signaling interlaced but if
> there is no consensus, it could let the user decide this using an
> option.

Yea, I was getting il confused with what tfields (mplayer) or
separatefields would produce.

The thing about using il, though, is that the frame interpolater is
working with images twice as far apart temporally as it would be with
de-interlaced.

I've just done a quick test converting 25i to 30i and the il way is
worse than yadif.

Of course it's just one test with a compressed SD sample which I then
deint and scale with mpv to see on an HD monitor.

If you want to try, I did with this small snooker sample -

https://drive.google.com/file/d/0BxP5-S1t9VEEUUR0QnVYRU8yczQ/view?usp=sharing

ffmpeg -i ~/snooker-short.ts -an -sn -vf 
il=l=d:c=d,framerate=fps=30,il=l=i:c=i il-snk-30i.y4m

ffmpeg -i ~/snooker-short.ts -an -sn -vf 
yadif=1,framerate=fps=60,interlace=scan=tff:lowpass=0 ya-snk-30i.y4m

mpv -fs -vf=lavfi=[yadif=1] ...

The motion on the cue especially, is far better on the latter.
Field stepping with mpv [.] shows the "blurring" on everything is 
tighter on the latter.


More information about the ffmpeg-devel mailing list