[FFmpeg-trac] #5057(undetermined:new): master broke AVCodecContext compatibility with LibAV project

[FFmpeg]

#5057: master broke AVCodecContext compatibility with LibAV project
-------------------------------------+-------------------------------------
             Reporter:  jyavenard    |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:               |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by jyavenard):

 Replying to [comment:11 michael]:
 > I have no real oppinion on it but IIRC there was noone who really argued
 to keep it.

 I guess because I wasn't there :)

 > But that aside, i dont fully understand how this affects firefox. No
 distro which used FFmpeg had this compatibility mode enabled. If the
 binary packages from distros where "compatible enough" then that was by
 chance of only using a small subset of their features, there certainly was
 no compatibility when the mode wasnt enabled (and it was not enabled in
 any official packages from any distro AFAIK).

 It seems that I need to give a little bit of background information on how
 firefox uses ffmpeg. I won't talk about distro compiling their own and
 however they are packaging it : this is not relevant to what I'm talking
 about.

 I'm only referring to the binary anyone can download from mozilla.org web
 site (e.g. something like https://www.mozilla.org/firefox/new/?scene=2
 #download-fx)

 We do not ship firefox with ffmpeg, nor do we recommend people install
 ffmpeg, we do not link against any ffmpeg libraries either.
 When you start firefox and you attempt to play some media, it will check
 at what is available: gstreamer, flash, ffmpeg, whatever.

 To detect if ffmpeg is available, we attempt to dlopen in order
 libavcodec-ffmpeg.so.56, libavcodec.so.56, libavcodec.so.55,
 libavcodec.so.54, libavcodec.so.53

 That entire process of finding which version of ffmpeg is available is
 very hacky to be honest, but we haven't found a better one yet.

 Once the library has been opened, we attempt to resolve the symbol
 avcodec_version and we query it to find out which version we have.
 While the code we have was implemented in a manner that is as cross-
 compatible between all versions as possible, we obviously need different
 code for different version.

 Note that I no time do we know if we're dealing with libav or FFmpeg ; and
 I'm yet to see a reliable method to do so that will work for all versions
 supported (anything between 53 and 56)

 Now all of this has always worked, because all the binary structures we
 use are binary compatible between either libav or FFmpeg: that is
 AVCodecContext, AVFrame and AVPacket

 So to decode a sample, the AVPacket and AVCodecContext we build will work
 no matter of which version we use (we have 3 different version of the same
 code: one for 53, on for 54 and one for 55 (as 56 works with the 55 code).

 Now, should libav decide to not follow FFmpeg lead and use different size
 for some fields, that fundamental requirement will no longer work. We will
 not be able to create on the heap a AVCodecContext so that it works with
 any version of libavcodec (so long that they have the same major version
 number).

 So now, I have two possible approaches to solve this issue: get the libAV
 folks to change those fields so AVCodecContext members, for the ones that
 we modify manually, are located in the same memory offset.
 Or get you guys to revert that change.

 Another possibility I guess would be for you to provide us with a reliable
 way to differentiate libavcodec from libav or the one from FFmpeg.
 But then we suddenly have to support two forks: support across major
 version is already hard enough (we still have lots of people running
 ubuntu 12.04 for example, that came with LibAV's 0.8). At this stage there
 are still too many distros that ship with LibAV by default. The wind
 appears to be shifting (like Ubuntu/Debian now shipping FFmpeg's version
 instead)

 As you can see, we do not care how a particular libavcodec was compiled,
 if it was compiled with an option or not. How we use it works across all
 versions, no matter the distribution.

 >
 > Now, is it still possible to link and use both across distros, iam not
 sure it very well might be.
 > Most fields in AVCodecContext can be accessed through the AVOption API,
 see libavutil/opt.h
 > Is this sufficient for your use case ?

 Going forward it may be. Is this something both forks support ?

 Hope you can see where I'm coming from now.

 And how all the "suggestions" I've received so far are totally irrelevant
 to us.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/5057#comment:15>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker