- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Thu, 17 Feb 2011 17:24:57 +1100
- To: David Singer <singer@apple.com>
- Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
On Thu, Feb 17, 2011 at 2:26 PM, David Singer <singer@apple.com> wrote: > > On Feb 17, 2011, at 10:17 , Silvia Pfeiffer wrote: > >> >> >> I'm concretely thinking about the following scenario: >> >> <video controls> >> <source src="webm_manifest.mpd" type="?? - maybe video/mpd+webm" /> >> <source src="mp4_manifest.mpd" type="?? - maybe video/mpd+mp4" /> >> </video> >> >> mpd is what MPEG specified. The manifest file has a mime type of >> video/vnd.mpeg.dash.mpd , which is not really useful for us in the >> realm of the <source> elements. So, for a profile, maybe we can define >> a more specific mime type, which makes more sense to our >> circumstances. Also, the use of @media would influence what can be in >> the manifest file, e.g. only videos below a certain screen size. >> >> Hope this clarifies the concern I raised. > > > Got it. Happily, we are also realizing that this is a potential problem. > > Obviously, one should explore whether this couldn't be one manifest that has both sets of media, and then the client can do its choosing based on supported media types. > > But, we also have the concept of 'profiles' in the MPD. They work like brands in the MP4 file format; they indicate a claim and a permission. The claim is that if the profile indicator is in the MPD, the MPD conforms to the requirements of that profile. The permission is that if a client implements a given profile, then if it interprets the MPD and processes what it recognizes and ignores the rest, that that is a satisfactory outcome from the point of view of the content author. And the good news is that the MPD can contain a list of these profiles. And the further good news is that they are URIs, so central registration and control are not needed. Hence the desire to have profiles not forbid more than they need to; so one would say "under this profile, the program content must be presentable using only 3GPP codecs" not "all content must use the 3GPP codecs", for example. > > Then, the draft MIME registration allows indicating the profiles as a mime parameter. > > So, if dual MPDs were, in fact, needed, one could write (with the escaping and so on correct): > > <video controls> > <source src="webm_manifest.mpd" type="application/dash+xml;profiles=\"http://web.org/profiles/simple\"" /> > <source src="mp4_manifest.mpd" type="application/dash+xml;profiles=\"urn:mpeg:dash:profiles:comple\x"" /> > </video> That could work, I'm glad DASH also considers profiles. I am concerned here with not making the source selection algorithm any more complex that it already is and I am equally concerned with the size of the manifests that a browser has to parse - and potentially download repeatedly. When the manifest only has data relevant to one codec, then it is most useful to a browser that supports that codec and it doesn't have to parse surplus stuff in the manifest. So, I am happy that this seems to be possible. Cheers, Silvia.
Received on Thursday, 17 February 2011 06:26:05 UTC