[FFmpeg-devel] [RFC] Split libavformat

[Luca Abeni]

Hi Michael,

Michael Niedermayer wrote:
[...]
>>> iam not sure what is best ...
>>> comments and ideas are welcome ...
>> At this point, I obviously have not good ideas about this issue...
>> I'll just wait to see what other people think.
> 
> i have a bad feeling about this, because i as well planed to wait for
> comments from others ...

Ok, so we agree on this ;-)

Anyway, I spent some time thinking about this, and I am posting some of
my ideas to stimulate the discussion (hoping that someone else will feel
encouraged to join it and we can end up with a productive outcome).
The reason I can see for moving grabbing code to libavdevice is that
although such code is implemented using AVFormats, the resulting
muxers/demuxers are (I believe) "special" because they do not read
data through an URLProtocol, but from a physical device.
Someone might say they abuse the AVFormat API, but I do not believe so.
So, moving them to libavdevice does not result in big advantages from the
practical point of view, but allows to isolate these strange demuxers in
their own library (in other words: libavdevice is a library for (de)muxers
that do not use an URLProtocol).
When I started working on this, I had the impression that this was what
people wanted...


> the whole started due to people dislikeing grabing code in lavf,

I had the same impression. I probably misunderstood, but I got the
strong impression that there was a general agreement about moving
grabbing code out of lavf (and since it was easy, I tried to do it).


> but the grabing code are demuxers and it doesnt look like that
> can be changed easily and demuxers do belong in lavf

Well, maybe what I am saying does not make too much sense, but I
believe they are special (de)muxers (as written above). Yes, they
are implemented using AVFormats, but from a logical point of view
they are different (IMHO).


> its split out now and i guess nothing terrible will happen if we leave it like
> that, i just dont think it achieved much beyond making people feel better

I believe making people feel better is already a good achievement :)


>>> 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
>> Ok. At least, this change should be reasonably uncontroversial... I'll start
>> having a look at the OS-dependent code. After a first look, I think that:
>> 1) There is nothing OS-dependent in libavutil (or do you think the memalign hack
>>     should go in the OS support library? In this case, can I just use the
>>     CONFIG_MEMALIGN_HACK code to implement memalign()?)
> 
> no i think the memalign should stay in lavu

Ok. What about the "better than nothing" lrintf replacement that is currently
in libavutil/internal.h?


>> 2) The only OS-dependent code in libavcodec is the threading code, but I do
>>     not see any easy way to move it in a separate library. Ideas?
>> 3) The remaining part of the work is to move os_support* from libavformat to
>>     the new library (and I think network.h contains some OS-dependent code too).
>>
>> I still need to have a better look at all the libav* code, but these are my
>> first impressions. Anything obvious I am missing?
> 
> *rintf() is missing on some platforms, we dont do anything about it but it
> would fit nicely in a libossupport

Ok. I was focusing more on the code that we currently have in libav*, but
I'll have a look at *rintf too.
Anyway, for the moment the only ffmpeg code that should be moved to libossupport
is libavformat/os_support.* (and maybe some part of network.h?), right?


				Thanks,
					Luca