It's specific to PPC, it works flawlessly on i386. Thus only a few devs can reproduce it.
Ok, good to know it doesn't happen on i386.
Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0d848c10 0x0168c1e0 in CBaseBitstream::Get1Bit () (gdb) bt #0 0x0168c1e0 in CBaseBitstream::Get1Bit () #1 0x01683fac in Decoder::parseBitStream () #2 0x01670574 in Decoder::Decode () #3 0x01666420 in _RV40toYUV420Transform () #4 0x00079160 in decode (sh=0x130f7d0, data=0x2838c10, len=815, flags=77254656) at vd_realvid.c:341 #5 0x00044880 in decode_video (sh_video=0x430000, start=0x2838c00 "", in_size=815, drop_frame=0) at dec_video.c:311 #6 0x00007380 in main (argc=4128768, argv=0x430000) at mplayer.c: 2346
IIUC this is crashing in the .so, so there is nothing we can do about it. Except maybe try to upgrade to newer version of the .so files that don't have the problem.
I am using the latest version of the .so files, a nightly build (btw, it is not a .so library, but a bundle package, since I am on OS X, but it is similar to linux .so). I am going to contact Real Helix community about this bug, however I am not entirely sure the culprit is not mplayer. As I said, if I extract the file from the matroska container, the crash doesn't happen so obviously the codec does its job. My guess would be that mplayer somehow sends a broken input to the .so codec when mplayer reads from the matroska container. That broken input later leads to a crash in the .so file during decoding, but the inital problem comes from mplayer not sending the correct stream of bytes... Of course, I am no expert on this, it's just a guess. Jean-Noël