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

[GStreamer (GNOME Bugzilla)]

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

Thiago Sousa Santos <thiagossantos at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thiagossantos at gmail.com

--- Comment #4 from Thiago Sousa Santos <thiagossantos at gmail.com> ---
(In reply to Mathieu Duponchelle from comment #0)
> 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?

>From the spec, it seems the default is indeed 1. We should follow the spec.

"if SegmentTemplate element is present the Template-based Segment URL
construction in 5.3.9.4.4 shall be applied with the number of the Media Segment
in the Media Segment list. The first number in the list is determined by the
value of the SegmentTemplate at startNumber attribute, if present, or is 1 in case
this attribute is not present."

> 
> 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.

So, despite the presentationTimeOffset, all streams start from timestamp=0 as
usual just like if the presentationTimeOffset was ignored?

> 
> 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

It seems the section 7.2.1 in the spec is the one that explains how
presentationTimeOffset should be used.

"The presentation times within each Period are relative to the PeriodStart time
of the Period minus the value of the @presentationTimeOffset, To , of the
containing Representation. This means for an access unit with a presentation
time Tp signalled in the media stream, the Media Presentation time relative to
the PeriodStart is Tm = Tp - To .
Media Segments should not contain any presentation time Tp that is smaller than
the value of the @presentationTimeOffset, To . However, if this is the case,
then presentation of the Media Segment is expected to only take place for
presentation times greater than or equal to To."

It seems like the offset into the stream where playback should start from. It
might be used to skip initial data. Maybe someone from BBC has a different
interpretation?

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