Combination Gallery 2/AVI/Firefox does not display video

Try this Firefox extension out. Worked like a charm for me, and keeps things embedded in the page.

Media Wrap
https://addons.mozilla.org/en-US/firefox/addon/1879

or If you want the media to open outside the browser window in Media Player, you can use this one.

MediaPlayerConnectivity
https://addons.mozilla.org/en-US/firefox/addon/446

enjoy,

Ed

This didn't work for me, perhaps because the line numbers were slightly different in my file (Gallery 2.1.1) and you didn't include any context, (grr) so I had no idea where to put the 274-277 section though I could figure out the other two. I was putting it right after the switch, before the case. Trying to load an album that had any videos in it would just give a blank browser window.

But this slghtly different way worked. Put the re-write outside of and before the entire switch statement.

$mimeType = $this->getMimeType();
    if( $mimeType == 'video/x-msvideo' ) {
        $mimeType = 'video/x-ms-wmv';
    }
switch($mimeType) {
...
$mimeType,
...

Also, You are one thousand percent right about how to treat this, as something that needs a work-around within Gallery, at least unless a similar workaround might appear in firefox or possibly the divx web-player installer or of course if the real problem in the MS mplayer plugin ever gets fixed by MS.

I can fix up my own browser any number of ways, or just use IE, but I'm still left with a web site that I have to always tell people what they can and can't do in order for the site to work "oh by the way it only works in internet explorer..." It doesn't matter that Gallery isn't what's broken, it's still no good to have a site that requires instructions.

It's not even that it's so galling to say it works in IE but not in firefox. If it worked everywhere _but_ IE, it would be even worse.
The problem is it's unacceptable to have to say anything at all.

As far as this kind of fix breaking other contexts, I think we have all the info we need in order to make the fix very specific.

First, the file command on one of the .avi's that my camera generates, does include "divx" (actually "XviD" in my case)

$ file SNV31104.AVI
SNV31104.AVI: RIFF (little-endian) data, AVI, 640 x 480, 30.00 fps, video: XviD, audio: ADPCM (mono, 22050 Hz)

so if necessary we can limit the fix to only divx, or a list of known broken codecs, not all .avi. However I think the problem isn't divx or divx+.avi, but any file that gets that mime-type. firefox doesn't know what to do with the mime-type, so detecting divx and only fixing divx probably isn't desireable. But it's there.

Actually, where is that mime-type coming from anyways? What decided that the mime type should be "video/x-msvideo" in the first place? Maybe the fix should go there?

Second, Don't we know what browser the client is using? Or at least what it's claiming to be? So we can also limit the re-write to only happen for firefox. In fact, can't we limit it to happen only for Windows firefox?

Could somebody post the full, working "GalleryMovieItem.class" - My file seems to be different.

I am using Gallery 2.2.2 and lines 258 - 266 look like this:

	    case 'video/mpeg':
	    case 'video/mp4':
	    case 'video/x-msvideo':
	    case 'video/x-ms-wmv':
		$classId = 'CLSID:05589FA1-C356-11CE-BF01-00AA0055595A';
	    case 'video/x-ms-asf':
	    case 'video/x-ms-asx':
		if (!isset($classId)) {
		    $classId = 'CLSID:22D6F312-B0F6-11D0-94AB-0080C74C7E95';

I would prefer to go the route that does not require any extra effort from the website's visitors.

Still seeing this problem in Firefox with avi files from a digital camera (MJPEG format, I think). (Mom just wants to see the kiddies!)

Did we end up with a final resolution to this problem? Is the G2 supported position that I edit my Firefox settings for the proper mime type? Or should I implement the "hack" to the GalleryMovieItem.class file listed above (in various forms, shapes, and sizes)? Or has this thread moved and I've been the only one not to find it's new location?

Please advise.

PS - I always get frustrated (as do others) when the open source community can't decide whose problem is whose. As mentioned by other frustrated folks, if it doesn't work for the end user... they are more likely to go back to the non-open source solutions.

Or convert them to Quicktime (.mov) files. The .avi (MJPEG) files from my Canon camera are monstrously large. Quicktime reduces the file size considerably while maintaining video quality. And, of course, the converted .mov files work on both IE and FF.

Thanks a lot! This works for me with Gallery 2.2.4. Now movies play fine embedded with both IE and Firefox. I too wanted a solution on my server. Didn't want my visitors to have to change things...

Pretty lame suggestion, you think I wanna post instructions on editing firefox files or avoiding .avi because the GALLERY cant handle it? you have the workarounds here for the script that are never implemented. Lucky this is free beer because if I had a developer palming me off with stupid suggestions my mother would think of rather then FIX the code IN THE GALLERY I'd be looking for new dev's. Just fix the damn thing, it's been long enough already. You cant blame MS or firefox when other gallery scripts have no problems playing an avi.

Well, I recently updated to G2.3, and the problem wasn't fixed with the new release. However, the workaround above still works. The GalleryMovieItem.class file from G2.2.4 can even be used in G2.3. The contents are the same, except for some comments. The code is identical. Good thing is that the fix also puts the direct download link back!