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

[Silvia Pfeiffer]

Hi Steve,

On Fri, Feb 18, 2011 at 4:52 AM, Steve Lhomme <slhomme at matroska.org> wrote:
> On Thu, Feb 17, 2011 at 3:19 AM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> On Thu, Feb 17, 2011 at 11:56 AM, Mark Watson <watsonm at netflix.com> wrote:
>>>
>>>> On Feb 16, 2011, at 4:14 PM, Silvia Pfeiffer wrote:
>>>>
>>>> I agree - I think we need profiles of DASH - in particular a
>>>> restriction to just one mime type being used in a file that should go
>>>> into a @src attribute of <video>, <audio> or <source>. Also, we'd need
>>>> to make sure it works with the @media query attribute of <source>
>>>> elements, thus targets particular device features.
>>>
>>> I think the requirement should be that it must be possible to determine
>>> whether a manifest can be played without loading the manifest.
>>
>>
>> That's indeed concretely what the @type and @media attributes are used for.
>>
>>
>>>> What I most wonder about is, if such a DASH file was to be used in
>>>> place of a media resource in the @src attribute of a <video>, <audio>,
>>>> or <source> element, what will its mime type be? It would make life
>>>> easy if the mime type could just be the mime type of the resource that
>>>> it stands for, e.g. when all referenced files are webm, the mime type
>>>> of the manifest file should be video/webm. Unfortunately, it is
>>>> proposed to be video/vnd.mpeg.dash.mpd which doesn't help the browser
>>>> in deciding whether it will support the resource type therein. Maybe
>>>> we could create a profile and then have something like video/dash+webm
>>>> and video/dash+mp4 as mime types which is much more informative.
>>>
>>> They defined a "profiles" parameter to this MIME type which can be used to
>>> say which profile or profiles the manifest is compliant to.
>>> So, if someone defines a profile which goes as far as specifying
>>> mp4+H.264+aac (say) and someone else goes defines a profile which specifies
>>> WebM+VP8+Vorbis, then it is possible to specify which one a manifest is
>>> compliant to. Or indeed that it is compliant to both, meaning that it can be
>>> played so long as you support one profile or the other.
>>
>> That sounds great. Maybe that's the best way to go.
>>
>> Silvia.
>
> It still seems restrictive not knowing if the stream is onDemand or
> live or simply.

To HTML5, there is no distinction between on-demand and live - the
resource is being loaded from the start and if it continues to receive
data until it reaches the end. If it continues to grow, it will
continue to be downloaded. The only difference really is that the UA
doesn't find out about the duration when it loads the metadata
(header) of the resource, so it continuously updates that during
playback.

The HTML5 media elements are already being used for live streaming and
there is no indication on the element about whether it is on demand or
live.


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


> But in the end, what's the advantage to know the MIME before reading
> the actual MDP ? The download is initiated anyway. And the MIME can
> only show so much about the details in the MDP.

The only thing that the MIME needs to show is what codecs are
supported in it. That's what the MIME is being used for with existing
<source> elements and that would be lost if we chose a generic MIME
type for the MPD files.

That would remove the need to parse MPD files for acceptable codecs
and can make the adaptive streaming implementation a lot more
efficient.

Cheers,
Silvia.


> Steve
>
> --
> Steve Lhomme
> Matroska association Chairman
>