MP4 timing issue implementing a dash demux

[david.corvoysier at orange.com]

Hi,
 
After discussing with DASH experts, it appears that specific DASH boxes have been added to address this issue.
The Track Fragment Decode Time (tfdt) seems in particular to be the place where the fragment offset is supposed to be specified.
I have modified the qtdemux to parse it and add the result to the output timestamps, and it solves the playback issues.
 
I have created a bug here: https://bugzilla.gnome.org/show_bug.cgi?id=677535 <https://bugzilla.gnome.org/show_bug.cgi?id=677535> 
 
David 

________________________________

De : gstreamer-devel-bounces+david.corvoysier=orange.com at lists.freedesktop.org [mailto:gstreamer-devel-bounces+david.corvoysier=orange.com at lists.freedesktop.org] De la part de david.corvoysier at orange.com
Envoyé : mardi 29 mai 2012 17:08
À : gstreamer-devel at lists.freedesktop.org
Cc : sebastian.droege at collabora.co.uk
Objet : MP4 timing issue implementing a dash demux



Hi, 

Following Sebastian advice, we have implemented an MPEG DASH demux based on the HLS demux code. 
Basically, the demux fetches the MP4 data fragments and pass them downstream. 
Whenever a new bitrate is selected, a new output pad is created and decodebin2 creates the appropriate decoding chain. 
In each new chain, decodebin2 instantiates in particular a new isomp4 demux, to which the DASH demux forwards an MP4 header (the initialization header), followed by as many MP4 data fragments.

The DASH demux also sends a new segment event to specify the playback offset for that chain. 

The issue we have is that the isomp4 demux ignores the new segment event and starts timestamping output buffers at 0. 
This is harmless on some configurations where the video sink outputs frames in decoding order ignoring the timestamps, but on more restrictive configurations, it blocks playback until the new chain catches up with the playback time at which the previous one stopped (and as a nasty side effect, it rapidly drains our download queue, causing playback jerkiness).

I am not sure how to handle this: should we force the new chain to seek up to the playback position it is supposed to start ? Should the offset rather be encoded in the MP4 enveloppe ? If so, would it even be parsed by the current isomp4 demux ?

Thanks in advance for any explainations (I may have got it all wrong) and/or tips ... 

David Corvoysier 
Orange Labs 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20120606/f3a011d1/attachment.htm>