Monthly Archives: August 2008

JavaFX and On2 TrueMotion

Have you heard of Sun’s JavaFX? It’s due out later this year and is allegedly positioned to compete in the RIA space. It might be pertinent to mention that I work on a competing technology. Anyway, the reason I bring this up is that I recently learned that On2 is reported to be supplying JavaFX with video codec technology. According to “Sun Adds Comprehensive Video Capabilities to Ubiquitous Java Platform with On2 Technologies,” Sun licensed On2’s “TrueMotion” codec. I’m not entirely sure what codec they’re talking about and I can’t quite find any solid details. On2’s site seems to classify TrueMotion as encompassing both VP6 and VP7. I’m always surprised to hear the name TrueMotion since I thought that went away after the Duck Corporation morphed into On2. But the VP* series seems to be interchangeable with TrueMotion, just for extra confusion.

Who knows? Maybe they actually are using the classic Duck TrueMotion video codec in JavaFX.

Curiously, there is no word on what JavaFX will use for audio. Maybe logarithmic PCM in au/snd files?

200 FATE Tests

FATE just hit 200 individual test specs. I added a bunch of new H.264 tests that Michael has recently fixed. FFmpeg now perfectly decodes 115/136 of the base H.264 conformance vectors (and a bunch of the extended vectors as well, but I still haven’t gotten to those yet).

Thanks again to Suxen Drol for working on the Electronic Arts family of FMV formats. Thanks to his efforts, FFmpeg can now decode DCT files such as the ones found in Need for Speed II for the PlayStation:


Need 4 Speed -- Jaguar

The file has to come from the Sony PlayStation version since DCT files contain data that is designed to be fed directly into the PS1’s Motion Decoder hardware.

Also, Suxel drol wrote the video decoder for the TGV format, most notably used for FMV in the Origin game Privateer 2: The Darkening:


Privateer 2: The Darkening

gcc Heisenbug

In my last post, when I endeavored to enter a gcc bug regarding the internal compiler error when compiling FFmpeg on PPC, I could not reproduce the problem when I separated the compiler from ccache. I finally got, umm, lucky when the FFmpeg tree got into a state when the compiler threw the error without ccache’s involvement.

So I followed the steps outlined for a proper, useful bug reporting page, as listed on gcc’s bug reporting page. I added the -save-temps option to the command line…

…and the compiler no longer crashes.

The term here is Heisenbug.

Anyway, I have finally entered a bug in order to start tracking this issue.

ccache Makes gcc Crash

Well this is mildly disconcerting: ccache can make gcc crash. Now, I am the first person to extol the virtues of ccache; the tool dramatically decreases the amount of time that the FATE farm has to spend rebuilding FFmpeg. But the crash is quite reproducible.

If you have kept up with FATE for any length of time, you know that there is a chronic problem with compiling FFmpeg using SVN versions of gcc on PowerPC — in particular, the build phase tends to crash with an internal compiler error. Last night, I upgraded the gcc-SVN compilers on all the FATE machines. Tonight, I was determined to sit down and finally go through all the steps to submit the highest quality gcc bug report I could. I thought it would be prudent to report the full command line without the ccache command. Wouldn’t you know, the problem file compiles fine. From there, it takes over 20 minutes instead under 5 to compile the whole tree. Running the FATE test suite also passes with flying colors.

So there’s a bug here. Where do you think the problem lies? ccache or gcc? I have a bad feeling that this is the kind of problem both camps are likely to blame on the other. All I know is that the following command:

$ /usr/bin/ccache /usr/local/gcc-138544-20080801/bin/gcc -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I. -I”/home/melanson/ffmpeg/ffmpeg-main” -fomit-frame-pointer -maltivec -mabi=altivec -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -O3 -fno-math-errno -fno-signed-zeros -fPIC -DPIC -c -o libavcodec/imc.o /home/melanson/ffmpeg/ffmpeg-main/libavcodec/imc.c

yields the output:

/home/melanson/ffmpeg/ffmpeg-main/libavcodec/imc.c: In function ‘imc_decode_init’:
/home/melanson/ffmpeg/ffmpeg-main/libavcodec/imc.c:146: warning: assignment from incompatible pointer type
/home/melanson/ffmpeg/ffmpeg-main/libavcodec/imc.c: In function ‘imc_decode_frame’:
/home/melanson/ffmpeg/ffmpeg-main/libavcodec/imc.c:808: internal compiler error: in tree_node_structure, at tree.c:2412
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.

Removing the prepended /usr/bin/ccache command makes the internal compiler error go away. For the time being, I have removed ccache, but only from the problematic FATE configuration. The PowerPC machine will not be nearly as efficient at performing FATE work, but at least it will keep abreast of gcc-SVN changes.

Update, 2008-08-05: Great news: Recent revisions of FFmpeg have been causing the gcc-SVN copy for PPC crash, and without ccache. It looks like I will be able to pin this on gcc after all.

Followup: