FWIW, in nightly Gecko builds we have an implementation of canPlayType per
spec. It parses the codecs parameter of the provided MIME type, so we can
answer no, maybe or probably depending on what's in the type. E.g.:
On Fri, 14 Nov 2008, Silvia Pfeiffer wrote:
On a little bit of a side not, may I point out that there is an updated
RFC for Ogg media types at http://www.ietf.org/rfc/rfc5334.txt and it
explicitly includes the codecs parameter with standard values for the
current ones supported by Ogg.
On Mon, Nov 17, 2008 at 12:49 PM, Ian Hickson [EMAIL PROTECTED] wrote:
On Fri, 14 Nov 2008, Silvia Pfeiffer wrote:
On a little bit of a side not, may I point out that there is an updated
RFC for Ogg media types at http://www.ietf.org/rfc/rfc5334.txt and it
explicitly includes the codecs
On Thu, 16 Oct 2008, Robert O'Callahan wrote:
I have added window.navigator.canPlayType(mimeType). It returns 1, 0,
or -1 to represent positive, neutral, and negative responses.
navigator.canPlayType could be confusing since authors might think it
includes media playable via plugins
did this thread go anywhere ?i'm concerned about the maybe case - looks
way too much like:
http://en.wikipedia.org/wiki/DShow#Codec_hell
also - when you probe for mime type, do you mean the entire type parameter
(including the codecs string) ? for example, there are too many cases where
just
On Nov 13, 2008, at 10:52 AM, Jeremy Doig wrote:
did this thread go anywhere ?
See http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-navigator-canplaytype
.
i'm concerned about the maybe case - looks way too much like:
I'm also a bit concerned about how to interpret the yes, no and maybe
return values. The truthful answer is going to be maybe for all but
the obviously unsupport (application/x-ms-dos-executable) and the more
trivial formats (audio/wav).
When asking about application/ogg, this could mean 2
On Fri, Nov 14, 2008 at 8:19 AM, Eric Carlson [EMAIL PROTECTED]wrote:
See
http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#dom-navigator-canplaytype
.
There was widespread dissatisfaction with the form of the API. I think it
would be a lot better if there were two
On Fri, Nov 14, 2008 at 8:38 AM, Philip Jägenstedt [EMAIL PROTECTED]wrote:
I'm also a bit concerned about how to interpret the yes, no and maybe
return values. The truthful answer is going to be maybe for all but
the obviously unsupporter (application/x-ms-dos-executable) and the more
trivial
On Fri, Nov 14, 2008 at 6:38 AM, Philip Jägenstedt [EMAIL PROTECTED] wrote:
Now, if the codec parameter is used then the user agent may answer yes
and no in a way that actually makes some sense.
I also think that this should be explicitly related to the type
attribute of the source element.
Pitching in here, I think it's OK if we want to go to a two-state
answer -- but those answers are No and Maybe, not No and Yes. There
are, after all, vanishingly small numbers of mime types where I can
be 'completely' (within reason) confident of a 'yes' answer. On the
other hand, given a
On Oct 15, 2008, at 1:44 AM, Ian Hickson wrote:
On Tue, 14 Oct 2008, Robert O'Callahan wrote:
On Tue, Oct 14, 2008 at 12:13 PM, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
While the underlying media frameworks can't necessarily answer,
if I
give you a file with this MIME type, can you
On Tue, 14 Oct 2008, Robert O'Callahan wrote:
On Tue, Oct 14, 2008 at 12:13 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
While the underlying media frameworks can't necessarily answer, if I
give you a file with this MIME type, can you play it?, they can at
least give a yes/no/maybe
Stachowiak; Robert O'Callahan; Dave Singer; Nils Dagsson Moskopp;
Eric Carlson
Cc: WHATWG List
Subject: Re: [whatwg] Scripted querying of video capabilities
On Tue, 14 Oct 2008, Robert O'Callahan wrote:
On Tue, Oct 14, 2008 at 12:13 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
While
Am Dienstag, den 14.10.2008, 14:51 +0900 schrieb Dave Singer:
At 7:40 +0200 14/10/08, Nils Dagsson Moskopp wrote:
No, I don't think authors can expect that the UA will automatically
suggest codec installs. It doesn't know the basis, and maintaining a
reliable database of
On Thu, 7 Aug 2008, Tim Starling wrote:
Would it be possible to add methods or properties to HTMLMediaElement to
support scripted determination of client codec capabilities?
The answer, based on replies quoted below from browser vendors, appears to
be no, sadly. I agree that it would be a
On Oct 13, 2008, at 1:06 PM, Ian Hickson wrote:
On Thu, 7 Aug 2008, Tim Starling wrote:
Would it be possible to add methods or properties to
HTMLMediaElement to
support scripted determination of client codec capabilities?
The answer, based on replies quoted below from browser vendors,
Am Dienstag, den 14.10.2008, 14:21 +0900 schrieb Dave Singer:
At 20:06 + 13/10/08, Ian Hickson wrote:
On Thu, 7 Aug 2008, Dave Singer wrote:
In general, the source fallbacks are also a way to 'probe' this, albeit
in a very different way.
I'm not sure you can always get a
At 7:40 +0200 14/10/08, Nils Dagsson Moskopp wrote:
What's a portal page - wouldn't it be the job of the Browser /
Media Framework to prompt for codec installs ?
They are used today; it's a page with a 'published URL' through
which people normally gain access to the site. You can check
timeless wrote:
yes, i'd expect it to just work. however i'd also expect the apis not
to work correctly. which means we'd probably be stuck with a case
where we either lie and say ogg isn't supported (because we have no
way to figure out if it's supported), which means it wouldn't work. or
On Aug 14, 2008, at 11:14, timeless wrote:
We'd probably be forced to lie and claim every codec imaginable.
[including ogg (or rather vorbis, theora, speex, ...), as these are
all imaginable]
On Thu, Aug 14, 2008 at 12:41 PM, Henri Sivonen [EMAIL PROTECTED] wrote:
Would the situation be any
On Aug 20, 2008, at 12:39, timeless wrote:
On Thu, Aug 14, 2008 at 12:41 PM, Henri Sivonen [EMAIL PROTECTED]
wrote:
Would the situation be any different for the source element
fallback?
yes. people wouldn't try to ask us questions we can't answer. instead
they'd be giving gecko lots of
: [whatwg] Scripted querying of video capabilities
footnote: if someone's annoying/evil and only provides one source,
then yes, bad things will probably happen.
Could i put in a plea for browsers to consider flagging this site
isn't nice, it probably won't work if you visit it with another
device, you
On Wed, Aug 20, 2008 at 1:52 PM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
Only the user that actually encounters a Web site deficiency should report
it to the creator/owner (assuming they provided a reverse link).
Otherwise such a report should be ignored as a supposition.
mass complaints
20, 2008 2:29 PM
To: WHATWG List
Subject: Re: [whatwg] Scripted querying of video capabilities
On Wed, Aug 20, 2008 at 1:52 PM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
Only the user that actually encounters a Web site deficiency should report
it to the creator/owner (assuming they provided
On Wed, Aug 20, 2008 at 9:53 PM, Henri Sivonen [EMAIL PROTECTED] wrote:
Do you mean trying to download each video, giving it to GStreaming and
seeing if an error code comes back?
That might be what we have to do, yes.
But at least that can be done asynchronously. You couldn't implement a
On Fri, Aug 8, 2008 at 10:13 PM, Tim Starling [EMAIL PROTECTED] wrote:
Or have I been shot down already?
I'd like to shoot you down.
javascript should not be required to play media. sniffing apps are
historically bad, and shouldn't be encouraged.
there should be no harm in using multiple
On Aug 14, 2008, at 11:14, timeless wrote:
We'd probably be forced to lie and claim every codec imaginable.
Would the situation be any different for the source element fallback?
If MicroB.next ships without Gecko's built-in liboggplay video back
end but ships with the GStreamer back end and
The spec mandates both video element support + ogg theora support.
No, that's incorrect.
-- Charles
?
IMHO,
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Chris Double
Sent: Wednesday, August 13, 2008 12:46 AM
To: Kristof Zelechovski
Cc: WHATWG List; Tim Starling
Subject: Re: [whatwg] Scripted querying of video capabilities
On Wed, Aug 13, 2008 at 3
Sent: Thursday, August 07, 2008 1:23 PM
To: WHATWG List
Subject: Re: [whatwg] Scripted querying of video capabilities
The reason this is needed, as opposed to using multiple source tags,
is because inevitably, some clients will support certain formats via
object (or in our special case, applet
On Tue, Aug 12, 2008 at 7:47 PM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
What is the advantage of using JavaScript to determine a viable embedding
method over using alternative streams and fallback content that can include
the OBJECT element where appropriate?
video src=foo.ogg
fallback
On Wed, Aug 13, 2008 at 3:35 AM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
Falling back to another method of displaying media is possible without a
dedicated media API. In this particular case, you can have a video element
with an ogg source and an object running Cortado to display it.
I
On Tue, Aug 12, 2008 at 3:46 PM, Chris Double [EMAIL PROTECTED]wrote:
A browser that supports video but not Ogg will not use the fallback
object. Instead it will just give an error when loading the foo.ogg
file.
In this case I believe it would be possible to listen to the `error' event
and
James Ide wrote:
On Tue, Aug 12, 2008 at 3:46 PM, Chris Double
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
A browser that supports video but not Ogg will not use the fallback
object. Instead it will just give an error when loading the foo.ogg
file.
In this case I believe
On Sat, Aug 9, 2008 at 7:13 AM, Tim Starling [EMAIL PROTECTED] wrote:
Where do I go from here with this? Should I make a concrete proposal? A
sample implementation? Get that Mozilla bug fixed? Or have I been shot
down already?
I think it is important for web sites to be able to detect in some
Jeremy Doig wrote:
how would this work (say) for different avc profile levels and
features (eg: PAFF support) ?
I don't think that's our problem. The details of determining a type name
for a given file should be in another standard, it should not be in HTML
5. All HTML 5 has to do is delegate
Dave Singer wrote:
I think this is a good idea, but one rapidly runs into the problems
talked about in the 'bucket' RFC, notably that there is not a
universal language for naming codecs (4ccs etc). But it's proved
useful in the past.
In general, the source fallbacks are also a way to
Robert O'Callahan wrote:
That would be nice to have. Unfortunately DirectShow and Quicktime do
not seem to expose the ability to enumerate supported codecs, so it
might be hard to implement for some browsers.
As things stand, you can use source elements to offer different
formats, and you
On Aug 7, 2008, at 09:53, Tim Starling wrote:
xiphQtVersion = videoElt.GetComponentVersion('imdc','XiTh',
'Xiph');
This kind of FourCC use is exactly the kind of thing I meant earlier
when I asked if the MIME stuff is really the best match for frameworks.
--
Henri Sivonen
[EMAIL
Henri Sivonen wrote:
On Aug 7, 2008, at 09:53, Tim Starling wrote:
xiphQtVersion = videoElt.GetComponentVersion('imdc','XiTh',
'Xiph');
This kind of FourCC use is exactly the kind of thing I meant earlier
when I asked if the MIME stuff is really the best match for frameworks.
Mikko Rantalainen wrote:
Tim Starling wrote:
Henri Sivonen wrote:
On Aug 7, 2008, at 09:53, Tim Starling wrote:
xiphQtVersion = videoElt.GetComponentVersion('imdc','XiTh',
'Xiph');
This kind of FourCC use is exactly the kind of thing I meant earlier
when
how would this work (say) for different avc profile levels and features (eg:
PAFF support) ?would we require video creators to know the specific
capabilities of every fourCC target ?
On Thu, Aug 7, 2008 at 4:23 AM, Tim Starling [EMAIL PROTECTED]wrote:
Mikko Rantalainen wrote:
Tim Starling
I think this is a good idea, but one rapidly runs into the problems
talked about in the 'bucket' RFC, notably that there is not a
universal language for naming codecs (4ccs etc). But it's proved
useful in the past.
In general, the source fallbacks are also a way to 'probe' this,
albeit in a
On Thu, Aug 7, 2008 at 6:53 PM, Tim Starling [EMAIL PROTECTED]wrote:
DirectShow and QuickTime can add those interfaces at a later date. When
the backends develop this capability, there should be a standard way to
go the next step and expose it to JavaScript. Otherwise every
implementor will
Would it be possible to add methods or properties to HTMLMediaElement to
support scripted determination of client codec capabilities?
The supported codecs will no doubt change through the years, as the
technology and the legal situation changes. I'd like to see
determination of codec support
That would be nice to have. Unfortunately DirectShow and Quicktime do not
seem to expose the ability to enumerate supported codecs, so it might be
hard to implement for some browsers.
As things stand, you can use source elements to offer different formats,
and you can try to play a stream and use
47 matches
Mail list logo
