B. Bogart wrote:
Hi,
Thanks for the clarification Chris, I had a feeling you would know the answer.
I got some ffmpeg sample code from the net and I'll take a look to see if that loads the file fine and go from there.
I thought I would mess around with my iBot camera today, I had to manually create the /dev/video1394/0 device, but now coriander sees the camera and will display the output. So the question is how do I tell pix_video to look at it? pix_video reports both 1394 and v4l support. I messed with "driver 0|1" and "device 0|1" but could not get anything out of it. I find these messages really confusing, often devices and drivers are considered the same thing.. blech. "device /dev/video1394/0" would actually be easier...
actually i am wondering now, why i didn't do it like that... i have no idea what happens if i open an ieee1394-device with the v4l-api. would it crash ? so that is why i chose to differentiate between the 2 "driver"-APIs with a message, and to separate between hardware devices (camera1, camera2) with another message.
apart from that: [pix_video] (in ieee1394 mode) tries to open /dev/ieee1394/dv/host#/{PAL,NTSC}/in, where "#" can be defined via the "device"-option. this device is created (with devfs) by the module "dv1394". i do know that devfs has been deprecated for some time, and i don't know how udev behaves in this way. the fallback (if there is no /dev/ieee1394/dv/host#/{PAL,NTSC}/in) is /dev/dv1394 (which might be created by udev (or by hand :-())
mfg.asd.r IOhannes