Bug#289182: kino endianness issues on powerpc
> On Fri, Mar 25, 2005 at 01:38:27AM +0100, Daniel Kobras wrote: > > On Tue, Mar 22, 2005 at 08:36:01PM +, Paul Brossier wrote: > > > there is probably a better mean to do so though, ie checking what > > > type of conversion is needed according to libavcodec, but it does > > > effectively fixes the XV Display of kino. > > > > Actually, we should probably check the value of component_order[] in the > > struct returned by XvListImageFormats() and shuffle components as > > appropriate, but from the feedback so far, apparently nowadays it is > > sufficient to keep the order of YUV components fixed, independent of > > host arch. I've attached a patch to this effect, and would welcome > > feedback from testers. > > it works perfectly on powerpc, a much nicer solution indeed. and > the first patch was wrong, the image was slightly more redish. Entirely possible; I hacked the original patch based on my limited understanding of YUV encoding, using a perhaps flawed piece of code from a yet earlier patch. It was enough to convice me there's some missing endianness adjustment, and to make the display bearable. > > > audio seems to work better now. there are a few glitches but at > > > least it's not white noise. oh and export to mpeg2 and wav bot > > > work. > > > > Great. We're getting closer, it seems. Does the video part of mpeg2 > > export also work correctly now? > > oh yes, very well. and the video filters too. Great, thanks for testing this (and sorry I didn't report any test results - simply didn't get around to do more video editing yet). Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289182: kino endianness issues on powerpc
On Fri, Mar 25, 2005 at 02:26:41AM +, Paul Brossier wrote: > On Fri, Mar 25, 2005 at 01:38:27AM +0100, Daniel Kobras wrote: > it works perfectly on powerpc, a much nicer solution indeed. and > the first patch was wrong, the image was slightly more redish. > > > Great. We're getting closer, it seems. Does the video part of mpeg2 > > export also work correctly now? > > oh yes, very well. and the video filters too. Very good! I've just uploaded 0.75-6 that should finally address all problems in this bug report. Thanks for testing! Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289182: kino endianness issues on powerpc
On Fri, Mar 25, 2005 at 01:38:27AM +0100, Daniel Kobras wrote: > On Tue, Mar 22, 2005 at 08:36:01PM +, Paul Brossier wrote: > > there is probably a better mean to do so though, ie checking what > > type of conversion is needed according to libavcodec, but it does > > effectively fixes the XV Display of kino. > > Actually, we should probably check the value of component_order[] in the > struct returned by XvListImageFormats() and shuffle components as > appropriate, but from the feedback so far, apparently nowadays it is > sufficient to keep the order of YUV components fixed, independent of > host arch. I've attached a patch to this effect, and would welcome > feedback from testers. it works perfectly on powerpc, a much nicer solution indeed. and the first patch was wrong, the image was slightly more redish. > > audio seems to work better now. there are a few glitches but at > > least it's not white noise. oh and export to mpeg2 and wav bot > > work. > > Great. We're getting closer, it seems. Does the video part of mpeg2 > export also work correctly now? oh yes, very well. and the video filters too. bye, paul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289182: kino endianness issues on powerpc
On Tue, Mar 22, 2005 at 08:36:01PM +, Paul Brossier wrote:
> On Tue, Mar 08, 2005 at 03:39:16PM +0100, Daniel Kobras wrote:
> > Furthermore, it looks obviously buggy. Eg. the little-endian
> > version of the first loop uses values Y[0] and Y[1], while the
> > big-endian variant reuses Y[0] twice. And I can't make sense of
> > the other array indices, either. I was expecting something like
> > dest_big_endian = bswap_32(dest_little_endian); maybe that's
> > what was intended, and the current version of the patch makes
> > little difference with smooth input data?
>
> well, i am not familiar with these maths, but it does look like
> there's some logic:
>
> LE -> BE
>
> Cr[0] << 24 -> Cr[0]
> Y [1] << 16 -> Y [0] << 8
> Cb[0] << 8 -> Cb[1] << 16
> Y [0]-> Y [0] << 24
Certainly, but as I noted before, this logic is flawed, incorrectly
reusing an old luminance value and shifting the blue component by one
pixel. (In a smooth image, artifacts might be small, though.)
> there is probably a better mean to do so though, ie checking what
> type of conversion is needed according to libavcodec, but it does
> effectively fixes the XV Display of kino.
Actually, we should probably check the value of component_order[] in the
struct returned by XvListImageFormats() and shuffle components as
appropriate, but from the feedback so far, apparently nowadays it is
sufficient to keep the order of YUV components fixed, independent of
host arch. I've attached a patch to this effect, and would welcome
feedback from testers.
> audio seems to work better now. there are a few glitches but at
> least it's not white noise. oh and export to mpeg2 and wav bot
> work.
Great. We're getting closer, it seems. Does the video part of mpeg2
export also work correctly now?
Paul, thanks a lot for looking into this issue!
Regards,
Daniel.
#! /bin/sh /usr/share/dpatch/dpatch-run
## 40_yuvdisplay_endian_fixes.dpatch by Daniel Kobras <[EMAIL PROTECTED]>
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: Always unroll YUV formats in same order, independent of host
## DP: endianness.
@DPATCH@
diff -urNad kino/src/frame.cc /tmp/dpep.thGYPG/kino/src/frame.cc
--- kino/src/frame.cc 2005-03-25 00:52:58.0 +0100
+++ /tmp/dpep.thGYPG/kino/src/frame.cc 2005-03-25 00:57:04.0 +0100
@@ -1052,12 +1052,10 @@
for ( int x = 0; x < width; x += 2 )
{
- *reinterpret_cast( dest ) = Y[ 0 ] +
( Cb[ 0 ] << 8 ) + ( Y[ 1 ] << 16 ) + ( Cr[ 0 ] << 24 );
-
- dest += 4;
- Y += 2;
- ++Cb;
- ++Cr;
+ *dest++ = *Y++;
+ *dest++ = *Cb++;
+ *dest++ = *Y++;
+ *dest++ = *Cr++;
}
}
}
@@ -1071,13 +1069,14 @@
for ( int x = 0; x < width; x += 4 )
{
- *reinterpret_cast( dest ) = Y[ 0 ] +
( Cb[ 0 ] << 8 ) + ( Y[ 1 ] << 16 ) + ( Cr[ 0 ] << 24 );
- *reinterpret_cast( dest + 4 ) = Y[ 2
] + ( Cb[ 0 ] << 8 ) + ( Y[ 3 ] << 16 ) + ( Cr[ 0 ] << 24 );
-
- dest += 8;
- Y += 4;
- ++Cb;
- ++Cr;
+ *dest++ = *Y++;
+ *dest++ = *Cb;
+ *dest++ = *Y++;
+ *dest++ = *Cr;
+ *dest++ = *Y++;
+ *dest++ = *Cb++;
+ *dest++ = *Y++;
+ *dest++ = *Cr++;
}
}
}
Bug#289182: kino endianness issues on powerpc
Hi,
On Tue, Mar 08, 2005 at 03:39:16PM +0100, Daniel Kobras wrote:
> On Mon, Feb 14, 2005 at 05:41:26PM +0100, Michael Schmitz wrote:
> > I can confirm the XV problem is the same old problem that a patch had
> > been posted for in http://jira.schirmacher.de/jira-kino/browse/KINO-76.
> > I've added some #ifdef __BIG_ENDIAN__ around that, the following patch
> > should finally fix the display issue:
> Err, this patch did fix the display problems for you!? It does
> not touch a single line of code that was executed in the Debian
> build that uses libdv to do the decoding. (Actually, this is no
> longer true as of today. Now with ffmpeg in main, I've
> uploaded a new version that uses libavcodec instead of libdv
> for the decoding part.)
mmh, after testing the patch, it does look much better with :)
> Furthermore, it looks obviously buggy. Eg. the little-endian
> version of the first loop uses values Y[0] and Y[1], while the
> big-endian variant reuses Y[0] twice. And I can't make sense of
> the other array indices, either. I was expecting something like
> dest_big_endian = bswap_32(dest_little_endian); maybe that's
> what was intended, and the current version of the patch makes
> little difference with smooth input data?
well, i am not familiar with these maths, but it does look like
there's some logic:
LE -> BE
Cr[0] << 24 -> Cr[0]
Y [1] << 16 -> Y [0] << 8
Cb[0] << 8 -> Cb[1] << 16
Y [0]-> Y [0] << 24
and for the third line (dest + 4)
Y [2]-> Y [0] << 24
Cb[0] << 8 -> Cb[3] << 16
Y [3] << 16 -> Y [0] << 8
Cr[0] << 24 -> Cr[2]
there is probably a better mean to do so though, ie checking what
type of conversion is needed according to libavcodec, but it does
effectively fixes the XV Display of kino.
> > --- src/frame.cc.org2005-02-14 16:59:13.798585200 +0100
> > +++ src/frame.cc2005-02-14 17:14:01.196680184 +0100
attached is and updated patch to go in debian/patches
> I've uploaded kino 0.75-5 that should make the archive by today's
> dinstall run. It includes a comprehensive patch that might fix the
> endianness problems with audio. Alas, I had to do some guessing on the
> endianness of the input data, so it might actually do worse than before,
> but in any case the framework is now in place to fix this with a few
> keypresses.
audio seems to work better now. there are a few glitches but at
least it's not white noise. oh and export to mpeg2 and wav bot
work.
> The second change in 0.75-5 related to this bug was the
> mentioned switch from libdv to libavcodec for video decoding. There's a
> small chance that it fixes the display problem out of the box already.
I can confirm that the switch did not fix anything.
IMO with this last patch the bug should be closed, as the main
functionalities of kino (ie display and export) have been fixed.
there are other bugs around, but they are probably not endian
related nor RC.
Cheers, piem
#! /bin/sh /usr/share/dpatch/dpatch-run
## 40_yuv_endian_fix.dpatch by <[EMAIL PROTECTED]>
##
## All lines beginning with `## DP:' are a description of the patch.
## DP: No description.
@DPATCH@
diff -urNad kino-0.75/src/frame.cc /tmp/dpep.RS5WqC/kino-0.75/src/frame.cc
--- kino-0.75/src/frame.cc 2005-03-22 20:29:47.0 +
+++ /tmp/dpep.RS5WqC/kino-0.75/src/frame.cc 2005-03-22 20:30:25.0
+
@@ -1052,7 +1052,11 @@
for ( int x = 0; x < width; x += 2 )
{
+#if defined __BIG_ENDIAN__ || defined _BIG_ENDIAN
+*reinterpret_cast( dest ) = Cr[ 0 ]
+ ( Y[ 0 ] << 8 ) + ( Cb[ 1 ] << 16 ) + ( Y[ 0 ] << 24 );
+#else
*reinterpret_cast( dest ) = Y[ 0 ] +
( Cb[ 0 ] << 8 ) + ( Y[ 1 ] << 16 ) + ( Cr[ 0 ] << 24 );
+#endif
dest += 4;
Y += 2;
@@ -1071,8 +1075,13 @@
for ( int x = 0; x < width; x += 4 )
{
+#if defined __BIG_ENDIAN__ || defined _BIG_ENDIAN
+*reinterpret_cast( dest ) = Cr[ 0 ]
+ ( Y[ 0 ] << 8 ) + ( Cb[ 1 ] << 16 ) + ( Y[ 0 ] << 24 );
+*reinterpret_cast( dest + 4 ) = Cr[
2 ] + ( Y[ 0 ] << 8 ) + ( Cb[ 3 ] << 16 ) + ( Y[ 0 ] << 24 );
+#else
*reinterpret_cast( dest ) = Y[ 0 ] +
( Cb[ 0 ] << 8 ) + ( Y[ 1 ] << 16 ) + ( Cr[ 0 ] << 24 );
*reinterpret_cast( dest + 4 ) = Y[ 2
] + ( Cb[ 0 ] << 8 ) + ( Y[ 3 ] << 16 ) + ( Cr[ 0 ] << 24 );
+#endif
dest += 8;
Y += 4;
Bug#289182: kino endianness issues on powerpc
> On Mon, Feb 14, 2005 at 05:41:26PM +0100, Michael Schmitz wrote: > > I can confirm the XV problem is the same old problem that a patch had > > been posted for in http://jira.schirmacher.de/jira-kino/browse/KINO-76. > > I've added some #ifdef __BIG_ENDIAN__ around that, the following patch > > should finally fix the display issue: > > Err, this patch did fix the display problems for you!? It does not touch > a single line of code that was executed in the Debian build that uses > libdv to do the decoding. (Actually, this is no longer true as of today. It did fix the xv problems for me - not sure what libdv version I was using at that time. 0.103-2 is what I find in the package cache. My guess is I didn't use libavcodec at first - preview speed was abysmal and is quite decent now that I built against libdv4 plus libavcodec-cvs. The patch is still required to fix byte ordering with libavcodec, however. > Now with ffmpeg in main, I've uploaded a new version that uses > libavcodec instead of libdv for the decoding part.) Furthermore, it > looks obviously buggy. Eg. the little-endian version of the first loop > uses values Y[0] and Y[1], while the big-endian variant reuses Y[0] > twice. And I can't make sense of the other array indices, either. I was > expecting something like dest_big_endian = bswap_32(dest_little_endian); > maybe that's what was intended, and the current version of the patch I took the patch from a URL mentioned in one of the comments in the BTS. I had established that yuv byte ordering was broken by experimenting with byteswappig schemes in displayer.cc but that, naturally, would not fix export issues. > makes little difference with smooth input data? Anyway, what I remember > from years ago, Xv did expect image data in host-endian format with DRI > turned off, and in PCI-endian (little-endian) format with DRI turned on. DRI is off in my case IIRC (I need to use UseFBDev in the server). > I'd be very interested to know whether this still holds true. (Cc'ing > debian-powerpc, hoping someone there might be able to help.) Just saw a message by Michel Dänzer arrive in my inbox, seems he knew something. > I've uploaded kino 0.75-5 that should make the archive by today's > dinstall run. It includes a comprehensive patch that might fix the > endianness problems with audio. Alas, I had to do some guessing on the > endianness of the input data, so it might actually do worse than before, > but in any case the framework is now in place to fix this with a few > keypresses. The second change in 0.75-5 related to this bug was the > mentioned switch from libdv to libavcodec for video decoding. There's a > small chance that it fixes the display problem out of the box already. I'll test that ASAP. > Otherwise, I'll have to apply a cleaned up version of the cited patch. > In any case, this move should significantly boost decoding performance > on non-x86 and bring us a bit closer to getting kino usable on ppc and > friends as well. You bet - I was quite happy with ffmpeg (hacked to assume BE audio) as export pipe plus libavcodec for decoding. Michael
Bug#289182: kino endianness issues on powerpc
On Tue, 2005-03-08 at 15:39 +0100, Daniel Kobras wrote: > > Anyway, what I remember from years ago, Xv did expect image data in > host-endian format with DRI turned off, and in PCI-endian (little-endian) > format with DRI turned on. The expected byte order should be well-defined regardless of whether the DRI is enabled or not. If it isn't, that's probably a driver bug. -- Earthling Michel DÃnzer | Debian (powerpc), X and DRI developer Libre software enthusiast| http://svcs.affero.net/rm.php?r=daenzer
Bug#289182: kino endianness issues on powerpc
On Mon, Feb 14, 2005 at 05:41:26PM +0100, Michael Schmitz wrote:
> I can confirm the XV problem is the same old problem that a patch had
> been posted for in http://jira.schirmacher.de/jira-kino/browse/KINO-76.
> I've added some #ifdef __BIG_ENDIAN__ around that, the following patch
> should finally fix the display issue:
Err, this patch did fix the display problems for you!? It does not touch
a single line of code that was executed in the Debian build that uses
libdv to do the decoding. (Actually, this is no longer true as of today.
Now with ffmpeg in main, I've uploaded a new version that uses
libavcodec instead of libdv for the decoding part.) Furthermore, it
looks obviously buggy. Eg. the little-endian version of the first loop
uses values Y[0] and Y[1], while the big-endian variant reuses Y[0]
twice. And I can't make sense of the other array indices, either. I was
expecting something like dest_big_endian = bswap_32(dest_little_endian);
maybe that's what was intended, and the current version of the patch
makes little difference with smooth input data? Anyway, what I remember
from years ago, Xv did expect image data in host-endian format with DRI
turned off, and in PCI-endian (little-endian) format with DRI turned on.
I'd be very interested to know whether this still holds true. (Cc'ing
debian-powerpc, hoping someone there might be able to help.)
> --- src/frame.cc.org 2005-02-14 16:59:13.798585200 +0100
> +++ src/frame.cc 2005-02-14 17:14:01.196680184 +0100
> @@ -1052,7 +1052,11 @@
>
> for ( int x = 0; x < width; x += 2 )
> {
> +#if defined __BIG_ENDIAN__ || defined _BIG_ENDIAN
> + *reinterpret_cast( dest ) = Cr[ 0 ]
> + ( Y[ 0 ] << 8 ) + ( Cb[ 1 ] << 16 ) + ( Y[ 0 ] << 24 );
> +#else
> *reinterpret_cast( dest ) = Y[ 0 ] +
> ( Cb[ 0 ] << 8 ) + ( Y[ 1 ] << 16 ) + ( Cr[ 0 ] << 24 );
> +#endif
>
> dest += 4;
> Y += 2;
> @@ -1071,8 +1075,13 @@
>
> for ( int x = 0; x < width; x += 4 )
> {
> +#if defined __BIG_ENDIAN__ || defined _BIG_ENDIAN
> + *reinterpret_cast( dest ) = Cr[ 0 ]
> + ( Y[ 0 ] << 8 ) + ( Cb[ 1 ] << 16 ) + ( Y[ 0 ] << 24 );
> + *reinterpret_cast( dest + 4 ) = Cr[
> 2 ] + ( Y[ 0 ] << 8 ) + ( Cb[ 3 ] << 16 ) + ( Y[ 0 ] << 24 );
> +#else
> *reinterpret_cast( dest ) = Y[ 0 ] +
> ( Cb[ 0 ] << 8 ) + ( Y[ 1 ] << 16 ) + ( Cr[ 0 ] << 24 );
> *reinterpret_cast( dest + 4 ) = Y[ 2
> ] + ( Cb[ 0 ] << 8 ) + ( Y[ 3 ] << 16 ) + ( Cr[ 0 ] << 24 );
> +#endif
>
> dest += 8;
> Y += 4;
>
> Waiting for your audio export fix now :-)
I've uploaded kino 0.75-5 that should make the archive by today's
dinstall run. It includes a comprehensive patch that might fix the
endianness problems with audio. Alas, I had to do some guessing on the
endianness of the input data, so it might actually do worse than before,
but in any case the framework is now in place to fix this with a few
keypresses. The second change in 0.75-5 related to this bug was the
mentioned switch from libdv to libavcodec for video decoding. There's a
small chance that it fixes the display problem out of the box already.
Otherwise, I'll have to apply a cleaned up version of the cited patch.
In any case, this move should significantly boost decoding performance
on non-x86 and bring us a bit closer to getting kino usable on ppc and
friends as well.
Regards,
Daniel.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289182: [Kino-dev] [schmitz@zirkon.biophys.uni-duesseldorf.de: Bug#289182: kino endianness issues on powerpc]
No movement. What is sickening is that I even have an iMac I could work on this, but I am already way overburdened with other tasks. As I like to remind people, I still have the rest of my life, so I might get around to it ;-) On Thu, 2005-02-17 at 21:14 -0500, Henry A. Leinhos wrote: > 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? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289182: [Kino-dev] [schmitz@zirkon.biophys.uni-duesseldorf.de: Bug#289182: kino endianness issues on powerpc]
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]
Bug#289182: kino endianness issues on powerpc
> > 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.
>
> The audio problems seem to be caused (at least) by big-endian length
> fields in an otherwise little-endian WAV file. I'm not too familiar with
> the various video encodings. I'll have another close look on it over the
> week-end, but might have to pass on the problem to upstream for a fix.
I can confirm the XV problem is the same old problem that a patch had
been posted for in http://jira.schirmacher.de/jira-kino/browse/KINO-76.
I've added some #ifdef __BIG_ENDIAN__ around that, the following patch
should finally fix the display issue:
--- src/frame.cc.org2005-02-14 16:59:13.798585200 +0100
+++ src/frame.cc2005-02-14 17:14:01.196680184 +0100
@@ -1052,7 +1052,11 @@
for ( int x = 0; x < width; x += 2 )
{
+#if defined __BIG_ENDIAN__ || defined _BIG_ENDIAN
+ *reinterpret_cast( dest ) = Cr[ 0 ]
+ ( Y[ 0 ] << 8 ) + ( Cb[ 1 ] << 16 ) + ( Y[ 0 ] << 24 );
+#else
*reinterpret_cast( dest ) = Y[ 0 ] +
( Cb[ 0 ] << 8 ) + ( Y[ 1 ] << 16 ) + ( Cr[ 0 ] << 24 );
+#endif
dest += 4;
Y += 2;
@@ -1071,8 +1075,13 @@
for ( int x = 0; x < width; x += 4 )
{
+#if defined __BIG_ENDIAN__ || defined _BIG_ENDIAN
+ *reinterpret_cast( dest ) = Cr[ 0 ]
+ ( Y[ 0 ] << 8 ) + ( Cb[ 1 ] << 16 ) + ( Y[ 0 ] << 24 );
+ *reinterpret_cast( dest + 4 ) = Cr[
2 ] + ( Y[ 0 ] << 8 ) + ( Cb[ 3 ] << 16 ) + ( Y[ 0 ] << 24 );
+#else
*reinterpret_cast( dest ) = Y[ 0 ] +
( Cb[ 0 ] << 8 ) + ( Y[ 1 ] << 16 ) + ( Cr[ 0 ] << 24 );
*reinterpret_cast( dest + 4 ) = Y[ 2
] + ( Cb[ 0 ] << 8 ) + ( Y[ 3 ] << 16 ) + ( Cr[ 0 ] << 24 );
+#endif
dest += 8;
Y += 4;
Waiting for your audio export fix now :-)
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289182: kino endianness issues on powerpc
Sorry for the late reply; I've been away from my Powerbook (or indeed, the net) for the last weeks... > On Fri, Jan 07, 2005 at 06:37:52PM +0100, Michael Schmitz wrote: > > Severity: serious > > Can you please comment on why you think these bugs make kino unsuitable > for release; specifically, which section of policy is violated? I'm not kino in its current shape is non-functional in a couple of ways on PPC (and perhaps other BE architectures). Steve initially suggested 'grave' and I think that's the correct one indeed - IIRC I had not succeeded in finding an export method that generates both correct video and audio formats - either one is broken, or both. Anyway, you seem to have found the audio problem, and the video problem indeed seems to be the old byteswap thing (see below) so I guess this can be finally fixed soon. > denying that the bugs you reported are nasty and should be fixed, but > unless you convince me otherwise, the severity looks inappropriate to > me. > > > 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). > > This sounds a lot like an old Xv bug that first came up in 2002. Can you > please supply me with the output of xvinfo? Which system are you testing X-Video Extension version 2.2 screen #0 Adaptor #0: "ATI Radeon Video Overlay" number of ports: 1 port base: 53 operations supported: PutImage supported visuals: depth 24, visualID 0x21 depth 24, visualID 0x22 number of attributes: 12 "XV_SET_DEFAULTS" (range 0 to 1) client settable attribute "XV_AUTOPAINT_COLORKEY" (range 0 to 1) client settable attribute client gettable attribute (current value is 1) "XV_COLORKEY" (range 0 to -1) client settable attribute client gettable attribute (current value is 30) "XV_DOUBLE_BUFFER" (range 0 to 1) client settable attribute client gettable attribute (current value is 1) "XV_BRIGHTNESS" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_CONTRAST" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_SATURATION" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_COLOR" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_HUE" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_RED_INTENSITY" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_GREEN_INTENSITY" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) "XV_BLUE_INTENSITY" (range -1000 to 1000) client settable attribute client gettable attribute (current value is 0) maximum XvImage size: 2048 x 2048 Number of image formats: 4 id: 0x32595559 (2YUY) guid: 59555932--0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x59565955 (YVYU) guid: 55595659--0010-8000-00aa00389b71 bits per pixel: 16 number of planes: 1 type: YUV (packed) id: 0x32315659 (21VY) guid: 59563132--0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) id: 0x30323449 (024I) guid: 49343230--0010-8000-00aa00389b71 bits per pixel: 12 number of planes: 3 type: YUV (planar) > this on, and what's your graphics adapter? Is DRI turned on, and does it That's a Powerbook G4 17" (PowerBook5,5). The graphics adapter is ATI Technologies Inc RV350 [Mobility Radeon 9600 M10]. DRI is disabled, as currrent XFree86 needs to use the framebuffer device interface for mode switching etc., and this clashes with DRI. With altivec optimized encoders, encoding speed is about on par with what the MacOS tools achieve, so it's only screen display that's dog slow here. > make a difference if you turn it off? For reference, the original > discussion should be available from here: > http://www.geocrawler.com/mail/thread.php3?subject=%5Blibdv-dev%5D+Re%3A+Should+dv1394+work+on+PPC%3F&list=3147 > > > 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. > > The audio proble
Bug#289182: kino endianness issues on powerpc
Hi, I have a debian powerpc available and am ready to help. The thread you were mentionning is at: http://sourceforge.net/mailarchive/message.php?msg_id=1699887 I will post my advances to the debian bts. Let me know if you have any more patches. cheers, piem -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289182: kino endianness issues on powerpc
On Thu, Jan 27, 2005 at 10:58:09AM +0100, Daniel Kobras wrote: > On Wed, Jan 26, 2005 at 09:59:08PM -0800, Steve Langasek wrote: > > You're right that this bug is not a policy violation; this is a "grave" bug, > > which is the severity for bugs that render a package "unusable or mostly > > so". We should not be releasing unusable binaries for any architecture; > > either the binaries for all big-endian architectures will need to be > > removed, or the bug fixed, for kino to be included in sarge. > I disagree. One of several display methods is broken. So is one of > several export methods. That does not sound unusable to me. (kino indeed > is mostly unusable on anything but x86 because libdv is dog slow on > these archs, but that's another matter.) If it really only affects one of several export methods and one of several display methods, then I agree with you that it isn't grave. The submitter's mail wasn't all that clear that other methods do work, only that certain methods that he tried did not. If you know for certain that the main functionality of kino is available on powerpc, then feel free to downgrade this bug. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Bug#289182: kino endianness issues on powerpc
On Wed, Jan 26, 2005 at 09:59:08PM -0800, Steve Langasek wrote: > You're right that this bug is not a policy violation; this is a "grave" bug, > which is the severity for bugs that render a package "unusable or mostly > so". We should not be releasing unusable binaries for any architecture; > either the binaries for all big-endian architectures will need to be > removed, or the bug fixed, for kino to be included in sarge. I disagree. One of several display methods is broken. So is one of several export methods. That does not sound unusable to me. (kino indeed is mostly unusable on anything but x86 because libdv is dog slow on these archs, but that's another matter.) Regards, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289182: kino endianness issues on powerpc
severity 289182 grave thanks Hi Daniel, You're right that this bug is not a policy violation; this is a "grave" bug, which is the severity for bugs that render a package "unusable or mostly so". We should not be releasing unusable binaries for any architecture; either the binaries for all big-endian architectures will need to be removed, or the bug fixed, for kino to be included in sarge. Thanks, -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Bug#289182: kino endianness issues on powerpc
On Fri, Jan 07, 2005 at 06:37:52PM +0100, Michael Schmitz wrote: > Severity: serious Can you please comment on why you think these bugs make kino unsuitable for release; specifically, which section of policy is violated? I'm not denying that the bugs you reported are nasty and should be fixed, but unless you convince me otherwise, the severity looks inappropriate to me. > 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). This sounds a lot like an old Xv bug that first came up in 2002. Can you please supply me with the output of xvinfo? Which system are you testing this on, and what's your graphics adapter? Is DRI turned on, and does it make a difference if you turn it off? For reference, the original discussion should be available from here: http://www.geocrawler.com/mail/thread.php3?subject=%5Blibdv-dev%5D+Re%3A+Should+dv1394+work+on+PPC%3F&list=3147 > 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. The audio problems seem to be caused (at least) by big-endian length fields in an otherwise little-endian WAV file. I'm not too familiar with the various video encodings. I'll have another close look on it over the week-end, but might have to pass on the problem to upstream for a fix. Thanks, Daniel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
