[FFmpeg-devel] [RFC] Split libavformat

Michael Niedermayer michaelni
Mon Nov 26 11:24:10 CET 2007

On Wed, Nov 21, 2007 at 02:31:53PM +0100, Luca Abeni wrote:
> [...]
> >  > -    av_register_all();
> >  > +    avdevice_register_all();
> > 
> > Since we're breaking API already, to avoid this recursive calling of 
> > av_register_all and deciding which register_all function to call, how 
> > about "the user MUST initialize every library", as in:
> > 
> > avcodec_register_all();
> > avformat_register_all();
> > avdevice_register_all();
> Uhmmm... I do not see many advantages in such a choice.
> Since all the *register*() calls are protected from multiple invocations,
> I think the current solution is more flexible: a user can explicitly
> initialize all the libraries, or can initialize only the one he wants to use
> (and all the needed libraries will be automagically initialized).
> Moreover, I split libavformat so that the split is transparent to all the
> users that do not need grabbing devices or network (think about mplayer).

i think many users of mplayer would like network and grabbing support
also i think thats true for most applications using libavformat, it might be
that the majority of users of an application dont want or need it but
applications CANNOT drop support for libavdevice or libavnet, practically
every application will have to support both (unless it has its own stream
layer but then a libavprotocol split would have made much more sense for them)

> I did not want to create new dependencies, because one of my goal is to
> reduce the number of changes needed to libav* users.

the number of changes needed for libav* users is of low relevance its much
more important that the final design is sane
its a one time annoyance vs. permanent annoyance question

also iam starting to think that the way you split lavf is extreemly bad
spliting out random (de)muxers and protocols is quite similar to what can
already and much cleaner be done with --disable-demuxer/...

could you before moving on with this spliting explain what advantage the
split has the way you do it?

spliting "os support" that is providing missing functionality (lrintf, 
resolve host, ...) off would
be very usefull for many (non av) applications and is a neccessry
prerequesit for IPv6 it seems. but this is not part of your split, libavnet
is absolutely not acceptable for providing non static/external net-os-support,
that is one which can be accessed by applications like ffmpeg.c or ffserver.c
any lib which would provide missing OS functionallity must be free of all
av related code

spliting off grabbing is somewhat nice as it keeps alot of silly dependancies
out of libavformat but IMHO all these grabbing devices should be URLProtocols
not demuxers and if they were then a libavstream (URLProtocol) split would
achive that as well ...

it seems my original idea of doing this split quickly does not work out like
i hoped :(

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071126/f3d82412/attachment.pgp>

More information about the ffmpeg-devel mailing list