[foms] Proposal: adaptive streaming using open codecs
fgalligan at google.com
Mon Nov 22 20:12:25 PST 2010
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>
> 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
>>> Right that is what I want to do. But before we just went off and made an
>> 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
>> Let's assume that interleaved chunks are easier to implement then
>> non-interleaved streams for the client (again I'm not convinced this is
>> 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
>> the issue of manging all the chunks). If we have 6 video streams and 3
>> 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.
>> can alleviate the growing number of file combinations for interleaved
>> 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
>> 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...
More information about the foms