[foms] WebM Manifest

[Steve Lhomme]

On Sat, Mar 19, 2011 at 11:34 AM, Timothy B. Terriberry
<tterribe at xiph.org> wrote:
>> 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
>
> This is not always true. In fact, the hardware people I spoke to at the
> WebM summit seemed genuinely confused why we (browsers) would even want
> to do this in software.

I know Matroska in a lot of hardware and I've never heard of a version
that does it in hardware. Could you be more specific ? For example the
framing in MP3 could be considered a "container" and that's usually
handled in hardware. But a container with an index, metadata,
chapters, etc. I doubt it would be done in hardware.

> Keep in mind also that TCP does not stop on a dime. If you haven't told
> the remote end where you want to stop receiving data in advance
> (because, for example, you had to download and parse the stream to even
> know where the frame boundaries were), it will blithely continue to
> stuff your channel with data, even if you're no longer interested in it,
> until it receives your CLOSE. That wastes your bandwidth whether you
> like it or not.

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.

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).

There's one other issue with the switch in the middle of a fragment.
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,
but it's likely many muxers don't do that.

-- 
Steve Lhomme
Matroska association Chairman