Looks like color correction issues nonetheless. Assigning to Campbell for further investigation.

Original tests were done with LCMS enabled, repeated with LCMS off and still same incorrect result.

Assigned to self for later investigation

No issue with 2.55 released or current svn, osx 10.5 G5.

Your report seems to be related to own builds, did you test binary from blender.org? I can only imagine something in your setup or binary went bad...

This also happens on other build not done by myself. In the past (cant be sure when exactly but a few months) using H264 etc worked fine on my builds and those downloaded.

Blender 2.55 beta release for Intel OSX 64 bit r32738 (downloaded from the blender downloads page) does this too. As well as numerous builds from graphicall.

This behaviour has not changed for some time and is the same after recent OS update to 10.6.5.

Attaching log of the 2.55beta official release doing a h264 with quicktime container run that produces bad results.

One thing I note is that "coder vlc" is on the first setup line.. Preset RenderSettings.file_format used was "H264" and manually changed container from AVI to Quicktime.

I also did the same test with released Intel 10.4 32 bit build and same bad results. (default AVI instead of quicktime container though)

The output files play equally bad in 2.49b, quicktime player and VLC.

I've tried this with H.264 codec as well. It generates the same colour issues.
I'm on OS X 10.6.4, using the ffmpeg svn from 33044.

I've used the .avi and the .mkv containers too, if that's relevant.

Can't find anything wrong, but I'm on old 32 bits PPC G5. Maybe Damien can verify.

Mike: you're using ffmpeg to produce your quicktime movie, as you are running Blender on a Mac, use Quicktime instead. You'll be able to select the codec afterwards (e.g. H264).
The output format selection menu can be misleading as ffmpeg presets are present there without stating it is ffmpeg.
I don't have the issue using quicktime with the H264 codec.

Ton: This is a ffmpeg issue, not a quicktime one. I won't be of much help here...

Damien: yes thanks for reminding me... quicktime works correctly and can be used for some applications.

ffmpeg used to work and has other codecs that quicktime does not have free to use. mpeg1/2, Theora and flash for example. XVID also broken although of not much practical use these days.

BTW 249b FFMPEG outputs still work fine so its no OS related.

Damien: good discovery. Now we need someone to track where in ffmpg code this happens...

Damien: the only suspicious Blender code i can find for this color issue is related to ENDIAN_ORDER

blenkernel/intern/blender.c:122
blenkernel/intern/writeffmpg.c:330

Could you check if the endianess is somehow incorrect? Just enforce the other type to check :)

Hi Ton,

Indeed changing: blenkernel/intern/blender.c:121

ENDIAN_ORDER= 0; (from 1)

does produce correct output from FFMPEG.

Does this mean we need some ifdef PPC/Intel here?

That's totally weird... but don't use Blender with that change please!
The error is most likely on the ffmpg code side.

FYI, another person having Mac endian issues:
http://www.hackerfactor.com/blog/index.php?/archives/300-Ten-Little-Endians.html

Jens is looking into it now, it appears our ffmpg for macs uses wrong endian

Damien: Jens said he sent you ffmpg libs for svn, but it appears you committed your own compiled version.
From the information I have, the ffmpg compile system defines endianess in config stage, not in compile stage.

Damien, i rechecked you compileflags and can´t find any wrong
things. You remade them all single-arch and glued , right ?

Perhaps an issue in the used ffmpeg rev ?


Jens

Damien, i rechecked you compileflags and can´t find any wrong
things. You remade them all single-arch and glued , right ?

Perhaps an issue in the used ffmpeg rev ?


Jens

I recompiled now ffmpeg 0.6 for a test and got correct outputs !
More later...


Jens

Jens, yes, I did it single arch and lipoed them after.
The config/build commands are the ones in the README file at the root of the libs folder, and I think that's the one you checked.

Thanks for your investigation!

I recompiled all 64bit new now, works o.k. as far as i tested.

Get it here:

http://www.jensverwiebe.de/Blender/ffmpeg_OSX_x86_64_repeaired.zip

You can extract x86_64 from old libs and reglue the new simply.

I changed the following in ogg:

FFMPG_REDO/libogg-1.2.1/include/ogg/os_types.h
69,76d68
< #elif (defined(__APPLE__) && defined(__MACH__)) /* MacOS X Framework build */
<
< # include <inttypes.h>
< typedef int16_t ogg_int16_t;
< typedef u_int16_t ogg_uint16_t;
< typedef int32_t ogg_int32_t;
< typedef u_int32_t ogg_uint32_t;
< typedef int64_t ogg_int64_t;

to get it compile, so it uses thus the upper typedevs:

#elif defined(__MACOS__)

# include <sys/types.h>
typedef SInt16 ogg_int16_t;
typedef UInt16 ogg_uint16_t;
typedef SInt32 ogg_int32_t;
typedef UInt32 ogg_uint32_t;
typedef SInt64 ogg_int64_t;


Jens

@Damien
used versions:
ffmpeg (version 0.6)
ogg (version 1.2.1)
vorbis (version 1.3.2)
theora (version 1.1.1)
flac (1.2.1)
sndfile (version 1.0.21)
lame (version 3.98.4)
xvidcore (version 1.2.2)
x264 (snapshot-20101118-2245)

For compile i reused exacly your flags, just compiled all
to a tempdir for investigation.

Jens

Yes, the problem was with the libs, and especially x264.
Jens: you got it working by using a more recent x264 lib, the one I initially used was faulty. I've committed your version (20101118). Thanks for the work.

I've also updated ogg(1.2.1), vorbis (1.3.2), and ffmpeg(0.6.1). And the colors are ok.

Committed in svn #33208 for 10.5 libs.
Still need to rebuild the 10.4 builds to close this bug

Committed the 10.4 i386 libs that fix the bug in svn #33293.
The ppc libs (same x264 version) still have the bug... I'll check with a more recent version, but fear ppc is no more supported by x264 people.

I've never managed to build ffmpg here anyway, i'm fine with closing it, and not release ppc versions with ffmpg.