[foms] WebM Manifest

[Steve Lhomme]

I understand everyone would like a single solution that works in all
cases. But what would you prefer ? 2 systems that are optimum for a
single case or 1 system that works OK but no great in all cases.

t's not like servers or players don't already have the "choice"
(rather necessity) to support more than 1 adaptive streaming format.
So I don't think it's a big deal if there is one for VOD and one for
live. After all these uses cases would never recoup anyway. A system
optimize for live could for VOD for sure. But a VOD system doesn't
need to be hacked and made complex for the sake of somehow working for
live streaming. And once you get rid of the live part for a VOD system
you can do more elaborate things or assume other (like forcing the
variants to be in single files).

Steve

On Wed, May 4, 2011 at 3:40 PM, Thomas Vander Stichele
<thomas at apestaart.org> wrote:
> Hi everyone,
>
> (I realize I am late to this email party, apologies!)
>
>
>
>> We have been talking about how to implement client-side HTTP adaptive
>> streaming for WebM for a few months. We have focused on VOD first
>> (with live to come later).
>
> Am I really the only one who considers the 'with live to come later' a
> mistake ?
>
> A good design should evaluate all existing use cases.  A lot of existing
> streaming designs have made the mistake of 'doing live later' and then
> never handling correctly some of the finer, important points.
>
> A good design should adapt itself to handle those existing use cases.
> What good does it do us if all the hard work we do for the VoD case does
> not work for the live case ? As a reminder, even Google's own Chrome
> browser was unable to play live WebM until more than a month after we
> (Flumotion) implemented the first live WebM streaming.
>
> A good design should be able to adapt itself to the changes in the
> market out there, or have compelling counter-offers.  The biggest reason
> why the three big streaming software implementors (Microsoft, Apple,
> Adobe) switched to chunked streaming for live is because CDN's have told
> them to do so - it is much easier for them to deploy reverse proxy
> infrastructure (which they already have) than it is to deploy streaming
> servers.  For example, Akamai typically only has about 10% of their
> edges with streaming capabilities.
>
> I realize all of you think live is 'not that important', and VoD is by
> nature easier to do, but I don't think it would be that hard to at least
> take it into account the use case.
>
> A single 'file' per track is surely possible for live - in fact, we've
> always done that in Flumotion, and so does Icecast - but it guarantees
> that the end result is simply *not* cacheable by the internet at large,
> as it is an ever changing ill-defined 'resource'.
>
> The reality today is that there isn't a single CDN out there (except
> maybe ours, but we're not even in the US) that is able to stream live
> non-adaptive WebM.  Not even Google seems to plan to do it.
>
> Not even considering live at this point just means that this whole cycle
> of getting it specced/implemented in browsers/adopted/available to
> actual customers will have to be repeated all over again.
>
> Just my 2 cents,
>
> Thomas
>
> --
>
> --
> Words are the part of silence that can be spoken.
> --
> Flumotion - the only way to stream!
> http://www.flumotion.net/
>
>
> _______________________________________________
> foms mailing list
> foms at lists.annodex.net
> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
>



-- 
Steve Lhomme
Matroska association Chairman