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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
