[Bug 754222] adaptivedemux: Timestamping of multi-period streams is not correct

[GStreamer (GNOME Bugzilla)]

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

--- Comment #13 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
(In reply to Sebastian Dröge (slomo) from comment #12)
> (In reply to Thiago Sousa Santos from comment #11)
> > Review of attachment 310519 [details] [review] [review]:
> > 
> > ::: gst-libs/gst/adaptivedemux/gstadaptivedemux.c
> > @@ +830,3 @@
> >        stream->segment.base =
> > +          gst_segment_to_running_time (&demux->segment, GST_FORMAT_TIME,
> > +          period_start);
> > 
> > Suppose you have a dash mpd with 2 periods, P0 and P1 with 10s each. No
> > offsets.
> > 
> > The user does a flushing seek to 7s, that lands within P0 and the segment
> > will have: base=0, start=7s - 0.
> > It plays P0 until the end and moves to P1, now the segment will have:
> > base=10s, start=0.
> 
> No, it will have base=3s because the running time is calculated based on the
> demuxer segment. The demuxer segment will be start=7s,base=0s which leads to
> a running time of 3s at P1's start time (10s).
> 
> I tested this case btw, but with presentation time offsets.

Cool, got how it works and also tested it.

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