On Aug 22, 2008, at 2:36 PM, Robert O'Callahan wrote:
On Sat, Aug 23, 2008 at 1:46 AM, Eric Carlson
<[EMAIL PROTECTED]> wrote:
On Aug 21, 2008, at 8:56 PM, Robert O'Callahan wrote:
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.
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.
That will require extensions to Quicktime, right?
Correct.
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".
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.
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. "application/ogg" can include
dirac, flac, theora, vorbis, speex, midi, cmml, png, mng, jng, celt,
pcm, kate, and/or yuv4mpeg. And then there is "video/quicktime"...
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.
eric
