[foms] WebM Manifest

[Timothy B. Terriberry]

> handled in hardware. But a container with an index, metadata,
> chapters, etc. I doubt it would be done in hardware.

I am not a hardware expert, so take anything I say with a grain of salt, 
but the codec itself is a heck of a lot more complex than the container, 
and they seem to manage those just fine. But they at the very least 
wanted to be able, in hardware, to skip ahead in the stream when they 
encountered a corrupt frame for error-concealment purposes, and they 
weren't talking about MP3. That may not require index and chapter marker 
parsing, but it does imply that you've surrendered more control over 
decode & presentation than you may be used to in a software system.

> Yes. But so does the TCP error repeat packets. Obviously TCP with a
> large window and a very small bandwidth is never going to work
> properly.

I think you've just described all residential internet in the US. Ask 
Netflix how well it works.

> This is the same whether you stop loading a stream at the end of a
> fragment or at the end of a frame (when a fragment is not a file but
> just a range request in a bigger file).

No, my point is that this is emphatically _not_ the same. If you make a 
range request for a single fragment, then the sender knows, in advance, 
to stop sending you more data when it reaches the end of the fragment. 
If you don't know where the frame boundaries are, in advance (and in 
your proposal the fragment you're switching from doesn't end at a 
keyframe, so an index won't help you), then the sender will keep sending 
until you tell it to stop.

> The corresponding audio needs to be in front of the n-1 video frame.
> This is not exactly a requirement of WebM (only needs to be in front
> of a keyframe), let alone Matroska. mkclean does this automatically,

I tried very hard not to take this opportunity to say, "Should have used 
Ogg," but I think I just failed.