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-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x59565955 (YVYU)
guid: 55595659-0000-0010-8000-00aa00389b71
bits per pixel: 16
number of planes: 1
type: YUV (packed)
id: 0x32315659 (21VY)
guid: 59563132-0000-0010-8000-00aa00389b71
bits per pixel: 12
number of planes: 3
type: YUV (planar)
id: 0x30323449 (024I)
guid: 49343230-0000-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 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
Good to know there's a lead to go on WRT audio; I had not looked into that
at all.
> 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.
On the video side, I did some more fudging around and found a way to fix
the video data on the fly before displaying via XV (swapping high and low
bytes, then swapping the red and blue chromas) but that didn't help the
export function, naturally. I'll have a look at what you came up with; it
seems your patch addresses the problem correctly but I'll have to test it
a bit. It's a shame this didn't get adopted by the developers :-(
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
