[Bug 754230] qtdemux: support sparse time ranges in qtdemux without needing a seek for MSE

[GStreamer (GNOME Bugzilla)]

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

--- Comment #1 from Enrique Ocaña González <eocanha at igalia.com> ---
We don't know the timestamps because the MSE append()[1] API only supports
binary data. This API is ultimately used from JavaScript by the web page,
completely out of WebKit's control.

This is a brief summary of how the spec expects things to work:

You append some raw binary data one or more times. That raw binary data can
provide info about an "initialization segment" (headers) or a "media segment"
(actual audio/video samples). The only information that the user of append()
can provide is the stream duration ([0, infinity] by default). The "segment
parser" (ie: qtdemux in our case) must be able to generate accurate timestamps
based on the info provided by the headers. As a result, some buffered ranges
are generated, indicating what collection of samples have been detected and are
now owned by the MSE layer, ready to be used for playback if needed.

Some particular cases:

- If you append the same raw data twice, the buffered ranges don't change,
because the same samples (PTS) are generated the second time and they overwrite
the existing ones.

- You should be able to append raw data corresponding to [0, 1:00] and [2:00,
2:30] and MSE should generate buffered ranges accordingly by itself.

Other implementations not based on GStreamer (eg: Chromium) have their own
"ChunkDemuxer" that analyzes the headers and report the times stored there. In
the case of GStreamer, this is a task for qtdemuxer.

I hope to have clarified the use case a little bit.

[1]
https://w3c.github.io/media-source/#widl-SourceBuffer-appendBuffer-void-ArrayBuffer-data

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