Opened 3 years ago

Closed 2 years ago

#12731 closed enhancement (fixed)

Implement deinterlacing using ffmpeg 3.x

Reported by: korli Owned by: Barrett
Priority: normal Milestone: Unscheduled
Component: Audio & Video/Codecs Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Change History (14)

comment:1 Changed 3 years ago by Barrett

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

comment:2 Changed 3 years ago by 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.

comment:3 Changed 3 years ago by 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.

Last edited 3 years ago by Barrett (previous) (diff)

comment:4 Changed 3 years ago by 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.

comment:5 Changed 3 years ago by 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.

comment:6 Changed 3 years ago by 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.

comment:7 Changed 3 years ago by korli

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

comment:8 Changed 2 years ago by Barrett

Owner: changed from pulkomandy to Barrett
Status: newassigned

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?

comment:9 Changed 2 years ago by 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 :)

comment:10 Changed 2 years ago by Barrett

Ah ok, now I get the meaning ;)

comment:11 Changed 2 years ago by pulkomandy

And we do have a sample file in #12650.

comment:12 in reply to:  11 Changed 2 years ago by 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.

comment:13 Changed 2 years ago by 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

comment:14 Changed 2 years ago by korli

Resolution: fixed
Status: assignedclosed

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

Note: See TracTickets for help on using tickets.