On Fri, Nov 14, 2008 at 8:38 AM, Philip Jägenstedt <span dir="ltr"><<a href="mailto:philipj@opera.com">philipj@opera.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;">
I'm also a bit concerned about how to interpret the yes, no and maybe<br><div class="Ih2E3d">
return values. The truthful answer is going to be "maybe" for all but<br>
</div>the obviously unsupporter (application/x-ms-dos-executable) and the more<br>
<div class="Ih2E3d">trivial formats (audio/wav).</div></blockquote><div><br>Even WAV is extensible.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">When asking about application/ogg, this could mean 2 things:<br>
<br>
</div>1. "can I demux Ogg streams?"<br>
2. "can I demux Ogg streams and decode unknown codecs?"</blockquote><div><br>It means "can I play this stream, given that the only thing I know about it is that it's an Ogg stream"? Which I guess is what you meant by option 2.<br>
<br>The browser can only answer "no" or "maybe" in this case. That seems fine to me. It lets the author know whether the browser can demux Ogg streams, while staying consistent with the behaviour when codec information is given in the MIME type.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Unless the codecs parameter is to be made mandatory I think that spec<br>
should explicitly make it such that the question asked is 1. In either<br>
case we will end up there because 2 is not a meaningful question and<br>
user agents will make untruthful answers in attempts to stay compatible<br>
with unknown and future content (which might be supported by installing<br>
new codecs in the media framework without upgrading the browser).</blockquote><div><br>I don't understand what the incentives are for browsers to lie. If we start off telling the truth, then authors will have to write scripts that either accept "maybe" or, better still, provide the codec information, or their scripts won't work. I don't see how that would change over time.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Now, if the codec parameter is used then the user agent may answer yes<br>
and no in a way that actually makes some sense.</blockquote><div><br>Yes. Authors should be strongly encouraged to give the codec parameters.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I also think that this should be explicitly related to the type<br>
attribute of the source element. One should be able to use canPlayType<br>
to predict with 100% accuracy which source the user agent will use when<br>
it encounters.<br>
<br>
<video><br>
<source type="application/ogg"/><br>
<source type="application/ogg codecs=dirac,flac"/><br>
</video><br>
<br>
If this isn't specified then one can expect lots of web app authors<br>
being forced to write scripts to work around the different behaviour of<br>
canPlayType and the "pick a source" algorithm in different browsers.</blockquote><div><br>I agree.<br><br>Rob<br></div></div>-- <br>"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]<br>