So after extensive testing of UVC devices, the common denominator that gets me kinda mad is this:
Frame times are never consistent polling from UVC devices in OBS on Linux, especially trying for 60fps.
I’ve done this on two machines now, a 4960X and a 3600X machine and each time I use a UVC device, it just doesn’t seem to want to have good frame time consistency.
Even when I use UVC on USB 2.0 with 60fps MJPEG capable devices it just never seems to be consistent.
Both devices are from Avermedia, one is the ExtremeCap UVC and the other is the new PW315 webcam. Reviews on Windows show both devices properly adhering to frame timings. As soon as I use both devices on Linux, frame time consistency instantly becomes hit or miss in OBS.
All my PCI-E based Blackmagic cards don’t do this BTW. qv4l2 also has smooth frame times for the PW315. (can’t say the same for the ExtremeCap UVC though for 59.94fps)
ALL UVC capture cards I’ve tried run into this issue where OBS on Linux can’t frame pace it correctly.
This is something to do with how OBS handles V4L2, but I’m unable to pinpoint the cause without more testing from other people with diverse hardware.
I genuinely wish someone took a look at how this bothersome issue crops up on Linux and I’m also fearful it might affect Looking Glass capture as well.
I haven’t really noticed this with my card but then again I’m a fairly casual user. Question is if this is an issue with OBS or the UVC driver. Have you contacted OBS about this via Discord or Github? I think they also have an IRC channel on Freenode(?).
I get into too many fights with dev communities. I much rather someone go through the effort to test how many frames are unique or are skipped to show this is a problem that only exists on Linux. Whenever I use qv4l2, this isn’t a issue pulling the raw frames, but as soon as OBS uses it, there’s frame time inconsistency.
Well but if noone contacts them about it you won’t see any change either…
It seems you already did extensive testing on it, so documenting it and then bringing it to their attention would plainly be the best course of action. Sometimes you just gotta fight through it to see change. I don’t know many people that do this kind of testing in the first place.
EposVox is trying to make a CLI for frame pacing detection, but not sure if it helps this.
I literally just tested my 10920X Ubuntu 20.04.2 system with the latest OBS and both the Webcam and the ExtremeCap UVC eventually ran into the same issue, but not at the same time, so they get the same symptom but desynchronous of each other. It’s not a bandwidth issue as the ExtremeCap was on 3.0 and the PW315 was on 2.0 MJPEG.
You can tell it is an artifact that makes it into the recording because bad frame times appear both on the canvas and the properties window simultaneously with the same pattern when modifying properties of the UVC device.
This pattern is also identical each time frame times stutter. It is not random. All framerates were matched to 60.00, with no render lag, and it’s still doing this but only for the UVC sources.
This basically means Blackmagic cards are literally it when it comes to capture cards that produce consistent frame times.
I was literally stumped at why frame times were inconsistent on the PW315 which on Windows was proven to consistently deliver 60fps… Then I realized this is a bigger problem. All UVC devices have the same problem in OBS Linux.
Here’s proof EposVox is on his way to making a CLI frame time analysis tool:
So had a lightbulb moment. If someone out there is able to see if it’s specifically the V4L2 capture in OBS that’s causing the issue, see if Magewell or Datapath PCI-E cards (if they use V4L2 on Linux) or 60fps camera modules over MIPI CSI-2 (that have to use V4L2) to compare qv4l2 and OBS. If it exhibits the same behavior I observed, despite those not being UVC sources, it’s a V4L2 OBS problem. IF however, one of those device types does not exhibit the issue, it’s a UVC problem with how it interacts with OBS. My guess is all instances of qv4l2 will not exhibit out of order or dropped frames, but OBS over V4L2 will either only have problems with UVC devices, or it’s a general flaw never caught since testing probably was done with sources no greater than 30fps, and was only done through spot checking.
I do not have this hardware and likely won’t ever get either a Magewell or YUAN or Datapath PCI-E card, or a MIPI CSI-2 camera module.
Listen, if Perseverance can use FLIR camera modules with UVC and V4L2 no problem, something’s gotta give to find out why OBS can’t produce the same result on Linux.
Just to reconfirm, I did an NDI source from a separate machine transmitting NDI and no issues were to speak of with frame time inconsistency. I can also assume the Looking Glass client for OBS might also work better than UVC and V4L2. If OBS can’t fix this issue (It can only grab the source at an awkward frame rate like 59.50 for 60.00) then I’m going to have to get a NDI encoder, because the V4L2 issues at high frame rates of 60fps are driving me nuts.
Well, I managed to piss off Xaymar. I’ve proven once again I do get into fights with dev communities.
Not sure of the context, i.e. what this is responding to tho.
Xaymar is doing a lot of deep dives into the encoding side of things though
Late reply, but yeah, I forgot MPEG LA licensing fees for using H265 in streaming content, and producing content in H265 has a really steep fee. That’s what I totally forgot in that conversation with Xaymar.