GNOME Bugzilla – Bug 733837
hlsdemux: doesn't stop buffering more segments after overrun
Last modified: 2014-08-01 12:08:58 UTC
Created attachment 281830 [details] pause buffering after first couple fragments hlsdemux don't stop buffering more and more segments this happen in 30% of time I test it
Created attachment 281833 [details] hlsdemux don't stop buffering after overrun
In most cases it depend on how many debug information I turn on this is my testing hls stream do a local copy of stream http://live.mdragon.org/gearmix4/stream-1-110000/
That should be a problem in multiqueue. I saw that too a few times but so far had no way to reproduce it, especially not with debug logs.
make a local webserver with this hls stream and you will see it most of the time
wget -r --no-parent http://live.mdragon.org/gearmix4/stream-1-110000/
GST_DEBUG="*:1,GST_MESSAGE:0,decodebin:1,multiqueue:3,hlsdemux:5,dashdemux:5,souphttpsrc:1,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://192.168.1.88/gearmix4/stream-1-110000/index.m3u8" \ 2>&1 I get to both situations after couple runs on i7 or AMD, ubuntu 14.04 or debian 8 And I don't know if this https://bugzilla.gnome.org/show_bug.cgi?id=733640 is related to multiqueue problem too but I can reproduce it any time. ubuntu 14.04 gstreamer form https://launchpad.net/~ricotz/+archive/ubuntu/experimental?field.series_filter=trusty
It is bug in multiqueue as if I change multiqueue0(id from my pipeline) to queue2 at least Bug 733837 disappear but 733640 is still there
Created attachment 281891 [details] [review] decodebin2 use queue2 insted of multiqueue for adaptive demuxers workaround for testing purpose
The issue seems to be some bad timestamping, maybe in mpegts: calling chainfunction &gst_multi_queue_chain with buffer buffer: 0x7f13540315e0, pts 5124095:34:33.405562727, dts 99:99:99.999999999, dur 99:99:99.999999999
Created attachment 281902 [details] [review] mpegtspacketizer: avoid timestamp overflows Cause timing to break in the pipeline that can lead to a stall I'm not sure this is 100% correct, I'd like someone with mpegts experience to review this.
But I have same problem with dashdemux (qtdemux base) wget -r --no-parent http://live.mdragon.org/redbull/
It seems to play here, what exactly is the issue? Can it be reproduced always just like the HLS one? How much does it happen? Any particular tricks to make it easier to reproduce?
GST_DEBUG="dashdemux:5" gst-launch-1.0 playbin video-sink="xvimagesink" uri="http://localhost/redbull/RedBullPlayStreets_4s_isoffmain_DIS_23009_1_v_2_1c2_2011_08_30.mpd" 2>&1 | grep "uri"
Ah, now I see it. It downloaded the entire thing /o\
exactly same problem as HLSdemux And if you you use my queue2 workaround https://bug733837.bugzilla-attachments.gnome.org/attachment.cgi?id=281891 hls and dash variant will be "OK". except Bug 733640 it cache some data and then it drain
Seems to be related to fixes 139c96c1 and a93615aea1a85d5059de43614d5e6148f6ae4054 for multiqueue. It prevents multiqueue having its buffers limit set below the current level. As it is 0 (infinite) and we are just setting it to 2 it will reject whenever we have more than 2 buffers on the queue (most of the time) so you have infinite buffering in it. The bug that was fixed by those commits: https://bugzilla.gnome.org/show_bug.cgi?id=712597
Created attachment 281974 [details] [review] multiqueue: avoid using infinite buffers limit if finite is requested If the current max-buffers limit it infinite and a finite value is requested, switch to the MAX (requested, current-value) to set some limit but not below what we know that we've needed so far. https://bugzilla.gnome.org/show_bug.cgi?id=733637
Pushed in master commit 463ccd96eb07fc1515ebbac3f3cd13a19c91f0c8 Author: Thiago Santos <ts.santos@osg.sisa.samsung.com> Date: Tue Jul 29 14:21:33 2014 -0300 multiqueue: avoid using infinite buffers limit if finite is requested If the current max-buffers limit it infinite and a finite value is requested, switch to the MAX (requested, current-value) to set some limit but not below what we know that we've needed so far. https://bugzilla.gnome.org/show_bug.cgi?id=733837 And 1.4: commit e5ac798c7bc9dae4084ca02b11ba2190185371cd
dashdemux/hlsdemux fixed with you multiqueue patch and hlsdemux buffers problem fixed with your mpegtspacketizer
now I think we have another problem with adaptive demuxers with properly fixed multiqueue => download bitrate is pretty much mess Bug 733959
maybe this is still related to multiqueue problem setup gstdecodebin2 DEFAULT_HIGH_PERCENT to something lower 30-50 for example and play hls stream from intranet server it don't start but if I slow down internet connection (with traffic shaper) all works fine
I made separate Bug 734015 for tsdemux problem
So this can be closed then, remaining problem tracked in the other bug.