[foms] WebM Manifest

[Mark Watson]

On Mar 17, 2011, at 11:52 PM, Steve Lhomme wrote:

> On Fri, Mar 18, 2011 at 12:10 AM, Timothy B. Terriberry
> <tterribe at xiph.org> wrote:
>>> In the case you describe the only drawback is that playback is not as
>>> perfect as it can theoretically be. But that's expected when using
>>> adaptive streaming anyway.
>> 
>> The comments I gave before were not meant to be an exhaustive list of
>> shortcomings. You also need to either a) know enough about the streams
>> in advance to know whether or not such a switch will be successful
>> (i.e., if you can't find that information in the manifest, then you'll
>> need a full keyframe index, exposed in Javascript, which you would
>> otherwise not need), meaning higher startup costs, etc., or b) you can
>> try to make such a switch without knowing that it will succeed, and
>> frequently download a lot of extra data which must be thrown away when
>> you fail. Either way you add a lot of implementation complexity to do
>> it. I guess maybe that all still falls under "playback is not as perfect
>> as it can theoretically be", but that continues all the way down to, "It
>> doesn't play at all."
> 
> The manifest usually don't contain all the possible switch points
> (range information) for each variant. That information is deduced from
> the index that is loaded at startup (which in binary format will take
> less space than XML/JSON anyway). I think that's how DASH works and
> IMO it makes more sense that way.

Yes, the keyframe positions are in the index.

It is certainly possible to provide seamless switching without there being any keyframe alignment, it is just more difficult, involving changes deeper into the media pipeline.

There are even cases where the keyframe position in the "switch-to" stream corresponds to a position in the middle of some frame re-ordering in the "switch-from" stream. This requires you to decode dependencies in the "switch-from" stream which will never be rendered. This is what you need to do if no guarantees are provided on keyframe alignment, for example as in Apple HTTP Live Streaming.

DASH also supports this mode, but allows you to explicitly indicate when there is the sort of keyframe alignment that enables seamless switching without downloading any overlapping data between old and new streams (this is precisely defined and is more flexible than just saying rigid 2s keyframes in every stream, for example). At Netflix, we've worked with many CE devices and none of them support the kind of overlap handling that would be required when this indicator is not set. I expect many DASH implementations will not play streams which do not have this property (or at least, will not switch). The flag in question (fragmentAlignmentFlag) must be true in the "Basic On-Demand" profile defined in DASH.

...Mark

> 
> -- 
> Steve Lhomme
> Matroska association Chairman
> _______________________________________________
> foms mailing list
> foms at lists.annodex.net
> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
>