On Wed, Apr 08, 2015 at 06:02:16PM +0200, wm4 wrote: > On Wed, 8 Apr 2015 17:52:18 +0200 > Michael Niedermayer <michae...@gmx.at> wrote: > > > On Wed, Apr 08, 2015 at 05:40:17PM +0200, Gilles Chanteperdrix wrote: > > > On Wed, Apr 08, 2015 at 05:29:13PM +0200, wm4 wrote: > > > > On Wed, 8 Apr 2015 17:22:58 +0200 > > > > Gilles Chanteperdrix <gilles.chanteperd...@xenomai.org> wrote: > > > > > > > > > On Wed, Apr 08, 2015 at 04:13:58PM +0200, wm4 wrote: > > > > > > On Wed, 8 Apr 2015 15:37:03 +0200 > > > > > > Gilles Chanteperdrix <gilles.chanteperd...@xenomai.org> wrote: > > > > > > > > > > > > > On Wed, Apr 08, 2015 at 02:40:52PM +0200, Michael Niedermayer > > > > > > > wrote: > > > > > > > > On Wed, Apr 08, 2015 at 10:55:45AM +0200, Gilles Chanteperdrix > > > > > > > > wrote: > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > I just triend libquvi, and get a segmentation fault in the > > > > > > > > > libquvi_read_header function, because ff_copy_whitelists is > > > > > > > > > called > > > > > > > > > before qc->fmtctx is allocated by avformat_open_input. I > > > > > > > > > added a > > > > > > > > > call to avformat_alloc_context() before ff_copy_whitelists > > > > > > > > > and the > > > > > > > > > libquvi demuxer works. > > > > > > > > > > > > > > > > > > However, I wonder how to fix this properly: the error handling > > > > > > > > > labels look backward, so that I am not sure where to free the > > > > > > > > > allocated context in case of error. > > > > > > > > > > > > > > > > applied this, yes its correct > > > > > > > > > > > > > > Ok, there are other details missing, the stream does not get a > > > > > > > duration, start_time and bitrate. This can easily be fixed, but as > > > > > > > wm4 said libquvi seems an abandoned project. > > > > > > > > > > > > > > Would there be any interest in a solution based on youtube-dl? It > > > > > > > seems to be the standard, these days. I just ran a few tests: > > > > > > > > > > > > > > youtube -qs 'url' returns 0 or 1 depending on whether the url can > > > > > > > be > > > > > > > parsed by the tool > > > > > > > > > > > > > > youtube -e 'url' prints the stream title > > > > > > > > > > > > > > and youtube -f 'url' prints the video url. > > > > > > > > > > > > > > To use this portably, we can use system() and redirect the > > > > > > > output to a temporary file, and read the title or URL from the > > > > > > > file. > > > > > > > Or is popen available on all platforms where ffmpeg runs? > > > > > > > > > > > > > > Is it a clean enough solution? If yes, I can submit the patch > > > > > > > adding > > > > > > > this solution. From what I could see, all solutions to parse > > > > > > > youtube > > > > > > > (including quvi) are based on scripts anyway. > > > > > > > > > > > > > > > > > > > Calling external processes from within libavformat doesn't sound > > > > > > like > > > > > > the right thing to do. You can do it perfectly fine in a higher > > > > > > level, > > > > > > of course (I'm doing this too). > > > > > > > > > > The point is: the youtube-dl developers are doing a terrific job > > > > > maintaining their software and supporting a lot of sites: > > > > > run youtube-dl --list-extractors to be convinced. So, I do not think > > > > > it makes sense to duplicate this effort "at a higher level", this is > > > > > a waste of ressources. Maybe ask them kindly to provide us with some > > > > > command line arguments that would arrange us would make sense, > > > > > though. > > > > > > > > > > > > > I'm not talking about duplicating this. I'm saying that you should put > > > > calling youtube-dl not into libavformat, but into the application which > > > > uses libavformat. > > > > > > So, everyone should duplicate the job of using youtube-dl instead of > > > having it done once and for all in a common library ? > > > > no, some solution should be found so that all users of the ffmpeg libs > > have this support and do not need to duplicate code. > > > > The solution should be choosen so as to make people be happy about it > > and not didlike the design. > > > > a libyoutube-dl might be an option, i dont know > > > > [...] > > What the heck would this lib consist of? > > 3 lines of code that call popen()?
if thats what makes everyone happy then that would be possible. of course it would be better if it interfaced to youtube-dl in a nicer way [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
