Hi,
Has there been any movement regarding endian issues in Kino? Are there any patches I can try to clean some up, or perhaps test?
Daniel Kobras wrote:
Moi!
I've received a bug report (quoted below) by a Debian user about multiple endianness issues when trying to use kino on a powerpc system. As I don't have a Linux/ppc desktop available any longer these days, I'd like to ask for your help on resolving these problems.
As for the inverted colours when using Xv display, this might be related to an Xv bug we discussed on the libdv-dev mailing list back in june 2002 ("Should dv1394 work on PPC" - are there still mail archives around that work and don't suck?).
Looking at the source code, I've already confirmed the source of the audio problems. WAV export in kino_av_pipe indeed is not endian-clean. Fixing the header will be easy, preferrably using the endian_types.h header I've been pimping on this list for a while. But I'm not so sure about the audio data itself. Specifically, I wonder whether its endianness might be different, depending on whether it's imported from a file, or via ieee1394? In any case, the various Resample methods in frame.cc look like the best place to take care of endianness conversions as well. Also, is PCM output always supposed to be in little-endian format like WAV, or can we stick with native endianness there?
As far as the problems with video encoding are concerned, I'm hoping on input from you. I don't know how endianness is spec'ed in the various video formats. Maybe we can even get away with adding the proper command-line switches to the external export filters?
Regards,
Daniel.
----- Forwarded message from Michael Schmitz <[EMAIL PROTECTED]> -----
From: Michael Schmitz <[EMAIL PROTECTED]> Date: Fri, 7 Jan 2005 18:37:52 +0100 (CET) To: [EMAIL PROTECTED] Reply-To: Michael Schmitz <[EMAIL PROTECTED]>, [EMAIL PROTECTED] Subject: Bug#289182: kino endianness issues on powerpc
Package: kino Version: 0.75-2 Severity: serious
kino appears to have multiple issues with data endianness on powerpc.
Symptoms:
Video display: fine when using GDK, reverse video (or rather: magenta on cyan) when using XV for display in the edit and trim menus. Audio in edit/trim mode is fine BTW (see audio problems below).
Video export: when using the MPEG export with mjpegtools 1.6.2-0.7 (built from source from Christian Marillat's site), mp2enc fails to produce output with a message like
EOF in WAV header when searching for tag "data"
The resulting .mpv file shows the same reverse video effects as the XV display in edit/trim mode.
Audio export: Exporting to WAV format directly results in audio data that can't be used with mp2enc, while exporting to WAV format using sox generates correct data (feeding such data to the MPEG encode process results in reverse video, correct audio files).
Using ffmpeg (20041227-0.1, built from source from Christian Marillat's site as well), exporting as DivX or DVD results in correct color video, while the audio stream is loud noise. Verbose output in ffmpeg shows audio format detection as pcm_s16le. Suspecting an endianness bug here, I've hacked ffmpeg to decode pcm 16 bit data as big endian regardless of detected data type, which gives perfect audio encoding in DivX or DVD exports.
I suspect kino declares BE audio data to be LE in the DV export (or indeed any) pipe. No idea what's the cause of the XV and mpeg2enc endianness problems though.
HTH,
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
