[FFmpeg-devel] [RFC] Split libavformat

Michael Niedermayer michaelni
Mon Nov 26 13:07:29 CET 2007

On Mon, Nov 26, 2007 at 12:28:41PM +0100, Luca Abeni wrote:
> Hi Michael,
> Michael Niedermayer wrote:
> > On Wed, Nov 21, 2007 at 02:31:53PM +0100, Luca Abeni wrote:
> >> 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
> [...]
> Yes, but last time I checked I saw that mplayer is configuring ffmpeg with
> networking and grabbing disabled, and is using its own networking and grabbing
> code... So, mplayer could currently take advantage of the split by just not
> linking libavdevice and libavnet.
> Anyway, I am more than willing to change things so that mplayer (or other
> applications) can use more easily our networking and grabbing code. If my
> original idea was wrong, just let me know what must be changed and I'll try
> to work on it...

iam not sure what is best ...
comments and ideas are welcome ...

but i think that at least the os support code / the code providing missing
standard functions should be split into its own lib instead of being spread
over 3 libs into which it doesnt belong ...
that of course is somewhat orthogonal to the net/device/protocol question

> > [...]
> >> 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
> Ok; I simply was not aware of the fact that my changes introduced any permanent
> annoyance. Of course I do not want to introduce such a permanent annoyance
> (my hope was to reduce to the minimum the one time annoyance while avoidind
> the permanent one).

well the way lavf is split is going to be somewhat permanent i hope ...

> > also iam starting to think that the way you split lavf is extreemly bad
> Sorry about that. Maybe I have been to fast in starting to hack, and I should
> have waited for more comments before trying to push my patches.
> Since I received some comments saying that the "avnet+avdevice" solution was
> preferred, I assumed this was the right way to go and I implemented it.

and i approved avdevice, now iam not that sure anymore that it was the best
solution :(

> Anyway, I hope it's not too late for changing it to something that makes sense.
> I want to improve ffmpeg, not to introduce any extremely bad solution.

its certainly not too late

> > could you before moving on with this spliting explain what advantage the
> > split has the way you do it?
> The advantage is that I had the impression that people liked it ;-)

yeah, the ultimate argument ;)

> More seriously, I see this split as a way to:
> 1) isolate all the networking-related code in a single library

> 2) remove from libavformat all the code that does not read frames from a
>     real file

but a file on a http server is a real file as well

> 3) after the split, libavformat's dependencies on the OS should be reduced
>     to the minimum (I was hoping to remove all the dependencies, but I was
>     not aware of the fact that lseek is os-dependent).
> > spliting "os support" that is providing missing functionality (lrintf, 
> > resolve host, ...) off
> You mean, creating an "os support" (libossupport, or similar) library?
> I can do it, if this is a better solution
> > would be very usefull for many (non av) applications and is a neccessry
> > prerequesit for IPv6 it seems.
> I agree that it would be very useful for a lot of applications; I do not
> agree that is needed for IPv6, but this is just my personal opinion.

ok, not ipv6
its needed even without ;)
just try to remove the os_support.h from ffmpeg.c/ffserver.c

> > 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
> Ok; I got the point, now :)

> > 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
> I read this some times, and some time ago I even tried to convert v4l2.c to an
> URLProtocol. I had a lot of problems because a protocol is not aware of things
> like video size, pixel format, and similar... While a video4linux(2) grabber
> needs to receive a requested size and pixel format to properly set the device
> (and to return back the actual frame size, etc...).
> Also, I believe an URLProtocol provides a stream of bytes, while an AVFormat
> provides frames (and from the logical point of view a video grabbing device is
> something that returns video frames, not a plain stream of bytes).
> Of course this can be worked around by splitting v4l2.c in an AVFormat + an
> URLProtocol, and passing the frame parameters to the URLProtocol as tags in the
> url... But when I tried to do it the code ended up being much uglier (in my
> opinion). I also think that using an URLProtocol would increase the number of
> memory copy (v4l2.c is currently trying to reduce the number of buffer copies
> by using the "destruct" method in the AVPacket structure...
> See v4l2.c:mmap_read_frame() and v4l2.c:mmap_release_buffer()).
> If you think that splitting the grabbing formats in an AVFormat + an URProtocol
> is the right way to go, I'll try to work on this... But I'll not be able to
> provide patches in a short time - and I fear v4l2 performance will suffer :(

no leave it as a demuxer then, its not my intent for it to become ugly, more
complex or slow

> [...]
> > it seems my original idea of doing this split quickly does not work out like
> > i hoped :(
> I am really sorry about that.
> I think I tried to do everything I can to help a quick split.
> When I started working on this split, I said that in my opinion it was mainly
> about moving files from one library to a different one. Since noone complained
> about that statement, I assumed it was ok, and I went ahead.
> It looks like I was wrong, and I should have waited for more comments and
> discussion.
> Anyway, what should be done at this point? Reverting my libavdevice commit, and
> restarting from scratch? (I am wondering if it is possible, since some other
> commits have been done after it)
> Or can the current situation be corrected in a proper way?
> Should I discard my libavnet patch and start working on libossupport?

well, i guess we should do what we should have done before starting to commit
that is disscuss the advantages/disadvanages/goals of the different ways
to split lavf, maybe the net/device split turns out to be the best anyway

iam quite confident that spliting os_support out is a good idea it doesnt
belong in any of the av libs and is very usefull on its own

iam less confident about what to do with the protocols and (de)muxers (which
really is the main question ...)
but it seems that dlopen() support could avoid dependancies more effectively
and more fine grained than splitting, that of course doesnt mean we shouldnt
split things but i think that spliting lavf to reduce dependancies is not
a solution it just moves the problem around.

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- 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/9abb7281/attachment.pgp>

More information about the ffmpeg-devel mailing list