[whatwg] Video with MIME type application/octet-stream
eric.carlson at apple.com
Wed Sep 1 09:29:01 PDT 2010
On Sep 1, 2010, at 9:07 AM, Zachary Ozer wrote:
> On Wed, Sep 1, 2010 at 10:51 AM, Adrian Sutton <adrian.sutton at ephox.com> wrote:
>> Given that there is a very limited set of video formats that are supported
>> anyway, wouldn't it be reasonable to just identify or define the "standard"
>> file extensions then work with server vendors to update their standard file
>> extension to mime type definitions to include that. While adoption and
>> upgrading to the new versions would obviously take time, that applies to the
>> video tag itself anyway and is just a temporary source of pain.
> At first glance, my eyes almost popped out of my sockets when I saw
> this suggestion. "Using the file extension?! He must be mad!"
> Then I remembered that our Flash player *has* to use file extension
> since the MIME type isn't available in Flash. Turns out that file
> extension is a pretty good indicator, but it doesn't work for custom
> server configurations where videos don't have extensions, ala YouTube.
> For that reason, we allow users to override whatever we detect with a
> "type" configuration parameter.
> Ultimately, the question is, "What are we trying to accomplish?"
> I think we're trying to make it easy for content creators to guarantee
> that their content is available to all viewers regardless of their
> If that's the case, I'd actually suggest that the browsers *strictly*
> follow the MIME type, with the <source> type as a override, and
> eliminating all sniffing (assuming that the file container format
> contains the codec meta-data). If a publisher notices that their video
> isn't working, they can either update their server's MIME type
> mapping, or just hard code the type in the HTML.
Hard coding the type is only possible if the element uses a <source> element, @type isn't allowed on <audio> or <video>.
> Neither is that time consuming / difficult.
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).
> Moreover, as Adrian suggested, it's probably quite easy to get the big
> HTTP servers (Apache, IIS, nginx, lighttpd) to add the new extensions
> (if they haven't already), so this would gradually become less and
> less of an issue.
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:
eric% curl -I "http://content.longtailvideo.com/videos/flvplayer.flv"
HTTP/1.1 200 OK
Last-Modified: Wed, 23 Jun 2010 20:42:28 GMT
Date: Wed, 01 Sep 2010 16:16:28 GMT
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg