[foms] WebM Manifest

[Steve Lhomme]

On Thu, Mar 17, 2011 at 10:10 PM, Steve Lhomme <slhomme at matroska.org> wrote:
> 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).

Another benefit is that you're likely to have more than one keyframe
every 10s, so more opportunities to switch than on a fixed duration
system.

-- 
Steve Lhomme
Matroska association Chairman