One common way to reduce the load on a web server is to use gzip or deflate compression when serving to a supporting web browser. When Firefox requests an Ogg media, it advertises that it can handle a gzipped or deflated response; the HTTP request includes the Accept-Encoding: gzip,deflate header. But despite Firefox advertising that it supports gzip/deflate, you probably don't want your web server to gzip or deflate Ogg media. If you serve an Ogg media compressed, Firefox won't be able to seek in the media, or determine its duration. Since the video/audio data in Ogg files is already compressed, gzip/deflate won't actually save you much bandwidth anyway, so you probably want to disable compression when serving Ogg files.
I have added this tip to the Mozilla Developer Center article on configuring servers for Ogg media.
9 comments:
Is this because of OggIndex and skeleton not being accessibly when compressed?
This is because most (all?) HTTP compression techniques don't send a Content-Length HTTP header. I assume this is because they compress on the fly, so they don't know the length of the compressed file in advance. If the server doesn't send a Content-Length, Firefox doesn't know what byte ranges it can request, so it can't do seeking using HTTP byte-range requests.
Even if you had an index, the index would record the pre-compression byte offsets, so you couldn't use it to guide a seek (even if you could start decompressing a compressed file at an arbitrary byte offset).
As a workaround, we can disable Accept-Encoding when asking for a media file, at least until someone will come with a better solution.
The same might happen with regular image files, and it might be useful to disable compression request for these files as well.
Could Firefox not send the Accept-Encoding header in the first place?
What Philip said. We know the load context; let's not ask for compression on loads from video and audio tags. (Unless it's a .WAV?)
Gerv
Sounds like the code that loads videos should just QI the channel to nsIHttpChannel and call httpChannel->SetRequestHeader(NS_LITERAL_CSTRING("accept-encoding"), EmptyCString(), PR_FALSE);
Speaking of which... it probably also ought to set an appropriate value for the "Accept" header, which it doesn't look like it currently does. (At least, I don't see code for it.) That would mean it's sending the (rather long) Accept header that we send for toplevel pages. (It looks like it does set the "Range" header (in two places, nsHTMLMediaElement and nsMediaStream), though, so you've already got code for it.)
There's a bug for sending a more appropriate Accept header (bug 489071). There's also some discussion about not sending Accept-Encoding there, but I'm not convinced it's the right thing to do now.
Hi,
I found your blog from my bug report on mozilla : https://bugzilla.mozilla.org/show_bug.cgi?id=551217
My problem is that I can seek videos on HTTP but not on HTTPS because of compression (apparently).
On the mozilla page you linked, there is a section "Don't use gzip/deflate compression".
But how to disable it for ogg files on https in apache?
Thank you for your answer.
@®om: I know very little about configuring apache, particularly the interactions between mod_ssl and other modules. I suggest you check out the documentation for mod_gzip:
http://schroepl.net/projekte/mod_gzip/config.htm
Perhaps you need a mod_gzip_item_exclude clause in your config?
Post a Comment