After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 691162 - qtdemux: very long prerolling time for totalrecall.mp4 in push mode
qtdemux: very long prerolling time for totalrecall.mp4 in push mode
Status: RESOLVED DUPLICATE of bug 705703
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
1.x
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-01-05 00:59 UTC by Arnaud Vrac
Modified: 2018-05-10 12:29 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Arnaud Vrac 2013-01-05 00:59:29 UTC 
The following pipeline takes a very long time to preroll when pipeline is configured in push mode:

gst-launch-1.0 -v souphttpsrc location= http://absolut.zogzog.org/share/samples/mp4/totalrecall.mp4 ! qtdemux .audio_0 ! fakesink silent=FALSE

It seems the audio stream first sample is far after the first video samples,  prerolling only happens after sample 163363. Maybe the file is badly muxed ? It works well in pull mode, but I guess it is easy to seek back and forth in this case.
Comment 1 Arnaud Vrac 2013-02-13 19:08:05 UTC 
I can't even play this file when qtdemux is in pull mode. Is there any way qtdemux could play files with audio samples at the end of the file in both push and pull mode ? I think it's better to seek a lot even on slow sources than to not play at all.
Comment 2 Tim-Philipp Müller 2013-02-13 19:15:50 UTC 
> I can't even play this file when qtdemux is in pull mode.

You mean push mode?

> I think it's better to seek a lot even on slow sources than to
> not play at all.

That can be enabled by setting ring-buffer-max-size on playbin, fwiw, or enabling download-buffering.
Comment 3 Arnaud Vrac 2013-02-13 19:40:29 UTC 
(In reply to comment #2)
> > I can't even play this file when qtdemux is in pull mode.
> 
> You mean push mode?

I did mean pull mode, there was a typo in my pipeline, sorry... The file still fails in push mode though.

> 
> > I think it's better to seek a lot even on slow sources than to
> > not play at all.
> 
> That can be enabled by setting ring-buffer-max-size on playbin, fwiw, or
> enabling download-buffering.

The ring-buffer breaks playback of some other streams like http web radios, because buffering will take a very long time and the stream is not advertised as live. Download buffering is out of the question, the device I'm using does not have local storage.
Comment 4 Arnaud Vrac 2013-02-13 19:50:46 UTC 
Maybe the demuxers could handle a downstream "overrun" signal from a queue, triggering a mechanism to send data on the other pads ?
Comment 5 Arnaud Vrac 2013-02-13 21:24:16 UTC 
The ring buffer will also trigger buffering very often on files where audio and video samples are far away. After each seek the queue will be empty and send a buffering event.
Comment 6 Arnaud Vrac 2013-02-13 21:26:36 UTC 
The problem could also be solved by reopening the http url for each stream in the avi file... No seek would be needed then except to read the index. This might be a little complicated to do though ;)
Comment 7 Edward Hervey 2018-05-10 12:29:45 UTC 

*** This bug has been marked as a duplicate of bug 705703 ***