Finally found the right solution after many trials, my MIME types were correctly configured but still not working!

The transfer type thru ftp/sftp must be to: Binary Transfer Type (NOT ascii transfer type)

see more infos

Here comes the solution:

When you upload the .htaccess file with a ftp-program you have to change your options to ASCII Mode! DO NOT use Binary Mode for upload!

All other files like audio, video, html, pictures etc. must be uploaded in Binary Mode.

Read this!

I have the same or a similar problem.

myvideo.theora.ogv will play on Opera but only intermittently on Firefox 8.0.1.

I edited .htaccess as suggested in earlier posts. This made no difference.

I checked that the MIME type being sent with the page was correct by entering the myvideo.theora.ogv URL in the browser and checking through right click "view page info" as suggested in an earlier post.

I tried long and short (14 seconds) videos and they behave differently.

Long videos will sometimes play the short one has done so consistently - so far.

I looked at the HTML5.media.readyState values. [[HTML5 Specification|http://www.w3.org/TR/html5/video.html#the-ready-states]]

readyState is 4 when the video plays and 2 when it does not. The controls time line object is at the start moving onward when it plays and "stuck" at the end when it does not. i.e. trying to set the timeline to earlier in the video does nothing and the cursor flies back to the end.

HAVE_CURRENT_DATA (numeric value 2)

Data for the immediate current playback position is available, but either not enough data is available that the user agent could successfully advance the current playback position in the direction of playback at all without immediately reverting to the HAVE_METADATA state, or there is no more data to obtain in the direction of playback. For example, in video this corresponds to the user agent having data from the current frame, but not the next frame; and to when playback has ended.

HAVE_ENOUGH_DATA (numeric value 4)

All the conditions described for the HAVE_FUTURE_DATA state are met, and, in addition, the user agent estimates that data is being fetched at a rate where the current playback position, if it were to advance at the effective playback rate, would not overtake the available data before playback reaches the end of the media resource

So something is not as it should be around buffering the video in Firefox.

I tried the suggestion, earlier in this thread, to change the <video> </video> to include autobuffer and preload="auto" and this made no difference.

Interrogating the video element i.e.

var myVideo = document.getElementById("myVideo");

var readyState = myVideo.readyState;

seems to have a positive impact (i.e. the video then plays) if the video element is interrogated before the video is "played".

I don't have a clue why this should be the case.

I would appreciate thoughts, ideas and suggestions.

Are the video files send by the server as compressed files (gzip) or as uncompressed files?

If a large file is send compressed then Firefox doesn't know where to start the next chunk from the server and fails, so make sure that media files are send uncompressed.

The files are uncompressed. I am not pre-loading.

Opera which is also using the ogg theora video files works "properly".

I am now on Firefox 9.0.1. But this makes not difference to the problem!

I have stopped trying to get ogg files to work.

The webm codec works with Firefox which reports a "probably" will play when interrogated with MediaElement.canPlayType against the ogg codec which reports "maybe" will play.