[jpstewart]

@Callahan:  which movie(s) are you having trouble with?  On my Indigo, I have Hospital.movie, orig.movie, and subliminal.movie which all play fine in mplayer on Linux.  I also have indigo.movie which is the only one where the sound plays at double speed.  Which has totally ruined my theory on what the problem was.

I used a hex editor to alter two bytes in indigo.movie to change it to 11025 Hz sound and it plays fine now.  (That's a big clue that the problem is the format not being recognized properly.  I'd previously speculated it might be an output problem but it's not.)  I can even convert it to .mp4 (or other formats) with ffmpeg, but I notice that ffmpeg reports that it is expecting 4 bytes of audio data and only finding two for each audio sample in the file.  So that's a clue.  Maybe it's monaural but being detected as stereo.  I don't know.  My next task is to try extracting just the audio and see what I get.  I'd love to be able to get to the point where I can send a patch upstream, but that might be a bit ambitious.

If that fails on Linux, I'll fire up the Indigo itself on the weekend and see what the IRIX native tools have to say about the files and how that differs from what the Linux apps are detecting.

For anyone playing along at home:

1. Fire up your favourite hex editor. 
   
2. Find the two bytes "56 22" at offsets 0x3A and 0x3B (fourth line of Callahan's hex dump screenshot). 
   
3. Change them to "2B 11" and save the file.
   

The audio will now play correctly, synced to video.  Editing video in hexadecimal is a dirty hack, but it worked well enough to get mplayer and ffmpeg to do their thing.

[jpstewart]

Minor update:  I have confirmed (by using moviemaker on IRIX 4.0.5F on my own Indigo) that the audio in indigo.movie is only one channel.  But mplayer is detecting it as two (stereo). 

My earlier hack of changing the header to halve the sample rate is wrong.  (But does get the desired result.)

I'm not entirely sure why mplayer thinks it's two channels when it is only one.  I don't have great documentation for the movie file format, but I think I know where the number of channels is stored in the file.  Now I'll see what I can do to convince mplayer to handle it.

[vishnu]

I'm sure you've seen this already but there's an SGI movie FAQ:

http://rainbow.ldeo.columbia.edu/documen...index.html

[jpstewart]

Unfortunately all that document does for me is confirm that the SGI movie file format is undocumented.

I've found where libavformat thinks the number of audio channels should be, but it is wrong.  In the indigo.movie file there is only one audio channel according to SGI's tools while mplayer and ffmpeg both think there are two.  I can edit the .movie file to put a 1 where they expect to find the number of channels and get it to play correctly, but that's another bad hack.  (It does confirm that I'm understanding their code, however.)  I need to create a couple more test files under IRIX to confirm that the number of channels is where I think it is.  Then I can patch libavformat.

[jpstewart]

Here's the latest:

I have indeed found the bug in libavformat (part of ffmpeg, but also used by mplayer and VLC) where they are misinterpreting a number as the number of audio channels when it is not.  The number of audio channels is actually 8 bytes later than what they think it is.  I have patched the source and rebuilt the library.  Now I have a working setup for both ffmpeg and mplayer that handles the movies without the need for the ugly binary hack I mentioned a few posts ago.

The ffmpeg project has several sample movies in SGI format but they all are either silent or stereo.  There are no monaural examples in their collection.  When I prepare my patch, I'll also provide them with a few more samples for their collection.  Not only will that help me prove that my patch is correct, it will help other developers working on SGI movie format support.

It is going to be a bit of a slow process to put together the right test cases and patch, which will then have to be reviewed by the ffmpeg maintainers before making it into libavformat.  But eventually ffmpeg, mplayer, and VLC (and probably others) should all better support SGI format movies.

[jpstewart]

At the moment I'm struggling to navigate the ffmpeg rules concerning patch submission and uploading sample videos and whatnot.  I want to get it right before I submit (rather than getting reprimanded for doing it wrong).  In the interim, here's the patch that fixes the handling of mono vs stereo audio and also adds support for 8 bit audio channels in SGI movie format.

Code:

diff --git a/libavformat/mvdec.c b/libavformat/mvdec.c
index d58281c3a9..fbaf68abaf 100644
--- a/libavformat/mvdec.c
+++ b/libavformat/mvdec.c
@@ -292,6 +292,7 @@ static int mv_read_header(AVFormatContext *avctx)
    AVStream *ast = NULL, *vst = NULL; //initialization to suppress warning
    int version, i;
    int ret;
+   int bytes_per_sample;

    avio_skip(pb, 4);

@@ -340,17 +341,32 @@ static int mv_read_header(AVFormatContext *avctx)
            return AVERROR_INVALIDDATA;
        }
        avpriv_set_pts_info(ast, 33, 1, ast->codecpar->sample_rate);
-       if (set_channels(avctx, ast, avio_rb32(pb)) < 0)
+       bytes_per_sample = avio_rb32(pb);
+       if (bytes_per_sample < 0)
            return AVERROR_INVALIDDATA;

        v = avio_rb32(pb);
        if (v == AUDIO_FORMAT_SIGNED) {
-           ast->codecpar->codec_id = AV_CODEC_ID_PCM_S16BE;
+           switch (bytes_per_sample)
+           {
+           case 1:
+               ast->codecpar->codec_id = AV_CODEC_ID_PCM_S8;
+               break;
+           case 2:
+               ast->codecpar->codec_id = AV_CODEC_ID_PCM_S16BE;
+               break;
+           default:
+               avpriv_request_sample(avctx, "Audio sample size (%i bytes)", bytes_per_sample);
+               break;
+           }
        } else {
            avpriv_request_sample(avctx, "Audio compression (format %i)", v);
        }

-       avio_skip(pb, 12);
+       if (set_channels(avctx, ast, avio_rb32(pb)) < 0)
+           return AVERROR_INVALIDDATA;
+
+       avio_skip(pb, 8);
        var_read_metadata(avctx, "title", 0x80);
        var_read_metadata(avctx, "comment", 0x100);
        avio_skip(pb, 0x80);

Apply that to the ffmpeg/libavformat souces and re-compile, if anyone wants to try it out for themselves before an official build comes along.  And I'll re-iterate that mplayer and VLC both use the same libavformat so they'll also eventually benefit from the improved handling of SGI movie files.

[Raion]

Nice. I will when I get around to ffmpeg again start a backport of this.

[jpstewart]

And two months later, here's another update:

There's still a synchronization problem happening.  It seems to be a cumulative thing:  it is more noticeable at the end of longer movies.  I haven't been able to track that down.  At least not yet. 

"Scope creep" has also derailed me a little.  I should be able to add support for more embedded audio formats easily.  There's a lot of information that can be gleaned by reading the headers in /usr/include/dmedia on on IRIX box.  But at the moment that's just delaying things.

I wanted to submit one patch set to cover all those bases.  That's just not practical.  So for now I've sent (a slightly updated version of) the above bugfix patch to the upstream developers.  It is pending review and will hopefully be included before the next release of FFmpeg.  (Which they are planning for December.)  From there, other projects that use FFmpeg's libavformat (such as MPlayer and VLC) will benefit from the bugfix too.

I'll submit other patches upstream one at a time when I get them working.

[jpstewart]

Next update:  the patch from earlier in the thread was accepted into the FFmpeg codebase as of today.  So the next release (libavformat 59) will have the fixed handling of stereo vs mono and 8-bit support.  (Or anyone building from the git repo has it now.)  Once that happens other projects using the library will also get fixed support when they're updated to use the new library.

And I'm still trying to figure out the timing problem.  Hopefully that gets fixed in time for the next release, but the clock is ticking!

[callahan]

That is amazing! Thank you for the contributions to the community.