[FFmpeg-user] ffplay and mpeg1video files

[Carl Eugen Hoyos]

Robert A. Schmied <ras <at> acm.org> writes:

> i also suspect there are problems with the build using sunpro c.

That is what I tried to tell you.
(Sorry if I was unclear.)

> as far as reporting compilation problems -- the ffmpeg changes
> were specifically related to my atypical environment, platform
> and for sunpro c 5.8. if you really think they are useful
> i will rollup a set of diffs.

I don't see anything atypical about using sunpro, 
FFmpeg supports a large range of compilers != gcc, 
see http://fate.ffmpeg.org/ for some.

The problem I see is that these patches imo only 
make sense if compilation actually succeeds (that 
includes the fate tests), if it does not succeed 
I would personally prefer a patch that makes 
configure fail for a compiler that is known to 
be broken (but that is only imo).

> the files and very brief description of change:

Sorry, but the description is really too brief!

>   ./libavutil/mem.h -- 
> #elif conditional defined(__SUNPRO_C) && __SUNPRO_C <= 0x580

(Does this indicate there is a sunpro version 
that works fine?)

>   ./libavformat/nsvdec.c -- 
> #if conditional #define __FUNCTION__ __func__

>   ./configure -- hashbang line change; 

Fix your PATH instead.

> -G not -shared if enabled suncc

Please start with "./configure && make"
(if I guess correctly)

> i tried the (g)make commands, got these results:
> %    /usr/local/bin/gmake  SAMPLES=fate fate-rsync |& tee gmake-fate.log
> rsync -vaLW --timeout=60 
> --contimeout=60 rsync://fate-suite.ffmpeg.org/fate-suite/ fate
> rsync: --contimeout=60: unknown option

To the best of my knowledge, this has been fixed, could 
you post your version hash?

> right about here i ran out of space on the build partition
> -- is there a way to conserve or reclaim disk space automatically?

(The first two characters of above line are bad: 
The make some mailers not quote the rest of your mail 
because they assume your signature starts here.)

No, you unfortunately need a lot of empty space to run 
the regression tests, if you want to work on this, 
you will need them.

To explain what you would have to do (I did it in the past 
for icc):
You find the failing codecs by running the regression tests.
You use a known-to-work version of FFmpeg (on another 
system if necessary) to find out if it is a decoder or 
encoder problem (if the failure does not happen for 
the downloaded samples but for the artificial samples as 
in your case).
You locate the file that defines the failing encoder or 
decoder.
You recompile the file with -O2, -O1, -O0 to find out if 
it is an optimisation problem (it nearly always is).
You report the bug to Sun / the provider of the compiler.

> my plan is to start over with fresh, unchanged ffmpeg-1.0.1 and

Use git head, a patch against 1.0 to add compilation 
support for a previously unsupported platform would 
probably not be accepted.
(And for users, current git head is always strongly 
recommended.)

> configure for gcc 3.4.3 ... but i'm thinking it (gcc) is 
> way too old.

Yes, but it will be much easier to work-around its problems;-)

Carl Eugen