[FFmpeg-devel] [RFC] Split libavformat

[Luca Abeni]

Hi Michael,

Michael Niedermayer wrote:
> 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();

Note: following this comment, I removed the call to av_register_all() from
avnet_register_all() and avdevice_register_all()... The only part of the
comment which I did not follow is the removal of the avcodec_register_all()
call from av_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
[...]

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...


> [...]
>> 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).


> 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.
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.


> 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 ;-)
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
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.


> 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 :(

[...]
> 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?

Let me know... I am still willing to work on this, but I want to do things
in the proper way, so that everyone is satisfied with the result...



				Thanks,
					Luca