> 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
