[foms] Adaptive streaming

[Silvia Pfeiffer]

On Wed, Oct 27, 2010 at 10:04 AM, Mark Watson <watsonm at netflix.com> wrote:
>
> On Oct 26, 2010, at 3:45 PM, Silvia Pfeiffer wrote:
>
>> On Wed, Oct 27, 2010 at 5:24 AM, Mark Watson <watsonm at netflix.com> wrote:
>>>
>>> On Oct 26, 2010, at 1:25 AM, Jeroen Wijering wrote:
>>>
>>> On Oct 25, 2010, at 1:15 AM, Mark Watson wrote:
>>>
>>> MW> The alternative is use of HTTP Range requests, with which we've had no
>>> problems in terms of support in devices, servers and CDNs. Store the movie
>>> as a single file accompanied with a compact index which enables clients to
>>> form range requests for arbitrary sized pieces, down to a single GoP. This
>>> also has the advantage that client requests do not need to always be the
>>> same size (in time).
>>>
>>> JW> Yes, either a range-request based or slicing-webserver-module based solution
>>> is preferred over actual chunks for larger libraries.
>>>
>>> The nice thing about also supporting separate chunks is that the barrier for
>>> getting started with adaptive HTTP is very low. One only needs an encoder o
>>> r a segmenter tool; everything else is basic components. We see this now
>>> with Apple HTTP - it's the format that's getting traction where
>>> Flash/Silverlight are not. Especially on the live side.
>>>
>>> MW> For live, you do need small files. For on-demand it's a pain, and a
>>> compact time/byte index is a really simple thing to create and put into the
>>> file (mp4box already does it for DASH-style indexes). Actually I think the
>>> majority of adaptive streaming on the Internet today (by traffic volume) is
>>> done this way ;-)
>>
>> Is that really true? I have only seen adaptive streaming with chunked
>> files (i.e. MPEG 4 transport stream segments) take off, but I may be
>> missing something. For playback without bitrate adaptation everyone
>> does byte range requests, but as soon as bitrate switching is
>> involved, chunks seem to be much simpler because they do not require
>> any server extensions, but only a clever client.
>
> Sorry, I should been clearer I was talking about Netflix, hence the smiley. We do a LOT of adaptive HTTP streaming, but of course our protocols are not published. There was a recent report saying that ~50% of US HTTP traffic at peak (viewing) times was Netflix, so that's why I said majority. It surprised even us. But the point is that adaptive streaming is still in its infancy to some extent and amongst deployed systems a variety of different approaches each have a good share.
>
> I'm not suggesting a mode where there are server extensions. All you need is a regular HTTP1.1 server and a clever client. The smarts to identify the ranges are all in the client based on the index supplied at the start of the file.


If it can be achieved, that indeed sounds like the smartest approach
for "canned" content.


> In my view, people jumped onto the chunking approach (i) because it was what Move did and (ii) for live, but it does have some big disadvantages for on-demand.


It increasingly sounds like we should prepare two different adaptive
HTTP streaming approaches - one for live and one for "canned"
content...

Cheers,
Silvia.