[FFmpeg-devel] Segmentation fault in libquvi.c

[Michael Niedermayer]

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

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

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire
-------------- 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/20150408/16257bb7/attachment.asc>