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

[Mark Watson]

On Feb 17, 2011, at 9:52 AM, Steve Lhomme 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. 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.

To handle that case I would expect there to be a profile for "Basic OnDemand with H.264" and another profile for "Basic OnDemand with VP8" (obviously including audio codecs etc., but this is the general idea) and an MPD MIME type "profiles" parameter could include both.

This should mean that if you support *either* of the profiles then you can play the MPD.

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

An interesting question is at what point the download of the manifest should be initiated ? Presumably it would be good for this to happen asap - perhaps earlier than download of a straightforward media file would occur ? I am not sufficiently familiar with the MediaElement to be precise.

...Mark 

> 
> Steve
> 
> -- 
> Steve Lhomme
> Matroska association Chairman
> _______________________________________________
> foms mailing list
> foms at lists.annodex.net
> http://lists.annodex.net/cgi-bin/mailman/listinfo/foms
>