[FFmpeg-devel] Segmentation fault in libquvi.c

[wm4]

On Wed, 8 Apr 2015 17:40:17 +0200
Gilles Chanteperdrix <gilles.chanteperdrix at xenomai.org> 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.chanteperdrix at 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.chanteperdrix at 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 ?
> 

There are many things that shouldn't be duplicated, but have to because
ffmpeg is a low level library.

Just calling youtube-dl with system() or whatever certainly isn't the
hardest or most common one.