libdv-dev

Re: [libdv-dev] [Fwd: samples...]

[Roman S. <rv...@su...>]

On Tue, Jul 06, 2004 at 08:21:44PM -0400, Dan Dennedy wrote:
> I do not know off hand, as I have not worked much in the audio code. I
> forwarded to the libdv mailing list. Please use it.

 See ffmpeg's libavformat/dv.c dv_extract_audio() for details, but in short
 in each audio block you have dv_audio_source pack and it tells you how
 many *extra* samples there are. So
   #samples == (min. number of samples for the particular sampling rate) +
               dv_audio_source_pack[1] & 0x3f;

Thanks,
Roman.
 
> -----Forwarded Message-----
> > From: Lo"ic Gatineau <l_g...@ya...>
> > To: Dan Dennedy <da...@de...>
> > Subject: samples...
> > Date: Tue, 06 Jul 2004 14:41:35 +0200
> > 
> >   I have a problem about audio samples... In fact, in
> > dv_decode_audio_block() in audio.c, I don't know how
> > locate the moment where it is the end of the samples
> > and the bigining of the unused space at the end of
> > each frame... (SMPTE 314 M, SS4.6.2.1.5 p.14). I will
> > be very happy if you can help me ! ;o)
> > 
> >   Thank you...
> > 
> > Lo"ic Gatineau.
> > 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> libdv-dev mailing list
> lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libdv-dev

[libdv-dev] Re: libdv 0.103 release

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

On Wed, 2004-07-14 at 12:31, Charles 'Buck' Krasic wrote:

> Also, "bootstrap" is now deprecated, as autoreconf can do the same
> things, and it is distributed as part of the autoconf package.

Cool, I did not know that!

Re: [libdv-dev] defined but unused variables

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

On Wed, 2004-07-14 at 16:30, Johannes Sixt wrote:
> On Mittwoch, 14. Juli 2004 04:03, Dan Dennedy wrote:
> > Also, as planned, dv1394.h is gone now too.
> 
> What is the official way to access the API that it contained?
> Am I supposed to do this:
> 
> #include </usr/src/linux/drivers/ieee1394/dv1394.h>
> #include </usr/src/linux/drivers/ieee1394/ieee1394-ioctl.h>

No, make a copy of dv1394.h into your local app. Don't worry, the
interface has never changed and will never changed as the module
gradually becomes the deprecated.

Re: [libdv-dev] defined but unused variables

[Johannes S. <joh...@te...>]

On Mittwoch, 14. Juli 2004 04:03, Dan Dennedy wrote:
> Also, as planned, dv1394.h is gone now too.

What is the official way to access the API that it contained?
Am I supposed to do this:

#include </usr/src/linux/drivers/ieee1394/dv1394.h>
#include </usr/src/linux/drivers/ieee1394/ieee1394-ioctl.h>

-- Hannes

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.

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

[Johannes S. <joh...@te...>]

On Dienstag, 13. Juli 2004 22: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".

strace -o /tmp/trace dvconnect

may reveal some additional clues.

-- Hannes

[libdv-dev] Re: libdv 0.103 release

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

Ok, I've generated the 0.103 release.

As part of the release, I've made some minior build changes, and
additions to CVS relating to the build.

Hopefully now, one can do a build from CVS or from the distribution
tarball without having autotools installed.  Of course, the correct
version of autotools would still be needed if you want to change
something in the build files.

Also, "bootstrap" is now deprecated, as autoreconf can do the same
things, and it is distributed as part of the autoconf package.

-- Buck


On Wed, 2004-07-14 at 04:16, Dan Dennedy wrote:
> On Wed, 2004-07-14 at 00:14, Charles 'Buck' Krasic wrote:
> > On Tue, 2004-07-13 at 20:33, Dan Dennedy wrote:
> > > Hi, we are ready for the 0.103 libdv release. Nothing major here - just
> > > bugfixes. Since I now have priveleges to post files to the SourceForge
> > > project I could post a source tarball. But how are you creating the
> > > various RPMs? Is there a process you follow? Does it require access to a
> > > RedHat machine - I do not have one - or are there machines at SF to use
> > > for this purpose?
> > 
> > Making the rpms is pretty straightforward, the libdv makefiles are
> > setup for it, so its just:  make rpm
> > 
> Would you please do the packaging and release, then? I do not currently
> have any rpm-based machines.
> I noticed with my very recent versions of autotools that Makefile.am no
> longer needs to include ltconfig and mkinstalldirs; they cause 'make
> dist' to fail. I did not remove them yet in CVS' Makefile.am.
> 
> 
> 

[libdv-dev] Re: stdint.h in libdv

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

On Sun, 2003-11-23 at 17:38, Avinoam Kalma wrote:
> In the next version of libdv (1.00?) please add a checker for
> stdint.h. It is not common to all systems (eg SGI does not have it).

I have replaced all stdint.h with inttypes.h. According to autoconf info
doc "Portability of Headers" topic, this is the way to go.

Re: [libdv-dev] defined but unused variables

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

On Wed, 2004-03-17 at 00:51, Steven M. Schultz wrote:
> Hi!
> 
> 	Compiling libdv gives 3 warning errors for every module:
> 
> ../libdv/dv_types.h:138: warning: `header_size' defined but not used
> ../libdv/dv_types.h:139: warning: `frame_size_525_60' defined but not used
> ../libdv/dv_types.h:140: warning: `frame_size_625_50' defined but not used
> 

These are gone now.
Also, as planned, dv1394.h is gone now too.

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

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

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?
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 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.

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

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

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".

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?
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?

Thanks,

Sergio Roysen
Buenos Aires
Argentina.

Re: [libdv-dev] [PATCH] Encoding video in threaded applications

[Johannes S. <joh...@te...>]

On Samstag, 10. Juli 2004 23:06, Dan Dennedy wrote:
> Hopefully, I have finished tying up the other loose ends others notified
> me about when I called for a new release recently. Are we all ready now?

It's fine with me.

I intend to hack the assembly code to get rid of global scratch variables (and 
the mutexes). That can wait for a future release, of course.

-- Hannes

Re: [libdv-dev] [PATCH] Encoding video in threaded applications

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

On Sat, 2004-07-10 at 16:27, Johannes Sixt wrote:
> On Montag, 5. Juli 2004 18:04, Dan Dennedy wrote:
> >
> > I applied your patch in CVS and added your test program too. When I run
> > the test program in parallel mode without the mutex locks, I am seeing
> > nice clean, gray images. I do not deny your results, but I am curious.
> 
> I've run the test program on a 4-CPU machine (Dual-Xeon + hyperthreading). 
> Maybe that makes the difference?
> 
Could be. My dual athlon machine's motherboard died recently :-/

Hopefully, I have finished tying up the other loose ends others notified
me about when I called for a new release recently. Are we all ready now?

Re: [libdv-dev] [PATCH] Encoding video in threaded applications

[Johannes S. <joh...@te...>]

On Montag, 5. Juli 2004 18:04, Dan Dennedy wrote:
> On Sun, 2004-06-20 at 04:31, Johannes Sixt wrote:
> > To test the current implementation I have used the attached test program.
> > See the comments at the top about compilation and usage. It writes the
> > encoded raw DV frames (which should be all gray) to stdout. You will see
> > (eg. in kino) that the encoded frames are not gray at all if the frames
> > are encoded in parallel, but they are if encoded sequentially.
>
> I applied your patch in CVS and added your test program too. When I run
> the test program in parallel mode without the mutex locks, I am seeing
> nice clean, gray images. I do not deny your results, but I am curious.

I've run the test program on a 4-CPU machine (Dual-Xeon + hyperthreading). 
Maybe that makes the difference?

Anyway, thanks for applying the patch.

-- Hannes

Re: [libdv-dev] call for 0.103 release

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

On Tue, 2004-07-06 at 05:29, Daniel Kobras wrote:
> On Mon, Jul 05, 2004 at 05:40:23PM -0400, Dan Dennedy wrote:
> > With recent bugfixes in place, I would like to issue a new release for
> > libdv. Any concerns?
> 
> Trying to view pond.dv in kino, I see an artifact every 32nd frame: The
> image looks scaled down, with blue bars appearing to the left and the
> right instead. It seems that backing out the wide screen fix cures this
> issue. At least it did so in a quick test last week. Can't tell for sure
> now because the sourceforge CVS appears to be broken currently. Can
> someone else confirm this bug?

Yes, I see it. Doh!
I am lucky that the pond.dv apparantly has a glitch such every 30th
frame indicates it adheres to SMTPE 314M as opposed to IEC 61834 because
it exposed the typo resulting in swapped logic for SMPTE videos. Fix is
in CVS.

Re: [libdv-dev] call for 0.103 release

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

Thanks as always, Stephen. Your patch is committed along with the
automake fix.

On Tue, 2004-07-06 at 11:14, Steven M. Schultz wrote:
> On Mon, 5 Jul 2004, Dan Dennedy wrote:
> 
> > With recent bugfixes in place, I would like to issue a new release for
> > libdv. Any concerns?
> 
> 	I see a couple automake warnings come out during ./bootstrap
> 
> libdv/Makefile.am:68: reppm_SOURCES multiply defined in condition TRUE ...
> libdv/Makefile.am:65: ... `reppm_SOURCES' previously defined here.
> libdv/Makefile.am:69: reppm_LDADD multiply defined in condition TRUE ...
> libdv/Makefile.am:66: ... `reppm_LDADD' previously defined here.
> 
> 	but more serious are a couple compile errors on a  system using gcc
> 	2.95.3:
> 
> encode.c: In function `dv_encode_full_frame':
> encode.c:1711: syntax error before `static'
> encode.c:1722: `mutex' undeclared (first use in this function)
> 
> 	That's caused by using a gcc 3.x'ism that 2.95.3 doesn't like.  Moving
> 	the time initialization down a line fixes that problem.  Then the
> 	next gotcha is in enctest (a similar error).
> 
> 	The attached patch enables building with gcc 2.95.x 
> 
> 	Cheers,
> 	Steven Schultz

[libdv-dev] [Fwd: samples...]

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

I do not know off hand, as I have not worked much in the audio code. I
forwarded to the libdv mailing list. Please use it.

-----Forwarded Message-----
> From: Lo=EFc Gatineau <l_g...@ya...>
> To: Dan Dennedy <da...@de...>
> Subject: samples...
> Date: Tue, 06 Jul 2004 14:41:35 +0200
>=20
>   I have a problem about audio samples... In fact, in
> dv_decode_audio_block() in audio.c, I don't know how
> locate the moment where it is the end of the samples
> and the bigining of the unused space at the end of
> each frame... (SMPTE 314 M, =A74.6.2.1.5 p.14). I will
> be very happy if you can help me ! ;o)
>=20
>   Thank you...
>=20
> Lo=EFc Gatineau.
>=20

Re: [libdv-dev] call for 0.103 release

[Steven M. S. <sm...@2B...>]

On Mon, 5 Jul 2004, Dan Dennedy wrote:

> With recent bugfixes in place, I would like to issue a new release for
> libdv. Any concerns?

	I see a couple automake warnings come out during ./bootstrap

libdv/Makefile.am:68: reppm_SOURCES multiply defined in condition TRUE ...
libdv/Makefile.am:65: ... `reppm_SOURCES' previously defined here.
libdv/Makefile.am:69: reppm_LDADD multiply defined in condition TRUE ...
libdv/Makefile.am:66: ... `reppm_LDADD' previously defined here.

	but more serious are a couple compile errors on a  system using gcc
	2.95.3:

encode.c: In function `dv_encode_full_frame':
encode.c:1711: syntax error before `static'
encode.c:1722: `mutex' undeclared (first use in this function)

	That's caused by using a gcc 3.x'ism that 2.95.3 doesn't like.  Moving
	the time initialization down a line fixes that problem.  Then the
	next gotcha is in enctest (a similar error).

	The attached patch enables building with gcc 2.95.x 

	Cheers,
	Steven Schultz

Re: [libdv-dev] call for 0.103 release

[Daniel K. <ko...@li...>]

On Mon, Jul 05, 2004 at 05:40:23PM -0400, Dan Dennedy wrote:
> With recent bugfixes in place, I would like to issue a new release for
> libdv. Any concerns?

Trying to view pond.dv in kino, I see an artifact every 32nd frame: The
image looks scaled down, with blue bars appearing to the left and the
right instead. It seems that backing out the wide screen fix cures this
issue. At least it did so in a quick test last week. Can't tell for sure
now because the sourceforge CVS appears to be broken currently. Can
someone else confirm this bug?

Regards,

Daniel.

Re: [libdv-dev] Delaying a video signal: Some basic questions.

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

On Mon, 2004-07-05 at 17:50, Sergio Roysen wrote:

> You mean I'll get a wrong aspect ratio? If that's the case, do you know 
> about any other player that can take the raw dv output from dvconnect and 
> play it properly?

I recommend trying mplayer. I would recommend Xine if they would stop
breaking raw DV support.

> If I cannot get a proper PAL or NTSC signal from the TV-out connector, What 
> is it good for?

You can get a proper NTSC or PAL signal; the difficulty is in
synchronizing another video source that originated in NTSC or PAL with
the output signal.

Re: [libdv-dev] Delaying a video signal: Some basic questions.

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

On Mon, 2004-07-05 at 18:15, Charles 'Buck' Krasic wrote:

> This is a bit pessimistic.   Recent drivers have done a better job of
> dealing with vertical retrace, and pretty much eliminate tearing.    

Yeah, probably for his need it is good enough. But I would definitely
opt for the DV-to-analog conversion in an external device if available.

Re: [libdv-dev] Delaying a video signal: Some basic questions.

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

On Mon, 2004-07-05 at 13:17, Dan Dennedy wrote:

> > 2) How to use the TV-out connector found in NVIDIA and ATI cards for the 
> > delayed signal? What parameters should playdv be feed?
> > Guess it has something to do with the --display=(0|1|2|3) parameter but I 
> > have not the slightest idea about the differences between gtk, Xv, and SDL, 
> > and, unfortunately it's beyond the amount of effort I can put in this 
> > project to study them in detail. (also, since I do all of my work in 
> > console mode, I'd love to see the solution implemented without having to go 
> > into X-Windows or depend on some of its libraries).

> Trying to output a NTSC or PAL video from the computer using a TV-Out
> feature is frought with problems. The biggest problem is that there is
> no vertical blanking/retrace interrupt with which to synchronize the
> video playback: how will you prevent "tearing" and make sure that the
> proper field (interlaced video) is displayed at the same field the TV
> Out is playing? Therefore, you pretty much have to deinterlace while
> resampling non-square pixels to square-pixels and hope something like
> XV_DOUBLE_BUFFER can handle the vertical blanking interrupt issue.

This is a bit pessimistic.   Recent drivers have done a better job of
dealing with vertical retrace, and pretty much eliminate tearing.    

I'd recommend getting an nvidia card, and installing nvidia's linux
drivers.   Their just released nvidia-settings utility lets you
explicitly control whether the driver should syncronize with vertical
retrace.

-- Buck

Re: [libdv-dev] Delaying a video signal: Some basic questions.

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

First of all, thanks Dan por your answer.
Then some more questions:

At 04:17 p.m. 05/07/2004 -0400, you wrote:
>On Mon, 2004-07-05 at 13:49, Sergio Roysen wrote:
> > Hi, hope some of the expert in this forum can help me.
> >
> > For a video art presentation involving several video signal (both recorded
> > and live), the specification for one of the live signals calls for a delay
> > of around five minutes before been exhibited. The video artist (a friend)
> > called me for help but I'm afraid I'm way out of my league on this (I do
> > mostly C programming for specialized databases engines under Linux). I
> > thought I could use dvconnect to capture the signal (the camera, a SONY
> > PC150 has a firewire connection) and playdv to show it five minutes later
> > in a scheme like this:
> >
> > dvconnect - | delay_five_minutes | playdv
> >
> > Here, delay_five_minutes should be a program (easy to write) that takes 
> its
> > input from stdin, stores it in a disk buffer and begins to output it to
> > stdout five minutes later (I also have plans to use two disks for these
> > buffer, one for getting the data in and one for getting the data out and
> > switch its use every five minutes).
> >
> > The input should be taken through firewire, and the output must be SVHS.
> > Video quality is not an issue, so I can live with some dropped frames.
> > The signals will all be PAL, but the only testing environment I has to
> > develop the solution is NTSC.
> >
> > I have several questions regarding this rather crude solution.
> >
> > 1) I don't see any parameter in the man page for playdv to take the video
> > stream from stdin. Is it posible?
>
>Yes. playdv with no args will play from stdin. Of course, without that
>you could have tried /dev/stdin or a fifo. The key thing, however, is to
>use option --no-mmap. However, playdv is not a very player and certainly
>not good for this application. For one, it does not resample to square
>pixels as used on your computer monitor if you try to play through X...

You mean I'll get a wrong aspect ratio? If that's the case, do you know 
about any other player that can take the raw dv output from dvconnect and 
play it properly?

> > 2) How to use the TV-out connector found in NVIDIA and ATI cards for the
> > delayed signal? What parameters should playdv be feed?
> > Guess it has something to do with the --display=(0|1|2|3) parameter but I
> > have not the slightest idea about the differences between gtk, Xv, and 
> SDL,
> > and, unfortunately it's beyond the amount of effort I can put in this
> > project to study them in detail. (also, since I do all of my work in
> > console mode, I'd love to see the solution implemented without having 
> to go
> > into X-Windows or depend on some of its libraries).
>
>Trying to output a NTSC or PAL video from the computer using a TV-Out
>feature is frought with problems. The biggest problem is that there is
>no vertical blanking/retrace interrupt with which to synchronize the
>video playback: how will you prevent "tearing" and make sure that the
>proper field (interlaced video) is displayed at the same field the TV
>Out is playing? Therefore, you pretty much have to deinterlace while
>resampling non-square pixels to square-pixels and hope something like
>XV_DOUBLE_BUFFER can handle the vertical blanking interrupt issue.
>
>Your best bet is to use an inexpensive DV/Analog converter box or the DV
>camera! Try using dvconnect to playback a raew DV stream you captured.
>You won't have much to worry about the issues above as long as it works.
>However, you might see some instability in the output due to interrupt
>and scheduling latency. So you will want to do a little read-ahead
>buffering on the disk I/O.

Unfortunately, the remaining budget is very tight and it would be next to 
imposible to rent 'just another piece of hardware'.
Can't use the same video camera because it's the only one available and 
it's required to take the video in signal I have to delay _all the time_.
If I cannot get a proper PAL or NTSC signal from the TV-out connector, What 
is it good for?
This signal is going to be entered in a switcher for more processing 
(chroma key and mix with another signal). The switcher is a PANASONIC 
WJ-MX20 model (in case you know something about it; may be there is 
something in it I can use for proper synchronization).
As you can see I'm pretty much stuck with that TV-out connector. Any other 
suggestions?

> > 3) Will it work? (the most I could get for the PC is a 2.4 GHz Pentium 4
> > with 256 Mb of RAM).
>
>yes

Again, thanks for you knowledge and time,

Sergio Roysen
Buenos Aires,
Argentina

[libdv-dev] call for 0.103 release

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

With recent bugfixes in place, I would like to issue a new release for
libdv. Any concerns?
 

Re: [libdv-dev] Delaying a video signal: Some basic questions.

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

On Mon, 2004-07-05 at 13:49, Sergio Roysen wrote:
> Hi, hope some of the expert in this forum can help me.
> 
> For a video art presentation involving several video signal (both recorded 
> and live), the specification for one of the live signals calls for a delay 
> of around five minutes before been exhibited. The video artist (a friend) 
> called me for help but I'm afraid I'm way out of my league on this (I do 
> mostly C programming for specialized databases engines under Linux). I 
> thought I could use dvconnect to capture the signal (the camera, a SONY 
> PC150 has a firewire connection) and playdv to show it five minutes later 
> in a scheme like this:
> 
> dvconnect - | delay_five_minutes | playdv
> 
> Here, delay_five_minutes should be a program (easy to write) that takes its 
> input from stdin, stores it in a disk buffer and begins to output it to 
> stdout five minutes later (I also have plans to use two disks for these 
> buffer, one for getting the data in and one for getting the data out and 
> switch its use every five minutes).
> 
> The input should be taken through firewire, and the output must be SVHS.
> Video quality is not an issue, so I can live with some dropped frames.
> The signals will all be PAL, but the only testing environment I has to 
> develop the solution is NTSC.
> 
> I have several questions regarding this rather crude solution.
> 
> 1) I don't see any parameter in the man page for playdv to take the video 
> stream from stdin. Is it posible?

Yes. playdv with no args will play from stdin. Of course, without that
you could have tried /dev/stdin or a fifo. The key thing, however, is to
use option --no-mmap. However, playdv is not a very player and certainly
not good for this application. For one, it does not resample to square
pixels as used on your computer monitor if you try to play through X...

> 2) How to use the TV-out connector found in NVIDIA and ATI cards for the 
> delayed signal? What parameters should playdv be feed?
> Guess it has something to do with the --display=(0|1|2|3) parameter but I 
> have not the slightest idea about the differences between gtk, Xv, and SDL, 
> and, unfortunately it's beyond the amount of effort I can put in this 
> project to study them in detail. (also, since I do all of my work in 
> console mode, I'd love to see the solution implemented without having to go 
> into X-Windows or depend on some of its libraries).

Trying to output a NTSC or PAL video from the computer using a TV-Out
feature is frought with problems. The biggest problem is that there is
no vertical blanking/retrace interrupt with which to synchronize the
video playback: how will you prevent "tearing" and make sure that the
proper field (interlaced video) is displayed at the same field the TV
Out is playing? Therefore, you pretty much have to deinterlace while
resampling non-square pixels to square-pixels and hope something like
XV_DOUBLE_BUFFER can handle the vertical blanking interrupt issue.

Your best bet is to use an inexpensive DV/Analog converter box or the DV
camera! Try using dvconnect to playback a raew DV stream you captured.
You won't have much to worry about the issues above as long as it works.
However, you might see some instability in the output due to interrupt
and scheduling latency. So you will want to do a little read-ahead
buffering on the disk I/O.

> 3) Will it work? (the most I could get for the PC is a 2.4 GHz Pentium 4 
> with 256 Mb of RAM).

yes