On Wed, Apr 08, 2015 at 07:15:51PM +0200, Gilles Chanteperdrix wrote: > Enough talking, here are some patches, and I will let the > maintainers decide. > > On the libquvi side, the first patch cleans up the error handling in > the libquvi_read_header function to avoid calling libquvi cleanup > functions on uninitialized variables. The second patch adds a call > to avformat_find_stream_info for the inner format context so as to > be able to fill the start_time, duration and bit_rate of the outer > format context. > > On the youtube-dl side, a patch adds support for a youtube-dl based > demuxer, which is functionally equivalent to libquvi, except that it > supports all the sites supported by youtube-dl. I avoided using > popen on purpose, so as to try and be as much cross-platform as > possible, though the av_tempfile function returns a file descriptor, > so, probably requires UNIX or POSIX anyway. > > In my opinion, it does not make sense to maintain both solutions. > > Regards. >
Alright, so first, I'd like to say I'm sorry to be somehow the cause of the drama, being the original author of the libquvi demuxer... At some point, I even stopped using it: it was originally written for the 0.4 (stable) serie, but then my distro upgraded it to 0.9 (unstable), dropping the 0.4 version. I don't remember if the API changed much, but one major change was about the license: it changed from LGPL to AGPL. I wasn't exactly so sure about what legal implication that had for our build so I just ignored the issue for a long time. And when I decided to long back at it, libquvi wasn't maintained anymore. So anyway, it would probably make sense to just drop libquvi support IMO. I don't consider myself a maintainer of this demuxer anymore, so feel free to send it back to hell. Now indeed there might be no alternative to this currently, as far as I understood from the youtube-dl discussions. If someone is working on an (real) API on youtube-dl side, something similar to libquvi might be nice. Oh an while I'm at it, a fast and good probe function on that API would be very welcome (just a matching of the URL, no request made or such). And finally, I'm still very much opposed to maintain our C version of these websites on FFmpeg side, as well as exec, system & friends calls to youtube-dl. If someone wants to do some heresy like that, he's free to do it outside the project (even if it's hidden in the official youtube-dl API). Anyway, sorry about digging up this dead flame, but I'm now back in the game :) -- Clément B.
pgpR0zvTNDpDb.pgp
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
