[Bug 751792] dashdemux: incorrect segment duration for a segment list

[GStreamer (GNOME Bugzilla)]

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

--- Comment #17 from Florin Apostol <florin.apostol at oregan.net> ---
(In reply to Vincent Penquerc'h from comment #16)
> (In reply to Florin Apostol from comment #15)
> > Review of attachment 311055 [details] [review] [review]:
> > 
> > ::: ext/dash/gstmpdparser.c
> > @@ +3408,3 @@
> > +              GstMediaSegment *next_segment =
> > +                  g_ptr_array_index (stream->segments, n + 1);
> > +              if (next_segment && next_segment->start < PeriodEnd)
> > 
> > how could media_segment->start + media_segment->duration > PeriodEnd but
> > next_segment->start < PeriodEnd ?
> > Isn't it guaranteed that segment end < next segment start? If not, then we
> > have overlapping segments.
> 
> We're trying to fix up segments that don't fit in the declared period in the
> first place. If we assume these could be wrong, then it seems fair not to
> assume those can't be wrong either. I'm still not very comfortable with how
> this (periods, segments, media durations) all fits together though, so maybe
> this makes less sense for those to be wrong.

We should aim to detect any possible inconsistencies in the mpd manifest.
In order to implement these checks, I would have changed the
gst_mpd_client_add_media_segment function or made the checks before calling it.
There, we could have checked overlaps between segments and conflicts between
segment end and period end. It is more natural to check before adding to list
than to add to list and later remove from it.
We still should add checks for overlaps between segments and those are more
easily done before adding to list than later.

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