[foms] Proposal: adaptive streaming using open codecs

[Frank Galligan]

On Mon, Nov 15, 2010 at 6:19 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com>wrote:

> On Tue, Nov 16, 2010 at 10:13 AM, Chris Pearce <chris at pearce.org.nz>
> wrote:
> > On 16/11/2010 6:48 a.m., Steve Lhomme wrote:
> >> Doesn't it lead to more sync issues when the files you received are
> >> not interleaved ?
> >
> > Yes, it's harder to manage non-interleaved streams over multiple
> > connections.
> >
> >> One big pro for non interleaved is that switching between languages
> >> (or regular/commentary track) is a lot easier and the only reasonable
> >> way to handle it server side.
> >
> > The earlier consensus from most of the content providers was the non
> > interleaved was easier to manage, particularly at large scale when you
> > have a number of different bitrate streams, and a number of different
> > audio tracks.
>
> We have to be careful where we take that statement. Just because the
> large content owners don't want to do physical chunks and want to keep
> audio and video tracks separate doesn't mean we have to do that over
> the network or use chunks in the manifest file. There is always the
> possibility to have something different on disk than what is being
> sent over the network.

There is that possibility but I don't think anyone really wants this. Big or
small.


> For large content providers use of such server
> extensions makes a lot of sense.

I don't necessarily think this statement is true. From reading the emails
before I think large content providers were forced into extended servers to
fit within the rules of the clients they were trying to stream too.


> We also have to look at what makes
> more sense in the players and what makes sense for small content
> providers.
>
Right that is what I want to do. But before we just went off and made an api
that was forcing how files should be physically laid out I wanted to make
sure that is the best option. We have a chance to design
adaptive streaming so it will work best for content providers as well as
clients.

Let's assume that interleaved chunks are easier to implement then
non-interleaved streams for the client (again I'm not convinced this is so).
Now lets look at it from the small content providers point of view. If we
have one video and one audio the content provider should be happy (negating
the issue of manging all the chunks). If we have 6 video streams and 3 audio
streams for one presentation that would be 18 combinations of interleaved
chunks the content provider is going to have to host vs 9 for
non-interleaved streams. That number is going to grow very quickly for
interleaved chunks once you start adding more streams like text streams. You
can alleviate the growing number of file combinations for interleaved chunks
by adding special software on the server side but I don't think this is
feasible for small content providers. This is why I think for small content
providers the best physical layout of files for http adaptive
streaming would be non-interleaved streams.

Frank


> Cheers,
> Silvia.
> _______________________________________________
> foms mailing list
> foms at lists.annodex.net
> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.annodex.net/cgi-bin/mailman/private/foms/attachments/20101115/b5baae1e/attachment.htm