[FFmpeg-devel] [RFC] Split libavformat

[Luca Abeni]

Hi Ramiro,

Ramiro Ribeiro Polla wrote:
> Sorry for not working any further on this. After all, summer is starting 
> and I live in a sub-tropical island, so it's quite hard to concentrate...

Well, I guess I'd like to have the same problems in concentrating... ;-)
Funnily enough, I am waiting for some snow to go skiing

> [...]
>> Index: ffmpeg/libavdevice/Makefile
>> ===================================================================
>> --- /dev/null	1970-01-01 00:00:00.000000000 +0000
>> +++ ffmpeg/libavdevice/Makefile	2007-11-19 19:57:22.061554240 +0100
> [...]
>> +
>> +# external libraries
>> +OBJS-$(CONFIG_LIBDC1394_DEMUXER)         += libdc1394.o
> 
> Sure, this lib is for grabbing devices, but it is also an external 
> library. What about also splitting external libraries out of libav* too? 

I have no strong opinions about it. I just tried to avoid creating too
many libraries. Where should libdc1394 support go?


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


>> --- ffmpeg.orig/libavformat/allformats.c	2007-11-19 19:57:22.062554088 +0100
>> +++ ffmpeg/libavformat/allformats.c	2007-11-19 20:09:18.796593952 +0100
> [...]
>>      /* protocols */
>>      REGISTER_PROTOCOL (FILE, file);
>> -    REGISTER_PROTOCOL (HTTP, http);
>>      REGISTER_PROTOCOL (PIPE, pipe);
>> -    REGISTER_PROTOCOL (RTP, rtp);
>> -    REGISTER_PROTOCOL (TCP, tcp);
>> -    REGISTER_PROTOCOL (UDP, udp);
> 
> Regarding keeping file_protocol and pipe_protocol (already questioned 
> and answered on [1]), well, libav* already depend on libavutil. I don't 
> see any harm on them also depending on libavprotocol.

I did not want to create new dependencies, because one of my goal is to
reduce the number of changes needed to libav* users.
I mean: 90% of libav* users do not need network or grabbing devices. In
My opinion, all those users must survive the split without needing to
change their code... This is of course only an opinion: if people agree
that libavformat should depend on libavprotocol (or something else), I'll
update my patches.

> That would  entirely isolate libavformat from any OS I/O stuff.

I was under the impression that file.c is not OS dependent... Is it?
If yes, then I can see the problem...


			Thanks,
				Luca