Re: [libdv-dev] Compiling and Installing libdv - Video stabilities problems.

[Sergio R. <sr...@ya...>]

At 09:03 p.m. 13/07/2004 -0400, you wrote:
>On Tue, 2004-07-13 at 16:14, Sergio Roysen wrote:
> > Hi,
> >
> > I'm smashing my head against these problems.
> >
> > I'm trying to capture dv data from a camera. Using the stock libdv that
> > comes with the distro I'm using (SUSE 9.1 and libdv version 0.101-43, 
> guess
> > that would be 1.01 built 43) I noticed the video seems very unstable. At
> > time it turns to its negative form or to a sepia color, at times it shakes
> > or do some zomming in-out at its own will, at times it changes its aspect
> > ratio, at times it superimposes frames taken among several seconds (like
> > doing a fade in fade out). Assumed it has something to do with newer
> > versions of libdv so I uninstalled that stock version and installed the
> > 1.02 one. After the ./configure; make and make install everything 
> seemed to
> > be OK, no complains at all. But whenever I try to use dvconnect it does
> > nothing. And I mean nothing. Even trying 'dvconnect --version' does
> > nothing. The program just exits. I see no core dumps or segmentation
> > faults, and now I'm completely lost. playdv does something similar. If I
> > use playdv ExampleFile.dv, it plays the file, but if I use 'playdv
> > --version' it exits with the message "open:: No such file or directory".
>
>The problems you report are strange indeed, and I have not heard or
>experienced them. Is this on x86?

Yes. It's a quite standard PC clone.

>I can understand a potential problem with using 0.101 because we
>versioned it wrong and created a binary compatibility problem. But that
>is impossible with 0.102 due to the way it is versioned. Are you sure
>you completely uninstalled 0.101 and all of its utilities?

I certainly hope so (I mean: I hope everything was successfully uninstalled 
before installing the 1.02 version. Didn't really check so I'm going to 
take a look). Concerning the video stabilities issues, I don't think now it 
has something to do with libdv. If that was the case, the capture with 
MainActor should had worked OK, and it didn't. It showed exactly the same 
problems. It's not a problem with the players either. I exported the dv 
captured files to several machines with a variety of OS and players and all 
showed the same, so the problem is definitely in the captured file. I guess 
now the problem should be:
1) In the camera itself (a SONY TRV900 I'm using for the tests). Remember 
I'm not capturing a recorded tape but the live output from the firewire 
port. (just in case, I'm going to try the same with a recorded tape).
2) In the firewire card itself (using a cheap VIA chipset).
3) In the kernel drivers.

If it helps you to visualize the problem, the stabilities issues are cyclic 
and repetitive. They allways follow the same pattern.
1) The image goes to its negative form.
2) It goes to a sepia colour
3) it gets stretched along its height.
4) it gets stretched along its wide.
5) gets normal.
6) 5 seconds later it goes black, normal, black and white and finally 
normal again.
6) 10 seconds later it does a Zoom in which fades out to show the correct 
image.
7) Begin panning from left to right and right to left with some ghosting.
8) finally the image takes a sepia colour and then goes back to normal.
about two to three minutes later the cycle repeats.

This half an hour later than the paragraph before. I deserve to be beated 
with a baseball bat! The problem was too periodic and cyclic. It seems the 
camera in its regular configuration does some kind of calibration every 
couple of minutes (or may be the standby mode trying to kick in?). After I 
switched everything I could to 'manual', that video disturbances just... 
faded away.

If you remember I was assembling a setup for a video art exhibition where 
the video signal must be delayed before being exhibited. Now finally the 
setup is working as planned, using in the software side dvgrab instead of 
dvconnect, mplayer and a small utility I wrote to delay xxx seconds (a 
parameter) stdin before sending it to stdout. In the hardware side that PC 
clone I mentioned with two hard disks, a cheap firewire card and a cheap 
nvidia Geforce4 MX4000 card. Tweaking the XF86Config a little I got two 
completely independent screens, one for the monitor from the VGA connector 
and one for the TV-OUT connector, no twinview involved. As a side note, I 
don't even want to think in the beating these hard disk are going to take 
in the next two months.

Still can't figure out why dvconnect is so dead....
Thanks anyway!!!

Sergio Roysen
Buenos Aires,
Argentina


> > I know I must be doing something incredibly stupid, but I can't figure out
> > what. Also, is that kind of unstableness with the video common? What could
> > be its source?
>
>No, this is not common at all! There is a memory problem in 0.102 with
>certain applications but not playdv or dvconnect.
>
> > After trying a lot of things I installed the demo version of the MainActor
> > suite for video editing and it exhibits the same video stabilities issues.
> > Guess it doesn't use the libdv library, so this must be coming in from
> > another source. Any ideas?
>
>Hmm. Interesting, I now suspect the Xv extension of your X
>server/driver. See if disabling Xv and SDL playback in playdv helps, use
>the option "-d1" with playdv.