Video Capture Device Input not detected

[redmage19]

I just recently started obs. It detects my webcam, but it doesn't detect input from my HD video capture device. When I select to add HD video capture device, there is no video, but there is video for web cam. When I try to select input for the HD video capture device, there is only one usb option, which is the same usb option for the web cam. Please don't delete my post. I need help.

20:09:28.035: Using EGL/X11

20:09:28.053: CPU Name: Intel(R) Pentium(R) CPU J3710 @ 1.60GHz

20:09:28.053: CPU Speed: 1849.504MHz

20:09:28.053: Physical Cores: 4, Logical Cores: 4

20:09:28.053: Physical Memory: 3826MB Total, 721MB Free

20:09:28.053: Kernel Version: Linux 5.4.0-155-generic

20:09:28.053: Distribution: "Ubuntu" "20.04"

20:09:28.053: Desktop Environment: LXDE (LXDE)

20:09:28.053: Session Type: x11

20:09:28.053: Window System: X11.0, Vendor: The X.Org Foundation, Version: 1.20.13

20:09:28.055: Qt Version: 5.12.8 (runtime), 5.12.8 (compiled)

20:09:28.055: Portable mode: false

20:09:28.224: OBS 29.1.3 (linux)

20:09:28.224: ---------------------------------

20:09:28.225: ---------------------------------

20:09:28.225: audio settings reset:

20:09:28.225: samples per sec: 48000

20:09:28.225: speakers: 2

20:09:28.225: max buffering: 960 milliseconds

20:09:28.225: buffering type: dynamically increasing

20:09:28.263: ---------------------------------

20:09:28.263: Initializing OpenGL...

20:09:28.376: Loading up OpenGL on adapter Intel Open Source Technology Center Mesa DRI Intel(R) HD Graphics 405 (BSW)

20:09:28.376: OpenGL loaded successfully, version 4.6 (Core Profile) Mesa 21.2.6, shading language 4.60

20:09:28.522: ---------------------------------

20:09:28.522: video settings reset:

20:09:28.522: base resolution: 1280x720

20:09:28.522: output resolution: 1280x720

20:09:28.522: downscale filter: Bicubic

20:09:28.522: fps: 60/1

20:09:28.522: format: NV12

20:09:28.522: YUV mode: Rec. 709/Partial

20:09:28.522: NV12 texture support not available

20:09:28.522: P010 texture support not available

20:09:28.541: Audio monitoring device:

20:09:28.541: name: Default

20:09:28.541: id: default

20:09:28.541: ---------------------------------

20:09:28.553: os_dlopen(/usr//lib/x86_64-linux-gnu/obs-plugins/aja-output-ui.so->/usr//lib/x86_64-linux-gnu/obs-plugins/aja-output-ui.so): /usr//lib/x86_64-linux-gnu/obs-plugins/aja-output-ui.so: undefined symbol: __libc_single_threaded

20:09:28.553:

20:09:28.553: Module '/usr//lib/x86_64-linux-gnu/obs-plugins/aja-output-ui.so' not loaded

20:09:28.564: os_dlopen(/usr//lib/x86_64-linux-gnu/obs-plugins/aja.so->/usr//lib/x86_64-linux-gnu/obs-plugins/aja.so): /usr//lib/x86_64-linux-gnu/obs-plugins/aja.so: undefined symbol: __libc_single_threaded

20:09:28.564:

20:09:28.564: Module '/usr//lib/x86_64-linux-gnu/obs-plugins/aja.so' not loaded

20:09:28.569: Failed to load 'en-US' text for module: 'decklink-captions.so'

20:09:28.574: Failed to load 'en-US' text for module: 'decklink-output-ui.so'

20:09:28.581: A DeckLink iterator could not be created. The DeckLink drivers may not be installed

20:09:28.581: Failed to initialize module 'decklink.so'

20:09:28.988: v4l2loopback not installed, virtual camera disabled

20:09:28.998: [obs-browser]: Version 2.21.1

20:09:28.998: [obs-browser]: CEF Version 103.0.5060.134 (runtime), 103.0.0-5060-shared-textures_143.2591+g4204d54+chromium-103.0.5060.134 (compiled)

20:09:29.087: VAAPI: API version 1.7

20:09:29.087: FFmpeg VAAPI H264 encoding supported

20:09:29.091: FFmpeg VAAPI HEVC encoding not supported

20:09:29.123: [obs-websocket] [obs_module_load] you can haz websockets (Version: 5.2.3 | RPC Version: 1)

20:09:29.123: [obs-websocket] [obs_module_load] Qt version (compile-time): 5.12.8 | Qt version (run-time): 5.12.8

20:09:29.123: [obs-websocket] [obs_module_load] Linked ASIO Version: 101202

20:09:29.148: [obs-websocket] [obs_module_load] Module loaded.

20:09:29.174: [vlc-video]: VLC 3.0.9.2 Vetinari found, VLC video source enabled

20:09:29.174: ---------------------------------

20:09:29.174: Loaded Modules:

20:09:29.174: vlc-video.so

20:09:29.174: text-freetype2.so

20:09:29.174: rtmp-services.so

20:09:29.174: obs-x264.so

20:09:29.174: obs-websocket.so

20:09:29.174: obs-vst.so

20:09:29.175: obs-transitions.so

20:09:29.175: obs-outputs.so

20:09:29.175: obs-libfdk.so

20:09:29.175: obs-filters.so

20:09:29.175: obs-ffmpeg.so

20:09:29.175: obs-browser.so

20:09:29.175: linux-v4l2.so

20:09:29.175: linux-pulseaudio.so

20:09:29.175: linux-jack.so

20:09:29.175: linux-capture.so

20:09:29.175: linux-alsa.so

20:09:29.175: image-source.so

20:09:29.175: frontend-tools.so

20:09:29.175: decklink-output-ui.so

20:09:29.175: decklink-captions.so

20:09:29.175: ---------------------------------

20:09:29.175: ==== Startup complete ===============================================

20:09:29.294: All scene data cleared

20:09:29.294: ------------------------------------------------

20:09:29.314: pulse-input: Server name: 'pulseaudio 13.99.1'

20:09:29.316: pulse-input: Audio format: s16le, 48000 Hz, 2 channels

20:09:29.316: pulse-input: Started recording from 'alsa_output.pci-0000_00_1b.0.analog-stereo.monitor' (default)

20:09:29.317: [Loaded global audio device]: 'Desktop Audio'

20:09:29.542: pulse-input: Server name: 'pulseaudio 13.99.1'

20:09:29.545: pulse-input: Audio format: s16le, 44100 Hz, 2 channels

20:09:29.546: pulse-input: Started recording from 'alsa_input.pci-0000_00_1b.0.analog-stereo'

20:09:29.566: pulse-am: Server name: 'pulseaudio 13.99.1'

20:09:29.568: pulse-am: Audio format: s16le, 48000 Hz, 2 channels

20:09:29.569: pulse-am: Started Monitoring in 'alsa_output.pci-0000_00_1b.0.analog-stereo'

20:09:29.569: [Loaded global audio device]: 'Mic/Aux'

20:09:29.569: - monitoring: monitor only

20:09:29.570: v4l2-input: Start capture from /dev/video0

20:09:29.824: v4l2-input: Input: 0

20:09:29.833: v4l2-input: Resolution: 1920x1080

20:09:29.833: v4l2-input: Pixelformat: MJPG

20:09:29.833: v4l2-input: Linesize: 0 Bytes

20:09:29.833: v4l2-input: Framerate: 30.00 fps

20:09:29.861: v4l2-input: /dev/video0: select timeout set to 166666 (5x frame periods)

20:09:29.877: alsa-input: PCM 'front:CARD=USB,DEV=0' rate set to 44100

20:09:29.878: alsa-input: PCM 'front:CARD=USB,DEV=0' channels set to 2

20:09:30.052: v4l2-input: Start capture from /dev/video2

20:09:30.052: v4l2-input: Unable to open device

20:09:30.052: v4l2-input: Initialization failed, errno: No such file or directory

20:09:30.057: Switched to scene 'Scene'

20:09:30.058: ------------------------------------------------

20:09:30.058: Loaded scenes:

20:09:30.058: - scene 'Scene':

20:09:30.058: - source: 'phone' (v4l2_input)

20:09:30.058: - source: 'camera' (v4l2_input)

20:09:30.058: - source: 'cam audio' (alsa_input_capture)

20:09:30.058: ------------------------------------------------

20:09:30.208: v4l2-input: /dev/video0: select timed out

20:09:30.208: v4l2-input: /dev/video0: failed to log status

20:10:21.712: v4l2-input: Device /dev/video2 reconnected

20:10:21.712: v4l2-input: Start capture from /dev/video2

20:10:21.714: v4l2-input: Input: 0

20:10:21.738: v4l2-input: Resolution: 1920x1080

20:10:21.738: v4l2-input: Pixelformat: MJPG

20:10:21.738: v4l2-input: Linesize: 0 Bytes

20:10:21.738: v4l2-input: Framerate: 60.00 fps

20:10:21.757: v4l2-input: /dev/video2: select timeout set to 83333 (5x frame periods)

20:10:21.850: v4l2-input: /dev/video2: select timed out

20:10:21.850: v4l2-input: /dev/video2: failed to log status

20:10:21.934: v4l2-input: /dev/video2: select timed out

20:10:21.934: v4l2-input: /dev/video2: failed to log status

 

[AaronD]

As I said in a different thread here, not everything works with Linux, because they don't use the established standards. They do their own thing, and rely on proprietary drivers to work at all, and the manufacturers don't take Linux seriously when they write that driver.

So those devices just don't work on Linux, unless someone wants to reverse-engineer the Windows driver. And they probably won't work on future versions of Windows either, because the same manufacturer doesn't value their own old products.

Try to not support manufacturers that create e-waste like that.

 

[Markosjal]

As I said in a different thread here, not everything works with Linux, because they don't use the established standards. They do their own thing, and rely on proprietary drivers to work at all, and the manufacturers don't take Linux seriously when they write that driver.

So those devices just don't work on Linux, unless someone wants to reverse-engineer the Windows driver. And they probably won't work on future versions of Windows either, because the same manufacturer doesn't value their own old products.

Try to not support manufacturers that create e-waste like that.

Unfortunately we never know what is e-waste till we buy it.

 

[AaronD]

Unfortunately we never know what is e-waste till we buy it.

True, and that's partly what communication is for within the community, which seems to be lacking in my experience.

But requiring a driver that only the manufacturer can provide, instead of following established standards so anyone can provide that driver, makes it far more likely.

They write a driver for Windows 10/11 only, then abandon the product, and then Windows 15 drops support for the way that that driver worked. And it's prohibitively expensive to reverse engineer from hardware units and software binaries. Now nobody can use that device, despite the physical units having never been damaged.

Following the standard allows anyone to (re)write a driver that makes that standard work, and so the device keeps working forever as long as the OS continues to support that standard. That's far more likely than a for-profit manufacturer continuing to support their ancient products.

 

[AaronD]

...that's partly what communication is for within the community, which seems to be lacking in my experience.

Okay, a different thread just happened to mention this:

Certified Devices | OBS

OBS (Open Broadcaster Software) is free and open source software for video recording and live streaming. Stream to Twitch, YouTube and many other providers or record your own videos with high quality H264 / AAC encoding.

obsproject.com

But the fact that this site's navigation didn't already lead me to it, especially when I was looking to replace my cheap deceptively-advertised one a few months ago, is a case in point of poor communication.

This site's navigation is terrible anyway. There's also no easily-discovered link to the Log Analyzer, so some of us, including myself recently, have added it to their signatures. What else are we missing?

 

[Markosjal]

True, and that's partly what communication is for within the community, which seems to be lacking in my experience.

But requiring a driver that only the manufacturer can provide, instead of following established standards so anyone can provide that driver, makes it far more likely.

They write a driver for Windows 10/11 only, then abandon the product, and then Windows 15 drops support for the way that that driver worked. And it's prohibitively expensive to reverse engineer from hardware units and software binaries. Now nobody can use that device, despite the physical units having never been damaged.

Following the standard allows anyone to (re)write a driver that makes that standard work, and so the device keeps working forever as long as the OS continues to support that standard. That's far more likely than a for-profit manufacturer continuing to support their ancient products.

"the standard"? to what "standard do you refer? You seem to refer to some standard that should be used in linux that comes from another OS. That in itself is ridiculous.

There is no guarantee that neither LInux, Windows nor Mac will support the hardware used currently in any next version. What you get in linux is someone who is desperate enough and who has the knowledge to write a driver, then doing so. Thjere is no guarantee of anything there is no "abandnware prevention" on any platform. Even windows 10 removed support for many firewire cards via updates to windows 10. The Mac is no better they seem to have now abandoned their own firewire child altogether.

 

[AaronD]

"the standard"? to what "standard do you refer? You seem to refer to some standard that should be used in linux that comes from another OS. That in itself is ridiculous.

There are actually a couple of them. Doesn't matter which one is used, so long as it's already in widespread use, well documented to the public, and not a recent invention by the manufacturer.

There is no guarantee that neither LInux, Windows nor Mac will support the hardware used currently in any next version. What you get in linux is someone who is desperate enough and who has the knowledge to write a driver, then doing so. Thjere is no guarantee of anything there is no "abandnware prevention" on any platform. Even windows 10 removed support for many firewire cards via updates to windows 10. The Mac is no better they seem to have now abandoned their own firewire child altogether.

The only reason Firewire died is because USB was better overall. Yes, FW was faster at the time, mostly because it had direct access to the system memory without using the CPU at all like USB did and still does, and then the CPU could look later at what showed up there. But that was also its downfall. Direct access to memory is awesome for efficiency, but terrible for security. Coffin sealed. THEN, computers got fast enough to drive a FW link through the CPU instead, and run the security checks on it, but it was already decided by that point.

In the early days of a particular type of device or connection, yes, there will be guaranteed abandonment of the devices that "lost", but we're well past that for video capture. USB is here to stay, as is running video through that connection. How that video gets *into* the card is irrelevant. No excuse now, to not follow a "plug conversion standard" (as consumers see it) that has existed for about as long as USB has had that capability, and become deeply ingrained in almost every OS's included library of generic drivers.

That library is not going away either. It would require deletion of code that works, not addition of something that may still have bugs, and that's a massively big deal on the development side. Breaking stuff that already works is bad, unless you have a VERY good and well-supported reason for it. Your two examples - Windows and Mac - come from corporate bean counters, who put that bean count over their product's actual usefulness.

Someone writing the established-standard drivers for Linux...already happened ages ago. So that point is moot. And they're not going away (previous paragraph). Just stop re-inventing the same wheel, and copy-paste what is known to work. Support manufacturers who do that, not the ones who reinvent the same thing.

Because of how the ecosystem tends to work, "just working" on a free system - any free system - tends to at least be a good suggestion of that, if not stronger. There's no money involved in supporting the free thing, so if it works there, then they're either altruistic or they've actually followed an existing standard. Likely the latter, though I *have* seen the former as well.

As an altruistic example, one of my rigs is set up to automatically rebuild a driver from source whenever the kernel gets updated. And yes, that driver is distributed from the manufacturer as source code, and a script to build it that really does "just work". No need to understand any of it; just run the script, reboot, and then the capture works. The source code and the build script don't change at all - it just runs again after every kernel update - so I'd still call that *somewhat* "future proof". Borderline on what I'm really going for, leaning towards not because of the extra step.

And I have some other capture cards too, that do just plug in and work on Linux. End of effort.

 

[Markosjal]

There are actually a couple of them. Doesn't matter which one is used, so long as it's already in widespread use, well documented to the public, and not a recent invention by the manufacturer.


The only reason Firewire died is because USB was better overall. Yes, FW was faster at the time, mostly because it had direct access to the system memory without using the CPU at all like USB did and still does, and then the CPU could look later at what showed up there. But that was also its downfall. Direct access to memory is awesome for efficiency, but terrible for security. Coffin sealed. THEN, computers got fast enough to drive a FW link through the CPU instead, and run the security checks on it, but it was already decided by that point.

In the early days of a particular type of device or connection, yes, there will be guaranteed abandonment of the devices that "lost", but we're well past that for video capture. USB is here to stay, as is running video through that connection. How that video gets *into* the card is irrelevant. No excuse now, to not follow a "plug conversion standard" (as consumers see it) that has existed for about as long as USB has had that capability, and become deeply ingrained in almost every OS's included library of generic drivers.

That library is not going away either. It would require deletion of code that works, not addition of something that may still have bugs, and that's a massively big deal on the development side. Breaking stuff that already works is bad, unless you have a VERY good and well-supported reason for it. Your two examples - Windows and Mac - come from corporate bean counters, who put that bean count over their product's actual usefulness.

Someone writing the established-standard drivers for Linux...already happened ages ago. So that point is moot. And they're not going away (previous paragraph). Just stop re-inventing the same wheel, and copy-paste what is known to work. Support manufacturers who do that, not the ones who reinvent the same thing.

Because of how the ecosystem tends to work, "just working" on a free system - any free system - tends to at least be a good suggestion of that, if not stronger. There's no money involved in supporting the free thing, so if it works there, then they're either altruistic or they've actually followed an existing standard. Likely the latter, though I *have* seen the former as well.

As an altruistic example, one of my rigs is set up to automatically rebuild a driver from source whenever the kernel gets updated. And yes, that driver is distributed from the manufacturer as source code, and a script to build it that really does "just work". No need to understand any of it; just run the script, reboot, and then the capture works. The source code and the build script don't change at all - it just runs again after every kernel update - so I'd still call that *somewhat* "future proof". Borderline on what I'm really going for, leaning towards not because of the extra step.

And I have some other capture cards too, that do just plug in and work on Linux. End of effort.

You fail to mention any ONE of these standards by name. I know my card is using an open source driver that was bundled into ubuntu. I never installed any driver to get it working with OBS.

It is not linux's fault that there is no working driver for the capture card you have. In fact it is your own. If you did not do your research before buying and if you could not read the box or expected the Windows drivers to work with Linux then its all on YOU.

You seem to imply that writing a driver is a trivial matter and you can "copy and paste" and if that is the case, then stop complaining and start copying and pasting what you need.

V4Linux is only a standard INTERFACE , and I do not believe it has any bearing on the code written to get there . For instance I wrote software compatible with the eSCL scanning standard (aka AirScan , or Mopria Scan) That is only a standard for an Interface and although much code is written in C++, i happened to write mine in php and it gets me to the same place and works perfectly with the eSCL standard interface.

All your whining and you still have not even said what card you have and that is the most basic thing to say.

Maybe you should just run your card under whatever OS it is "officially supported" in or write your own driver as you seem to imply is so trivial.

 

[AaronD]

You seem to imply that writing a driver is a trivial matter and you can "copy and paste" and if that is the case, then stop complaining and start copying and pasting what you need.

Not the driver, and not the Linux devs. It's the hardware and manufacturers. That mis-focus invalidates most of what else you said.

And yes, there is something to be said about extensive research beforehand...which gets back to communication within the community, or lack thereof.