<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"><<a href="mailto:tstarling@wikimedia.org">tstarling@wikimedia.org</a>></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>
> Tim Starling wrote:<br>
><br>
>> Henri Sivonen wrote:<br>
>><br>
>>> On Aug 7, 2008, at 09:53, Tim Starling wrote:<br>
>>><br>
>>><br>
>>>>        xiphQtVersion = videoElt.GetComponentVersion('imdc','XiTh',<br>
>>>> 'Xiph');<br>
>>>><br>
>>> This kind of FourCC use is exactly the kind of thing I meant earlier<br>
>>> when I asked if the MIME stuff is really the best match for frameworks.<br>
>>><br>
>> FourCC and MIME are not mutually exclusive, see RFC 2361.<br>
>><br>
><br>
> RFC 2361 doesn't seem to provide a method for describing both video<br>
> codec and audio codec for a resource. The same parameter ("codec") is<br>
> used for both audio and video codec information but I cannot understand<br>
> how a resource that contains both video and audio should be labeled.<br>
><br>
> RFC 4281 seems to provide a parameter "codecs" that is a comma separated<br>
> list of used codecs. The detail required ("MUST") for the "codecs"<br>
> parameter seems quite high and I'm afraid that this parameter will not<br>
> be correctly used in real world, unfortunately. In theory, this would<br>
> seem a good way to provide the information needed for a resource.<br>
><br>
><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( 'application/ogg;codecs="vorbis,theora"' ) ) {<br>
 ...<br>
}<br>
<br>
By codec/container:<br>
<br>
if ( 'application/ogg' in video.supportedTypes<br>
  && 'video/theora' in video.supportedTypes<br>
  && 'audio/vorbis' in video.supportedTypes )<br>
{<br>
  ...<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'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 <source> tags,<br>
is because inevitably, some clients will support certain formats via<br>
<object> (or in our special case, <applet>) and not via <video>.<br>
Querying the browser's <video> capabilities allows JS to decide what<br>
sort of embedding method to use. It's an essential migration feature.<br>
<font color="#888888"><br>
-- Tim Starling<br>
</font></blockquote></div><br></div></div>