ffmpeg-snapshot

[Felipe Sateler]

On Mon, 2009-10-12 at 13:05 +0200, Reinhard Tartler wrote:
> Loïc Minier <lool at dooz.org> writes:
> 
> >  My understanding is that the ffmpeg we have in Debian/Ubuntu is
> >  relatively stabilized and aligned with other distros (Gentoo IIRC).
> >  Would it make sense to provide a ffmpeg-snapshot like gcc-snapshot
> >  which we would update as we see fit?  Perhaps to allow people to play
> >  with latest upstream stuff and also to have them test for regression or
> >  upstream fixes.  It could be kept out of testing like gcc-snapshot.
> >
> >  What do you folks think?
> 
> I've been thinking about this as well. Let me lists my thoughts on this:
> 
>  - The FFmpeg libraries make intensive use of internal structures that
>    are not exported externally; e.g. libavcodec usees a lot of structs
>    in libavutil (historically, some of them started ad-hoc in libavcodec
>    and then got moved to libavutil), and the same does happen in
>    libavformat, which uses internals of both libavcodec and libavutil.
>    This means that you cannot expect a newer libavcodec to be usable
>    against an "older" libavutil, even when the soname of libavutil
>    didn't change.
> 
>  - Debian-multimedia.org is already replacing debian's FFmpeg libraries
>    with newer versions from upstream. The result can be seen fairly
>    frequently in forms of bugreports against the debian vlc and mplayer
>    packages: crashes, unresolved symbols while program loading and so
>    on.   
> 
>  - This could be strictly speaking considered as an ABI break and would
>    require a SONAME change. The ffmpeg developers disagree here and
>    don't really support mixing library versions. Therefore, I'd suggest
>    that a potential ffmpeg-snapshot package must not replace the
>    libraries from the current packages in order to not break existing
>    applications.
> 
>  - If we go that way, how are applications supposed to use the new
>    ffmpeg-snapshot libraries then?

An alternative is to ship only static libraries. Is that possible with
ffmpeg? Shipping only static libraries inside /usr/lib/ffmpeg-snapshot
and the headers in /usr/include/ffmpeg-snapshot would suffice for
application testing. Remember that ffmpeg-snapshot would be kept out of
testing so any application that wants to be in a stable release cannot
be packaged and built against this version of ffmpeg.



-- 
Saludos,
Felipe Sateler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20091012/95f38875/attachment.pgp>