[foms] Adaptive streaming

Silvia Pfeiffer silviapfeiffer1 at gmail.com
Tue Oct 26 15:45:28 PDT 2010

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.

> JW: Also (this might be another discussion), are there thoughts on standardizing
> the subtitling format?
> MW> Not in the MPEG DASH work, but it would be a good idea. I put TTML/DFXP in
> the example because that is what we use at Netflix. I'm not sure what the
> venue would be for standardizing that.

Let's not replicate that work. There is already work in the W3C and
WHATWG about standardising a subtitling format and right now the
discussions are about WebSRT (
http://www.whatwg.org/specs/web-apps/current-work/websrt.html ) which
may as yet see changes before it has the chance to become the baseline
format for HTML5. Then I believe it would also be able to fulfill this
role in this context.


More information about the foms mailing list