[foms] WebM Manifest

[Steve Lhomme]

On Thu, Mar 17, 2011 at 4:59 PM, Mark Watson <watsonm at netflix.com> wrote:
> The problem is that adaptive streaming is more complex than simply
> concatenating a bunch of resources found at URLs advertised in a manifest.
> Firstly, you need reasonably small granularity in terms of switch points. 2s
> is good. 10s is too long.
> Next if you had a separate file for each 2s chunk, then you have an
> unmanageably large number of files (it would be ~25 billion for our content
> library).
> The solution in DASH (required in the "Basic On Demand" profile) is to store
> the content as a single file for each bitrate. At the start of a file is an
> index giving the time-to-byte-range mapping for the 2s fragments (2s is an
> example - the spec doesn't constrain you). This is for on-demand, not live,
> btw. The index is in the file, binary coded, to keep it compact and thereby
> keep startup time low. If it was in the XML Manifest it would be huge.
> To construct byte range requests you need to read and parse this index. I'm
> not sure Javascript has good tools for efficiently handling & parsing binary
> data yet.

Would it be possible in DASH to have no pre-defined fragment duration
? If you load the index of all the available streams on startup, you
have your seek points with time. Given it's the same source and
probably the same codec/encoder, there's a very good chance the
keyframes, and thus the switch points are exactly in the same place.
That would avoid forcing the encoder the extra fragmentation
constraint and use the available bandwidth more wisely (better end
user quality).

The pre-defined fragment duration may not be avoidable in the live
streaming context.

I think there is a JavaScript library somewhere that can parse Matroska streams.

-- 
Steve Lhomme
Matroska association Chairman