[Bug 701404] dashdemux: should not buffer the entire Period

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=701404
  GStreamer | gst-plugins-bad | 1.x

--- Comment #10 from Greg Rutz <greg at gsr-tek.com> 2013-06-12 22:51:59 UTC ---
(In reply to comment #1)
> Do you have a stream that has this scenario so we can test your patch?

Here is a test stream that exhibits the problem:

gst-launch-1.0 --gst-debug=dashdemux:5 playbin
uri=http://www-itec.uni-klu.ac.at/ftp/datasets/mmsys12/BigBuckBunny/bunny_4s/BigBuckBunny_4s_isoffmain_DIS_23009_1_v_2_1c2_2011_08_30.mpd

If you inspect the log after running this stream for about 3min, you will see
two problems.  First, the internal buffer of downloaded fragments grows large:

0:03:01.918608932  3775 0xb5b024f0 INFO               dashdemux
gstdashdemux.c:1566:gst_dash_demux_download_loop:<dashdemux0> Internal
buffering : 76 s

But the other problem is the stream_loop.  The stream loop pushes buffers out
the dashdemux src pad as fast as it can (as long as it has buffers in its
internal queue to push).  So, initially, the stream loop can keep up with the
download_loop because it is just filling downstream queue(s).  Once those
downstream queues are full, the stream loop blocks trying to push buffers. 
This causes the internal queue of downloaded buffers to continue growing since
the download loop never stops adding them.

This is bad for another reason.  With the downstream queues completely full (in
my case, it was around 30 seconds of media queued up), it takes that long for a
representation switch to appear to the user.  So, it seems like there might be
two values we want to control:

1) How much media we want to download into our internal queue of segments. 
This makes us resilient against fluctuations in network bandwidth.

2) How fast we want to push media buffers downstream on our src pad.  The
slower this value (closer to actual presentation time), the quicker the user
will see Representation changes.

Thoughts?

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.