[Bug 745455] dashdemux: doesn't take the presentationTimeOffset into account.
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Thu Jun 25 14:41:58 PDT 2015
https://bugzilla.gnome.org/show_bug.cgi?id=745455
Sebastian Dröge (slomo) <slomo at coaxion.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Resolution|--- |FIXED
--- Comment #36 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
commit 548ed60e86b21c55ab566a32eb60a109d4757587
Author: Sebastian Dröge <sebastian at centricular.com>
Date: Thu Jun 25 23:32:10 2015 +0200
adaptivedemux: Properly handle presentationTimeOffset for seeking and
multi-period streams
Segment start/time/position/base should only be modified if this is the
first
time we send a segment, otherwise we will override values from the seek
segment if new streams have to be exposed as part of the seek.
Segment base should be calculated from the segment start based on the
stream's
own segment, not the demuxer's segment. Both might differ slightly because
of
the presentationTimeOffset.
Always add the presentationTimeOffset (relative to the period start, not
timestamp 0) to the segment start after resetting the stream's segment
based
on the demuxer's segment (i.e. after seeks or stream restart). Also make
sure
to keep the stream's segment up to date and not just send a new segment
event
without storing the segment in the stream.
https://bugzilla.gnome.org/show_bug.cgi?id=745455
commit 626a8f0a74f8ea748b811b74ba9e7ae2baea2cca
Author: Sebastian Dröge <sebastian at centricular.com>
Date: Thu Jun 25 23:24:50 2015 +0200
dashdemux: Subtract the period start time from the presentation offset
We're interested in the offset between the period start timestamp and the
actual media timestamp so that we can properly correct for it. The absolute
presentation offset to timestamp 0 is useless as the only thing we really
care about is the offset between the current fragment timestamp and the
media timestamp.
commit 95eb1aa49c130bb2f58ec6712bd8cb8b61326b99
Author: Sebastian Dröge <sebastian at centricular.com>
Date: Thu Jun 25 20:19:34 2015 +0200
dashdemux: Subtract the period start when seeking based on a template
Otherwise we will look for segments after the period usually. The seek
timestamp is relative to the start of the first period and we have to
select a segment relative to the current period's start.
commit e671ad25a989cb21c62c7a5867c2090890ce49ba
Author: Sebastian Dröge <sebastian at centricular.com>
Date: Thu Jun 25 20:09:14 2015 +0200
dashdemux: Include the period start in the fragment timestamps in all cases
We didn't do this for fragments that are generated on demand from a
template,
only for the other cases when they were all generated upfront. This caused
fragment timestamps to start from 0 again for each new period.
commit 9e8e1c452d6264498f8cfc6b0fa8f92556c8c121
Author: Sebastian Dröge <sebastian at centricular.com>
Date: Thu Jun 25 23:23:58 2015 +0200
dashdemux: Seek on the new streams if the seek caused a period switch
Seeking on the old streams is pointless, they are going to be freed on the
next opportunity.
--
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