[whatwg] Video with MIME type application/octet-stream

[Eric Carlson]

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
> browser.
> 
> 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
Server-Status: load=0
Content-Type: application/octet-stream
Accept-Ranges: bytes
ETag: "4288394655"
Last-Modified: Wed, 23 Jun 2010 20:42:28 GMT
Content-Length: 2533148
Date: Wed, 01 Sep 2010 16:16:28 GMT
Server: bit_asic/3.8/r8s1-bitcast-b


eric

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100901/848f33a0/attachment-0002.htm>