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

[Jeroen Wijering]

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). 

Kind regards,

Jeroen