| Message |
 |
- Date: 2010-10-15 10:12
- Sender: Nathan Letwory
- Looks like color correction issues nonetheless. Assigning to Campbell for further investigation.
|
- Date: 2010-10-18 01:54
- Sender: Mike Sloman
- Original tests were done with LCMS enabled, repeated with LCMS off and still same incorrect result.
|
- Date: 2010-11-10 20:08
- Sender: Ton Roosendaal
- Assigned to self for later investigation
|
- Date: 2010-11-12 17:22
- Sender: Ton Roosendaal
- 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...
|
- Date: 2010-11-13 00:46
- Sender: Mike Sloman
- 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.
|
- Date: 2010-11-13 05:09
- Sender: Mike Belanger
- 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.
|
- Date: 2010-11-15 17:52
- Sender: Ton Roosendaal
- Can't find anything wrong, but I'm on old 32 bits PPC G5. Maybe Damien can verify.
|
- Date: 2010-11-15 22:26
- Sender: Damien Plisson
- 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...
|
- Date: 2010-11-16 03:03
- Sender: Mike Sloman
- 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.
|
- Date: 2010-11-16 10:22
- Sender: Ton Roosendaal
- Damien: good discovery. Now we need someone to track where in ffmpg code this happens...
|
- Date: 2010-11-18 18:12
- Sender: Ton Roosendaal
- 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 :)
|
- Date: 2010-11-19 03:31
- Sender: Mike Sloman
- 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?
|
- Date: 2010-11-19 11:47
- Sender: Ton Roosendaal
- That's totally weird... but don't use Blender with that change please!
The error is most likely on the ffmpg code side.
|
|
- Date: 2010-11-19 12:32
- Sender: Ton Roosendaal
- 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.
|
- Date: 2010-11-19 19:09
- Sender: jens verwiebe
- 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
|
- Date: 2010-11-19 19:09
- Sender: jens verwiebe
- 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
|
- Date: 2010-11-19 20:04
- Sender: jens verwiebe
- I recompiled now ffmpeg 0.6 for a test and got correct outputs !
More later...
Jens
|
- Date: 2010-11-19 20:28
- Sender: Damien Plisson
- 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!
|
- Date: 2010-11-19 22:34
- Sender: jens verwiebe
- 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
|
- Date: 2010-11-20 13:41
- Sender: jens verwiebe
- @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
|
- Date: 2010-11-21 10:42
- Sender: Damien Plisson
- 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
|
- Date: 2010-11-24 18:38
- Sender: Damien Plisson
- 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.
|
- Date: 2010-11-24 20:07
- Sender: Ton Roosendaal
- I've never managed to build ffmpg here anyway, i'm fine with closing it, and not release ppc versions with ffmpg.
|
