I'm punting on audio and video sniffing for now. If and when audio and video sniffing becomes crushingly prevalent, we can revisit this issue. Adam On Mon, Jun 22, 2009 at 2:55 PM, Joe D Williams <joedwil@earthlink.net> wrote: > Hi Adam, > >> Hi Joe, > >> I had a lot of difficulty understanding your message. Are you suggesting >> we sniff the media type from the file extension for audio/video content? > > I have done some wandering on this topic and in this thread, but to me an > important point is that I am still thinking in terms of audio and video as > an embedded (nested) or auxiliary context. That is, the audio or video might > be embedded content using the HTML 5 <audio> or <video> element, and that > the UA will open an auxiliary context if a standard hyperlink with an audio > or video file extension as @href is selected. Either way, I get access to > the host DOM through interfaces granted by the host context. > > What does the host, or source, context need to know about the served content > type and encoding and maybe contents of the file in order to send it to the > <audio> or <video> requester, or to the auxiliary context? > > If we knew that, then the mime-sniffing table used to find Sniffed Type by > the Unknown algorithm might get longer, or maybe more entries in Image, or > better yet, an added main title for Audio and Video objects. I think this is > where a real contribution will be made by HTML 5, is when there is a > standard or highly recommended (evolving) set of mimes that will play > 'standard' audio and video (@src, @type, @codecs) in W3C HTML 5 UAs. This > list needs to be readily available to web authors. > > For example, for audio media, I have commented that the spec should not > recommend 'any audio codecs' but instead state a selected subset of > available content types/file extensions as 'native' to the <audio> element. > I think it would be best to just say current typical .wav and Ogg Vorbis > (.oog) - if those are as open and free and available as we believe and hope. > I wish I knew more about this and thus aid my point of view here with > conclusive argument that allowing 'any' container/codec in the <audio> node > is not an improvement in what was already there in <object>. Well, fine that > the media style interfaces are being specified in <audio> and <video>; that > is a great step forward for simplified implementation-independent authoring, > for sure. However, if there are no 'native' audio media types in HTML 5 then > it is just like it was where the author gets to depend upon the client > determination of which proprietary media player system (legacy audio plugin) > gets used. Basically, that just means a level of inconvenience for everyone. > > Also, looking at: [ myemphasis ] DIFF1 > > Metatdata > ... only the [first last] Content-Type HTTP header, ... > http://www.ietf.org/internet-drafts/draft-abarth-mime-sniff-01.txt > May 31, 2009 > and > http://tools.ietf.org/html/draft-abarth-mime-sniff-00 > January 9, 2009 > > Adam, please update the link on your site with the latest draft? > I know now which one to read = 01 but it distracted me for a while:) > > The choice of which of multiple content type headers to use seems important > and interesting. > Is there some background on the final choice of last/first? > > Thank You and Best Regards, > Joe > > ps. can that entry down at the bottom of that unknown type table:| FF FF FF > | 49 44 33 | audio/mpeg | Safe | > | Comment: The string "ID3", the MP3 signature.have anything to do with this > conversation? >Received on Tuesday, 26 January 2010 20:26:48 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:21 UTC