GNOME Bugzilla – Bug 755172
dashdemux: seeking in a stream that uses a SegmentList downloads all fragments
Last modified: 2015-09-18 10:02:55 UTC
I have produced two DASH streams from the same fragmented MP4 files. The first uses a single file for each Representation and a SegmentList with SegmentURL elements to extract each fragment from the file. The second has separate MP4 files for each fragment. Seeking when using the version with separate MP4 files is working, but the version using the SegmentList is exhibiting some odd behaviour. If I seek to the middle of the stream, dashdemux is downloading all fragments between the start and the chosen seek point. The version with a SegmentList: http://test-media.youview.co.uk/ondemand/bbb/timecode/range/timecode.mpd The version with separate files: http://test-media.youview.co.uk/ondemand/bbb/timecode/sep/timecode.mpd There are also versions with a single Representation per AdaptationSet (i.e. no adaptive bitrate). Single bitrate with a SegmentList: http://test-media.youview.co.uk/ondemand/bbb/timecode/range/timecode-sbr.mpd Single bitrate with separate files: http://test-media.youview.co.uk/ondemand/bbb/timecode/sep/timecode-sbr.mpd
We're not parsing the d attributes from the SegmentURL currently, it probably starts at the very beginning each time you seek and drops all data until the seek position.
The 2014 spec does not allow the d attribute there, only in S nodes
You can have a duration attribute in the SegmentList node though, which is the duration of each segment (not the sum of all).
When overriding the SegmentList duration value from that high number to 512 (the segment duration), seeking works just fine on this stream.
(In reply to Sebastian Dröge (slomo) from comment #2) > The 2014 spec does not allow the d attribute there, only in S nodes Actually the Schema says: <!-- Segment URL --> <xs:complexType name="SegmentURLType"> <xs:sequence> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="media" type="xs:anyURI"/> <xs:attribute name="mediaRange" type="xs:string"/> <xs:attribute name="index" type="xs:anyURI"/> <xs:attribute name="indexRange" type="xs:string"/> <xs:anyAttribute namespace="##other" processContents="lax"/> </xs:complexType> So the d node is undefined in the spec, rather than prohibited. The reason for the bug ticket was because this is the style of manifest used by a certain large provider of VoD content. Thanks for spotting the error in the SegmentList@duration. I will feed that back.
Great, please make sure they fix that :) Not really surprising that everybody gets this monster spec wrong in one way or another.
I've updated the manifests and I am no longer seeing dashdemux download every fragment following a seek.
Thanks for confirming!