GNOME Bugzilla – Bug 780397
dashdemux: Fix SEEK of multi-period On-Demand profile
Last modified: 2017-04-09 07:55:03 UTC
For each period, media presentation time is the relative to the period-start time. So SIDX seek position should be target seek position minus period-start. Also, if presentationTimeOffset is defined, the value should be compensated
Created attachment 348483 [details] [review] dashdemux: Fix SEEK of multi-period On-Demand profile
Do you have a example stream for this?
Review of attachment 348483 [details] [review]: ::: 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? Would it make sense to first add the presentation offset, and then do the subtraction?
Created attachment 348626 [details] [review] dashdemux: Fix SEEK of multi-period On-Demand profile
(In reply to Sebastian Dröge (slomo) from comment #3) > Review of attachment 348483 [details] [review] [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 [details] [review]. 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 :)
Attachment 348626 [details] pushed as 41996ad - dashdemux: Fix SEEK of multi-period On-Demand profile