libdv-dev

[libdv-dev] Audio

[David B. <dav...@id...>]

Hi all,

Does anybody know something about the audio part of a dv file ?
I need to know :
* FormatTag
* Channels
* SamplesPerSec
* AvgBytesPerSec
* BlockAlign
* BitsPerSample

I am using both PAL DV-VCR and DV-Camera, and I would like to know how
to get the audio part and make a wav file. I think I will use the
existing ExtractAudio function but I don't know how long will be the
char* I'll get.

If somebody knows anything about this ....
Thanks

David

[libdv-dev] gtk is not correct checked in configure

[Fabian S. <f...@rt...>]

Hello!

I have two small problems with libdv.
The first is that i have 
checking for glib >= 1.2.4 gtk+ >= 1.2.4... yes
but it does not define HAVE_GTK in the config.h file.
Therefore the part which opens a gtk window is not compiled in :(
Shuold be a small bugfix.

The other problem is that mm_support() in mmx.h  produces a segemntation
fault.
I have put a return in the function before the asm code
and then the program works (without mmx).
I dont know how to fix this second error.

Thanks Fabian

[libdv-dev] crash in mmx_ok()

[Arne S. <arn...@d2...>]

Can somebody please check this bug report? I have received several
similar emails, all having trouble with the mmx_ok function (or
somewhere near it).

http://www.schirmacher.de/dcforum/DCForumID4/35.html

Thanks, Arne

[libdv-dev] [ libdv-Bugs-437135 ] Cannot install RPM

[<no...@so...>]

Bugs item #437135, was opened at 2001-06-28 10:00
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104393&aid=437135&group_id=4393

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cannot install RPM

Initial Comment:
root# rpm -Uvh libdv-0.9-1.i386.rpm
error: failed dependencies:
      libdv.so.1   is needed by libdv-0.9-1

I might be missing something here...

Thanks,
Martin


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=104393&aid=437135&group_id=4393

[libdv-dev] Re: Problem with KINO and libdv

[Charles 'B. K. <kr...@ac...>]

I don't have too much time to debug this at the moment, but here is a
hint.

I've had several reports of libdv crashing on unusual DV input, such
as that produced by a camera during FF and RW.  In those cases, I had
DV sequences that triggered the error in a reproducable fashion.  I've
verified that the cause was a discrepancy between the C and assembly
versions of the parser.  I'm not sure why the crash would occur in
rgb.c as in your case.

When configured with the --disable-asm option, libdv did not crash on
said sequences.  For some people, this workaround helped as they did
not care to much about speed.  If you do, this will not be acceptable
because the pure C version of libdv is so much slower.

-- Buck

[libdv-dev] [ libdv-Patches-434466 ] New option for selecting Xvideo port.

[<no...@so...>]

Patches item #434466, was updated on 2001-06-19 07:15
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304393&aid=434466&group_id=4393

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Artur Zaprzala (zybi)
Assigned to: Nobody/Anonymous (nobody)
Summary: New option for selecting Xvideo port.

Initial Comment:
nVidia drivers have now 2 Xvideo adaptors: `Video
overlay' (1 port) and `Video blitter' (32 ports).
This patch allows to select any of their ports.

----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=304393&aid=434466&group_id=4393

[libdv-dev] Re: Fw: Kino frequently crashes on G3 Mac - Now no more crashes

[Peter H. <har...@de...>]

Hi folks,

here's a patch that keeps Kino on my G3 Mac from crashing. It patches
libdv-0.8 in there libdv/rgb.c. As I already said: It's pretty dirty and
I have no clue why it works...

Peter







Dan Dennedy wrote:
> 
> Check out this from Peter Hartmann, also a PAL user on Mac. Note that he had
> to patch libdv for endian issues. He is not using Xv, but I think this
> potentially points to some endian issues in libdv. I asked Peter to send his
> patches to libdv.
> 
> I am dropping linux1394-devel from the recipient list because it is off
> topic. Instead, I want you and Peter to collaborate with the libdv and Kino
> teams to resolve this. Also, please test libdv's playdv program because it
> too supports Xv.
> 
> One thing that concerns me with the capture2.jpg screen shot you sent me is
> that video only appears in half the height of the video drawable. If the YUV
> format is correct and there is only an endian issue, then the full height
> should be drawing with distortion. What version of libdv are you using? The
> Xv display format patch I just had you apply was for libdv v0.4+ -- at least
> as far as I can tell from the dates in the libdv ChangeLog and the file
> release dates on SourceForge.
> 
> In reference to your other e-mail about screen captures with Xv, the X
> server knows nothing about the video. Video overlay is like a chroma key
> effect where the X server is reponsible for drawing a rectangle filled with
> a specific color.
> 
> ----- Original Message -----
> From: "Peter Hartmann" <har...@de...>
> To: "Dan Dennedy" <dde...@co...>
> Cc: <har...@pr...>; <pe...@ha...>;
> <dv...@sc...>
> Sent: Monday, June 11, 2001 12:19 PM
> Subject: Re: Kino frequently crashes on G3 Mac
> 
> > Hi Dan,
> >
> > thanks for your answer. I'll try your patch as soon as I find the time
> > (should be this week).
> > Kino is no more crashing on the G3, I had to patch libdv in a pretty
> > dirty way, but at least it works. My last problem is the framerate. I
> > can use GTK display only and I get about 1 frame per second. What is
> > your opinion: Is the processor too slow for dv decompression or is the
> > drawing routine the reason ? I ordered the book Arne advised me to read,
> > but it takes three weeks...Oh well.
> >
> > Take care
> >
> > Peter
> >
> >
> > Dan Dennedy wrote:
> > >
> > > In Kino 0.43, I made an attempt to do an endian fix in riff.cc. Please
> test
> > > it and let me know how it works.
> > >
> > > As it turns out, the logic seems reversed. Apparantly, casting the
> > > character pointer as a pointer to an unsigned int and then dereferencing
> it
> > > is causing the correct interpretation on a little endian machine with no
> > > explicit byte swapping required! I do not know if the same holds true on
> > > big endian. Therefore, I applied a bswap for big endian just to reverse
> the
> > > logic of the little endian case. In any case, just try it. If it fails
> to
> > > load an AVI, then try removing the call bswap in riff.cc. Maybe the cast
> is
> > > universal and no special handling is required anymore.
> > >
> > > On Tue, 05 Jun 2001 07:13:48 Peter Hartmann wrote:
> > > > Hi Danny,
> > > >
> > > > I am kindof surprised that the patch does not work. I took
> netinet/in.h
> > > > and not something from endian.h because netinet is available also on
> > > > other than GNU systems (e.g. HP/UX). After I read your mail I checked
> my
> > > > office linux box (Intel) out and - surprise - ntohl was commented out
> in
> > > > netinet/in.h. I do not have the faintest clue why this is so. Please
> > > > accept my apologies.
> > > >
> > > > Peter
> > > >
> > > > Dan Dennedy wrote:
> > > > >
> > > > > Peter, this patch does not work for me. I tried htonl too. Both do
> not
> > > > byte
> > > > > swap as needed. I do not know these as well as I should. What
> #defines
> > > > > __BYTE_ORDER, which is what <netinet/in.h> needs?
> > > > >
> > > > > On Fri, 01 Jun 2001 14:53:04 Peter Hartmann wrote:
> > > > > > Hi Dan,
> > > > > >
> > > > > > here's a little patch for kino04b/src/riff.cc which enables kino
> to
> > > > read
> > > > > > his own avi's on my G3 Mac (big endian):
> > > > > >
> > > > > > 27a28
> > > > > > > #include <netinet/in.h>
> > > > > > 38d38
> > > > > > <     \bugs This code is byte-order dependent and runs only on
> > > > > > little-endian (Intel) systems
> > > > > > 50c50
> > > > > > <         return (s[3] << 24) | (s[2] << 16) | (s[1] << 8) | s[0];
> > > > > > ---
> > > > > > >       return ntohl(*((long *) s));
> > > > > > 652a653,656
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > Other than that Kino works fine except that it tends to crash
> after
> > > > some
> > > > > > tens of seconds of video grabbing with a segmentation fault. I
> > > > believe
> > > > > > one reason (there are probably several different reasons) for
> these
> > > > > > crashes is a routine named dv_mb420_rgb in libdv/rgb.c. Is there
> any
> > > > > > chance to find documentation on the source code (or at least on
> the
> > > > > > compression algorithm) ?
> > > > > > My biggest problem is that ddd/gdb do not seem to work on the
> cores
> > > > kino
> > > > > > dumps. How do you guys do the debugging ?
> > > > > >
> > > > > > Peter
> > > > > >
> > > > > >
> > > > > >
> > > > > > Dan Dennedy wrote:
> > > > > > >
> > > > > > > We are still working on big endian support in the Linux IEEE
> 1394
> > > > > > > subsystem. It seems awefully close, though. Since I do not
> closely
> > > > > > track
> > > > > > > the issue, you should browse the linux1394-devel mail list
> arhives.
> > > > > > There
> > > > > > > has been plenty of activity and patches sent around.
> > > > > > > The fact that Kino showed something very much surprises me!
> > > > Therefore,
> > > > > > > maybe the endian issues are more related to ohci1394 and not
> > > > pcilynx.
> > > > > > This
> > > > > > > is the first I have heard anyone trying to use dvgrab or Kino on
> a
> > > > > > Mac/big
> > > > > > > endian. I suspect that some big endian users have at least tried
> > > > > > dvgrab,
> > > > > > > but I do not know their successes. Can you help us? Can you
> program
> > > > and
> > > > > > > debug?
> > > > > > > You can try some other programs too like dvcont
> > > > > > > (http://sourceforge.net/projects/libavc1394/) or testlibraw,
> which
> > > > is a
> > > > > > > test program included with the libraw1394 tarball (not RPM).
> > > > > >
> > > >
> > > >
> >
> >

[libdv-dev] Re: libdv decode performance (Was Kino frequently crashes on G3 Mac)

[Charles 'B. K. <kr...@ac...>]

Chris Emerson <ch...@ta...> writes:

> Is there some good documentation on what that code needs to do?  I doubt
> I'll ever have time to learn enough about ppc (or altivec) optimisation to
> do anything about it, but it can't hurt.  :-)

Do a search on google with query "altivec idct" and you will get great
stuff.  :-)

It shouldn't be hard to incorporate into libdv.  It's mostly a matter of
access to a MAC development environment, which you have.  (nudge nudge).

-- Buck

[libdv-dev] RE: [Kino-dev] RE: Kino 0.43, XV output and NVidia cards

[Arne S. <ar...@sc...>]

I'll go ahead and make a 0.44 tarball then. Who knows how long the endian 
issues will take (fixing the avi library sure takes longer than expected). 
We can easily release anoter version for andy additional libdv issues, in 
case this is required.

Arne

-----Original Message-----
From:	Dan Dennedy
Sent:	Monday, June 18, 2001 2:16 PM
To:	Arne Schirmacher
Cc:	Chris Emerson; linux1394-devel @ lists . sourceforge . net; kino-dev; 
libdv-dev @ lists . sourceforge . net
Subject:	Re: [Kino-dev] RE:  Kino 0.43, XV output and NVidia cards

I will be a little while before dv1394 is ready, and no other changes are 
as
critical as this PAL Xv fix. We might want to synchronize the timing of 
0.44
with libdv endian patches so we can say this fixes both PAL Xv and big
endian architectures.

[libdv-dev] Re: [Kino-dev] libdv decode performance (Was Kino frequently crashes on G3 Mac)

[Chris E. <ch...@ta...>]

On Mon, Jun 18, 2001 at 07:33:13AM -0700, Charles 'Buck' Krasic wrote:
> On x86, I estimate libdv decode to be about 2-3x slower than a
> commercial codec.  

That's not so bad really.

> The main culprit is definitely the front end: bitstream scanner,
> variable length decoding, and parsing.  Last time I ran a profile,
> they accounted for more than 50% of decode time.   

Do you have a program you use for profiling, or just kino etc.?  I'd be
interested to see what happens on my Mac.

> On the MAC, this is not totally true, as you need an optimized idct,
> which is already there in the x86 libdv.

Is there some good documentation on what that code needs to do?  I doubt
I'll ever have time to learn enough about ppc (or altivec) optimisation to
do anything about it, but it can't hurt.  :-)

Cheers,

Chris

[libdv-dev] libdv decode performance (Was Kino frequently crashes on G3 Mac)

[Charles 'B. K. <kr...@ac...>]

On x86, I estimate libdv decode to be about 2-3x slower than a
commercial codec.  

The main culprit is definitely the front end: bitstream scanner,
variable length decoding, and parsing.  Last time I ran a profile,
they accounted for more than 50% of decode time.   

On the MAC, this is not totally true, as you need an optimized idct,
which is already there in the x86 libdv.

-- Buck

[libdv-dev] Re: [Kino-dev] RE: Kino 0.43, XV output and NVidia cards

[Dan D. <da...@de...>]

I will be a little while before dv1394 is ready, and no other changes are as
critical as this PAL Xv fix. We might want to synchronize the timing of 0.44
with libdv endian patches so we can say this fixes both PAL Xv and big
endian architectures.

----- Original Message -----
From: "Arne Schirmacher" <ar...@sc...>
To: "'Dan Dennedy'" <da...@de...>
Cc: "Chris Emerson" <ch...@ta...>; "linux1394-devel @ lists .
sourceforge . net" <lin...@li...>; "kino-dev"
<kin...@li...>; "libdv-dev @ lists . sourceforge . net"
<lib...@li...>
Sent: Sunday, June 17, 2001 1:12 PM
Subject: RE: [Kino-dev] RE: Kino 0.43, XV output and NVidia cards


> Ok, this works perfect for me.
>
> I have already checked in the changes to CVS, including a fix to the
IsPAL() function which I got from Stefan Lucke.
>
> Dan, are there any additional improvements to ieee1394 i/o or should I go
ahead and build a Kino version 0.44?
>
> Arne
> -----Original Message-----
> From: Dan Dennedy
> Sent: Saturday, June 16, 2001 10:29 PM
> To: Arne Schirmacher
> Cc: 'Dan Dennedy'; Chris Emerson; linux1394-devel @ lists . sourceforge .
net; kino-dev; libdv-dev @ lists . sourceforge . net
> Subject: RE: [Kino-dev] RE:  Kino 0.43, XV output and NVidia cards
>
>
> On Sat, 16 Jun 2001 17:18:12 Arne Schirmacher wrote:
> > I tried this, but it does not work correctly. The bottom half of the
> > image
> > is solid green, the top half has correct color but is scrambled.
>
> Ok, here is another thing to change in Frame.cc:
>
>
> int Frame::ExtractYUV(void *yuv)
> {
>     guchar *pixels[3];
>     gint pitches[3];
>
>     pixels[0] = (guchar*)yuv;
>
> -    switch(decoder->sampling) {
> -    case e_dv_sample_411:
> -    case e_dv_sample_422:
>         pitches[0] = decoder->width * 2;
> -        break;
> -    case e_dv_sample_420:
> -        pixels[1] = pixels[0] + (decoder->width * decoder->height);
> -        pixels[2] = pixels[1] + (decoder->width * decoder->height / 4);
> -        pitches[0] = decoder->width;
> -        pitches[1] = decoder->width / 2;
> -        pitches[2] = decoder->width / 2;
> -        break;
> -    default:
> -        break;
> -    } // switch
>
>     dv_decode_full_frame(decoder, data, e_dv_color_yuv, pixels, pitches);
>     return 0;
> }
>
>
> Remove the lines beginning with '-'
>
> > However playdv will display PAL DV files. I saved a PAL file as DV and
it
> >
> > displays with 30 fps. So even though libdv has changed, it will still
> > decode PAL data. But I did not compare playdv and Kino's functions yet,
> > but
> > it is probably a trivial change (once you know where to look).
> >
> > Arne
> >
> > -----Original Message-----
> > From: Dan Dennedy
> > Sent: Friday, June 15, 2001 7:19 PM
> > To: Chris Emerson
> > Cc: lin...@li...; kino-dev;
> > lib...@li...
> > Subject: Re: [Kino-dev] RE:  Kino 0.43, XV output and NVidia cards
> >
> > Right, well if Arne is correct, then the issue affects all PAL users
> > using
> > libdv version 0.4+. From the libdv ChangeLog:
> > 2001-02-06  Charles 'Buck' Krasic  <kr...@ac...>
> >
> > * Integrate patch from Stefan Lucke for various speedups:
> > [...]
> >            - change IEC PAL (420) to generate YUY2 instead of YV12.
> >
> > --
> > However, I am surprised to hear about it now with libdv at version 0.8!
I
> >
> > am
> > an NTSC user, so I did not notice it. On the other hand, activity in the
> > Kino scene from Feb-May was slow as I was working on other things, and
> > activity has recently picked up.
> >
> > Nevertheless, I see our offending code in FrameDisplayer::PutXv. The fix
> > will be in Kino 0.44. In the meantime, change FrameDisplayer.cc,
> > FrameDisplayer::PutXv.
> > FROM:
> >         case e_dv_sample_411:
> >         case e_dv_sample_422:
> >             format = DV_FOURCC_YUY2;
> >             len = frame.decoder->width * frame.decoder->height * 2;
> >             break;
> >         case e_dv_sample_420:
> >             format = DV_FOURCC_YV12;
> >             len = (frame.decoder->width * frame.decoder->height * 3) /
2;
> >             break;
> >
> > TO:
> >         case e_dv_sample_411:
> >         case e_dv_sample_420:
> >         case e_dv_sample_422:
> >             format = DV_FOURCC_YUY2;
> >             len = frame.decoder->width * frame.decoder->height * 2;
> >             break;
> >
> >
> > +-DRD-+
> >
> > From: "Chris Emerson"
> > > On Fri, Jun 15, 2001 at 10:55:42AM -0400, Dan Dennedy wrote:
> > > > Are the Kino users with Xv issues on NVIDIA cards using PAL or NTSC?
> > Arne
> > > > Schirmacher believes the issue is related to a change in libdv's PAL
> > YUV
> > > > output. If you are an NTSC user, then please send the output of the
> > xvinfo
> > > > program.
> > >
> > > I have the issue with an ATI card on PPC.  I am indeed using PAL.
> > >
> > > Cheers,
> > >
> > > Chris
> > >
> >
> >
> > _______________________________________________
> > mailing list lin...@li...
> > http://lists.sourceforge.net/lists/listinfo/linux1394-devel
> >
>
>
>
> _______________________________________________
> mailing list lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linux1394-devel
>

[libdv-dev] Re: Fw: Kino frequently crashes on G3 Mac

[Chris E. <ch...@ta...>]

Hi,

On Mon, Jun 18, 2001 at 09:49:48AM +0200, Peter Hartmann wrote:
> each time he would have decoded or diplayed a frame. When I commented
> out the decoding part (and displayed black frames) I got a 'displayed'
> message every 4-5 'grabbed' messages. When I commented out the
> displaying part I got a 'decoded' message every 45-50 'grabbed'
> messages. This tells me that the bottleneck on my G3 is indeed not the
> displaying code, but the decoding part, which is slower by a factor of
> 10 ! Now I am wondering: Can libdv be made more efficient or do I need a
> new computer ??

Have you tried adjusting the display quality?  I haven't, but it sounds
like it's worth a try.

I would hope that libdv can be made more efficient.  My G4/250 running iMovie
under MacOS does a perfectly good job of decoding and displaying video from
my camcorder, so the processor is fine.  I guess some profiling is in order.

Cheers,

Chris

[libdv-dev] Re: Fw: Kino frequently crashes on G3 Mac

[Peter H. <har...@de...>]

Hi Chris,

I have answered Dan's email before I read yours. About the displaying
speed on a G3 here's what I wrote to Danny:


On the weekend I tested the speed of decoding and displaying frames: I
put a 'cout' into the grabber thread in order to tell me each time a
frame was grabbed. I put two other cout's into the framedisplayer to
tell me
each time he would have decoded or diplayed a frame. When I commented
out the decoding part (and displayed black frames) I got a 'displayed'
message every 4-5 'grabbed' messages. When I commented out the
displaying part I got a 'decoded' message every 45-50 'grabbed'
messages. This tells me that the bottleneck on my G3 is indeed not the
displaying code, but the decoding part, which is slower by a factor of
10 ! Now I am wondering: Can libdv be made more efficient or do I need a
new computer ??

Take care

Peter

Chris Emerson wrote:
> 
> On Fri, Jun 15, 2001 at 05:41:15PM -0400, Dan Dennedy wrote:
> > Check out this from Peter Hartmann, also a PAL user on Mac. Note that he had
> > to patch libdv for endian issues. He is not using Xv, but I think this
> > potentially points to some endian issues in libdv. I asked Peter to send his
> > patches to libdv.
> 
> Ok, I was sent a patch to libdv from Stefan Lucke, which fixed the colour
> problems with Xv but not the garbling.
> 
> > I am dropping linux1394-devel from the recipient list because it is off
> > topic. Instead, I want you and Peter to collaborate with the libdv and Kino
> > teams to resolve this. Also, please test libdv's playdv program because it
> > too supports Xv.
> 
> playdv seems to have a different problem on my machine:
> > ./playdv: error while loading shared libraries: /usr/lib/libSDL-1.1.so.0: R_PPC_REL24 relocation at 0x6fac8670 for symbol `location' out of range
> 
> This happens both with a self-compiled and packaged one.  I'm just rebuilding
> libSDL in case that helps.
> 
> > One thing that concerns me with the capture2.jpg screen shot you sent me is
> > that video only appears in half the height of the video drawable. If the YUV
> > format is correct and there is only an endian issue, then the full height
> > should be drawing with distortion. What version of libdv are you using?
> 
> I'm using 0.8.  With Stefan's patch it now looks like
> http://www.tartarus.org/~chris/capture3.jpg
> ie the same "shape" but correct colours.
> 
> > In reference to your other e-mail about screen captures with Xv, the X
> > server knows nothing about the video. Video overlay is like a chroma key
> > effect where the X server is reponsible for drawing a rectangle filled with
> > a specific color.
> 
> Ah, that would explain some other strange effects I've seen.  Thanks.
> 
> > ----- Original Message -----
> > From: "Peter Hartmann" <har...@de...>
> > To: "Dan Dennedy" <dde...@co...>
> [snip]
> > > Kino is no more crashing on the G3, I had to patch libdv in a pretty
> > > dirty way, but at least it works. My last problem is the framerate. I
> > > can use GTK display only and I get about 1 frame per second. What is
> > > your opinion: Is the processor too slow for dv decompression or is the
> > > drawing routine the reason ?
> 
> I get a similarly bad framerate for both the GTK and the (mangled) Xv
> displays, on a G4/350.
> 
> Cheers,
> 
> Chris

[libdv-dev] RE: [Kino-dev] RE: Kino 0.43, XV output and NVidia cards

[Arne S. <ar...@sc...>]

Ok, this works perfect for me.

I have already checked in the changes to CVS, including a fix to the IsPAL() function which I got from Stefan Lucke.

Dan, are there any additional improvements to ieee1394 i/o or should I go ahead and build a Kino version 0.44?

Arne
-----Original Message-----
From:	Dan Dennedy 
Sent:	Saturday, June 16, 2001 10:29 PM
To:	Arne Schirmacher
Cc:	'Dan Dennedy'; Chris Emerson; linux1394-devel @ lists . sourceforge . net; kino-dev; libdv-dev @ lists . sourceforge . net
Subject:	RE: [Kino-dev] RE:  Kino 0.43, XV output and NVidia cards


On Sat, 16 Jun 2001 17:18:12 Arne Schirmacher wrote:
> I tried this, but it does not work correctly. The bottom half of the
> image 
> is solid green, the top half has correct color but is scrambled.

Ok, here is another thing to change in Frame.cc:


int Frame::ExtractYUV(void *yuv)
{
    guchar *pixels[3];
    gint pitches[3];

    pixels[0] = (guchar*)yuv;

-    switch(decoder->sampling) {
-    case e_dv_sample_411:
-    case e_dv_sample_422:
        pitches[0] = decoder->width * 2;
-        break;
-    case e_dv_sample_420:
-        pixels[1] = pixels[0] + (decoder->width * decoder->height);
-        pixels[2] = pixels[1] + (decoder->width * decoder->height / 4);
-        pitches[0] = decoder->width;
-        pitches[1] = decoder->width / 2;
-        pitches[2] = decoder->width / 2;
-        break;
-    default:
-        break;
-    } // switch

    dv_decode_full_frame(decoder, data, e_dv_color_yuv, pixels, pitches);
    return 0;
}


Remove the lines beginning with '-'
 
> However playdv will display PAL DV files. I saved a PAL file as DV and it
> 
> displays with 30 fps. So even though libdv has changed, it will still 
> decode PAL data. But I did not compare playdv and Kino's functions yet,
> but 
> it is probably a trivial change (once you know where to look).
> 
> Arne
> 
> -----Original Message-----
> From:	Dan Dennedy
> Sent:	Friday, June 15, 2001 7:19 PM
> To:	Chris Emerson
> Cc:	lin...@li...; kino-dev; 
> lib...@li...
> Subject:	Re: [Kino-dev] RE:  Kino 0.43, XV output and NVidia cards
> 
> Right, well if Arne is correct, then the issue affects all PAL users
> using
> libdv version 0.4+. From the libdv ChangeLog:
> 2001-02-06  Charles 'Buck' Krasic  <kr...@ac...>
> 
> 	* Integrate patch from Stefan Lucke for various speedups:
> [...]
>            - change IEC PAL (420) to generate YUY2 instead of YV12.
> 
> --
> However, I am surprised to hear about it now with libdv at version 0.8! I
> 
> am
> an NTSC user, so I did not notice it. On the other hand, activity in the
> Kino scene from Feb-May was slow as I was working on other things, and
> activity has recently picked up.
> 
> Nevertheless, I see our offending code in FrameDisplayer::PutXv. The fix
> will be in Kino 0.44. In the meantime, change FrameDisplayer.cc,
> FrameDisplayer::PutXv.
> FROM:
>         case e_dv_sample_411:
>         case e_dv_sample_422:
>             format = DV_FOURCC_YUY2;
>             len = frame.decoder->width * frame.decoder->height * 2;
>             break;
>         case e_dv_sample_420:
>             format = DV_FOURCC_YV12;
>             len = (frame.decoder->width * frame.decoder->height * 3) / 2;
>             break;
> 
> TO:
>         case e_dv_sample_411:
>         case e_dv_sample_420:
>         case e_dv_sample_422:
>             format = DV_FOURCC_YUY2;
>             len = frame.decoder->width * frame.decoder->height * 2;
>             break;
> 
> 
> +-DRD-+
> 
> From: "Chris Emerson"
> > On Fri, Jun 15, 2001 at 10:55:42AM -0400, Dan Dennedy wrote:
> > > Are the Kino users with Xv issues on NVIDIA cards using PAL or NTSC?
> Arne
> > > Schirmacher believes the issue is related to a change in libdv's PAL 
> YUV
> > > output. If you are an NTSC user, then please send the output of the
> xvinfo
> > > program.
> >
> > I have the issue with an ATI card on PPC.  I am indeed using PAL.
> >
> > Cheers,
> >
> > Chris
> >
> 
> 
> _______________________________________________
> mailing list lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linux1394-devel
> 



_______________________________________________
mailing list lin...@li...
http://lists.sourceforge.net/lists/listinfo/linux1394-devel

[libdv-dev] RE: [Kino-dev] RE: Kino 0.43, XV output and NVidia cards

[Dan D. <da...@de...>]

On Sat, 16 Jun 2001 17:18:12 Arne Schirmacher wrote:
> I tried this, but it does not work correctly. The bottom half of the
> image 
> is solid green, the top half has correct color but is scrambled.

Ok, here is another thing to change in Frame.cc:


int Frame::ExtractYUV(void *yuv)
{
    guchar *pixels[3];
    gint pitches[3];

    pixels[0] = (guchar*)yuv;

-    switch(decoder->sampling) {
-    case e_dv_sample_411:
-    case e_dv_sample_422:
        pitches[0] = decoder->width * 2;
-        break;
-    case e_dv_sample_420:
-        pixels[1] = pixels[0] + (decoder->width * decoder->height);
-        pixels[2] = pixels[1] + (decoder->width * decoder->height / 4);
-        pitches[0] = decoder->width;
-        pitches[1] = decoder->width / 2;
-        pitches[2] = decoder->width / 2;
-        break;
-    default:
-        break;
-    } // switch

    dv_decode_full_frame(decoder, data, e_dv_color_yuv, pixels, pitches);
    return 0;
}


Remove the lines beginning with '-'
 
> However playdv will display PAL DV files. I saved a PAL file as DV and it
> 
> displays with 30 fps. So even though libdv has changed, it will still 
> decode PAL data. But I did not compare playdv and Kino's functions yet,
> but 
> it is probably a trivial change (once you know where to look).
> 
> Arne
> 
> -----Original Message-----
> From:	Dan Dennedy
> Sent:	Friday, June 15, 2001 7:19 PM
> To:	Chris Emerson
> Cc:	lin...@li...; kino-dev; 
> lib...@li...
> Subject:	Re: [Kino-dev] RE:  Kino 0.43, XV output and NVidia cards
> 
> Right, well if Arne is correct, then the issue affects all PAL users
> using
> libdv version 0.4+. From the libdv ChangeLog:
> 2001-02-06  Charles 'Buck' Krasic  <kr...@ac...>
> 
> 	* Integrate patch from Stefan Lucke for various speedups:
> [...]
>            - change IEC PAL (420) to generate YUY2 instead of YV12.
> 
> --
> However, I am surprised to hear about it now with libdv at version 0.8! I
> 
> am
> an NTSC user, so I did not notice it. On the other hand, activity in the
> Kino scene from Feb-May was slow as I was working on other things, and
> activity has recently picked up.
> 
> Nevertheless, I see our offending code in FrameDisplayer::PutXv. The fix
> will be in Kino 0.44. In the meantime, change FrameDisplayer.cc,
> FrameDisplayer::PutXv.
> FROM:
>         case e_dv_sample_411:
>         case e_dv_sample_422:
>             format = DV_FOURCC_YUY2;
>             len = frame.decoder->width * frame.decoder->height * 2;
>             break;
>         case e_dv_sample_420:
>             format = DV_FOURCC_YV12;
>             len = (frame.decoder->width * frame.decoder->height * 3) / 2;
>             break;
> 
> TO:
>         case e_dv_sample_411:
>         case e_dv_sample_420:
>         case e_dv_sample_422:
>             format = DV_FOURCC_YUY2;
>             len = frame.decoder->width * frame.decoder->height * 2;
>             break;
> 
> 
> +-DRD-+
> 
> From: "Chris Emerson"
> > On Fri, Jun 15, 2001 at 10:55:42AM -0400, Dan Dennedy wrote:
> > > Are the Kino users with Xv issues on NVIDIA cards using PAL or NTSC?
> Arne
> > > Schirmacher believes the issue is related to a change in libdv's PAL 
> YUV
> > > output. If you are an NTSC user, then please send the output of the
> xvinfo
> > > program.
> >
> > I have the issue with an ATI card on PPC.  I am indeed using PAL.
> >
> > Cheers,
> >
> > Chris
> >
> 
> 
> _______________________________________________
> mailing list lin...@li...
> http://lists.sourceforge.net/lists/listinfo/linux1394-devel
> 

[libdv-dev] RE: [Kino-dev] RE: Kino 0.43, XV output and NVidia cards

[Arne S. <ar...@sc...>]

I tried this, but it does not work correctly. The bottom half of the image 
is solid green, the top half has correct color but is scrambled.

However playdv will display PAL DV files. I saved a PAL file as DV and it 
displays with 30 fps. So even though libdv has changed, it will still 
decode PAL data. But I did not compare playdv and Kino's functions yet, but 
it is probably a trivial change (once you know where to look).

Arne

-----Original Message-----
From:	Dan Dennedy
Sent:	Friday, June 15, 2001 7:19 PM
To:	Chris Emerson
Cc:	lin...@li...; kino-dev; 
lib...@li...
Subject:	Re: [Kino-dev] RE:  Kino 0.43, XV output and NVidia cards

Right, well if Arne is correct, then the issue affects all PAL users using
libdv version 0.4+. From the libdv ChangeLog:
2001-02-06  Charles 'Buck' Krasic  <kr...@ac...>

	* Integrate patch from Stefan Lucke for various speedups:
[...]
           - change IEC PAL (420) to generate YUY2 instead of YV12.

--
However, I am surprised to hear about it now with libdv at version 0.8! I 
am
an NTSC user, so I did not notice it. On the other hand, activity in the
Kino scene from Feb-May was slow as I was working on other things, and
activity has recently picked up.

Nevertheless, I see our offending code in FrameDisplayer::PutXv. The fix
will be in Kino 0.44. In the meantime, change FrameDisplayer.cc,
FrameDisplayer::PutXv.
FROM:
        case e_dv_sample_411:
        case e_dv_sample_422:
            format = DV_FOURCC_YUY2;
            len = frame.decoder->width * frame.decoder->height * 2;
            break;
        case e_dv_sample_420:
            format = DV_FOURCC_YV12;
            len = (frame.decoder->width * frame.decoder->height * 3) / 2;
            break;

TO:
        case e_dv_sample_411:
        case e_dv_sample_420:
        case e_dv_sample_422:
            format = DV_FOURCC_YUY2;
            len = frame.decoder->width * frame.decoder->height * 2;
            break;


+-DRD-+

From: "Chris Emerson"
> On Fri, Jun 15, 2001 at 10:55:42AM -0400, Dan Dennedy wrote:
> > Are the Kino users with Xv issues on NVIDIA cards using PAL or NTSC?
Arne
> > Schirmacher believes the issue is related to a change in libdv's PAL 
YUV
> > output. If you are an NTSC user, then please send the output of the
xvinfo
> > program.
>
> I have the issue with an ATI card on PPC.  I am indeed using PAL.
>
> Cheers,
>
> Chris
>


_______________________________________________
mailing list lin...@li...
http://lists.sourceforge.net/lists/listinfo/linux1394-devel

[libdv-dev] Re: Fw: Kino frequently crashes on G3 Mac

[Chris E. <ch...@ta...>]

On Fri, Jun 15, 2001 at 05:41:15PM -0400, Dan Dennedy wrote:
> Check out this from Peter Hartmann, also a PAL user on Mac. Note that he had
> to patch libdv for endian issues. He is not using Xv, but I think this
> potentially points to some endian issues in libdv. I asked Peter to send his
> patches to libdv.

Ok, I was sent a patch to libdv from Stefan Lucke, which fixed the colour
problems with Xv but not the garbling.

> I am dropping linux1394-devel from the recipient list because it is off
> topic. Instead, I want you and Peter to collaborate with the libdv and Kino
> teams to resolve this. Also, please test libdv's playdv program because it
> too supports Xv.

playdv seems to have a different problem on my machine:
> ./playdv: error while loading shared libraries: /usr/lib/libSDL-1.1.so.0: R_PPC_REL24 relocation at 0x6fac8670 for symbol `location' out of range

This happens both with a self-compiled and packaged one.  I'm just rebuilding
libSDL in case that helps.

> One thing that concerns me with the capture2.jpg screen shot you sent me is
> that video only appears in half the height of the video drawable. If the YUV
> format is correct and there is only an endian issue, then the full height
> should be drawing with distortion. What version of libdv are you using?

I'm using 0.8.  With Stefan's patch it now looks like
http://www.tartarus.org/~chris/capture3.jpg
ie the same "shape" but correct colours.

> In reference to your other e-mail about screen captures with Xv, the X
> server knows nothing about the video. Video overlay is like a chroma key
> effect where the X server is reponsible for drawing a rectangle filled with
> a specific color.

Ah, that would explain some other strange effects I've seen.  Thanks.

> ----- Original Message -----
> From: "Peter Hartmann" <har...@de...>
> To: "Dan Dennedy" <dde...@co...>
[snip]
> > Kino is no more crashing on the G3, I had to patch libdv in a pretty
> > dirty way, but at least it works. My last problem is the framerate. I
> > can use GTK display only and I get about 1 frame per second. What is
> > your opinion: Is the processor too slow for dv decompression or is the
> > drawing routine the reason ?

I get a similarly bad framerate for both the GTK and the (mangled) Xv
displays, on a G4/350.

Cheers,

Chris

[libdv-dev] Fw: Kino frequently crashes on G3 Mac

[Dan D. <da...@de...>]

Check out this from Peter Hartmann, also a PAL user on Mac. Note that he had
to patch libdv for endian issues. He is not using Xv, but I think this
potentially points to some endian issues in libdv. I asked Peter to send his
patches to libdv.

I am dropping linux1394-devel from the recipient list because it is off
topic. Instead, I want you and Peter to collaborate with the libdv and Kino
teams to resolve this. Also, please test libdv's playdv program because it
too supports Xv.

One thing that concerns me with the capture2.jpg screen shot you sent me is
that video only appears in half the height of the video drawable. If the YUV
format is correct and there is only an endian issue, then the full height
should be drawing with distortion. What version of libdv are you using? The
Xv display format patch I just had you apply was for libdv v0.4+ -- at least
as far as I can tell from the dates in the libdv ChangeLog and the file
release dates on SourceForge.

In reference to your other e-mail about screen captures with Xv, the X
server knows nothing about the video. Video overlay is like a chroma key
effect where the X server is reponsible for drawing a rectangle filled with
a specific color.

----- Original Message -----
From: "Peter Hartmann" <har...@de...>
To: "Dan Dennedy" <dde...@co...>
Cc: <har...@pr...>; <pe...@ha...>;
<dv...@sc...>
Sent: Monday, June 11, 2001 12:19 PM
Subject: Re: Kino frequently crashes on G3 Mac


> Hi Dan,
>
> thanks for your answer. I'll try your patch as soon as I find the time
> (should be this week).
> Kino is no more crashing on the G3, I had to patch libdv in a pretty
> dirty way, but at least it works. My last problem is the framerate. I
> can use GTK display only and I get about 1 frame per second. What is
> your opinion: Is the processor too slow for dv decompression or is the
> drawing routine the reason ? I ordered the book Arne advised me to read,
> but it takes three weeks...Oh well.
>
> Take care
>
> Peter
>
>
> Dan Dennedy wrote:
> >
> > In Kino 0.43, I made an attempt to do an endian fix in riff.cc. Please
test
> > it and let me know how it works.
> >
> > As it turns out, the logic seems reversed. Apparantly, casting the
> > character pointer as a pointer to an unsigned int and then dereferencing
it
> > is causing the correct interpretation on a little endian machine with no
> > explicit byte swapping required! I do not know if the same holds true on
> > big endian. Therefore, I applied a bswap for big endian just to reverse
the
> > logic of the little endian case. In any case, just try it. If it fails
to
> > load an AVI, then try removing the call bswap in riff.cc. Maybe the cast
is
> > universal and no special handling is required anymore.
> >
> > On Tue, 05 Jun 2001 07:13:48 Peter Hartmann wrote:
> > > Hi Danny,
> > >
> > > I am kindof surprised that the patch does not work. I took
netinet/in.h
> > > and not something from endian.h because netinet is available also on
> > > other than GNU systems (e.g. HP/UX). After I read your mail I checked
my
> > > office linux box (Intel) out and - surprise - ntohl was commented out
in
> > > netinet/in.h. I do not have the faintest clue why this is so. Please
> > > accept my apologies.
> > >
> > > Peter
> > >
> > > Dan Dennedy wrote:
> > > >
> > > > Peter, this patch does not work for me. I tried htonl too. Both do
not
> > > byte
> > > > swap as needed. I do not know these as well as I should. What
#defines
> > > > __BYTE_ORDER, which is what <netinet/in.h> needs?
> > > >
> > > > On Fri, 01 Jun 2001 14:53:04 Peter Hartmann wrote:
> > > > > Hi Dan,
> > > > >
> > > > > here's a little patch for kino04b/src/riff.cc which enables kino
to
> > > read
> > > > > his own avi's on my G3 Mac (big endian):
> > > > >
> > > > > 27a28
> > > > > > #include <netinet/in.h>
> > > > > 38d38
> > > > > <     \bugs This code is byte-order dependent and runs only on
> > > > > little-endian (Intel) systems
> > > > > 50c50
> > > > > <         return (s[3] << 24) | (s[2] << 16) | (s[1] << 8) | s[0];
> > > > > ---
> > > > > >       return ntohl(*((long *) s));
> > > > > 652a653,656
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > Other than that Kino works fine except that it tends to crash
after
> > > some
> > > > > tens of seconds of video grabbing with a segmentation fault. I
> > > believe
> > > > > one reason (there are probably several different reasons) for
these
> > > > > crashes is a routine named dv_mb420_rgb in libdv/rgb.c. Is there
any
> > > > > chance to find documentation on the source code (or at least on
the
> > > > > compression algorithm) ?
> > > > > My biggest problem is that ddd/gdb do not seem to work on the
cores
> > > kino
> > > > > dumps. How do you guys do the debugging ?
> > > > >
> > > > > Peter
> > > > >
> > > > >
> > > > >
> > > > > Dan Dennedy wrote:
> > > > > >
> > > > > > We are still working on big endian support in the Linux IEEE
1394
> > > > > > subsystem. It seems awefully close, though. Since I do not
closely
> > > > > track
> > > > > > the issue, you should browse the linux1394-devel mail list
arhives.
> > > > > There
> > > > > > has been plenty of activity and patches sent around.
> > > > > > The fact that Kino showed something very much surprises me!
> > > Therefore,
> > > > > > maybe the endian issues are more related to ohci1394 and not
> > > pcilynx.
> > > > > This
> > > > > > is the first I have heard anyone trying to use dvgrab or Kino on
a
> > > > > Mac/big
> > > > > > endian. I suspect that some big endian users have at least tried
> > > > > dvgrab,
> > > > > > but I do not know their successes. Can you help us? Can you
program
> > > and
> > > > > > debug?
> > > > > > You can try some other programs too like dvcont
> > > > > > (http://sourceforge.net/projects/libavc1394/) or testlibraw,
which
> > > is a
> > > > > > test program included with the libraw1394 tarball (not RPM).
> > > > >
> > >
> > >
>
>

[libdv-dev] Re: [Kino-dev] RE: Kino 0.43, XV output and NVidia cards

[Chris E. <ch...@ta...>]

On Fri, Jun 15, 2001 at 02:19:04PM -0400, Dan Dennedy wrote:
> Nevertheless, I see our offending code in FrameDisplayer::PutXv. The fix
> will be in Kino 0.44. In the meantime, change FrameDisplayer.cc,
> FrameDisplayer::PutXv.
> FROM:
[snip]

I've made this change, but it ends up doing something differently wrong.
This time the image is green with some magenta bits, and slightly differently
garbled from before.  I could believe that it's an endianness problem and/or
the X server that's at fault rather than the same problem.

An example of what it looked like before is at
http://www.tartarus.org/~chris/capture1.jpg.  .../capture2.jpg is a similar
image after the change.  I'm afraid they're photos of the screen, as it
doesn't seem to be possible to take a real screenshot of the Xv stuff.
(I'm willing to be proved wrong, but I even tried "cat /dev/fb0")


Cheers,

Chris

Re: [libdv-dev] Problem decoding DV file

[Stefan L. <Ste...@sn...>]

On Friday 15 June 2001 09:13, Arne Schirmacher wrote:
> A Kino user sent in a file that displays correctly under Windows, but fails
> when displayed with Kino. I have converted the avi to *.dv, and this fails
> with the latest libdv from cvs too (although it looks different).
>
> Also, Windows Media Player says it is an NTSC format, but I think it should
> actually be PAL. But it looks good.
>
> The files are at http://www.schirmacher.de/tmp/, gen.dv is the good one,
> and calc.dv has been created from this one, but won't display.

In file calc.dv the DSF flag disappeared at the 6th frame when the effect
starts. So I had look at the file sizes:
  gen.dv  3600000 bytes / 144000 bytes (per frame) = 25 frames
  calc.dv 3120000 bytes / 144000 bytes             = 21.666 frames ????

but    5 * 144000 + 20 * 120000 = 3120000 bytes.
I think the sofware which generated the effect made an error !


Which program generated the effect ?
Is a plain .dv sequence of "The Surfer" available too ?
Was it possible to record avi sequence back to camcorder (with a M$ system) 
and playable ?

>
> Another issue, but unrelated to this one: when decoding the dv data
> generated by fast forward play of my camcorder, there will be always a
> crash sooner or later. It is easy to reproduce, just start Kino's preview
> window and do a fast forward play. I can also capture the offending frames
> if this is of any help.
>
> Arne

Stefan Lucke

[libdv-dev] Re: [Kino-dev] RE: Kino 0.43, XV output and NVidia cards

[Dan D. <da...@de...>]

Right, well if Arne is correct, then the issue affects all PAL users using
libdv version 0.4+. From the libdv ChangeLog:
2001-02-06  Charles 'Buck' Krasic  <kr...@ac...>

	* Integrate patch from Stefan Lucke for various speedups:
[...]
           - change IEC PAL (420) to generate YUY2 instead of YV12.

--
However, I am surprised to hear about it now with libdv at version 0.8! I am
an NTSC user, so I did not notice it. On the other hand, activity in the
Kino scene from Feb-May was slow as I was working on other things, and
activity has recently picked up.

Nevertheless, I see our offending code in FrameDisplayer::PutXv. The fix
will be in Kino 0.44. In the meantime, change FrameDisplayer.cc,
FrameDisplayer::PutXv.
FROM:
        case e_dv_sample_411:
        case e_dv_sample_422:
            format = DV_FOURCC_YUY2;
            len = frame.decoder->width * frame.decoder->height * 2;
            break;
        case e_dv_sample_420:
            format = DV_FOURCC_YV12;
            len = (frame.decoder->width * frame.decoder->height * 3) / 2;
            break;

TO:
        case e_dv_sample_411:
        case e_dv_sample_420:
        case e_dv_sample_422:
            format = DV_FOURCC_YUY2;
            len = frame.decoder->width * frame.decoder->height * 2;
            break;


+-DRD-+

From: "Chris Emerson"
> On Fri, Jun 15, 2001 at 10:55:42AM -0400, Dan Dennedy wrote:
> > Are the Kino users with Xv issues on NVIDIA cards using PAL or NTSC?
Arne
> > Schirmacher believes the issue is related to a change in libdv's PAL YUV
> > output. If you are an NTSC user, then please send the output of the
xvinfo
> > program.
>
> I have the issue with an ATI card on PPC.  I am indeed using PAL.
>
> Cheers,
>
> Chris
>

[libdv-dev] Problem decoding DV file

[Arne S. <ar...@sc...>]

A Kino user sent in a file that displays correctly under Windows, but fails 
when displayed with Kino. I have converted the avi to *.dv, and this fails 
with the latest libdv from cvs too (although it looks different).

Also, Windows Media Player says it is an NTSC format, but I think it should 
actually be PAL. But it looks good.

The files are at http://www.schirmacher.de/tmp/, gen.dv is the good one, 
and calc.dv has been created from this one, but won't display.

Another issue, but unrelated to this one: when decoding the dv data 
generated by fast forward play of my camcorder, there will be always a 
crash sooner or later. It is easy to reproduce, just start Kino's preview 
window and do a fast forward play. I can also capture the offending frames 
if this is of any help.

Arne

[libdv-dev] RE: Kino 0.43, XV output and NVidia cards

[Christoph S. <ch...@ne...>]

Hello Arne,

On Wed, Jun 13, 2001 at 11:50:06PM +0100, Arne Schirmacher wrote:
> I am convinced that this is a problem with libdv:
> 
> I tried Kino 0.33, which has a now obsolete libdv version included, 
> installed that libdv version and had a good XV image. Then I removed the 
> old libdv release, installed the version 0.8 of libdv and recompiled Kino: 
> the result was a green image with all parts of the original scene moved 
> around. So I think the problem is somewhere in the YUV code of libdv.
I initially had a very similar problem (scrambled green pictures) when I wrote
the DV decoding part for lav2yuv of the MJPEG project. In my case it was
related to the fact that the developers of libdv decided at some point that
the common output from both PAL and NTSC sources is packed YUV 422 with
repeated U and V information and not the generic YUV formats of PAL or NTSC
DV. The configure script of libdv still has an option (--with-pal-yv12 I
think) that generates planar YUV 420 (i.e. YV12) for PAL DV files.

That means that you will have to send the correct FOURCC for packed YUV 422 to
the Xserver and be sure to make the arrays for the U and V components twice as
large as you would expect for (non-professional) DV.

I hope that helps,

Christoph

------------------------------------------------------------------------------
 Christoph Scheurer              e-mail: ch...@fe...
 Department of Chemistry         WWW: http://nessy.chem.rochester.edu/~chris
 University of Rochester
 P.O. Box RC 270216              phone:  +1-716-275-8289
 Rochester, NY 14627-0216                +1-716-242-0989 (private)
 USA                             Fax:    +1-716-473-6889
------------------------------------------------------------------------------
      GnuPG public key: http://nessy.chem.rochester.edu/~chris/key.html

[libdv-dev] RE: Kino 0.43, XV output and NVidia cards

[Arne S. <ar...@sc...>]

I am convinced that this is a problem with libdv:

I tried Kino 0.33, which has a now obsolete libdv version included, 
installed that libdv version and had a good XV image. Then I removed the 
old libdv release, installed the version 0.8 of libdv and recompiled Kino: 
the result was a green image with all parts of the original scene moved 
around. So I think the problem is somewhere in the YUV code of libdv.

The version 0.33 is still on my website. You have to make a few changes to 
get it compiling with the latest libdv, but that is easy.

Arne

-----Original Message-----
From:	Steven Ellis
Sent:	Wednesday, June 13, 2001 12:29 AM
To:	kin...@li...
Cc:	lin...@li...
Subject:	Kino 0.43, XV output and NVidia cards


Managed to get a build of 0.43 running last nught with
some stability problems. My main issue is that video
output with XV and the NVidia native drivers on my
machine is all scrambled. I get a green picture and
the actual image is a real mess. My input is a
Panasonic NV DS15 camcorder.

Steve

=====
--
If you listen very carefully you can sometimes hear the dolphins sing

pin...@ya...

____________________________________________________________
Do You Yahoo!?
Get your free @yahoo.co.uk address at http://mail.yahoo.co.uk
or your free @yahoo.ie address at http://mail.yahoo.ie

_______________________________________________
mailing list lin...@li...
http://lists.sourceforge.net/lists/listinfo/linux1394-devel