ofVideoGrabber format problem (OR: suggestions for a different webcam?)

I’m having the same problem that @joeseeba did five years ago with my brand new HD camera running at 10-15fps in oF. Did you ever figure anything out? I get the same output in the console when starting my camera:

[notice ] ofDirectShowGrabber: initGrabber(): choosing 1
SETUP: Setting up device 1
SETUP: HD Pro Webcam C920
SETUP: Couldn't find preview pin using SmartTee
SETUP: Default Format is set to 640 by 480
SETUP: trying requested format RGB24 @ 1920 by 1080
SETUP: trying format RGB24 @ 1920 by 1080
SETUP: trying format RGB32 @ 1920 by 1080
SETUP: trying format RGB555 @ 1920 by 1080
SETUP: trying format RGB565 @ 1920 by 1080
SETUP: trying format YUY2 @ 1920 by 1080
SETUP: Capture callback set
SETUP: Device is setup and ready to capture.

Specifying a texture type @ setup apparently does nothing, because even trying to set YUY2 directly with m_cam.setup(1920, 1080, OF_PIXELS_YUY2); gives the same console output.

I also found a topic from seven years ago about the same problem with the same camera from @georgeprofenza here. @arturo suggests ofxGStreamer but then says it can’t grab video from a camera in Windows yet. Has this changed in the past seven years?

@georgeprofenza suggested there might be a way to modify the ofVideoGrabber code, which uses a videoInput library from @theo . Any ideas there?

…or am I better off just buying a different webcam? What would be a good one that can run in HD in oF and Windows 11 at 30+fps?

Can you try building in release in you aren’t already?
If you are getting the issue in Release then it might be something on my end :slight_smile:

Hey @theo Yeah, I’m building in Release. In @georgeprofenza 's post, he linked to this stackOverflow post by someone having the same problem in Processing. The only answer is:

I ran into this problem a few months back as well. Here’s what I found, searching through forums and contacting customer support:

The Logitech C920 only provides 30fps at 1080p with applications that supports H.264 directly, and can pull in the H.264 stream directly from the camera. The C920 does on-board H.264 compression, but most applications don’t support pulling the compressed stream straight from the camera; instead, they have to decompress then re-compress the stream, dropping the framerate.

Skype supports H.264 straight from the camera, so with Skype you should be able to get 1920x1080 @ 30fps, but you won’t see this high framerate with Processing. Also, I think you have to use Windows to use the Logitech drivers to support this.

I’ll post the research I did a while back if I can find it, but unfortunately the answer is that you’ll have to drop either your resolution or your framerate.

So unless you’re planning to modify ofVideoGrabber to support H.264 straight from the camera, I guess I’ll need a new new webcam…

Trying to get modern hd cameras working at a 30 or 60 fps in oF is hard in Windows because, if I read the code correctly and understood it correctly, Videoinput library is based on the old infamous Windows Media Foundation. Which at least for me seems quite tricky and cumbersome both to use and when I try to modify Videoinput code. Expecially if your camera is recognized as a multiple device from the system things gets messy. In that case oF “sees” only one of the virtual devices, often the one having lower performance.That’s maybe because your “good” camera device lays behind several “tee” components and something always goes wrong when choosing the desired path.
I don’t have experience with Gstreamer on Windows, but on the other side on Linux it works very well with cameras. I wrote a class to get real 1920x1080 60fps video on a Jetson Nano from an Arducam. It works anyway from any cam or even movie files or anything scriptable and playable with a Gst Pipeline. And it stays quite light on the system even if for each frame it moves around 6MB of raw RGB (actually BGR) data from the Gst buffer to an ofTexture.
Maybe it works nicely even on Windows? For now I can’t test, I quitted developing on Windows and don’t know even if I still have Visual Studio installed. But before or after I’ll try, you made me curious.

Ohhh, can you send me the class so I can try it? Or would it be simpler to try using Gstreamer from scratch? @arturo Does this work on Windows now?

After finally getting the video loop working, it’d suck if I can’t get hd video… don’t want to have to try and redo the loop in TouchDesigner…

Hmm, looking at a similar issue with OpenCV which used videoInput I see some people getting faster fps with the mjpg subtype and not setting the frame rate.

Maybe try adding this to this:
VI.setRequestedMediaSubType(VI_MEDIASUBTYPE_MJPG);

to this line of ofDirectShowGrabber.cpp

@theo You’re a legend- it works great! Thank you so much. (and it seems to work even if I set the framerate)

I guess because of the larger file size the jpeg loop from my other thread runs slower now, so it seems I’ll have to use the camera in 1280x720 mode anyway. BUT, even in 1280x720 mode it’s still smoother now than it was before thanks to you. And it’s a very important fix in general.

1 Like

Oh wow, glad it works! :+1:

I’ll see if I can add an easier way to set this ( instead of hardcoding it ) maybe exposing it via the ofDirectShowGrabber to start with.

My ultimate goal is to move both video and grabber on Windows from DirectShow to WMF ( Windows Media Foundation ), but it will def be a project. Or maybe just to look into using gstreamer capture as it seems quite powerful across win/mac/linux.

I’m a bit late, I see Theo found a solution.
Great! Anyway I post here my GST class. It’s raw stuff, here it works fine on Linux and MacOS but I think it is a bit rough on the customizing side.
You have to install GST libraries on your machine, you should find instructions on their site.
I’m quite sure you have to change in gstplayer.h the line which contains the Gst Pipeline script, which sets up the frame grabbing process from camera. You’ll recognize it, I put a comment there. You should find on the web a pipeline that suits your system and your camera, I doubt mine will work since it has specific parameters for NVIDIA Jetson / CUDA / Linux.
This is the only part of the string which must be left as it is at the line end:

... ! fakesink name=sink silent=false -v"...

otherwise nothing works.
I also put here a test ofApp to show you how to use the class.

1 Like

you could try NDI tools too. (or Spout)
on one of their apps (virtual cam, screen capture, monitor etc) you can intialize the camera,
and then sending through the network to another computer or localhost.
then there are some NDI add-ons to receive the camera signal and draw into oF.
you should make a try and look how it performs, maybe could work better in some situations bc both apps run in parallel or bc better drivers/com on the NDI app.
could be comfy.

1 Like