<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Sep 1, 2010, at 9:07 AM, Zachary Ozer wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Wed, Sep 1, 2010 at 10:51 AM, Adrian Sutton <<a href="mailto:adrian.sutton@ephox.com">adrian.sutton@ephox.com</a>> wrote:<br><blockquote type="cite">Given that there is a very limited set of video formats that are supported<br></blockquote><blockquote type="cite">anyway, wouldn't it be reasonable to just identify or define the "standard"<br></blockquote><blockquote type="cite">file extensions then work with server vendors to update their standard file<br></blockquote><blockquote type="cite">extension to mime type definitions to include that. While adoption and<br></blockquote><blockquote type="cite">upgrading to the new versions would obviously take time, that applies to the<br></blockquote><blockquote type="cite">video tag itself anyway and is just a temporary source of pain.<br></blockquote><br>At first glance, my eyes almost popped out of my sockets when I saw<br>this suggestion. "Using the file extension?! He must be mad!"<br><br>Then I remembered that our Flash player *has* to use file extension<br>since the MIME type isn't available in Flash. Turns out that file<br>extension is a pretty good indicator, but it doesn't work for custom<br>server configurations where videos don't have extensions, ala YouTube.<br>For that reason, we allow users to override whatever we detect with a<br>"type" configuration parameter.<br><br>Ultimately, the question is, "What are we trying to accomplish?"<br><br>I think we're trying to make it easy for content creators to guarantee<br>that their content is available to all viewers regardless of their<br>browser.<br><br>If that's the case, I'd actually suggest that the browsers *strictly*<br>follow the MIME type, with the <source> type as a override, and<br>eliminating all sniffing (assuming that the file container format<br>contains the codec meta-data). If a publisher notices that their video<br>isn't working, they can either update their server's MIME type<br>mapping, or just hard code the type in the HTML. </div></blockquote><div><blockquote type="cite"><br></blockquote></div><div> Hard coding the type is only possible if the element uses a <source> element, @type isn't allowed on <audio> or <video>.</div><div><br></div><blockquote type="cite"><div>Neither is that time consuming / difficult.<br><br></div></blockquote><div> It isn't hard to update a server if you control it, but it can be *very* difficult and time consuming if you don't (as is the case with most web developers, I assume).</div><div><br></div><div><br></div><blockquote type="cite"><div>Moreover, as Adrian suggested, it's probably quite easy to get the big<br>HTTP servers (Apache, IIS, nginx, lighttpd) to add the new extensions<br>(if they haven't already), so this would gradually become less and<br>less of an issue.<br><br></div></blockquote><div> Really? Your company specializes in web video and flv files have been around for years, but your own server still isn't configured for it:</div><div><br></div><div>eric% curl -I "<a href="http://content.longtailvideo.com/videos/flvplayer.flv">http://content.longtailvideo.com/videos/flvplayer.flv</a>"<br>HTTP/1.1 200 OK<br>Server-Status: load=0<br>Content-Type: <b>application/octet-stream</b><br>Accept-Ranges: bytes<br>ETag: "4288394655"<br>Last-Modified: Wed, 23 Jun 2010 20:42:28 GMT<br>Content-Length: 2533148<br>Date: Wed, 01 Sep 2010 16:16:28 GMT<br>Server: bit_asic/3.8/r8s1-bitcast-b<br><br></div><div><br></div>eric</div><div><br></div></body></html>