Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
Le quintidi 5 messidor, an CCXXIII, wm4 a écrit : People don't follow mathematic rules, and neither do human arguments. Not even software development does. And yet, even so, the reasoning discipline gives valuable results even in these areas. Wonderful, isn't it? The current architecture just doesn't allow it without committing API atrocities. There is no doubt that FFmpeg has a lot of round pegs in square holes. Just repeating it ad nauseam is not a constructive contribution. There are two kind of constructive contributions that you can do: 1. Help design round holes for the round pegs. 2. Build a case to prove that FFmpeg is better without the round pegs. For now, I have not yet seen you do any of these things. Personally, I consider that we should strive to make sure that all pegs, even the square ones and even the very useful ones, do not have a cost when they are not used (i.e. an application that uses lavf and lavc to demux and decode MP3 should not be burdened by initiating the H.266 tables or loading the TLS certificates). And in that case, it is better to have the pegs, even if we do not have the correctly shaped holes yet. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Tue, 23 Jun 2015 17:33:42 +0200 Nicolas George geo...@nsup.org wrote: Le quintidi 5 messidor, an CCXXIII, wm4 a écrit : People don't follow mathematic rules, and neither do human arguments. Not even software development does. And yet, even so, the reasoning discipline gives valuable results even in these areas. Wonderful, isn't it? The current architecture just doesn't allow it without committing API atrocities. There is no doubt that FFmpeg has a lot of round pegs in square holes. Just repeating it ad nauseam is not a constructive contribution. There are two kind of constructive contributions that you can do: 1. Help design round holes for the round pegs. I've often enough suggested alternative ways how to do something, but you just keep calling me a troll instead of listening. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
Le quintidi 5 messidor, an CCXXIII, Derek Buitenhuis a écrit : The crux of the issue here is that there is disagreement on whether some features should be in libav* at all. It's separation of functionality. It's not really possible to show something satisfactory when it's the wrong place for it in the first place, in someone's mind. I speak for myself here, only, of course. Take it with a grain of salt. As someone who pushed for a project that had similar opposition (the HTTP server), I believe I must intervene. First, let us try to agree on a few basic points. Statement: you only get to decide on what you spent your own time. Other developers decide for themselves. You can try to persuade them that optimizing a codec is more important than writing a spell checker, but in the end, if they want to write a spell checker, they will write a spell checker, for FFmpeg or for another project. Agreed? Second, and this is rather a big point, so it will be itemized; please read to the end before replying: What actual harm does it do if someone works on something that you believe is outside the scope of the project? I understand that you do not want to endorse committing lavu: add a spell checker, and even less spend time on it, but why actually oppose it? I can see a few reasons, let us discuss them. 1. It looks silly. Yes it does. And for that reason, nobody will actually support adding a spell checker to lavu. But that does not apply to exposing extra features of protocols that are already implemented. 2. It is a waste of valuable developer time. See my first statement: you do not get to decide that, each person decide for themselves. If someone decides to implement it now, if someone else decides to maintain it later, that is their decision, they do so because they find value in it. And if nobody does, you can let it bitrot and have the pleasure of removing it when it has become obvious it was useless. 3. It pollutes the code. That, I can agree with, but that can be mitigated: separate source files, optional compilation, well-defined entry points. You can insist on such things. Note that the notion of maintainership applies: AFAIK, you never wrote a line about the libssh client, so your say in what happens in it is limited. Limited, I would say, to the parts of the code that can be reached by your use cases. In other words: if it does not affect the code you actively work on and if it does not change the run path of the features you really use, let it be. 4. It wastes compilation time. That, I could agree too, having worked on under-powered boxes. But let us be realistic: all these features we are talking about are tiny. All together, they take less time building than the file for the optimized DSP code of a single major codec. 5. It wastes limited resources, in particular funding and sponsorship. Does it? Did we have a promising candidate that did not get a slot because of one of these project? As far as I can see, the limiting factor until now was the number of motivated candidates. 6. Anything else? There is another point I wish to make before ending this too long mail: I believe we can agree on a few very generic guidelines about what should be accepted in the project. In other words, I wish to explain why I support the directory listing API and the HTTP server but I would oppose libavspellcheck. I believe any of at least three conditions can make a new feature acceptable: 1. A feature that is similar, in essence, to an already widely accepted feature. New codecs are ok, because FFmpeg already has a lot of codecs. We already have a X11 screen capture device, that means a windows screen capture device or a Wayland capture device would have its place. 2. If we already have code that we need, then exposing the feature as a clean API makes sense. With a caveat: exposing a public API freezes it, so the evolution must be considered carefully. An example: we need FFTs for the codecs. Then exposing a public AVFFT interface makes sense. Another example: hashes, we need them for some the checksums in some formats, they have a rather natural an well-delimited interface, it would be absurd not to expose them. Well, we already have a HTTP server! It is hidden in ffserver and duplicates some of the HTTP client code. If Stephan can merge the code and give it a good overhaul, how is that bad? Same goes for the output devices in lavd: ffplay needs a window to display the video, other apps would benefit from it too. It does not look very good currently because the work is only less than halfway done: the devices are added, but they are not used in ffplay because the API has some missing features. But theoretically it would look really good. 3. If it makes existing feature
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Tue, 23 Jun 2015 12:51:18 +0200 Nicolas George geo...@nsup.org wrote: Le quintidi 5 messidor, an CCXXIII, wm4 a écrit : I think you're alone with this. I do not intend to push for it, it was just an extreme example. I do maths, and there is one thing we learn: if you want to know how solid an argument is, push it to the extreme. If you suspect f is monotonic and want to know whether it is increasing or decreasing, look at its asymptotic behaviour. If you want to know if libavremotefileoperations makes sense, wonder about libspellcheck. People don't follow mathematic rules, and neither do human arguments. Not even software development does. libav* are for (de)muxing and decoding/encoding. libav* are for what developers want to make them for. The current architecture just doesn't allow it without committing API atrocities. (You might consider this abuse, but I gave enough convincing examples.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Tue, 23 Jun 2015 11:05:31 +0200 Nicolas George geo...@nsup.org wrote: Yes, libavspellcheck! I used it as an absurd example, but if you think carefully on it, it is not actually absurd. I think you're alone with this. libav* are for (de)muxing and decoding/encoding. That's why people are using it. Everything else FFmpeg does extremely badly, and thus is better done somewhere else. It all boils down to API and organization really. It wouldn't be much of a problem to add a separate git repo that contains libavspellchecker. This would be truly independent. But I know what would happen... you'd add subtitle support to libavfilter, and the spell checker would be implemented as a filter. We could have libavremotefileoperations too, but no, it will just end up in libavformat. Oh, and even if we had libavspellchecker or libavremotefileoperations, it would have to be part of The Big Git Repo. For some reason. Even though the sub-libs are supposed to be independent. (Totally.) Your arguments all make sense, but the way things will actually be done is different and usually terrible. (Just think about it. Things such as adding video outputs through a muxer API just because the original authors didn't know a better place for it. Using a muxer API for video output is absurd, but if you bang your head against ffmpeg.c enough, your brain matter becomes squished enough that it starts making sense.) Regarding bloat: distro versions of FFmpeg are typically extremely bloated. It's fun to watch: merely linking a C source file containing only a main function to Debian's build of libavformat will allocate at least 10 MB of RAM on program start. Bloat is bad because it adds up. And you can't escape it either. If you link to a distro build of libavformat, your program will use more memory and will take longer to load as it would if you'd compile it yourself. I'm also not sure why you think maintaining essentially dead code is hard. Hint: it is pretty hard if you actually want to make FFmpeg saner overall. Bloat is like the concrete that keeps entangled software entangled. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
Le quintidi 5 messidor, an CCXXIII, wm4 a écrit : I think you're alone with this. I do not intend to push for it, it was just an extreme example. I do maths, and there is one thing we learn: if you want to know how solid an argument is, push it to the extreme. If you suspect f is monotonic and want to know whether it is increasing or decreasing, look at its asymptotic behaviour. If you want to know if libavremotefileoperations makes sense, wonder about libspellcheck. libav* are for (de)muxing and decoding/encoding. libav* are for what developers want to make them for. It wouldn't be much of a problem to add a separate git repo that contains libavspellchecker. This would be truly independent. But I know what would happen... you'd add subtitle support to libavfilter, and the spell checker would be implemented as a filter. Yes, exactly. We want everything in FFmpeg because multimedia is an entangled topic: if you want to do anything non-trivial, you need everything. We could have libavremotefileoperations too, but no, it will just end up in libavformat. Please give us ONE GOOD REASON to split the libraries. I myself advocate for one single libffmpeg.so, because the only practical consequences I see to the split is the hassle of intra-project ABI stability, with all the avpriv_frobnicate() stuff. Even libavformat and libavcodec belong together: demuxers require parsers, and parsers share code with decoders. The rest is peanuts. By having all together, we can have a common testing framework. Look at what happens in the Linux kernel: even for modules that could be shipped separately, the policy is to have it all in one huge repository. The FFmpeg code base is not nearly as big as the Linux code base. is different and usually terrible. For your information, I consider the paragraphs that contain that kind of gratuitous abuse non-existent. I'm also not sure why you think maintaining essentially dead code is hard. That is exactly the opposite, I think it is easy: just run the bulldozer on the oldest parts of the graveyard once in a while. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 22/06/15 9:11 AM, Derek Buitenhuis wrote: On 6/21/2015 8:04 PM, Mariusz Szczepańczyk wrote: Anyway, this is a part of my GSoC task that has been accepted and I'm compelled to implement it so I won't be getting into further discussion. Let's just say a large portion of the community didn't and don't think this idea has any place in libav* in the first place, but were ignored, or our complaints pushed aside. - Derek 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
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. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
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=diffversion=28old_version=27confirm_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
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
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
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 6/22/2015 11:58 PM, Mariusz Szczepańczyk wrote: I don't think it's fair to say Lukasz is the only one standing for these changes. But let's not make it personal and hold on any grudges for a moment. I hold no ill will against anyone, as long as no ill will is held against me. I do, however, think it was pretty dishonest of some people to push this forward as a GSOC project when there was internal dissent for it (on IRC, on the ffmpeg-mentor list, etc.). This is of course not your problem, nor should it be. We're here now, so we should make the best of it. My point is that ongoing fights like this are counterproductive and only discourage people from contributing into open source. I also think everyone wants the best for the project regardless they are pro or against the changes. Agreed. I see the current situation is as follows: there is increasing amount of code in libav* that you and some others find out of place. This is obviously not good. Is there any viable solution not involving removing functionality from ffmpeg would you agree on and make adding changes like this less painful? What do you think about making a temporary fork, moving things around there and showing something that is satisfactory to you? The crux of the issue here is that there is disagreement on whether some features should be in libav* at all. It's separation of functionality. It's not really possible to show something satisfactory when it's the wrong place for it in the first place, in someone's mind. I speak for myself here, only, of course. Take it with a grain of salt. As far as I see this situation, the damage is done already (it's in libav*), so we may as well make it (the API) as decent as possible. (P.S. I wouldn't use the word fork here, people get angsty :P) - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Mon, Jun 22, 2015 at 11:31 PM, Derek Buitenhuis derek.buitenh...@gmail.com wrote: 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.) No offence taken. Actually this remark wasn't directed at you any way, just an observation of what's going on in this thread (and some other). 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. I don't think it's fair to say Lukasz is the only one standing for these changes. But let's not make it personal and hold on any grudges for a moment. My point is that ongoing fights like this are counterproductive and only discourage people from contributing into open source. I also think everyone wants the best for the project regardless they are pro or against the changes. I see the current situation is as follows: there is increasing amount of code in libav* that you and some others find out of place. This is obviously not good. Is there any viable solution not involving removing functionality from ffmpeg would you agree on and make adding changes like this less painful? What do you think about making a temporary fork, moving things around there and showing something that is satisfactory to you? Mariusz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Mon, Jun 22, 2015 at 08:46:01PM -0300, Reynaldo H. Verdejo Pinochet wrote: Hi everyone Not really getting into the whole discussion on blocking remarks to a running (sponsored) project. I sincerely hope we all agree that once work has started on these, we should try to be constructive and let the student do their job while benefiting from all we can feed to them on the do-it-better side. Now, on the hopes of being constructive: I do understand resource renaming and removing are borderline use cases, but I also see the need for such functionality when, for instance, there's no easy way to properly inform the application about what and how to rename/move. It been a protocol:// issue, a loosely defined naming%0Xd*.ext convention, etc (there are similar examples for renaming). Lacking a better solution and considering we should be at least responsible for our own cleanup, I'd just make sure this API stays in the avpriv_ realm and work together on designing a solution that would let us have this functionality available for internal use while being maintainable , have good platform coverage, and be as uncluttered (use-case wise) as it can possibly be. +1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Mon, Jun 22, 2015 at 10:31:00PM +0100, Derek Buitenhuis wrote: [...] Your mentor is the only one who decided it belongs here, because he wanted to use it. Please stop the finger pointing and work toward a resolution of this its not just one man, iam not even sure he intended to use it himself. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 6/22/2015 10:24 PM, Derek Buitenhuis wrote: 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. I went and looked. It wad *directly* brought up by Keiran on ffmpeg-mentors. He was, of course, shat on. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 6/23/2015 12:46 AM, Reynaldo H. Verdejo Pinochet wrote: Not really getting into the whole discussion on blocking remarks to a running (sponsored) project. I sincerely hope we all agree that once work has started on these, we should try to be constructive and let the student do their job while benefiting from all we can feed to them on the do-it-better side. As noted in my other mail(s), I agree, since work has started already on GSOC. I do understand resource renaming and removing are borderline use cases, but I also see the need for such functionality when, for instance, there's no easy way to properly inform the application about what and how to rename/move. It been a protocol:// issue, a loosely defined naming%0Xd*.ext convention, etc (there are similar examples for renaming). Lacking a better solution and considering we should be at least responsible for our own cleanup, I'd just make sure this API stays in the avpriv_ realm and work together on designing a solution that would let us have this functionality available for internal use while being maintainable , have good platform coverage, and be as uncluttered (use-case wise) as it can possibly be. That's the most reasonable thing I've read so far. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 6/22/2015 11:18 PM, Michael Niedermayer wrote: Please stop the finger pointing and work toward a resolution of this its not just one man, iam not even sure he intended to use it himself. I agree I was a too aggressive. However, I am not aware of a single person. As for working towards a resolution, I don't think that will happen, since it shouldn't have been done at all / it should not be done at all is likely not an acceptable solution to those involved. Instead, I will relegate myself to being an annoying guy on IRC, and leave the thread be. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 6/22/2015 10:31 PM, Derek Buitenhuis wrote: That is not on you though, and I apologize for dragging your GSOC application into it. To follow up on this, I do understand how GSOC works, and it is too late to say 'no' to this, and I feel bad for you having negatives dumped on you like this. I suppose you should continue on. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Sun, Jun 21, 2015 at 05:04:10PM +0200, Mariusz Szczepańczyk wrote:
On 21/06/15 09:37, Timothy Gu wrote:
El sábado, 20 de junio de 2015, Mariusz Szczepańczyk
mszczepanc...@gmail.com mailto:mszczepanc...@gmail.com escribió:
---
doc/APIchanges| 4
libavformat/avio.c| 38 ++
libavformat/avio.h| 19 +++
libavformat/url.h | 2 ++
libavformat/version.h | 2 +-
5 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 6e64a05..a9efd12 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -17,6 +17,10 @@ API changes, most recent first:
8 - FFmpeg 2.7 was cut here 8 -
+2015-xx-xx - xxx - lavf 56.38.100 - avio.h url.h
+ Add avio_move(), avio_delete().
+ Extend URLProtocol with url_move(), url_delete().
+
This goes above the 2.7 release cut line.
Timothy
You're right. Thanks!
Mariusz
doc/APIchanges|4
libavformat/avio.c| 38 ++
libavformat/avio.h| 19 +++
libavformat/url.h |2 ++
libavformat/version.h |2 +-
5 files changed, 64 insertions(+), 1 deletion(-)
1a7bf656f7e0a71b313c14fad1684083b148636a
0001-lavf-avio-Extend-API-with-avio_move-and-avio_delete.patch
From 283f81e40b8776ac485e0e575ba351618a5c2332 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mariusz=20Szczepa=C5=84czyk?= mszczepanc...@gmail.com
Date: Wed, 17 Jun 2015 20:12:00 +0200
Subject: [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Observe your enemies, for they first find out your faults. -- Antisthenes
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 6/21/2015 8:04 PM, Mariusz Szczepańczyk wrote: Anyway, this is a part of my GSoC task that has been accepted and I'm compelled to implement it so I won't be getting into further discussion. Let's just say a large portion of the community didn't and don't think this idea has any place in libav* in the first place, but were ignored, or our complaints pushed aside. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 22/06/15 14:11, Derek Buitenhuis wrote: On 6/21/2015 8:04 PM, Mariusz Szczepańczyk wrote: Anyway, this is a part of my GSoC task that has been accepted and I'm compelled to implement it so I won't be getting into further discussion. Let's just say a large portion of the community didn't and don't think this idea has any place in libav* in the first place, but were ignored, or our complaints pushed aside. - Derek 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. 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. 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. Mariusz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
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=diffversion=28old_version=27confirm_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. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 21/06/15 09:37, Timothy Gu wrote:
El sábado, 20 de junio de 2015, Mariusz Szczepańczyk
mszczepanc...@gmail.com mailto:mszczepanc...@gmail.com escribió:
---
doc/APIchanges| 4
libavformat/avio.c| 38 ++
libavformat/avio.h| 19 +++
libavformat/url.h | 2 ++
libavformat/version.h | 2 +-
5 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 6e64a05..a9efd12 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -17,6 +17,10 @@ API changes, most recent first:
8 - FFmpeg 2.7 was cut here 8 -
+2015-xx-xx - xxx - lavf 56.38.100 - avio.h url.h
+ Add avio_move(), avio_delete().
+ Extend URLProtocol with url_move(), url_delete().
+
This goes above the 2.7 release cut line.
Timothy
You're right. Thanks!
Mariusz
From 283f81e40b8776ac485e0e575ba351618a5c2332 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Mariusz=20Szczepa=C5=84czyk?= mszczepanc...@gmail.com
Date: Wed, 17 Jun 2015 20:12:00 +0200
Subject: [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
---
doc/APIchanges| 4
libavformat/avio.c| 38 ++
libavformat/avio.h| 19 +++
libavformat/url.h | 2 ++
libavformat/version.h | 2 +-
5 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 6e64a05..cc2ebf3 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2014-08-09
API changes, most recent first:
+2015-xx-xx - xxx - lavf 56.38.100 - avio.h url.h
+ Add avio_move(), avio_delete().
+ Extend URLProtocol with url_move(), url_delete().
+
8 - FFmpeg 2.7 was cut here 8 -
2015-06-04 - cc17b43 - lswr 1.2.100
diff --git a/libavformat/avio.c b/libavformat/avio.c
index 261ff2a..bd32944 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -421,6 +421,44 @@ int avio_check(const char *url, int flags)
return ret;
}
+int avio_move(const char *url_src, const char *url_dst)
+{
+URLContext *h_src, *h_dst;
+int ret = ffurl_alloc(h_src, url_src, AVIO_FLAG_READ_WRITE, NULL);
+if (ret 0)
+return ret;
+ret = ffurl_alloc(h_dst, url_dst, AVIO_FLAG_WRITE, NULL);
+if (ret 0) {
+ffurl_close(h_src);
+return ret;
+}
+
+if (h_src-prot == h_dst-prot h_src-prot-url_move)
+ret = h_src-prot-url_move(h_src, h_dst);
+else
+ret = AVERROR(ENOSYS);
+
+ffurl_close(h_src);
+ffurl_close(h_dst);
+return ret;
+}
+
+int avio_delete(const char *url)
+{
+URLContext *h;
+int ret = ffurl_alloc(h, url, AVIO_FLAG_WRITE, NULL);
+if (ret 0)
+return ret;
+
+if (h-prot-url_delete)
+ret = h-prot-url_delete(h);
+else
+ret = AVERROR(ENOSYS);
+
+ffurl_close(h);
+return ret;
+}
+
int avio_open_dir(AVIODirContext **s, const char *url, AVDictionary **options)
{
URLContext *h = NULL;
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 9f3a992..5ac5d38 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -230,6 +230,25 @@ const char *avio_find_protocol_name(const char *url);
int avio_check(const char *url, int flags);
/**
+ * Move or rename a resource.
+ *
+ * @note url_src and url_dst should share the same protocol and authority.
+ *
+ * @param url_src url to resource to be moved
+ * @param url_dst new url to resource if the operation succeeded
+ * @return =0 on success or negative on error.
+ */
+int avio_move(const char *url_src, const char *url_dst);
+
+/**
+ * Delete a resource.
+ *
+ * @param url resource to be deleted.
+ * @return =0 on success or negative on error.
+ */
+int avio_delete(const char *url);
+
+/**
* Open directory for reading.
*
* @param s directory read context. Pointer to a NULL pointer must be passed.
diff --git a/libavformat/url.h b/libavformat/url.h
index 1a845b7..99a3201 100644
--- a/libavformat/url.h
+++ b/libavformat/url.h
@@ -90,6 +90,8 @@ typedef struct URLProtocol {
int (*url_open_dir)(URLContext *h);
int (*url_read_dir)(URLContext *h, AVIODirEntry **next);
int (*url_close_dir)(URLContext *h);
+int (*url_delete)(URLContext *h);
+int (*url_move)(URLContext *h_src, URLContext *h_dst);
} URLProtocol;
/**
diff --git a/libavformat/version.h b/libavformat/version.h
index 99b7190..ec84570 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -30,7 +30,7 @@
#include libavutil/version.h
#define LIBAVFORMAT_VERSION_MAJOR 56
-#define LIBAVFORMAT_VERSION_MINOR 37
+#define LIBAVFORMAT_VERSION_MINOR 38
#define LIBAVFORMAT_VERSION_MICRO 100
#define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
--
2.3.6
___
ffmpeg-devel mailing list
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On 21/06/15 10:11, Hendrik Leppkes wrote: On Sat, Jun 20, 2015 at 2:52 PM, Mariusz Szczepańczyk mszczepanc...@gmail.com wrote: --- doc/APIchanges| 4 libavformat/avio.c| 38 ++ libavformat/avio.h| 19 +++ libavformat/url.h | 2 ++ libavformat/version.h | 2 +- 5 files changed, 64 insertions(+), 1 deletion(-) Why do we need moving and deleting files in avio? Whats the use-case for ffmpeg? - Hendrik Suppose you're writing a video player with browsing capabilities for network protocols (like Kodi/XBMC). Now you can have file rename/delete functionality in it. Mariusz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
Suppose you're writing a video player with browsing capabilities for network protocols (like Kodi/XBMC). Now you can have file rename/delete functionality in it. Suppose you are writing a video player and need to change the screen resolution. Can we have that feature in libavutil too? Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Sun, Jun 21, 2015 at 8:24 PM, wm4 nfx...@googlemail.com wrote: On Sun, 21 Jun 2015 19:20:53 +0100 Kieran Kunhya kier...@obe.tv wrote: Suppose you're writing a video player with browsing capabilities for network protocols (like Kodi/XBMC). Now you can have file rename/delete functionality in it. Suppose you are writing a video player and need to change the screen resolution. Can we have that feature in libavutil too? Don't give them ideas... there's space for such features in libavdevice. (I'd like to have a more general multimedia framework around FFmpeg too, but messing such features into the existing libav*s for the lack of a better place is _not_ a good idea.) You know you can just say why do you think it's an unneeded feature and don't have to be trolling. Anyway, this is a part of my GSoC task that has been accepted and I'm compelled to implement it so I won't be getting into further discussion. Mariusz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Sun, Jun 21, 2015 at 10:11:53AM +0200, Hendrik Leppkes wrote: On Sat, Jun 20, 2015 at 2:52 PM, Mariusz Szczepańczyk mszczepanc...@gmail.com wrote: --- doc/APIchanges| 4 libavformat/avio.c| 38 ++ libavformat/avio.h| 19 +++ libavformat/url.h | 2 ++ libavformat/version.h | 2 +- 5 files changed, 64 insertions(+), 1 deletion(-) Why do we need moving and deleting files in avio? Whats the use-case for ffmpeg? In addition to what has been mentioned there is also the need to atomically replace files in some muxers we currently use ff_rename() for that, but that is specific to local files, It would be better / more ideal if that was not specific to just local files [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Sun, 21 Jun 2015 19:20:53 +0100 Kieran Kunhya kier...@obe.tv wrote: Suppose you're writing a video player with browsing capabilities for network protocols (like Kodi/XBMC). Now you can have file rename/delete functionality in it. Suppose you are writing a video player and need to change the screen resolution. Can we have that feature in libavutil too? Don't give them ideas... there's space for such features in libavdevice. (I'd like to have a more general multimedia framework around FFmpeg too, but messing such features into the existing libav*s for the lack of a better place is _not_ a good idea.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
El sábado, 20 de junio de 2015, Mariusz Szczepańczyk mszczepanc...@gmail.com escribió: --- doc/APIchanges| 4 libavformat/avio.c| 38 ++ libavformat/avio.h| 19 +++ libavformat/url.h | 2 ++ libavformat/version.h | 2 +- 5 files changed, 64 insertions(+), 1 deletion(-) diff --git a/doc/APIchanges b/doc/APIchanges index 6e64a05..a9efd12 100644 --- a/doc/APIchanges +++ b/doc/APIchanges @@ -17,6 +17,10 @@ API changes, most recent first: 8 - FFmpeg 2.7 was cut here 8 - +2015-xx-xx - xxx - lavf 56.38.100 - avio.h url.h + Add avio_move(), avio_delete(). + Extend URLProtocol with url_move(), url_delete(). + This goes above the 2.7 release cut line. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavf/avio: Extend API with avio_move() and avio_delete()
On Sat, Jun 20, 2015 at 2:52 PM, Mariusz Szczepańczyk mszczepanc...@gmail.com wrote: --- doc/APIchanges| 4 libavformat/avio.c| 38 ++ libavformat/avio.h| 19 +++ libavformat/url.h | 2 ++ libavformat/version.h | 2 +- 5 files changed, 64 insertions(+), 1 deletion(-) Why do we need moving and deleting files in avio? Whats the use-case for ffmpeg? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
