[Bug] finish implementation of (ffmpeg-3.0,) ffmpeg-3.1 and ffmpeg-3.2 support

[nanu-c]

Ultrastar is not compatible with ubuntu 16.10 and all derivates from that because they dropped support for ffmpeg 2.8

[nanu-c]

This one is related #143

[douardda]

And also Debian stretch since it comes with ffmpeg 3.2. The correct title of this issue should probably includes ffmpeg 3.2 as well (are there any distro with ffmpeg 3.1?)

[brianch]

I will try to create the headers for ffmpeg 3.2, so it gets easier to test when trying to fix this.

But that is the easiest part, actually fixing the ffmpeg 3+ support is the real work, when I tried some months ago I was kinda lost on how to do it.

[ftoledo]

Hi. i can working on debian package. i want help to colabore if somebody work on it. What is the actual status of ffmpeg 3.2 support? Thanks!

[basisbit]

@ftoledo currently, only up to ffmpeg 2.8 is supported. There were (again!) big api changes in ffmpeg. brianch translated the ffmpeg headers for use in freepascal, but the actual code in srv/media/UVideo.pas needs to be adapted to not use the deprecated and now dropped functions. Sadly, even most tutorials on what functions to call in what manner out there aren't updated to use the new api, either. If someone of you knows where to find a list about which of the library (libavformat, avcodex, swscale, .....) versions relate to which ffmpeg version numbers, that would already be very helpful.

[nanu-c]

Hey basisbit, you can look this up in the package dependencies for the debian ffmpeg 3.2 https://packages.debian.org/stretch/ffmpeg

    dep: libavcodec57 (>= 7:3.2.2)
        FFmpeg library with de/encoders for audio/video codecs - runtime files 
    or libavcodec-extra57 (>= 7:3.2.2)
        FFmpeg library with additional de/encoders for audio/video codecs 

    dep: libavdevice57 (>= 7:3.2.2)
        FFmpeg library for handling input and output devices - runtime files 

    dep: libavfilter6 (>= 7:3.2.2)
        FFmpeg library containing media filters - runtime files 
    or libavfilter-extra6 (>= 7:3.2.2)
        FFmpeg library with extra media filters - runtime files 

    dep: libavformat57 (>= 7:3.2.2)
        FFmpeg library with (de)muxers for multimedia containers - runtime files 

    dep: libavresample3 (>= 7:3.2.2)
        FFmpeg compatibility library for resampling - runtime files 

    dep: libavutil55 (>= 7:3.2.2)
        FFmpeg library with functions for simplifying programming - runtime files 

    dep: libc6 (>= 2.14) [amd64]
        GNU C Library: Shared libraries
        also a virtual package provided by libc6-udeb 

    dep: libc6 (>= 2.17) [arm64, ppc64el]

    dep: libc6 (>= 2.19) [mips, mipsel]

    dep: libc6 (>= 2.7) [armel, armhf, i386, mips64el, s390x]

    dep: libpostproc54 (>= 7:3.2.2)
        FFmpeg library for post processing - runtime files 

    dep: libsdl2-2.0-0 (>= 2.0.4)
        Simple DirectMedia Layer 

    dep: libswresample2 (>= 7:3.2.2)
        FFmpeg library for audio resampling, rematrixing etc. - runtime files 

    dep: libswscale4 (>= 7:3.2.2)
        FFmpeg library for image scaling and various conversions - runtime files 

    dep: libva1 (>= 1.7.3)
        Video Acceleration (VA) API for Linux -- runtime 

or on the donwload page of ffmpeg where you can download the right version of the lib as tarball https://ffmpeg.org/download.html FFmpeg 3.2.2 "Hypatia"

libavutil      55. 34.100
libavcodec     57. 64.101
libavformat    57. 56.100
libavdevice    57.  1.100
libavfilter     6. 65.100
libavresample   3.  1.  0
libswscale      4.  2.100
libswresample   2.  3.100
libpostproc    54.  1.100

[nanu-c]

there is also this handy deprecation list which states what to replace with what: https://www.ffmpeg.org/doxygen/2.8/deprecated.html https://www.ffmpeg.org/doxygen/3.0/deprecated.html https://www.ffmpeg.org/doxygen/3.1/deprecated.html https://www.ffmpeg.org/doxygen/3.2/deprecated.html

[nanu-c]

for the avcodec_default_release_buffer() deprecation there is a fix for the same error in another library but in c++. Maybe it helps: https://trac.macports.org/attachment/ticket/51223/patch-ffmpeg3.txt And sorry, I don't understand pascal, so I can't help you with pr

[basisbit]

well, we have to support about any version with api changes inbetween ffmpeg 2.8 and 3.2. Thus, we'll need a table of which version of ffmpeg related to which lib-versions, then check for these lib version ranges in the code and call the required functions accordingly. Testing also will be a nightmare. I still can't believe how such a widely used project like ffmpeg can have such an unstable API and not provide any stable mapping / binding library at all. I'd rather prefer doing development on the USDX project instead of having to adapt to every single API change of ffmpeg (and these happen way too often!).

[nanu-c]

i understand your angry, but ffmpeg is mostly a one-man-show and the one-man don't care about documentation and api breaks. That's also the reason for the fork libav which tries to have a more stable api. there is a good quote:

it seems that every media project is bundling a local copy of FFmpeg because of fundamental incompatibilities even between minor releases.

I found it there https://lwn.net/Articles/650816/ so maybe this is the way. Don't depend on the ffmpeg provided by the system, but use your own version shipped with usdx

FFmpeg 2.8.10 "Feynman"

libavutil      54. 31.100
libavcodec     56. 60.100
libavformat    56. 40.101
libavdevice    56.  4.100
libavfilter     5. 40.101
libavresample   2.  1.  0
libswscale      3.  1.101
libswresample   1.  2.101
libpostproc    53.  3.100

FFmpeg 3.0.5 "Einstein"

libavutil      55. 17.103
libavcodec     57. 24.102
libavformat    57. 25.100
libavdevice    57.  0.101
libavfilter     6. 31.100
libavresample   3.  0.  0
libswscale      4.  0.100
libswresample   2.  0.101
libpostproc    54.  0.100

FFmpeg 3.1.6 "Laplace"

libavutil      55. 28.100
libavcodec     57. 48.101
libavformat    57. 41.100
libavdevice    57.  0.101
libavfilter     6. 47.100
libavresample   3.  0.  0
libswscale      4.  1.100
libswresample   2.  1.100
libpostproc    54.  0.100

FFmpeg 3.2.2 "Hypatia"

libavutil      55. 34.100
libavcodec     57. 64.101
libavformat    57. 56.100
libavdevice    57.  1.100
libavfilter     6. 65.100
libavresample   3.  1.  0
libswscale      4.  2.100
libswresample   2.  3.100
libpostproc    54.  1.100

[basisbit]

it seems that every media project is bundling a local copy of FFmpeg because of fundamental incompatibilities even between minor releases.

I found it there https://lwn.net/Articles/650816/ so maybe this is the way. Don't depend on the ffmpeg provided by the system, but use your own version shipped with usdx

I get sick reading the comments on that page. How come people forget to quickly what this is all about and what free / libre open source software development means. It is not about showing off and being the most successful project/fork/... but instead about incrementally continuing development of the software while at the same time being independent from single people. On that page there is lots of ranting about who did what from which project and that "copying" the work from the other fork would be bad.

Anyways, back to topic: I develop mainly for windows and there, we just ship one readily compiled and tested version of ffmpeg with the game. Don't have much experience with releasing for linux/bsd based distributions. So maybe @AlexanderS @brianch @kamischi @raspbeguy or any of the other developers can decide / comment on if we should ship our own version of ffmpeg or not. From what I heard so far, the suggestion was to not add our own versions of ffmpeg to our shipping builds because that would be additional work.

[brianch]

I pushed a branch with the ffmpeg 3.2 headers and the changes I had removed from master about the new ffmpeg versions on the configure file.

@basisbit, about a compatibility list, I like this page: https://abi-laboratory.pro/tracker/timeline/ffmpeg/

Click for example on the percentage on the 'Backward Compatibility' column, it will then open the list of level of compatibility per library, if you click again on one of the percentages, it will detail all the functions/symbols that were removed or added to that library, e.g.: https://abi-laboratory.pro/tracker/compat_report/ffmpeg/2.8.10/3.0/44ac4/abi_compat_report.html

But after that you would need to google how to replace the removed function.

On the bright side, there was a very big compatibility break on 3.0 but nothing that serious after that, so if we could make it work with 3.2 probably 3.0 and 3.1 would work without additional modifications.

This repository below could be a good reference, you only need to put the "AV_" prefix on the "PIX_FMT...." constants for it to compile with ffmpeg 3.2: https://github.com/illuusio/ffmpeg-tutorial

But we won't need all those defines about the resample lib, we can simply use libswresample as we don't support libAV anyway, the repository it forked from (https://github.com/mpenkov/ffmpeg-tutorial) is more clear in this point, but it has more deprecated things that prevent it from compiling.

-- About packaging, in Archlinux there's a package with ffmpeg 2.8 in the 'extra' repository (I mistakenly said it was on the AUR repo the last time I spoke with @basisbit), and the 'ultrastardx-git' package (this one is from AUR) use it as a dependency. If ffmpeg is to be shipped with USDX, this would be the only way IMHO (and still a ugly one), it would be an horrendous practice to try to put it on the same package as the game itself.

Distros that have an 'ffmpeg-compat' package are easier to make packages to, unfortunately I don't think this is the case with Debian.

On the other hand, one positive point about making all this work is that other FPC projects can benefit from it and be able to use recent ffmpeg versions.

[kamischi]

At least as long as i was working on the ffmpeg headers, in most cases I only updated the header files. Anything else had to be changed only very rarely, which can be seen by the small number of IFDEFs in the rest of the code. In this way, we could simply rely on the version, which was found by configure and did not need to ship our own version of ffmpeg for linux as well as for the fink version on OSX. The standalone version for OSX shipped with its own version, simply copied from the fink version. No problem with interference, because this was restricted to the application bundle.

There were two approaches to make life easier with ffmpeg. One is with an additional C-wrapper, which would expose a stable API for Pascal. The second is to teach tools like h2pas the missing tricks for an automatic translation of the headers. However, I presume that both approaches will only catch minor changes and not the big one as from 2.8 to 3.2.

[AlexanderS]

@ftoledo I think I have a working Debian package, once the ffmpeg/libav version of Debian is supported.

@all:

One is with an additional C-wrapper, which would expose a stable API for Pascal.

There was already code for this stuff. I think it was the mediaplugin branch in the svn: https://sourceforge.net/p/ultrastardx/svn/HEAD/tree/branches/experimental/mediaplugin/ This would remove the need for pascal header files for ffmpeg. But the autoconf/automake stuff will get a bit more difficult and the build process will require a working c/c++ compiler.

[ftoledo]

@AlexanderS very good... as performous user i like to have ultrastardx in debian too. (unfortunately performous are broken in unstable now https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=847819, related to ffpmeg) so i have no karaoke player on gnu/linux =( )

[brianch]

The mediaplugin idea mentioned by @AlexanderS is very interesting, I wonder how much work it would take to put it to work again, but update the pascal code for ffmpeg 3+ seems to be a faster way to make we compile in recent systems again, and if that's true I think we should do this before making a change to C for ffmpeg, it wouldn't be a waste of effort, since the C could then be translated from the updated pascal code.

I agree with @kamischi that the actual code didn't had to be changed that often, just the headers (and nowadays this is just a day or so of work), things get deprecated fast but at least they aren't removed with the same speed. The problem for us was that ffmpeg 3 got hid of a lot of stuff that was deprecated and that now need to be done a bit different than it was before.

If we could manage to keep up with ffmpeg, the biggest problem with packaging now, the lack of a version we support in the repositories of distros, would be solved.

[basisbit]

If you are talking about accinerella, I just got the main developer to change license from GPLv3 to GPLv2+, so we can also use it. @lukeIam (one of the vocaluxe devs) also adapts accinerella once in a while, so maybe adding accinerella support would be worth it.

[s09bQ5]

While we still have to manually add support for each new FFmpeg version, even if it is binary compatible to an already supported one, FFmpeg 3.0, 3.1, and 3.2 are supported now since #235 and #239 have been merged.

[basisbit]

Let's close this one and open another one for accinerella support

[mattcurrie]

If anyone is trying to install on macOS Sierra and getting this error:

Unsupported ffmpeg version, most recent version supported is 3.2.

Try this:

brew install homebrew/versions/ffmpeg28

[cRaZy-bisCuiT]

Actually I can't build with either ffmpeg 3.2.2 from the jessie backports nor using ffmpeg 3.2 (3.2.0) from the sources. The configure script still complains. What's the matter?

Could we make USDX compatible with any 3.2.x version as well as the recent 3.3.1 and 3.3.2?