Implement deinterlacing using ffmpeg 3.x

[korli]

ffmpeg 3.x deprecates the deinterlacing API.

It needs to be reimplemented using libavfilter. See ​TODO

An example: ​https://git.reviewboard.kde.org/r/126992/diff/1/

I don't know how to test this feature though. x86 and x86_64 have already ffmpeg 3.x as default.

[Barrett]

Isn't going to be a pain maintaining the plugin this way?

[pulkomandy]

Why so? Libavfilter is available in ffmpeg 0.10 as well and we can use the modern API for it as well. It may even help solving some problems and hacks around guessing the framerate when we play a video.

[Barrett]

I've been recently looking at a few issues of our 0.10 ffmpeg and I'm under the impression that bugs among the two versions are mining our capacity to develop it further. If that API wasn't finalized in 0.10 I can expect a lot of possible discrepances with 3.x.

EDIT

With that I'm not saying it shouldn't be done, I've just pointed out the doubt.

[pulkomandy]

From what I saw, most of our API problems were because we are using APIs from the 0.7 or 0.8 days (when stippi wrote most of our ffmpeg add-on). These were still working on 0.10, but after that they were deprecated then dropped.

If we upgrade to using up-to-date 0.10 APIs, these are usually still supported in the 2.8 series (I have no idea about 3.x yet). The divergence isn't big enough yet to make two different plugins (ffmpeg0.10 and ffmpeg3), but if that changes in the future, we may go this way (just duplicate the sources, then remove the respective part of the #ifdefs)

Finally, ffmpeg provides us with defines allowing to cleanly test for library versions, and each time I introduced a version-dependant change, I made sure to find the exact version of the lib where the change was made. This way it is clear which of these we need to keep, and which can be dropped, depending on which ffmpeg versions we are shipping.

[Barrett]

I pointed out this project in past :

​https://github.com/h4tr3d/avcpp

It requires C++0x and ffmpeg 3.0 but I guess giving the size of the code we could backport it easily. I've not tested it myself already, but it seems not so much different than our codecs API, switching to this library should be considered.

[pulkomandy]

So we would switch from the well-known and somewhat documented ffmpeg, to a wrapper with no documentation and no guarantees on ABI stability? I don't see much win in doing that. We won't be able to decode more formats, we may hit limitations in the wrapper, etc. And, we can't make it work with gcc2, so we would have to rewrite the wrapper anyway.

[korli]

If someone can point to media files making use of this feature, it would help.

[Barrett]

I will try to allocate some time to do this work ASAP.

@korli what do you mean exactly?

@PulkoMandy, relating to the ticket description, wouldn't testing for regressions be enough for unsupported archs?

[pulkomandy]

Unsupported archs are ARM and PowerPC. We are going to release beta1 as a gcc2hybrid + x86_64, which means all 3 of these should be working. But as Korli said, interlaced files seem quite uncommon nowadays, and I don't remember a bugreport submitting one. Not a reason for closing the ticket, but we should find at least one file to test our changes :)

[Barrett]

Ah ok, now I get the meaning ;)

[pulkomandy]

And we do have a sample file in #12650.

[korli]

Replying to pulkomandy:

And we do have a sample file in #12650.

I had another look, and the file isn't interlaced, so the problem is another one.

[jua]

ffmpeg has a collection with plenty of sample files at ​https://samples.ffmpeg.org/

e.g. this one is interlaced: ​https://samples.ffmpeg.org/MPEG2/dothack2.mpg

[korli]

Implemented in hrev51303, tested with dothack2.mpg (thanks jua!)