GNOME Bugzilla – Bug 734385
decodebin2: tunning startup time for network stream
Last modified: 2018-01-25 12:53:00 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
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?
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
You could give the patches from bug #734040 a spin.
(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
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.
than if you can point me to your git branch. I tested your patch with git master.
You say "my patch", but there is also a reference to a "tsdemux-gap" branch in the other report. You need both.
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
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!