<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 22, 2008, at 2:36 PM, Robert O'Callahan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">On Sat, Aug 23, 2008 at 1:46 AM, Eric Carlson <span dir="ltr"><<a href="mailto:eric.carlson@apple.com">eric.carlson@apple.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> <div style="word-wrap: break-word;"><br><div><div class="Ih2E3d"><div>On Aug 21, 2008, at 8:56 PM, Robert O'Callahan wrote:</div><br></div><div class="Ih2E3d"><blockquote type="cite"><div dir="ltr">Does that actually enumerate all supported codecs? Looking at the Webkit code and the Quicktime docs, it looks like it's just enumerating file/container types.<br> <br></div></blockquote></div><div> Indeed the code enumerates movie importers and just builds a list of the MIME types supported by QuickTime, so it can not yet deal with a type string with an RFC4281 "codecs" parameter. We are working on that requirement, but the current approach is still useful because the "codecs" parameter is not yet widely used.</div> <div></div></div></div></blockquote><div><br>That will require extensions to Quicktime, right?<br><br></div></div></div></blockquote><div> Correct.</div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_quote"><div>So using your current approach implement Tim's proposed API, we can use this to answer "yes" or "no" if the MIME type contains no codec string, and if the MIME type does contain a codec string we can either answer "no" (if the container is not supported) or "maybe".<br> <br>I suppose if Tim's willing to assume that anything supporting the Ogg container supports Theora and Vorbis, that's good enough for now ... for Quicktime. We'll have to look into whether something similar is possible with GStreamer and DirectShow. But I guess even if it isn't, a 3-value version of Tim's proposed API is better than nothing.<br> <br></div></div></div></blockquote><div> A three state return is an interesting idea, but wouldn't you then be required to return "maybe" for MIME types that can describe multiple formats? For example, "video/mpeg" can be used to describe a video elementary stream, an MPEG-1 system stream, an MPEG-2 program stream, or an MPEG-2 transport stream. "<span class="Apple-style-span" style="font-family: -webkit-monospace; font-size: 10px; white-space: pre; "><font class="Apple-style-span" face="Helvetica" size="3"><span class="Apple-style-span" style="font-size: 12px; white-space: normal;">application/ogg</span></font><span class="Apple-style-span" style="font-family: Helvetica; font-size: 12px; white-space: normal; ">" can include dirac, flac, theora, vorbis, speex, midi, cmml, png, mng, jng, celt, pcm, kate, and/or yuv4mpeg. And then there is "video/quicktime"...</span></span></div><div><br></div><div> I think it makes more sense to leave it as a boolean, where "no" means the UA does not support the type, and "yes" means that the UA implements some support for the type but errors can occur during loading and/or decoding. </div><div><br></div><div>eric</div></div></body></html>