[FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
derek.buitenhuis at gmail.com
Mon Jun 22 23:24:11 CEST 2015
On 6/22/2015 6:52 PM, Michael Niedermayer wrote:
> When and where ?
And also *constantly* on IRC, although I am sure "IRC doesn't count"
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:
> 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
> 4. remove the code that uses ff_rename (hls, hds, dash, smoothstreaming, ...)
> I might be wrong but i think people really like none of the options
> 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
> 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:
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
More information about the ffmpeg-devel