[Bug 777206] mosaic issue for MPEG DASH live streaming

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=777206

--- Comment #5 from John Chang <r97922153 at gmail.com> ---
Created attachment 343516
  --> https://bugzilla.gnome.org/attachment.cgi?id=343516&action=edit
Fix the issue when updating thread sets slow start without passing necessary
header & caps down.

Dear Sebastian:

As your suggestions;
I have put "last_representation_id" under GstDashDemuxStream instead of the
common part "GstAdaptiveDemuxStream" 

As the other part, I am not so sure about your comments.

For this issue, the race condition may NOT merely happen in this case.
As an example, please check the scenario below:
1. Update loop thread gets the manifest_lock & selects slow start. = 125000
bits/sec(originaly it is at 250000 bits/sec).

2. The src thread calculates the estimated bitrate & the result is as original
= 250000.

To this point, if we could execute the flow:
  if (ret == GST_FLOW_OK) {
    if (gst_adaptive_demux_stream_select_bitrate (demux, stream,
            gst_adaptive_demux_stream_update_current_bitrate (demux, stream)))
{
      stream->need_header = TRUE;
      ret = (GstFlowReturn) GST_ADAPTIVE_DEMUX_FLOW_SWITCH;
    }
    ...

Everything will be fine.
However, the ret may not always be GST_FLOW_OK but sometimes is GST_FLOW_EOS. 
Hence the calculated bit-rate = 250000 will NOT be set (since
gst_adaptive_demux_stream_select_bitrate() is skipped).

In fact, there are several conditions involved when this issue hapeens.

Also, the timing to set new caps should be taken into consideration.
Notice that at gst_adaptive_demux_stream_push_buffer():

  ...
  if (G_UNLIKELY (stream->pending_segment)) {
    GST_ADAPTIVE_DEMUX_SEGMENT_LOCK (demux);
    pending_segment = stream->pending_segment;
    stream->pending_segment = NULL;
    GST_ADAPTIVE_DEMUX_SEGMENT_UNLOCK (demux);
  }
  ...

It passes the pending caps immediately when we are about to push a buffer down.
However, the update loop thread may NOT always set the pending caps (be
executed) on the beginning (at the 1st buffer) of a new segment (fragment).
Hence the new caps may locate within the buffers of a segment instead of at the
beginning as required.
Since the caps event is expected to be serialized, we should avoid this case.

As the result, I put the check for header & caps when live streaming within
gst_dash_demux_stream_update_fragment_info.

It is the place when we finally decide which fragment (representation of a
specific bit-rate) will be downloaded.
So no matter how the execution sequence of mentioned threads changes, we could
make sure the correctness.

Could you please give a more detailed description about your first comments?

Thank you.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.