[foms] Text of ISO/IEC DIS 23001-6 Dynamic Adaptive Streaming over HTTP

[Mark Watson]

On Feb 18, 2011, at 3:12 AM, Silvia Pfeiffer wrote:

> On Fri, Feb 18, 2011 at 9:50 PM, Jeroen Wijering
> <jeroen at longtailvideo.com> wrote:
>> Hey Silvia, all,
>> 
>>>> Also it's not allowed to mixed streams that have VP8
>>>> and H264 in the same MDP (for example) ? I bet that will be the most
>>>> common case so that you have one MDP per onDemand stream with
>>>> something for devices that can handle H264 only and browsers that only
>>>> handle VP8.
>>> 
>>> I don't speak for the browser vendors, so I don't know what MDP
>>> support they are willing to implement. But I can analyse the features
>>> required to support the different possibilities.
>>> 
>>> It is possible to create one large MDP file with all codecs and all
>>> information in it and throw it at the @src attribute of the video
>>> element like so:
>>> <video src="manifest.mdp" controls />
>>> Then the browser have to re-implement the resource selection algorithm
>>> for the manifest files to determine which part of the manifest file is
>>> relevant to them and needs to be interpreted and ignore the rest.
>>> 
>>> I am not actually sure what happens with a video element that has both
>>> a @src attribute and <source> elements - if we assume that only the
>>> @src is interpreted, then at least there will be no conflict between
>>> the two different instances of resource selection.
>>> 
>>> However, in a live scenario where the manifest has to be downloaded
>>> continuously, we have a potentially large overhead of information in
>>> the manifest file that needs to be downloaded, parsed and ignored. In
>>> a situation where we are already tight on time, this could lead to
>>> unacceptable delays.
>>> 
>>> In my opinion, it makes a lot more sense to specify two different MPD
>>> files that serve different browsers: Safari and IE would only ever
>>> need to download the mp4-containing MPD files, while the rest would
>>> download the webm or ogg containing MPD files. I think that could
>>> easily be specified something like this:
>>> 
>>> <video controls>
>>>  <source src="webm_manifest.mpd" type="video/vnd.mpeg.dash.mpd;profile=webm" />
>>>  <source src="mp4_manifest.mpd" type="video/vnd.mpeg.dash.mpd;profile=mp4" />
>>> </video>
>> 
>> There are a few downsides to restricting manifests to one codec:
>> 
>> *) It rules out non-HTML5 players. If all the codecs are in one manifest, that same manifest can be fed to every client (e.g. tools like VLC or JW Player). If manifests are codec-restricted, these devices need to be targeted in some other way.
>> *) Codec restriction is only one type of client restriction, which is being made into a special case here. There's also things like rights restrictions, processing limits, container support (fragmented / nonfragmented?) and multiview/surround capabilities. I don't think that should all get built into HTML5.
>> 
>> It might be better to leave the "source" selection algorithm for legacy video support and use the manifest-based selection as the way to go forward. This will also serve as a nice fallback for non-adaptive browsers:
>> 
>> <video controls>
>>   <source src="manifest.mpd" type="video/vnd.mpeg.dash.mpd" />
>>   <source src="video.webm" type="video/webm" />
>>   <source src="video.mp4" type="video/mp4" />
>> </video>
>> 
>> Re-pulling of manifest shouldn't be an issue. With its URL templating support, DASH files specifically are quite small. Pulling a 5kb file every 10 seconds is OK IMO. I'm more concerned with videoplayers pinging analytics back to the server (for ads, QOS, engagement). Players exist today that do this up to sub-second rates (ouch).
> 
> 
> I think we'll probably need all of the above - eventually. Browsers
> may implement support in steps - the codec-specific manifests are
> probably easier to implement support for than the full-blown
> manifests. I haven't even read the DASH spec yet, so wouldn't know how
> complex it is. ;-)

The spec just defines the format and semantics of the manifest but does not dictate client procedures.

But this has been discussed and is relatively straightforward.

First, when parsing a manifest, the client should just discard/ignore any Representation or Groups that
- indicate an unsupported file format or codec
- are protected only with unsupported content protection schemes
- have a content rating not allowed by current content rating settings
- have only unrecognised content rating schemes and the device does have some content rating restrictions
- are otherwise unsuitable (e.g. high resolution when the device has only a low resolution display etc.)

Now you have a supported subset of the manifest. You may have some selection left to do based on language and accessibility requirements. After that you should present everything that is left. If you can't (e.g. there are still somehow two video tracks left and you can only present one) then the choice is arbitrary, although you might choose the one which has no "viewpoint" annotation over one which has some unrecognised viewpoint annotation etc.

I'm not sure whether this functionality will be in "browsers" or in the underlying "video player" (or whether you make a distinction). As with in-band tracks within a single file, the video player will need to expose an API for the browser to discover and manipulate the in-band tracks.

...Mark

> 
> Cheers,
> Silvia.
> _______________________________________________
> foms mailing list
> foms at lists.annodex.net
> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
>