[MEncoder-users] msmpegv4 vs msmpeg

[The Wanderer]

srdan bejakovic wrote:

> On Wed, Jul 23, 2008 at 6:43 AM, The Wanderer
> <inverseparadox at comcast.net>wrote:
> 
>>> I haven't been able to compile ffmpeg separately so I don't know
>>> what it would say.
>> 
>> That's not good either. What kind of problem was it? (Based on the
>> below, there's a chance that this might even be relevant to the
>> MPlayer problem...)
> 
> A bunch of errors of the following form, all from the same file:
> 
> libavdevice/alldevices.c:41: error: `ENABLE_AUDIO_BEOS_MUXER'
> undeclared (first use in this function)

That sounds like either bad configuration options or, more likely, a
problem with the build system.

What FFmpeg version?

What configure options did you use?

>>> I did download the windows compiled distribution of mplayer, and
>>> mencoder handled the avi just fine, and mplayer opened it and
>>> displayed it also.
>> 
>> That probably (but not definitely) means that there's something
>> wrong with your copy of MPlayer.
>> 
>> Does this happen with every input file (AVI or otherwise), or just
>> with a particular file or group of files?
> 
> I tried some mpeg-1 files and it worked fine. I tried a quicktime mp4
> video and it played on windows but not under Solaris. I couldn't find
> any other files with the same encoding as the files that are giving
> me trouble (ms mpeg4 v2), so I don't know how those would behave.

The encoding is, almost certainly, not the issue. The failure is
happening while trying to identify what container format the file is,
and the codec is not even checked on until after that identification.

>> Off the top of my head, just try adding a few '-v' options to the
>> MPlayer command line, and see what - if any - additional
>> information it provides. If that doesn't work, we'll probably have
>> to go back and see what's going on with your compilation setup.
> 
> Here is the output under Windows and under Solaris with the -v flag
> for the files that are giving me trouble.

Unfortunately, this isn't enough information - I said "a few 'v'
options", because more than one increases the verbosity level further.
For this purpose I would (if investigating such a file myself) probably
want at least three. The interesting information would probably

> Windows finds the mpeg4v2 codec, but Solaris doesn't. Is there maybe
> some configuration option that handles this?

In theory yes, but it's probably just a matter of exactly which version
of MPlayer is involved and exactly what was available when it was
compiled.

I'm running out of immediate ideas (that is, without having a sample of
the broken files on hand to play around with), but one guess at a
suggestion:

> Found movie at 0x800 - 0x12882A
> Reading INDEX block, 100 chunks for 1677721600 frames (fpos=1214514).
> stream_seek: WARNING! Can't seek to 0x8040E44E !

How big is this AVI file? This is trying to seek to a little over 2GB,
and failing. If the file is not actually that big, you may have a bad or
otherwise broken index; if that is the case, the '-forceidx' option may
help.

Also, are the two attempts on the two different OSes with the same input
file? They are reporting very different things about the file, and if
they are getting their data from the same source then something is very
broken indeed.

I would be interested to get my hands on a copy of a file with this
problem (a truncated sample big enough to exhibit the problem would be
good enough), but at this point, the next practical step would most
likely be to go back and recompile, looking at each step to make sure
nothing obviously odd is happening.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.