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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #25 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
commit c9f60db2d489cda27629e91fe3009e7c90769460
Author: Sebastian Dröge <sebastian at centricular.com>
Date:   Thu Sep 3 14:20:00 2015 +0300

    mpdparser: Don't consider period start times in periods with segment lists
either

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

commit d9c45e918fd70cfbb2dea076c0320f1b69146c3a
Author: Sebastian Dröge <sebastian at centricular.com>
Date:   Thu Sep 3 10:26:03 2015 +0300

    mpdparser: Fix unit test that assumed that fragment timestamps should
include the period start timestamp

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

commit 0d0455e346438c6bf3bc68c3510587016f1a5bdc
Author: Sebastian Dröge <sebastian at centricular.com>
Date:   Wed Sep 2 18:33:51 2015 +0300

    dashdemux: Export the period start time to the base class

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

commit d1c5669a384dfb7bc451eb68ba1dbfe11675a149
Author: Sebastian Dröge <sebastian at centricular.com>
Date:   Wed Sep 2 18:29:43 2015 +0300

    adaptivedemux: Properly implement timestamping of multi-period streams

    Each period will start again with pts 0 + period presentation offset, which
is
    also going to be the presentation time inside the container stream if any.
    However all periods together should form a continuous timeline, with regard
to
    stream time and running time.

    For making this possible we keep track of the "user requested segment",
i.e.
    the seek events, inside the demuxer without adjusting anything and taking
this
    demuxer segment only as orientation for modified segments per stream.

    This per stream segments will have their segment.start at pts that would be
    produced for this stream in this period, and the segment.base/time adjusted
so
    that this pts maps to the running and stream time this period should have
in
    the context of all other periods.

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


commit b5697b8ced15b995382a9dd5d899eb6c10e7f775
Author: Sebastian Dröge <sebastian at centricular.com>
Date:   Tue Sep 1 13:13:58 2015 +0300

    Revert "dashdemux: Subtract the period start time from the presentation
offset"

    This reverts commit 626a8f0a74f8ea748b811b74ba9e7ae2baea2cca.

    This allows us to get the plain presentation offset and the period start
time
    separately. We have to adjust the timestamp by the presentation offset, but
    the period start time should only adjust the stream time and running time.

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

commit bb05bbafd55833f18722ffc828186fa7710dc352
Author: Sebastian Dröge <sebastian at centricular.com>
Date:   Tue Sep 1 13:12:45 2015 +0300

    Revert "dashdemux: Include the period start in the fragment timestamps in
all cases"

    This reverts commit e671ad25a989cb21c62c7a5867c2090890ce49ba.

    The timestamps should restart at 0 again for each period, but we have to
    adjust the segment to map those timestamps to the actual stream time and
    running time of that period.

    Otherwise we would have timestamps that conflict with the ones from the
tfdt
    inside the MP4 container, which are restarting at 0 for each period.

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

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