I am using dvconnect with a JVC camcorder. I can download data from the camcorder using the following command:
dvconnect -v > test.dv
However when I try to upload data to the camcorder, the camcorder does not do anything. Here are the steps I use:
Put the JVC in PLAY mode. Hit the record button, the words "DV IN" appear in the viewfinder and I hear the miniDV tape cue up. I then issue the following command:
dvconnect -v -s test.dv
It buffers and then sends the frames. The camcorder however does nothing. It just sits there with the Time Code at 00:00:00. It this an incompatibility with my camcorder?
My OS is RedHat 7.1, Kernel 2.4.3, OHCI Card..
Thanks!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've installed linux 2.4.9 with the ieee1394 drivers from 2.4.6 plus the video1394 stuff from
kino 0.45. This seems to be the most reliable conglamoration of ieee1394 stuff available btw.
From kino I can export a movie back to the camcorder, so I now know that part is working.
Using kino, I've found the best results using a SYT of 14000.
I thought I'd give all my new-found knowledge a try with dvbackup. I ran several combinations of:
Have you had any luck downloading NTSC video generated by the 0.0.3 dvbackup -n? When I try to send it to the JVC the camcorder kicks out of 'DV IN' mode and I have to stop the dvconnect transfer before it will go back in.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can stream the dvbackup -n data to my camcorder
and see the tux picture on it. I can even record... for 1:05 seconds, then my camcorder
reboots herself. Peter is helping me
debug this problem.
As for your problem:
After the "DV-IN" disappears try hitting the start/stop button again. Your camcorder may just
be having problems syncing to the video thereby
displaying the default blue screen not leaving DV-IN mode.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is the exact same problem I am seeing. After examining the Tux image file in the source, the one that appears on the camcorder is larger and the red text that says dvbackup 0.0.3 is black and cut off. Let me know how you and Peter are doing.
Thanks again for your help and confirmation.
I have been able to get my kernel to panic a few times plugging and unplugging the IEEE-1394 cable to and from the camcorder. I would assume this is a problem with the IEEE-1394 code in the kernel.
Thanks again!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> After examining the Tux image file in the source, the one
> that appears on the camcorder is larger and the red text that
> says dvbackup 0.0.3 is black and cut off
That's OK. The U and V components are averaged across 4 pixels in horizontal direction for NTSC which leaves no chance for the red pixels to survive. Haven't really thought of this, when I drew the picture...
Greetings,
Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
About your kernel panic's. If you compile all
the ieee1394 stuff as modules, the kernel won't
crash and you can reset them with:
rmmod -r video1394
rmmod -r raw1394
modprobe video1394
modprobe raw1394
Every once in awhile I have to do this, but I'm
unable to find a pattern to it.
I always turn my camcorder off before I plug the
cable into it. It says to in the camcorder owner
manual.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It appears that you and I are the only two people to try to use dvbackup on an NTSC camcorder.
I stepped throught the kino ieee1394io.cc file comparing it to dvconnect.c and found that there was a condition for NTSC missing. I am now able to use dvconnect to stream dv data to and from my camcorder. My patched version is here:
Now for the bad news.... dvbackup doesn't appear to be NTSC compatable either :(. There IS a --ntsc-mode flag for dvbackup, and it does create output that is displayed on the camcorder, but it is just rainbow-like garbage (supposed to be a tux image i think). Furthermore, when I try to record this input to tape, my camcorder crashes.
-Tony
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I compiled your patched version, however my camcorder is still doing nothing. I tried adding the full parameters as you did to the dvconnect command but the camcorder still sits motionless.
I did get dvconnect into some kind of weird mode where it would only send seven frames and then stop. I tried unloading and reloading the 1394 kernel modules but that did not help. I also tried a warm boot, but the problem persisted. I finally powered down and backup. dvconnect began sending full dvclips again, just not to my camcorder. :-)
gscanbus does show the camera in record mode when 'DV IN' is on the camcorder display.
Good going on finding the NTSC bug!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Kino is suffering a similar fate on my JVC as well, although the camcorder does put a timestamp on the tape. I hear some different tape noises, but still, no video on the tape.
Kino captures just fine though.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So does the LCD screen on the camcorder flicker
or anything when streaming DV data to it?
What happens when you push record again when the
DV-IN is on the screen and data is being streamed? (this is how you record to tape on JVC's).
For reference, these are the commands I used to get successful results with dvconnect:
1. Record a sample movie with the camcorder
2. Rewind
3. Play movie
4. dvconnect --video-1394-version=2 --syt-offset=14000 > test.dv
5. Stop camcorder
6. Put camcorder in PLAY mode
7. dvconnect -s --video-1394-version=2 --syt-offset=14000 test.dv
Note I did not need to push record in order to see
the video on the screen as it was streamed to the
camcorder.
I'm assuming you are using kernel 2.4.9 with drivers/ieee1394 from 2.4.6 and the drivers/ieee1394/video1394.c and drivers/ieee1394/video1394.h from kino 0.45.
ALL other combinations have produced unstable results for me.
I upgraded my kernel from 2.4.3 to 2.4.9 and I can now stream video to the JVC using the following command:
dvconnect -s -v --video-1394-version=2 test.dv
If I omit the --video-1394-version=2 I just get a jitter of the blue screen on the camcorder. Playing with the SYT value can make it better or worse, but I never can get a good picture.
Thanks for all your help!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi I am using a JVC gr-DVM70 and am experiencing the exact same problems as above .. i am using
dvbackup-0.0.3
libdc1394-0.8.3
libraw1394_0.9.0
libavc1394-0.3.1
libdv-0.9
i am running gentoo with kernel 2.4.19 with ieee1394 built into the kernel i can control the camera fine with kino and gscanbus and dvgrab works flawlessly..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello!
I am using dvconnect with a JVC camcorder. I can download data from the camcorder using the following command:
dvconnect -v > test.dv
However when I try to upload data to the camcorder, the camcorder does not do anything. Here are the steps I use:
Put the JVC in PLAY mode. Hit the record button, the words "DV IN" appear in the viewfinder and I hear the miniDV tape cue up. I then issue the following command:
dvconnect -v -s test.dv
It buffers and then sends the frames. The camcorder however does nothing. It just sits there with the Time Code at 00:00:00. It this an incompatibility with my camcorder?
My OS is RedHat 7.1, Kernel 2.4.3, OHCI Card..
Thanks!
I have the same problem with a JVC DVM50U.
Using kernel 2.4.6, D-Link DFW-500 OHCI card.
The plot thickens...
I've installed linux 2.4.9 with the ieee1394 drivers from 2.4.6 plus the video1394 stuff from
kino 0.45. This seems to be the most reliable conglamoration of ieee1394 stuff available btw.
From kino I can export a movie back to the camcorder, so I now know that part is working.
Using kino, I've found the best results using a SYT of 14000.
I thought I'd give all my new-found knowledge a try with dvbackup. I ran several combinations of:
dvconnect --video-1394-version=2 --syt-offset=14000 --cip-n-ntsc=2436 --cip-d-ntsc=38400 -s test.dv -v
I still get ZERO feedback on the camcorder as the dv data is streamed to it.
Any ideas? Has anyone else with a JVC camcorder got dvconnect to work?
Tony,
Have you had any luck downloading NTSC video generated by the 0.0.3 dvbackup -n? When I try to send it to the JVC the camcorder kicks out of 'DV IN' mode and I have to stop the dvconnect transfer before it will go back in.
I can stream the dvbackup -n data to my camcorder
and see the tux picture on it. I can even record... for 1:05 seconds, then my camcorder
reboots herself. Peter is helping me
debug this problem.
As for your problem:
After the "DV-IN" disappears try hitting the start/stop button again. Your camcorder may just
be having problems syncing to the video thereby
displaying the default blue screen not leaving DV-IN mode.
This is the exact same problem I am seeing. After examining the Tux image file in the source, the one that appears on the camcorder is larger and the red text that says dvbackup 0.0.3 is black and cut off. Let me know how you and Peter are doing.
Thanks again for your help and confirmation.
I have been able to get my kernel to panic a few times plugging and unplugging the IEEE-1394 cable to and from the camcorder. I would assume this is a problem with the IEEE-1394 code in the kernel.
Thanks again!
> After examining the Tux image file in the source, the one
> that appears on the camcorder is larger and the red text that
> says dvbackup 0.0.3 is black and cut off
That's OK. The U and V components are averaged across 4 pixels in horizontal direction for NTSC which leaves no chance for the red pixels to survive. Haven't really thought of this, when I drew the picture...
Greetings,
Peter
About your kernel panic's. If you compile all
the ieee1394 stuff as modules, the kernel won't
crash and you can reset them with:
rmmod -r video1394
rmmod -r raw1394
modprobe video1394
modprobe raw1394
Every once in awhile I have to do this, but I'm
unable to find a pattern to it.
I always turn my camcorder off before I plug the
cable into it. It says to in the camcorder owner
manual.
Interesting, they are compiled as modules... hmm, no more hot swapping of the camcorder I guess. :-)
Hey Tony,
Thanks for all your work on this! I will give kino a try to verify that my setup will at least export video properly.
Thanks again!
w00t! I finally got dvconnect working!
It appears that you and I are the only two people to try to use dvbackup on an NTSC camcorder.
I stepped throught the kino ieee1394io.cc file comparing it to dvconnect.c and found that there was a condition for NTSC missing. I am now able to use dvconnect to stream dv data to and from my camcorder. My patched version is here:
http://tjw.org/dvbackup-0.0.2_ntsc_patched.tar.gz
Now for the bad news.... dvbackup doesn't appear to be NTSC compatable either :(. There IS a --ntsc-mode flag for dvbackup, and it does create output that is displayed on the camcorder, but it is just rainbow-like garbage (supposed to be a tux image i think). Furthermore, when I try to record this input to tape, my camcorder crashes.
-Tony
Hi Tony,
I compiled your patched version, however my camcorder is still doing nothing. I tried adding the full parameters as you did to the dvconnect command but the camcorder still sits motionless.
I did get dvconnect into some kind of weird mode where it would only send seven frames and then stop. I tried unloading and reloading the 1394 kernel modules but that did not help. I also tried a warm boot, but the problem persisted. I finally powered down and backup. dvconnect began sending full dvclips again, just not to my camcorder. :-)
gscanbus does show the camera in record mode when 'DV IN' is on the camcorder display.
Good going on finding the NTSC bug!
Also Tony,
Kino is suffering a similar fate on my JVC as well, although the camcorder does put a timestamp on the tape. I hear some different tape noises, but still, no video on the tape.
Kino captures just fine though.
So does the LCD screen on the camcorder flicker
or anything when streaming DV data to it?
What happens when you push record again when the
DV-IN is on the screen and data is being streamed? (this is how you record to tape on JVC's).
For reference, these are the commands I used to get successful results with dvconnect:
1. Record a sample movie with the camcorder
2. Rewind
3. Play movie
4. dvconnect --video-1394-version=2 --syt-offset=14000 > test.dv
5. Stop camcorder
6. Put camcorder in PLAY mode
7. dvconnect -s --video-1394-version=2 --syt-offset=14000 test.dv
Note I did not need to push record in order to see
the video on the screen as it was streamed to the
camcorder.
I'm assuming you are using kernel 2.4.9 with drivers/ieee1394 from 2.4.6 and the drivers/ieee1394/video1394.c and drivers/ieee1394/video1394.h from kino 0.45.
ALL other combinations have produced unstable results for me.
In kino, you should try to play with the SYT offset. See http://www.schirmacher.de/dcforum/DCForumID4/53.html
Success Tony!
I upgraded my kernel from 2.4.3 to 2.4.9 and I can now stream video to the JVC using the following command:
dvconnect -s -v --video-1394-version=2 test.dv
If I omit the --video-1394-version=2 I just get a jitter of the blue screen on the camcorder. Playing with the SYT value can make it better or worse, but I never can get a good picture.
Thanks for all your help!
Hi,
sorry about the late response, but I haven't noticed, that I have to monitor a forum to get messages by mail. Shame on me ;-)
I uploaded dvbackup-0.0.3 which at least includes the fixes by Tony and enough bugfixes to make NTSC work with playdv.
If this still doesn't fix the problem, please send me some e-mail.
Greetings,
Peter
Hi I am using a JVC gr-DVM70 and am experiencing the exact same problems as above .. i am using
dvbackup-0.0.3
libdc1394-0.8.3
libraw1394_0.9.0
libavc1394-0.3.1
libdv-0.9
i am running gentoo with kernel 2.4.19 with ieee1394 built into the kernel i can control the camera fine with kino and gscanbus and dvgrab works flawlessly..
I have at lease a similar problem with a JV GR-DVL725:-( I am very disappointed as I was really counting on using this for backups.
I also now get a VIDEO1394_TALK_WAIT_BUFFER: Bad address when issueing the following command although I feel like I got it to work at least once.
dvconnect -s --video-1394-version=2 --syt-offset=14000 dvbackup-0.0.4.tar.gz
any help is greatly appreciated, thanks.
I've found that adding a second or two delay after starting record helps quite a bit as well...