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 734385 - decodebin2: tunning startup time for network stream
decodebin2: tunning startup time for network stream
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.4.0
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-08-06 21:47 UTC by m][sko
Modified: 2018-01-25 12:53 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description m][sko 2014-08-06 21:47:20 UTC
I recently play with network stream startup time
and it isn't really nice to wait 10 and more seconds until user really see something

for example for hls stream
AUTO_PREROLL_SIZE_BYTES                  2 * 1024 * 1024  => 2MB
AUTO_PREROLL_NOT_SEEKABLE_SIZE_TIME      10 * GST_SECOND

and after it preroll it is switch to 
AUTO_PLAY_ADAPTIVE_SIZE_BUFFERS 2

but still we have 10s PREROLL TIME in second multiqueue

I know that most of this values isn't problem for playback from local file system
but for network streaming it is long wait time.

I think we can tune it with  DEFAULT_HIGH_PERCENT     to something like 20% for network streams and first multiqueue can stay in buffers mode
Comment 1 Sebastian Dröge (slomo) 2014-08-13 15:29:17 UTC
The 10 seconds are only completely used if the demuxer does not signal no-more-pads. Otherwise it waits only until then.

What's the scenario where you see these 10 seconds to be completely used?
Comment 2 m][sko 2014-08-13 22:04:15 UTC
I wasn't aware of no-more-pads.
but still
1.
VDR stream server provide http to get transport stream
it is like when you have .ts file on web server
http://live.mdragon.org/test.ts

And it wait until queue2( in uridecodebin ) is full 

GST_DEBUG="*:1,GST_STATES:0,GST_MESSAGE:0,decodebin:5,multiqueue:5,queue2:5,hlsdemux:5,dashdemux:0,souphttpsrc:0,mpegtspacketizer:0,input-selector:0,query:0,pad:0,uridecodebin:1,basesink:0,GST_PADS:0,glimagesink:0,xvimagesink:0,videodecoder:0,tsdemux:0,mpegtsbase:0,mpegtsparse:0,uridownloader:0" \
gst-launch-1.0 playbin video-sink="xvimagesink" uri="http://live.mdragon.org/test.ts"

2.
hls
ok it don't take 10s
10s is changed to 5s after no-more-pads

but it still wait until multiqueue( multiqueue1 ) preroll 5s
http://pastebin.com/04s3yLBW

and sometimes if I changed multiqueue2( multiqueue1 ) low/high-percent to low values like 5 and 10 and max-size-time=2s
It don't start at all. absolutely random
Comment 3 Tim-Philipp Müller 2014-08-13 22:13:43 UTC
You could give the patches from bug #734040 a spin.
Comment 4 m][sko 2014-08-14 21:36:59 UTC
(In reply to comment #3)
> You could give the patches from bug #734040 a spin.
still too much seconds until pipeline start to PLAY

it still wait until multiqueue in uridecodebin signal overrun
Comment 5 Tim-Philipp Müller 2014-08-14 22:10:57 UTC
With the patches from the git branch and my gap event patch? Not here. It still takes longer than it should, but not multiple seconds, and it certainly doesn't wait until the multiqueue is full, not in my testing anyway, but perhaps I have other patches that you don't have.
Comment 6 m][sko 2014-08-15 08:47:12 UTC
than if you can point me to your git branch.
I tested your patch with git master.
Comment 7 Tim-Philipp Müller 2014-08-15 08:50:36 UTC
You say "my patch", but there is also a reference to a "tsdemux-gap" branch in the other report. You need both.
Comment 8 m][sko 2014-08-18 22:32:05 UTC
I did try both but still same effect
pipeline wait until queue2-0 preroll
I can see no-more-pads event
but then it still wait for preroll

gst-launch-1.0 playbin video-sink="xvimagesink"
uri="http://live.mdragon.org/test.ts"

gstreamer git master 
(2 days old from
https://launchpad.net/~ricotz/+archive/ubuntu/experimental?field.series_filter=trusty)
+
gstreamer-bad from
https://github.com/thaytan/gst-plugins-bad/commits/tsdemux-gap
and your patch
Comment 9 Tim-Philipp Müller 2018-01-25 12:53:00 UTC
Not sure what to do about this. Lots of changes since. Test stream is gone.

Please feel free to re-open if it's still a problem with a recent version of GStreamer, thanks!