Hi Mike,
Thank you very much for your help, the sysfs interface did get the
device work indeed. Since the many folders to tune sysfs disappear every
time the device is unplugged, I have created a script to update the
.../ctl_input folder's 'cur_val' value to s-video. Little bit odd as
those folders are owned by root so you need root privileges to do that,
but it does work. Btw, is there any way to change those default values
in the ../ctl_... folders so that you do not have to use the script
every time? These folders seem to be generated by V4L so perhaps you can
instruct V4L what the default values should be.
Using V4L applications is not an option for me as the camera will be
used in an imaging application with an embedded computer so I need to
get the video stream for image processing purposes, not just for
watching the video on screen. But this way it should work.
Thanks a lot again for the fast response and for your determination to
help people out,
Tamas
Mike Isely wrote:
On Tue, 21 Apr 2009, Tamas Szecsi wrote:
Hi all,
I am trying to use a Canon VC-C4 analogue videocamera in Linux
(Ubuntu). I have used it with a Belkin frame-grabber in Windows but
there seems to be no Linux support for that. So instead I bought a
WinTV PVR USB2 (as there appears to be an excellent support group and
discussion forum for it).
I have connected the camera to the SVideo input of the WinTV, in the
Windows WinTV programme I set up the SVideo input for PAL_BGHIDK (I
live in Ireland). Then I tested the setup in Ulead Videostudio (for
Windows), it was abled to capture the video, so everything seems to be
working fine with Windows. However, I have problems with the Linux
installation.
The 'mplayer /dev/video0' command only produces a snowflake-like
image, as if I am using a channel without a signal on it. The 'cat
/dev/video0 >test.mpg' command does produce a video file, but again,
when watched on mplayer it is still the same 'empty' video.
There seems to be a conflict between the 'Detected format' (NTSC-M)
and the 'Specified standard' (PAL-BDGHI). Any help would be
appreciated. I have attached below the 'standard' printouts for the
device that appear in most mailing lists.
[...]
My first guess is similar to yours - a mismatch of the video standard.
When you cat from /dev/video0 (or use mplayer), you're not using the
actual V4L API. That itself is not really a problem, however it means
that you're not doing anything to configure the driver for things like,
for example, the video standard. It's entirely possible that the wrong
video standard was used. However I'm not 100% because if you have a PAL
vs NTSC foulup, you'll generally see *something* though it won't be
usable. But you're describing snow which suggests no signal at all. As
for the cx25843 log messages, the "detected format" doesn't carry any
meaning if there's no signal. And the fact that the specified standard
looks right means that this aspect seems not to be the problem.
Another (very likely) issue is that you don't have the right input
selected. Again, unless you did something to set up the driver before
cat'ing from /dev/video0 then the driver is just going to use its
current settings. And certainly in that case the driver defaults to the
RF tuner, not the S-video input.
The way to solve this is through the sysfs driver interface. Read here:
http://www.isely.net/pvrusb2/usage.html#sysfs
Then look at ctl_input/cur_val and ctl_video_standard/cur_val. You can
do all of this from a simple shell. Check that those are correct (and
if not, correct them). Then try mplayer again.
If you run a V4L app, like MythTV, xawtv or the tv-viewer app I had
mentioned a short while ago, then you don't have to worry about the
sysfs interface. In those V4L cases, the controls all are available via
the V4L API, and your app will take care of it.
Let me know if that helps.
-Mike
_______________________________________________
pvrusb2 mailing list
[email protected]
http://www.isely.net/cgi-bin/mailman/listinfo/pvrusb2
