[FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()

Derek Buitenhuis derek.buitenhuis at gmail.com
Mon Jun 22 23:31:00 CEST 2015


On 6/22/2015 9:15 PM, Mariusz Szczepańczyk wrote:
> Thank you for clarification. I understand there are people who are not 
> happy with additions like this. However, there are also people who think 
> these changes are needed and trying to stop them just because "we don't 
> want this here" or worse, making fun of their work is not the way to go 
> to be honest.

Considering whether a feature should be in a particular library by design
is a legitimate consideration. You can't just blindly accept all features
someone might find useful. Some may also think a GUI toolkit and X protocol
implementation would be awesome to have in libav*, but does it belong? No.

May I add, that I do not think pushing through APIs and and design choices
that have registered dissent is kinda of sketchy at best. That is not on
you though, and I apologize for dragging your GSOC application into it.

(Also I'm not making fun of your work. If you point out where I've done
that, I'd be glad to retract and apologize.)

> I don't really know how/when this conflict started or have your 
> complaints been answered or not but it seems to me there are some of you 
> who are really frustrated with the direction ffmpeg have taken.

Yes, it predates your GSOC task, and involves your mentor. Again, apologies
for it being dumped on you in this thread.

> So why don't you propose something constructive, e.g. partition into 
> distinct libraries so muxing/demuxing code is not getting "spoiled"? 
> There must be some kind of solution everyone can agree with.

We did. We proposed it is *not* the task of libav* to do this. It belongs in
the layer above, in the application (e.g. a player). And indeed, this is
what VLC and mplayer/mpv already do. Your mentor is the only one who
decided it belongs here, because he wanted to use it.

- Derek


More information about the ffmpeg-devel mailing list