[Bug 780397] dashdemux: Fix SEEK of multi-period On-Demand profile

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Thu Mar 23 23:36:51 UTC 2017


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

--- Comment #5 from Seungha Yang <sh.yang at lge.com> ---
(In reply to Sebastian Dröge (slomo) from comment #3)
> Review of attachment 348483 [details] [review]:

Sorry, I couldn't share it since it's private stream.
But I can show how the MPD looks like (it's on-demand profile)

<Period duration="PT8S" id="0">
... 
<SegmentTemplate duration="90000" media="audio$Number%08d$.m4a"
presentationTimeOffset="1231" startNumber="0" timescale="1000">
</SegmentTemplate>
..
</Period>

<Period duration="PT10S" id="1">
<SegmentTemplate duration="90000" media="audio$Number%08d$.m4a"
presentationTimeOffset="22599" startNumber="1" timescale="1000">
</SegmentTemplate>
...
</Period>
....

> ::: ext/dash/gstdashdemux.c
> @@ +1345,3 @@
> +        gst_mpd_parser_get_period_start_time (dashdemux->client);
> +    if (ts > period_start)
> +      ts -= period_start;
> 
> What if ts <= period_start? Especially the == case seems useful to handle
> here. The < case is probably an error and we should just error out?

Obviously, equal condition need to be handled. I fixed it on attachment 348626.
The "<" case seems to be an error case (it's outside of period!!), which should
not be happen but seems to be probable case for example Bug 776559 case.
I'm not sure whether return ERROR is correct or not, because whenever
stream_seek() has returned FLOW_OK until now. 

> Would it make sense to first add the presentation offset, and then do the
> subtraction?

In my opinion, add presentation offset first or later seems same if the target
seek position was inside of the period :)

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


More information about the gstreamer-bugs mailing list