<div dir="ltr">how would this work (say) for different avc profile levels and features (eg: PAFF support) ?<div>would we require video creators to know the specific capabilities of every fourCC target ?</div><div><br><div class="gmail_quote">
On Thu, Aug 7, 2008 at 4:23 AM, Tim Starling <span dir="ltr">&lt;<a href="mailto:tstarling@wikimedia.org">tstarling@wikimedia.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class="Wj3C7c">Mikko Rantalainen wrote:<br>
&gt; Tim Starling wrote:<br>
&gt;<br>
&gt;&gt; Henri Sivonen wrote:<br>
&gt;&gt;<br>
&gt;&gt;&gt; On Aug 7, 2008, at 09:53, Tim Starling wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp;xiphQtVersion = videoElt.GetComponentVersion(&#39;imdc&#39;,&#39;XiTh&#39;,<br>
&gt;&gt;&gt;&gt; &#39;Xiph&#39;);<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt; This kind of FourCC use is exactly the kind of thing I meant earlier<br>
&gt;&gt;&gt; when I asked if the MIME stuff is really the best match for frameworks.<br>
&gt;&gt;&gt;<br>
&gt;&gt; FourCC and MIME are not mutually exclusive, see RFC 2361.<br>
&gt;&gt;<br>
&gt;<br>
&gt; RFC 2361 doesn&#39;t seem to provide a method for describing both video<br>
&gt; codec and audio codec for a resource. The same parameter (&quot;codec&quot;) is<br>
&gt; used for both audio and video codec information but I cannot understand<br>
&gt; how a resource that contains both video and audio should be labeled.<br>
&gt;<br>
&gt; RFC 4281 seems to provide a parameter &quot;codecs&quot; that is a comma separated<br>
&gt; list of used codecs. The detail required (&quot;MUST&quot;) for the &quot;codecs&quot;<br>
&gt; parameter seems quite high and I&#39;m afraid that this parameter will not<br>
&gt; be correctly used in real world, unfortunately. In theory, this would<br>
&gt; seem a good way to provide the information needed for a resource.<br>
&gt;<br>
&gt;<br>
<br>
</div></div>Well, I was thinking of an interface which would list the codecs, rather<br>
than the overall file types. But it could be done either way. By file type:<br>
<br>
if ( video.supportsType( &#39;application/ogg;codecs=&quot;vorbis,theora&quot;&#39; ) ) {<br>
&nbsp;...<br>
}<br>
<br>
By codec/container:<br>
<br>
if ( &#39;application/ogg&#39; in video.supportedTypes<br>
 &nbsp;&amp;&amp; &#39;video/theora&#39; in video.supportedTypes<br>
 &nbsp;&amp;&amp; &#39;audio/vorbis&#39; in video.supportedTypes )<br>
{<br>
 &nbsp;...<br>
}<br>
<br>
The first one looks easier in this application, and allows for multiple<br>
backends with different allowed combinations of container and codec. The<br>
second one allows for complete enumeration of client capabilities.<br>
<br>
Obviously you couldn&#39;t provide an interface to enumerate every possible<br>
combination of container, audio codec and video codec.<br>
<br>
The reason this is needed, as opposed to using multiple &lt;source&gt; tags,<br>
is because inevitably, some clients will support certain formats via<br>
&lt;object&gt; (or in our special case, &lt;applet&gt;) and not via &lt;video&gt;.<br>
Querying the browser&#39;s &lt;video&gt; capabilities allows JS to decide what<br>
sort of embedding method to use. It&#39;s an essential migration feature.<br>
<font color="#888888"><br>
-- Tim Starling<br>
</font></blockquote></div><br></div></div>