[theora] Http adaptive streaming for html5

[Silvia Pfeiffer]

On Tue, Dec 29, 2009 at 3:46 AM, Christopher Blizzard
<blizzard at mozilla.com> wrote:
> On 12/23/2009 2:51 AM, Silvia Pfeiffer wrote:
>>
>> I think the sequential switching stuff should as much as possible be
>> hidden away from the client and be a server-side thing, exposed to the
>> Web as a single resource. Other than telling the server what bandwidth
>> it is currently receiving, the client should not need to do anything,
>> IMHO. Not sure how that can be done other than something like what
>> Apple proposed.
>>
>>
>
> Just FYI this is what everyone is doing today and based on the (bad)
> experience that people are having with it flash, silverlight and others are
> all moving to doing this client side.  It's easier to make the client a
> little more complicated in order to make it easier to deploy and complex
> servers.

Yes and no. They are all moving to mixed solutions.

Adobe Flash's dynamic stream switching [1] uses its RTMP protocol to
do the switching server-side upon data reported from the flash client
or upon explicit switches made through script/API calls on the client.
This means they are doing both.

JWplayer has implemented the switching client-side [2] and the
switch-over is only smooth when using the RTMP server. There's always
a delay over HTTP, where JWplayer is switching between different
files.

Silverlight's smooth streaming [3] uses byte range requests over HTTP
to do the smooth streaming. The IIS server is heavily involved in
putting the right data together: "Once IIS receives a request for
media, it will dynamically create cacheable virtual fragments from
several video files and deliver the best content possible to each end
user." So, again, client and server are both involved in delivering
the data.

Apple's HTTP adaptive streaming [4] breaks down a video file on the
server and creates an index file containing a list of the media files.
The URL of the index file is published on the web server. Client
software reads the index, then requests the listed media files in
order and displays them without any pauses or gaps between segments.
So, there, again, there is work done on the server and on the client.

Since one has to react to Bandwidth use and CPU load on a client, it
probably makes sense to have the choice of switching to a lower
bandwidth source file done by the client. It seems though that a
smooth switch-over can only be achieved if the server is somewhat
involved, or at minimum has files available that allow smooth
switch-over at certain index points.

I'm not sure which approach is preferable to HTML5 and to Ogg. Maybe
the media fragment addressing will make it easier to switch to a
different file without losing sync and still do it all client-side.