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

[Michael Niedermayer]

On Mon, Jun 22, 2015 at 06:06:58PM +0100, Derek Buitenhuis wrote:
> On 6/22/2015 5:33 PM, James Almer wrote:
> > I have no opinion one or way or another regarding this addition, but if this
> > is a GSoC project then i guess the time to show disagreement was back in
> > February when it was a suggested project waiting for applications, and not in
> > the middle of the program long after a student got the project assigned.
> 
> We did. Several times. It was ignored or pushed aside.

When and where ?

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 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
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

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 ...

Also lets rather encourage work toward a solution, everyone is happy
with instead of disencouraging people from working

Thanks

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20150622/caa505af/attachment.asc>