On 6/22/2015 6:52 PM, Michael Niedermayer wrote: > When and where ? Example: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/179883
And also *constantly* on IRC, although I am sure "IRC doesn't count" or somesuch. My argument then is the same as now: this does not belong in libav*. It belongs in the player or user application who uses the libav* API. (And before you say "but that is for smb", the argument is the same, and the end goal and author+mentor are the same. It's the same issue.) You may also recall I brought up the fact that the GSOC qualification task was mostly reworking the patch set from Lukasz, and thinking that was a bit sketchy. P.S. I'm getting pretty tired of the demand for proof every time a bad design shows itself for the Nth time. A bad design is a bad design. The burden is on the designer to prove it is WORTH including, not the other way around. The burden should not be on the review to have to respond and register their dissent for every Nth iteration of an idea or patch set, lest it be pushed through anyway, be it as a GSOC or patch set. If it was bad once, it is still bad. > Also, the "Browsing content on the server" project was added 17 months ago > to the GSoC 2014 page: > https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2014?confirm_email=&email_confirm=&action=diff&version=28&old_version=27&confirm_email=&email_confirm= > > Thats a long time prior to GSoC 2015 in which anyone could have > removed it if they wanted, its a publically editable wiki basically And pissed off Lukasz? > And theres another aspect to this, theres quite some code that > needs the rename function (git grep ff_rename). > What options exist here > 1. leave it so it only works with local files [...] > 2. support other "protocols" than file:// by the API here > 3. support other "protocols" than file:// by some other API "protocol" indeed. > 4. remove the code that uses ff_rename (hls, hds, dash, smoothstreaming, ...) Very funny. > I might be wrong but i think people really like none of the options > here > for 3. also some other API would need to be suggested, this may very > well be the solution if someone does have a better idea for a better > API, that is one that everyone likes or at least can live with Yes, let us dump every idea someone has into libav*. Everything belongs in libav. > also another use case for this may be simple cleanup on errors, > a muxer might (possibly not by default if people prefer) remove > files that failed to be created at an early stage [...] > that is for example when writing the header fails in the middle and > before any content is stored in a file deleting the file is probably > what some users would want ... "Probably what some users want" can pretty much be quoted as the reasoning for every insane design choice in libav*... > Also lets rather encourage work toward a solution, everyone is happy > with instead of disencouraging people from working I don't think encouraging work just for the sake of encouraging work is a good idea. It leads to bad technical design is we just go "well we shouldn't discourage work, even if it's a bad idea." I get now it's "too late" as it was registered for GSOC, but crikey. Bonus random IRC logs found by grepping for "directory listing" in #ffmpeg-devel: 17:54 < cone-632> ffmpeg Lukasz Marek master:184084c6998c: lavf: add directory listing API 18:02 <+wm4> Daemon404: shit ^ 18:02 <+wm4> damage done, maintain forever 18:05 <@Daemon404> D: Days later: 16:38 <+kierank> ffmpeg has too much mission creep 16:38 <+kierank> an in built web server 16:38 <+kierank> directory listing api 16:38 <+kierank> wtf 16:40 <@iive> avsystemd 16:40 <@BBB_> yeah the directory listing api kind of confused me 16:41 < rcombs> isn't that supposed to be MKV ordered chapters and such 16:41 <@BBB_> as long as I can disable it I don't care I guess 16:41 <+wm4> rcombs: fuck no 16:41 < rcombs> well then I have no idea what that's for then 16:41 <+wm4> nobody knows 16:42 <+wm4> because Lukasz wanted it and mini can't say no? 16:42 <+kierank> wm4: ding ding ding - Derek _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
