Menu
▾
▴
#130 HDV cameras do not work in WCS
What steps will reproduce the problem?
1. Connect an HDV camera via Firewire
2. Add a DV Firewire device to the current WCS environment. Select the relevant device from the Firewire sources list.
3. Turn on the Firewire source in WCS
What do you see instead (of expected output)?
No display of camera feed in WCS.
The Operating system you are using (Linux, Windows etc)?
Linux
What version of WebcamStudio are you using?
0.73 build 589
What version of Java are you using?
java -version
openjdk version "1.8.0_45-internal"
OpenJDK Runtime Environment (build 1.8.0_45-internal-b14)
OpenJDK 64-Bit Server VM (build 25.45-b02, mixed mode)
What is your Webcamera vendor, model and version?
Canon Vixia HV40
Basically, HDV cameras need different input processing than DV cameras. I haven't figured out exactly what's needed yet. dvgrab can get video from the camera, but I don't have a gstreamer pipeline that converts that to the decoded RGB frames that WCS needs. gstreamer also has an hdv1394src plugin (allowing it to read the Firewire bus itself instead of via dvgrab) but so far I've had no luck using that to feed anything.
Ideally it'd probably be nice to have just one Firewire device dialog which could auto-detect the type of device - but I'm not really sure how to do that. Alternately we could add another separate device dialog for HDV devices
After some further experiementation I've managed to cook up a gstreamer pipeline that reads the HDV camera, though not with audio. For now that work is being placed in DV.properties alongside the commands for normal DV devices
I added a new source button for HDV (right next to the DVCam button) so HDV has its own procedure that's cloned from the DVCam support but otherwise independent of it.
Audio is not supported at present - I just haven't managed to get any gstreamer HDV pipeline involving audio to work.
In the newly-added HDV.properties file, the best-performing filter in my experience is the third one, which uses gstreamer's glcolorscale filter to scale the video and set the encoding. (The CPU overhead of bilinear-scaling HD video is considerable, and offloading that to the GPU is a significant improvement in this case.) However, by default the one I presently enable is the second one, which uses software scaling and deinterlacing. I chose that one as the default to maximize compatibility, and because GL acceleration can really backfire sometimes.
So there's still room for improvement, but HDV is now supported.
Hi George,
i try WS build 593 and from my tests seems that with the new implementation of MasterFrameBulder the FX like Twirl, WaterFX, and some others if applied to a movie take fps down from 25 to 15 or less. In the previous build with the same stream, resolution, FX and frame rate, the effects applied without slowing down fps mixer. I also try FX facedetector in a webcam, and seems that WS hardly handle it with the new MasterFrameBuilder, but the fps remains ok. I have to say that this FX are very heavy indeed.
Thanks.
karl
I added frame dropping to the implementation to try to address the issues I've been seeing. That's probably why:
Previously the frame builder would try to stick to a very rigid 30:033fps schedule: producing new frames at T(x)=T0+(33ms * x). But invariably it'd reach a state of being behind schedule, where the current time is greater than T(x), and once behind schedule, it would stay behind schedule (because MFB always has to wait for the next source frame before producing the next output frame, and the sources run at 30fps)
Now, when MasterFrameBuilder thinks it's behind schedule, it drops a frame to save CPU time in the mixer. That helps when the app is choking due to CPU limits, but unfortunately it also means it'll drop frames when the sources aren't producing them as fast as expected. So turning frame-dropping on by default was probably a mistake.
That said, the current implementation is a stopgap: my next step is to decouple the timing of MFB from the timing of the sources so the two won't produce all these unfortunate interactions. That should clear up the current issues with frame dropping as well.