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

[GStreamer (GNOME Bugzilla)]

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

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

OK, should I then push my first patch with an amended message?

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

No, with the patches I proposed, the timestamps are left untouched, for example
with
http://rdmedia.bbc.co.uk/dash/ondemand/testcard/1/client_manifest-pto_video-events.mpd
the first timestamp is 0:00:03.840000000 for audio and 0:10:03.840000000 for
video.

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

I actually share BBC's interpretation, as far as I understand, taking the mpd I
linked above as an example, I understand the first Tp to be 10:03.840000000 for
video and 00:03.840000000 for audio, thus being compliant with the requirement
of having Tp - To to be positive (in both cases it is 00:03.840000000). I'm not
exactly sure about the use case this is supposed to serve, but I think the
BBC's interpretation is correct here?

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