Bug#833713: mpv new upstream version 0.18.1 and ffmpeg version compilation with it.

[James Cowgill]

Control: tags 831537 - pending

Hi,

On 08/08/16 09:25, shirish शिरीष wrote:
> Package: mpv
> Version: 0.18.0-1
> Severity: wishlist
> 
> Dear Maintainer,
> First of all a big thanx to the whole multimedia team for taking such
> good care of us (the users) for so many years and making life simpler
> for us.
> 
> Now, I read #831537 and while the bug seems to have been fixed in the
> git repo. it is yet to flow down to us (i.e. the users). But more than
> that, a new upstream version has been launched by mpv.io with the
> following statement -

The bug isn't actually fixed in git (the fix was reverted). I've removed
the pending tag now.

> "Note: Running mpv with different versions of the FFmpeg/Libav
> libraries than it was compiled with is no longer supported. Even
> supposedly ABI-compatible versions have been a source of trouble, and
> it creates far too much complexity with little to no benefit, coupled
> with absurd and unusable FFmpeg API artifacts.
> 
> Instead, mpv will exit with an error when such a situation is
> detected. This simply means that mpv needs to be rebuilt whenever
> FFmpeg libraries change."

You should know that this isn't the first time upstream mpv have pulled
this. You might want to read these bug as well:
https://bugs.debian.org/790446
https://bugs.debian.org/762229

The conclusion seemed to be that the warning was completely bogus and is
probably used to prevent bug reports whenever ffmpeg breaks their ABI.
Maybe it was re-added to mpv after the recent ffmpeg ABI breakage?

> https://github.com/mpv-player/mpv/releases
> 
> What this probably means in long-term that the multimedia team would
> have to either of these three things -
> 
> a. Abandon mpv
> b. Maintain mpv independantly and use ffmpeg versions that we are
> comfortable with, OR lastly
> c. Move to a scenario where both ffmpeg and mpv are in sync with each other.
> 
> The 3rd may not be possible as it would probably would mean more
> transition cycles and to deal with the fall-outs of rebuilding
> failures along with other things. The first option would be easiest
> but like many people, I have started using mpv more than any other
> media player so I would be sad to see it go, if that happens.

Yes c is unacceptable because it would require the security/release team
to binNMU mpv EVERY time ffmpeg is updated which is a major PITA.

> The second option seems to be where we are now and at least for the
> short-term this is where we probably would be for sometime.
> 
> People could use this bug as an excuse as what they see the roadmap in
> the next 6-8 months to a year in respect of mpv and the ffmpeg
> libraries.

Since I also use mpv a lot, I'll happily help out packaging it. When
packaging 0.18.1, patching out the error seems like the obvious
solution. In the end if there are any ABI issues, it's probably an
actual bug in either mpv or ffmpeg which we should fix.

Thanks,
James

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20160808/849cf9b5/attachment.sig>