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 733837 - hlsdemux: doesn't stop buffering more segments after overrun
hlsdemux: doesn't stop buffering more segments after overrun
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
1.4.0
Other All
: Normal major
: 1.4.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2014-07-27 22:54 UTC by m][sko
Modified: 2014-08-01 12:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
pause buffering after first couple fragments (15.02 KB, application/octet-stream)
2014-07-27 22:54 UTC, m][sko
  Details
hlsdemux don't stop buffering after overrun (149.88 KB, application/octet-stream)
2014-07-27 22:55 UTC, m][sko
  Details
decodebin2 use queue2 insted of multiqueue for adaptive demuxers (2.87 KB, patch)
2014-07-28 22:00 UTC, m][sko
rejected Details | Review
mpegtspacketizer: avoid timestamp overflows (1.30 KB, patch)
2014-07-29 05:14 UTC, Thiago Sousa Santos
accepted-commit_now Details | Review
multiqueue: avoid using infinite buffers limit if finite is requested (1.71 KB, patch)
2014-07-29 18:27 UTC, Thiago Sousa Santos
committed Details | Review

Description m][sko 2014-07-27 22:54:33 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
Comment 1 m][sko 2014-07-27 22:55:37 UTC
Created attachment 281833 [details]
hlsdemux don't stop buffering after overrun
Comment 2 m][sko 2014-07-27 23:04:05 UTC
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/
Comment 3 Sebastian Dröge (slomo) 2014-07-28 07:01:43 UTC
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.
Comment 4 m][sko 2014-07-28 08:26:23 UTC
make a local webserver with this hls stream
and you will see it most of the time
Comment 5 m][sko 2014-07-28 08:56:48 UTC
wget -r --no-parent http://live.mdragon.org/gearmix4/stream-1-110000/
Comment 6 m][sko 2014-07-28 16:31:11 UTC
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
Comment 7 m][sko 2014-07-28 18:57:47 UTC
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
Comment 8 m][sko 2014-07-28 22:00:06 UTC
Created attachment 281891 [details] [review]
decodebin2 use queue2 insted of multiqueue for adaptive demuxers

workaround for testing purpose
Comment 9 Thiago Sousa Santos 2014-07-28 23:48:50 UTC
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
Comment 10 Thiago Sousa Santos 2014-07-29 05:14:18 UTC
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.
Comment 11 m][sko 2014-07-29 07:07:01 UTC
But I have same problem with dashdemux (qtdemux base)

wget -r --no-parent http://live.mdragon.org/redbull/
Comment 12 Thiago Sousa Santos 2014-07-29 12:58:15 UTC
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?
Comment 13 m][sko 2014-07-29 14:14:04 UTC
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"
Comment 14 Thiago Sousa Santos 2014-07-29 15:38:18 UTC
Ah, now I see it. It downloaded the entire thing /o\
Comment 15 m][sko 2014-07-29 15:46:36 UTC
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
Comment 16 Thiago Sousa Santos 2014-07-29 16:26:03 UTC
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
Comment 17 Thiago Sousa Santos 2014-07-29 18:27:21 UTC
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
Comment 18 Thiago Sousa Santos 2014-07-30 00:09:32 UTC
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
Comment 19 m][sko 2014-07-30 06:56:37 UTC
dashdemux/hlsdemux fixed with you multiqueue patch
and
hlsdemux buffers problem fixed with your mpegtspacketizer
Comment 20 m][sko 2014-07-30 07:27:41 UTC
now I think we have another problem with adaptive demuxers
with properly fixed multiqueue
 => download bitrate is pretty much mess
Bug 733959
Comment 21 m][sko 2014-07-30 22:08:37 UTC
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
Comment 22 m][sko 2014-07-30 22:45:11 UTC
I made separate 
Bug 734015
for tsdemux problem
Comment 23 Sebastian Dröge (slomo) 2014-08-01 12:08:58 UTC
So this can be closed then, remaining problem tracked in the other bug.