[foms] Proposal: adaptive streaming using open codecs

[Frank Galligan]

On Wed, Nov 17, 2010 at 3:19 AM, Philip Jägenstedt <philipj at opera.com>wrote:

> On Tue, 16 Nov 2010 05:54:02 +0100, Frank Galligan <fgalligan at google.com>
> wrote:
>
>  On Mon, Nov 15, 2010 at 6:19 PM, Silvia Pfeiffer
>> <silviapfeiffer1 at gmail.com>wrote:
>>
>>  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.
>>
>
> Is this actually the case? Wouldn't you actually match low audio quality
> with low video quality, and end up with at most 6 combinations, where the
> each audio track is duplicated twice? In actual deployed solutions, how many
> different bitrates is anyone actually bothering to provide? My guess is 3
> (low, mid, high) but I truly have no clue.

I think there were companies that were doing more than 3 streams.  Probably
most are doing 3 but is that because of the client limitations?  As time
goes on I think we will add more tracks. I would rather have support for
something that should not be much harder from a playback perspective than
limit what content creators could do.


>
>  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.
>>
>
> I don't think captions is a real problem. Duplicating them doesn't really
> impact the bandwidth and it's easy to deliver separately from the
> audio/video tracks anyway (using <track>).
>
I'm not sure the bandwidth, but as you said I'm sure it is really low. I
think it would still be good to support captions within the manifest (either
as separate streams or in-band) so this could work on other players. Another
reason to have separate streams for captions (either using <track> or in the
manifest) is you can easily add them without remuxing all of your content
when you add another language.


> --
> Philip Jägenstedt
> Core Developer
> Opera Software
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.annodex.net/cgi-bin/mailman/private/foms/attachments/20101122/9fe9f4d1/attachment-0001.htm