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

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 745455
           Summary: dashdemux doesn't take the presentationTimeOffset into
                    account.
    Classification: Platform
           Product: GStreamer
           Version: unspecified
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: mduponchelle1 at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Disclaimer: I don't think these patches are ready for merging yet, submitting
them for discussion's sake.

The BBC offers various kinds of streams for testing at
http://rdmedia.bbc.co.uk/dash/ondemand/testcard/

I want to make the streams containing presentationTimeOffsets work with dash
demux, for now the sinks receive segments that make them wait for 10 minutes
before starting playback with these streams, for example :

gst-validate-1.0 playbin
uri=http://rdmedia.bbc.co.uk/dash/ondemand/testcard/1/client_manifest-pto_both-events.mpd

There also is a separate issue with the three streams listed there, in that
their segment indices start at 1, which requires a patch to avoid getting a
404. I couldn't find anything in the specifications stating the default index
to start from, I would expect it to be 0, in which case I wonder if dashdemux
could maybe try 0 first, then if it gets a 404 try with 1?

The second patch makes dashdemux take into account the presentationTimeOffset
to calculate the fragment timestamp, it only does this for SegmentTemplates, I
don't have a mpd available with individual segments, I suppose the patch should
also be needed for that case.

The third patch makes it so adaptivedemux sets a different start on the
segments it sends for each stream, so that the presentationTimeOffset is
correctly taken into account.

With these patches, the behaviour matches what the BBC describes (audio and
video are matched, playback starts at ~ 0 second (actually 3.84), and lasts for
twenty minutes.

Patches attached next

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