[foms] Proposal: adaptive streaming using open codecs

[Steve Lhomme]

On Tue, Nov 16, 2010 at 7:29 PM, Pierre-Yves KEREMBELLEC
<pierre-yves.kerembellec at dailymotion.com> wrote:
> That said, I think the best compromise would be for browsers to accept both interleaved and elementary streams: when there's only one
> video track and one audio track (which probably covers 99% of the video content out there), it makes sense not to add complexity for
> publishers and ask them to demux their videos (some probably don't know exactly what video internals are about anyway).

Having to support 2 ways of doing the same thing (and from the same
standard) is not a good thing. And even though you have 1 audio track
and 1 video track, we're talking about adaptative streaming. That
means multiple versions of these same tracks cut in many small
chuncks. So the fact that the chuncks are for 1 track or many doesn't
make too much difference in the end.

Also we're talking about something to support the web in general, in
an open way. That means people should be able to create their stream,
put them on *any* website and it will work. So those chuncks, in
general, have to be in different files. (unlike the specialized server
you talked about earlier which is a local (and good) optimisation).

> - the chosen container is easily "streamable", and require minimum headers overhead to pass codec initialization info

I agree, even though that may make Vorbis a little less competitive (8
KB codec initialization).

> - RAP may not be aligned between versions (or at least it shouldn't be a strong requirement even if in practice it's often
>   the case), thus end-user experience with no-glitch stream-switching would depend on renderer and double-decoding/buffering
>   pipeline capabilities

A crossfader will be necessary for audio to avoid any glitch when
switching streams. That's (a little) more buffering needed.

By the way, we should also keep in mind that at some point this
audio/video transmission may end up going both ways (a la
Chatroulette), so we should keep the client/server as little complex
as possible.

Steve