Robert Krüger wrote:
On Sun, Aug 30, 2015 at 1:45 PM, Andy Furniss <adf.li...@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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
