[FFmpeg-devel] Segmentation fault in libquvi.c

Michael Niedermayer michaelni at gmx.at
Wed Apr 8 16:26:20 CEST 2015


On Wed, Apr 08, 2015 at 04:01:38PM +0200, Gilles Chanteperdrix wrote:
> On Wed, Apr 08, 2015 at 03:51:36PM +0200, Lukasz Marek wrote:
> > On 8 April 2015 at 15:37, 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.
> > >
> > 
> > I submitted a patch more that year ago to support youtube natively, as I
> > remember this was based on the script you mention, but it was rejected
> > because we have libquvi. [sic!]
> > Project not actively developed is not the same as project not working.
> > In corner case it is not developed because everything is working
> > perfectly.
> 
> libquvi seems to work on youtube yes, but not on daily motion and
> other streaming sites I tried where youtube-dl works, it simply does
> not work. The sites change, so the tool to parse them must be up to
> date to work correctly. So no, libquvi does not "work perfectly".
> 
> And libquvi ffmpeg demuxer does not seem to be in a very good shape
> either, it simply segfaults, and even when the segfault is resolved,
> has other issues, the extern AVFormatcontext fields are simply not
> filled.

the whitelist segfault is already fixed
and it worked with git master (download from youtube) today

maybe someone wants to take over libquvi maintaince ? i mean libquvi
not our wraper. ive seen there are patches on teh libquvi developer
mailing list which supposedly fix some of the not working services

but really iam happy with any solution that works and that people
like, libquvi, youtube-dl, anythng else

but a plain ./ffplay http://youtube.com/...
should work ideally
or less ideally with a forced demuxer -f xxx http://youtube.com/...

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- 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/e12bc166/attachment.asc>


More information about the ffmpeg-devel mailing list