W3C home > Mailing lists > Public > public-media-fragment@w3.org > June 2011

Re: [foms] WebM Manifest

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 15 Jun 2011 10:11:44 +1000
Message-ID: <BANLkTin6YvEB06QMVW6+ZFMrPg_mzH5STA@mail.gmail.com>
To: RaphaŽl Troncy <raphael.troncy@eurecom.fr>
Cc: Media Fragment <public-media-fragment@w3.org>
Hi Raphael,

I'm not fussed about replying about "server" implementations. Feel
free to write something - I maintain belief that cient-side is the
most important.

However, revisiting that email and following the link, I noticed that
they re-visiting the HTTP spec. In particular, they are preparing a
whole section on byte range requests, see
http://tools.ietf.org/html/draft-ietf-httpbis-p5-range-14 .

This would be a very good time to get in contact with that group and
make sure that our spec is in sync with theirs, in particular allow
time range requests etc.

There's some active liaison work necessary. Who will do it?


2011/6/15 RaphaŽl Troncy <raphael.troncy@eurecom.fr>:
> Dear all,
> I spot this message on the FOMS mailing list which is pretty active to
> define an adaptive streaming mechanism that may use byte ranges. Silvia and
> most likely Davy are reading/writing to this mailing list.
> Should we answer to this message on behalf of the Working Group in order to
> trigger more *server* implementation of media fragments?
> Best regards.
> †RaphaŽl
> -------- Message original --------
> Sujet: Re: [foms] WebM Manifest
> Date : Wed, 1 Jun 2011 19:20:45 +1000
> De : Mark Nottingham <mnot@mnot.net>
> Rťpondre ŗ : Foundations of Open Media Software <foms@lists.annodex.net>
> Pour : Foundations of Open Media Software <foms@lists.annodex.net>
> De-lurking briefly...
> If folks have use cases / test scenarios where they'd like to see byterange
> support improved, please send them my way. †We're seeing pretty good
> engagement from HTTP implementers in the HTTPbis WG [1] (including cache
> vendors like Traffic Server, Squid and Varnish), and can improve things by
> clarifying the HTTP specification and/or minting test suites.
> In particular, if you can give me known bugs and/or a ranked wishlist, I can
> pursue that with implementors.
> Cheers,
> 1. http://trac.tools.ietf.org/wg/httpbis/trac/wiki
> Mark Nottingham † http://www.mnot.net/
> On 10/05/2011, at 2:34 AM, Mark Watson wrote:
>> Pierre-Yves,
>> Interesting discussion. To be clear, I agree that a chunked mode is
>> necessary for live, and clearly clients should not see much difference
>> between live and on-demand, except that they should not requests chunks
>> "from the future" in the live case.
>> My point is that this is not sufficient for efficient large scale
>> on-demand services. See comments below...
>> On May 7, 2011, at 1:40 AM, Pierre-Yves KEREMBELLEC wrote:
>>>>> Exactly. I don't know about any HTTP cache that deals properly with
>>>>> byte-ranges and
>>>>> partial caching (using for instance hollow files + bitmaps, like Thomas
>>>>> described).
>>>>> (this problem is now new, see http://bit.ly/ixdQwo for instance). As
>>>>> pointed by Thomas,
>>>>> Varnish may be able to achieve partial caching through the
>>>>> http_range_support directive,
>>>>> (since 2.1.3), but it has to be proven stable.
>>>>> Unfortunately, this type of caches is more the exception than the norm
>>>>> today.
>>>> At Netflix we make extensive use of byte ranges (allegedly 20% of US
>>>> Internet traffic at peak times). This is well supported by the major CDNs
>>>> who all support byte ranges and partial caching of large files.
>>> Well, maybe major CDNs supports byte-range caching properly (and even
>>> that seems to be handled specifically
>>> by some CDN, see http://www.akamai.com/dl/feature_sheets/fs_lfdo.pdf for
>>> instance). Anyway, this is definitely
>>> not the case for most ISPs (transparent proxies) or enterprises today (we
>>> are reminded of that fact everyday
>>> unfortunately). Again, efficient byte-ranges caching is more the
>>> exception than the norm globally (Microsoft
>>> even recently filed a patent for that:
>>> http://www.faqs.org/patents/app/20100318632 ^_^).
>>>> Lack of byte range support is not the reason chunking is used for live
>>>> (more on that below). I absolutely agree
>>>> that solutions need to work with "dumb" HTTP infrastructure and for me
>>>> this excludes special media-format-specific
>>>> capabilities on the origin servers more than it excludes byte ranges
>>>> which are part of HTTP1.1.
>>> I agree to disagree here: the first origin server may implement some
>>> dynamic chunk/fragmentation intelligence because
>>> it's under the content provider control, and generally backed-up by a
>>> first level of CDN proxies. It doesn't break the
>>> "dumb public internet network" rule (from any perspective but the
>>> origin's, the chunks are just simple separate documents
>>> with unique URL).
>> CDNs often provide the origin servers. For us it is nice to be able to
>> purchase all the real-time streaming services from a 3rd party, rather than
>> having our own HTTP servers involved on a real-time basis.
>> There is an architectural issue here. Today, only a small fraction of
>> media consumption takes place over the Internet. That will become a big
>> fraction in time. To me this means that asynchronous one-to-many content
>> delivery needs to become a first-class service of the "dumb public internet"
>> - and this is happening through the increasing embedding of HTTP proxies in
>> the form of CDNs and also deep into ISP networks.
>> Secondly, it's valuable to decouple the unit of storage from the unit of
>> request - we seem to agree on this.
>> Thirdly, byte ranges naturally provide caches with a hint about what
>> requests might come next (the next bytes in the same file), which allows
>> pre-filling of caches to improve cache hit ratios.
>> It seems clear to me that these things should be done in an
>> application-independent way and indeed the HTTP specification already
>> supports this using byte ranges. Using chunking immediately introduces
>> application-specific requirements at the origin, but these requirements
>> quickly leak down to the caches because of the third point above.
>> ISPs and enterprises will have an increasing financial incentive to cache
>> content. And indeed we are talking to some of them about this. I think it
>> far more likely they will address this with support for the (now quite
>> mature) HTTP1.1 specification then by embarking on an uncharted path where
>> request/storage decoupling is done in an application-specific way.
>> If we are talking about standardizing adaptive streaming solutions we
>> should focus on something which really scales in this sense.
>>>> For us, chunking is completely infeasible due to the excessive number of
>>>> files required (note that this is not so much
>>>> to do with having separate audio/video files - that causes just a 10x
>>>> multiplier, but splitting by time, which is a ~3600x
>>>> multiplier). Storing on the origin as a large file and chunking based on
>>>> requests is more of a restriction (in terms of CDN
>>>> capabilities required) than byte ranges. Byte range support is a generic
>>>> capability which can find applications for many
>>>> services.
>>> I totally understand your point, but dynamically chunking also works in
>>> this case: you may have a single MP4 (or MKV for
>>> that matter) with 4 video angles, 10 audio tracks and 10 subtitle tracks,
>>> and still be able to dynamically remux and deliver
>>> independent short segments for each individual track if needed (no
>>> byte-ranges involved). In a ideal world, neither MP4 nor
>>> MKV would be used for the wire container format anyway, because even with
>>> static or dynamic chunking, these containers are
>>> quite complicated to handle and do not represent a pure "stream"
>>> (contrary to MPEG2-TS or in a certain degree FLV, which are
>>> pure streams).
>> Maybe we have to agree to disagree here too: I find mp4 vastly easier to
>> understand and parse than MPEG2-TS. A Transport Stream is not a "pure
>> stream" - it's a multiplexing layer and extracting the Elementary Streams is
>> not straightforward. There are also timing and conformance rules associated
>> with Transport Streams which I don't think anyone would describe as simple.
>>>> Furthermore, chunking like this restricts all clients to make the same
>>>> requests: if one client requests a 10s chunk and another
>>>> a 5s chunk then you cache 15s of data even if the 5s piece is contained
>>>> within the 10s piece. This restriction reduces either
>>>> cache efficiency or client performance.
>>> Absolutely, this is the whole point: encouraging all clients to make the
>>> exact same requests, to increase cache-ability for
>>> all types of caches, even those not playing nice with byte-ranges
>>> (enterprises, ISPs, browsers, ...).
>> But this comes with a cost! Good adaptivity argues for small requests. But
>> if all clients make small requests all the time you have a high server and
>> uplink load. So this argues for making larger requests when fast adaptivity
>> is not required (e.g. when a client has plenty of buffered data). Forcing
>> all clients to make the same requests means you cannot engineer this
>> trade-off.
>>>> We've discussed this at length will many of the major players
>>>> (especially Microsoft but also Apple) in MPEG. The "Basic on-demand"
>>>> profile in MPEG DASH is based on the single-file-with-byte-ranges
>>>> approach. The reason chunking was chosen by Apple, Microsoft etc.
>>>> for live is that HTTP caching procedures do not play well with files
>>>> that change size over time. A change in size is a change which
>>>> can cause the whole file to be ejected from cache. There is nothing in
>>>> HTTP to indicate that the file just grew and so all the earlier
>>>> data in the file is still the same. There are certainly things you could
>>>> do with a growing file, but you need to be careful that all
>>>> your caches support it - and there's no spec for what "it" is.
>>> It seems all the major vendors (Microsoft, Apple, Adobe) are using fixed
>>> resources URL for chunks (whether those chunks are
>>> pre-prepared or extracted dynamically), for live and on-demand. For
>>> instance, Microsoft chunks URL format is something like
>>> (no byte-ranges involved):
>>> http://video.foo.com/NBA.ism/QualityLevels(400000)/Fragments(video=610275114)
>>> http://video.foo.com/NBA.ism/QualityLevels(64000)/Fragments(audio=610275114)
>>> The reason for that are described in this document :
>>> http://download.microsoft.com/download/4/2/4/4247C3AA-7105-4764-A8F9-321CB6C765EB/IIS_Smooth_Streaming_Technical_Overview.pdf
>> I always thought it convenient that you needed IIS servers to support the
>> Micro$oft solution ;-) Anyway, MS are deeply involved in the DASH
>> discussions and seem quite keen to support and migrate to that standard
>> (though I don't speak for them of course).
>>> Same for Adobe, and Apple is physically pre-splitting MPEG2-TS files (but
>>> this is a limitation of their tools, Wowza servers
>>> are doing this on the fly for instance).
>> Yes, well, Move Networks were doing that many years ago too - it's the
>> first thing that works - but that doesn't mean it's the best scalable
>> solution.
>>>> Also a factor is the fact that the big disadvantages of chunking don't
>>>> really apply to live where by definition there is a real-time
>>>> media-aware process generating the files and feeding them into the HTTP
>>>> infrastructure.
>>> As Sylvia pointed out, I think both systems should be allowed to co-exist
>>> from a manifest/ABR technic pov.
>> This I agree with.
>>> Regards,
>>> Pierre-Yves
>>> _______________________________________________
>>> foms mailing list
>>> foms@lists.annodex.net
>>> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
>> _______________________________________________
>> foms mailing list
>> foms@lists.annodex.net
>> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
> _______________________________________________
> foms mailing list
> foms@lists.annodex.net
> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
Received on Wednesday, 15 June 2011 00:12:42 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:46 UTC