[Bug 745455] dashdemux: doesn't take the presentationTimeOffset into account.

[GStreamer (GNOME Bugzilla)]

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.