if /bin/sh ../../libtool --mode=compile powerpc64-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -D_REENTRANT -DMOD_PATH=\"/usr/lib64/transcode\" -I../.. -I../../import -I../../src -Wall -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -pipe -mcpu=970 -mtune=970 -U__ALTIVEC__ -DDCT_YUV_PRECISION=1 -MT rtjpeg_aud_plugin.lo -MD -MP -MF ".deps/rtjpeg_aud_plugin.Tpo" -c -o rtjpeg_aud_plugin.lo rtjpeg_aud_plugin.c; \ then mv -f ".deps/rtjpeg_aud_plugin.Tpo" ".deps/rtjpeg_aud_plugin.Plo"; else rm -f ".deps/rtjpeg_aud_plugin.Tpo"; exit 1; fi powerpc64-unknown-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I../.. -D_REENTRANT -DMOD_PATH=\"/usr/lib64/transcode\" -I../.. -I../../import -I../../src -Wall -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -pipe -mcpu=970 -mtune=970 -U__ALTIVEC__ -DDCT_YUV_PRECISION=1 -MT rtjpeg_aud_plugin.lo -MD -MP -MF .deps/rtjpeg_aud_plugin.Tpo -c rtjpeg_aud_plugin.c -fPIC -DPIC -o .libs/rtjpeg_aud_plugin.o In file included from /usr/include/asm/elf.h:5, from /usr/include/asm/sigcontext.h:12, from /usr/include/bits/sigcontext.h:28, from /usr/include/signal.h:333, from ../../src/transcode.h:47, from rtjpeg_aud_plugin.c:61: /usr/include/asm/types.h:36: error: conflicting types for '__s32' RTjpegN.h:32: error: previous declaration of '__s32' was here /usr/include/asm/types.h:37: error: conflicting types for '__u32' RTjpegN.h:28: error: previous declaration of '__u32' was here /usr/include/asm/types.h:41: error: conflicting types for '__u64' RTjpegN.h:29: error: previous declaration of '__u64' was here make: *** [rtjpeg_aud_plugin.lo] Error 1 [ebuild U ] media-video/transcode-1.0.4 [1.0.3] USE="X a52 altivec dv dvdread iconv imagemagick jpeg lzo mjpeg mp3 mpeg ogg quicktime sdl theora truetype vorbis xml xvid (-3dnow) -extrafilters -fame (-mmx) -network -oss% (-sse) (-sse2) -v4l2 (-gtk%)" 0 kB I'll try to attach/commit a patch asap
in fact, just the same as bug #93797 any clue why the patch has been dropped / not upstreamed ?
http://www.itdp.de/transcode-users/2006-07/msg00061.html
oh.. a comment would be good I think: that's the thread showing that I've posted the patch upstream. they rejected it. I don't know why it was dropped from the ebuild though.
(In reply to comment #3) > oh.. a comment would be good I think: that's the thread showing that I've > posted the patch upstream. they rejected it. > > I don't know why it was dropped from the ebuild though. > Thanks for the info. The problem seems more serious than a build failure on ppc64 though : grabbing samples from http://samples.mplayerhq.hu/nuv/ On x86 (chroot from amd64) : transcode -i nirvana.nuv -o foo.mjpeg -y mjpeg,null transcode v1.0.4 (C) 2001-2003 Thomas Oestreich, 2003-2004 T. Bitterberg, 2004-2007 Transcode Team (dvd_reader.c) no support for DVD reading configured - exit. [transcode] (probe) suggested AV correction -D 0 (0 ms) | AV 0 ms | 0 ms [transcode] auto-probing source nirvana.nuv (ok) [transcode] V: import format | RTjpeg NuppelVideo (V=nuv|A=nuv) [transcode] V: import frame | 352x288 1.22:1 [transcode] V: bits/pixel | 0.710 [transcode] V: decoding fps,frc | 25.000,0 [transcode] V: Y'CbCr | YV12/I420 [transcode] A: import format | 0x1 PCM [44100,16,2] [transcode] A: export | disabled [transcode] V: encoding fps,frc | 25.000,3 [transcode] A: bytes per frame | 7056 (7056.000000) [transcode] A: adjustment | 0@1000 [transcode] V: IA32/AMD64 accel | sse2 (sse2 sse 3dnowext 3dnow mmxext mmx asm C) tc_memcpy: using sse for memcpy [transcode] V: video buffer | 10 @ 352x288 [import_nuv.so] v0.1.2 (2002-08-01) (video) YUV | (audio) PCM [export_null.so] v0.1.2 (2001-08-17) (video) null | (audio) null [export_mjpeg.so] v0.0.5 (2003-07-24) (video) Motion JPEG | (audio) MPEG/AC3/PCM [import_nuv.so] effdsp=43947 0 encoding frames [000000-000268], 79.88 fps, EMT: 0:00:10, ( 0| 0| 0) clean up | frame threads | unload modules | cancel signal | internal threads | done [transcode] encoded 269 frames (0 dropped, 0 cloned), clip length 10.76 s produced file is ok on amd64: transcode -i nirvana.nuv -o foo.mjpeg -y mjpeg,null transcode v1.0.4 (C) 2001-2003 Thomas Oestreich, 2003-2004 T. Bitterberg, 2004-2007 Transcode Team [transcode] (probe) suggested AV correction -D 0 (0 ms) | AV 0 ms | 0 ms [transcode] auto-probing source nirvana.nuv (ok) [transcode] V: import format | RTjpeg NuppelVideo (V=nuv|A=nuv) [transcode] V: import frame | 352x288 1.22:1 [transcode] V: bits/pixel | 0.710 [transcode] V: decoding fps,frc | 25.000,0 [transcode] V: Y'CbCr | YV12/I420 [transcode] A: import format | 0x1 PCM [44100,16,2] [transcode] A: export | disabled [transcode] V: encoding fps,frc | 25.000,3 [transcode] A: bytes per frame | 7056 (7056.000000) [transcode] A: adjustment | 0@1000 [transcode] V: IA32/AMD64 accel | sse2 (sse2 sse 3dnowext 3dnow mmxext mmx asm C) tc_memcpy: using amd64 for memcpy [transcode] V: video buffer | 10 @ 352x288 [import_nuv.so] v0.1.2 (2002-08-01) (video) YUV | (audio) PCM [export_null.so] v0.1.2 (2001-08-17) (video) null | (audio) null [export_mjpeg.so] v0.0.5 (2003-07-24) (video) Motion JPEG | (audio) MPEG/AC3/PCM [import_nuv.so] effdsp=43947 0 Segmentation fault basic debugging shows : (gdb) bt #0 0x00002aaaab75349a in RTjpeg_idct_init () from /usr/lib64/transcode/import_nuv.so #1 0x00002aaaab75b4a4 in rtjpeg_vid_open () from /usr/lib64/transcode/import_nuv.so #2 0x00002aaaab7564c9 in tc_import () from /usr/lib64/transcode/import_nuv.so #3 0x0000000000418362 in tcv_import () #4 0x00000000004166e5 in import_open () #5 0x000000000041226e in main () so I suppose nuv import plugin is broken there. on ppc64, I had an 'invalid data' or something, transcode refused to open the nuv file. upstream's reason for rejecting the patch are understandable, but as of now, it seems only x86 can use nuv demuxer :/
Forgot to mention : x86 and am64 tests were made without the dropped patch, ppc64 with it. Readding the types patch gives me that on amd64 : transcode -i nirvana.nuv -o foo.mjpeg -y mjpeg,null transcode v1.0.4 (C) 2001-2003 Thomas Oestreich, 2003-2004 T. Bitterberg, 2004-2007 Transcode Team [transcode] (probe) suggested AV correction -D 0 (0 ms) | AV 0 ms | 0 ms [transcode] auto-probing source nirvana.nuv (ok) [transcode] V: import format | RTjpeg NuppelVideo (V=nuv|A=nuv) [transcode] V: import frame | 352x288 1.22:1 [transcode] V: bits/pixel | 0.710 [transcode] V: decoding fps,frc | 25.000,0 [transcode] V: Y'CbCr | YV12/I420 [transcode] A: import format | 0x1 PCM [44100,16,2] [transcode] A: export | disabled [transcode] V: encoding fps,frc | 25.000,3 [transcode] A: bytes per frame | 7056 (7056.000000) [transcode] A: adjustment | 0@1000 [transcode] V: IA32/AMD64 accel | sse2 (sse2 sse 3dnowext 3dnow mmxext mmx asm C) tc_memcpy: using amd64 for memcpy [transcode] V: video buffer | 10 @ 352x288 [import_nuv.so] v0.1.2 (2002-08-01) (video) YUV | (audio) PCM [export_null.so] v0.1.2 (2001-08-17) (video) null | (audio) null [export_mjpeg.so] v0.0.5 (2003-07-24) (video) Motion JPEG | (audio) MPEG/AC3/PCM [import_nuv.so] effdsp=43947 0 (null): resample: Can not handle this sample rate change. Nx not positive: 1160528863 so the patch probably needs to be polished a bit :/
1.0.5 fixes this, there is that in configure.in: if test x"$have_x86cpu" = x"false" ; then force_nuv_off=yes iirc I read on upstream ml's that it failed on debian sid amd64 so they disabled it on anything but x86
transcode 1.0.5 at least builds unlike 1.0.4. When will this be stable?
