[foms] WebM Manifest

[Steve Lhomme]

On Sat, Mar 19, 2011 at 11:03 AM, Timothy B. Terriberry
<tterribe at xiph.org> wrote:
>> Yes, there is a problem when B frames are used (again, not a problem
>> in WebM). But B frames are a problem for adaptive streaming anyway. It
>> imposes downloading data far ahead (like n+60) before you can play a
>> certain frame (n). That poses a big threat of starving the decoder
>
> This is not how B-frames work.

Oops, my bad. You are totally right (coding order vs display order).

So that makes Mark's point #2 irrelevant.

Now I'd be curious if point #1 is a real problem or not.

In my proposition (not have keyframes (=fragment start) forced to be
synchronized between variants) you need to known when you have
downloaded frame n-1 so you can stop loading this variant and start
loading the new variant/fragment (starting at frame n). Whereas in the
synchronized case you need to know when the fragment is fully
downloaded so you can stop loading this variant and start loading the
new variant/fragment.

In terms of computing or buffering there's nothing. The data up to n-1
will have to be loaded, demuxed and decoded. The demuxing is always
done in software (ie not hardware) so it is flexible enough to allow
both ways. The metrics to decide when to switch are not just based on
network speed but also decoding speed/CPU load (a phone may choke on
720p and decide to get a lower resolution). So it goes even higher
than the demuxing stage. So what could be the constraint here ?

PS: I keep using the word "variant", is there something more appropriate ?

-- 
Steve Lhomme
Matroska association Chairman