[FFmpeg-devel] Segmentation fault in libquvi.c

[Michael Niedermayer]

On Wed, Apr 08, 2015 at 05:29:40PM +0200, Gilles Chanteperdrix wrote:
> On Wed, Apr 08, 2015 at 04:26:20PM +0200, Michael Niedermayer wrote:
> > 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
> 
> I think the set of sites supported by libquvi is really small
> compared to the ones supported by youtube-dl, and even smaller the
> site that actually work, because they have changed and quvi did not
> change.
> 
> > 
> > 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/...
> 
> Meanwhile, I get that solution working, however, there is a catch:
> youtube-dl has a "generic" extractor which accepts plain http urls
> to videos, so, when the input format opens the nested import
> formats, the probe function succeeds again, and we have an infinite
> recursion, I have not found a way to disable this extractor on the
> command line, and have to admit that my ffmpeg knowledge is not
> sufficient at this point, the only solution I have found to prevent
> recursion is to return 0 in the probe function all the time, and
> only be able to use the format with -f. Shall I send the patch, or
> could you explain me how to avoid this ?

probe could detect the most common things by comparing strings
to a short list of domains/url fragments the rest could require
-f

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- 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/96efaa44/attachment.asc>