• Intro/Overview
  • Decode Mode Support
  • Notes on RGB Color Space
  • Format Support
  • Notes on Scaler Support
  • Input Latency Testing
  • Notes on “Bitrate” support
  • Testing Methodology
  • Limitations & Future Improvement
  • How to submit capture cards for testing


IN THIS RESOURCE: I will provide extensive documentation about the connection types, supported decode modes, supported resolutions, frame rates, passthrough, and input latency (to preview) of every capture card I have access to.

This will be an evolving project - I will be testing every capture card I can get my hands on moving forward and updating this guide along the way, potentially for years to come. I only have access to so many capture cards at this exact moment, but I’m constantly reviewing more, and am trying to test as many as possible. Have a capture card you want me to test? Check out the last section in this guide.

I have posted a breakdown/walkthrough of this Resource to my YouTube channel - this explains each of the charts, some of my reasoning and thinking process, etc. Keep in mind that this is simply a snapshot of things at the time of posting, whereas this Resource page will remain updated.

[For those interested in the raw data (which will be updated sooner than this Resource) you can view my Google Sheets workbook (multiple sheets) here.]


Decode Mode Support

Some buyers are looking for capture cards that provide specific decode modes to the user. These are color compression formats (not to be confused with data compression) that affect the bandwidth required by the video feed through the device, as well as the total image quality.
Common decode modes include:
  • YUY2 - 4:2:2 color space, uncompressed data stream
    • This is the most common, and generally the target you want to aim for
    • Requires more bandwidth over USB/PCIe bus, but has minimal system resource load and latency
  • MJPEG - Compressed data stream, can be 4:2:0, 4:4:4, or 4:2:2
    • Literally “Motion JPEG” - it’s JPEG (like the photos) image compression
    • Lower bandwidth over USB/PCIe bus, but requires your CPU to decode the stream before re-encoding on your OBS canvas. Increases system resource load and latency.
    • Usually through UVC protocols, MJPEG is 4:2:2
  • YV12/NV12 - 4:2:0 color space, uncompressed data stream
    • Elgato’s preferred decode mode
    • Requires less bandwidth over USB/PCIe bus than YUY2 (more than MJPEG), should have less system resource impact as well - unless OBS is set to RGB mode or something (in advanced settings)
  • RGB (XRGB) - 4:4:4 completely uncompressed color and data stream
    • Much less common
    • Best possible quality image, improves scaling and final encode quality
    • Uses much more bandwidth than any other mode

[link to high res copy]

Here are the supported (and functional) decode modes exposed to OBS Studio from the capture cards I have tested. Do note that the native applications respective to specific capture cards may only allow or utilize one of these modes.

The “UYVY” mode is essentially the exact same as YUY2. It’s 4:2:2 and etc.
“P010” is a compressed color mode for HDR encoding from HDR-compatible capture cards (namely from AVerMedia).
Any capture card (such as the original Elgato Game Capture HD) that shows a “h264” decode mode is likely exposing the on-board encoder’s feed from the card and is going to take even more work from your CPU to decode prior to encoding, cause even more latency, etc. It is not recommended to use these modes. (And no, this will not allow you encode your OBS stream using the capture card’s encoder. There’s a specific plugin for this integrated for only the original AVerMedia Live Gamer HD, but does not apply to anything else.)

(Information on YUV/etc. color spaces: 1, 2, 3)

Notes on RGB Color Space
Also I wanted to point out that current drivers for Elgato capture cards may show XRGB/RGB modes in OBS Studio - however these are not real. They’re emulated (or simulated?) from the 4:2:0 color space that those devices primarily operate in. Using them may result in a solid color screen, washed out view, or just add more resource load to your system as the driver is taking the 4:2:0 color feed and converting it to the emulated RGB mode and then OBS has to convert it back to NV12 for your stream. Elgato does not recommend using these modes and neither do I.

Full 4:4:4 RGB support in general is pretty rare to encounter on capture cards in general - both due to cost and to bandwidth requirements. Typically this is reserved for the very expensive and high end cards from the likes of Magewell, BlackMagic Design, and AJA. However, the AVerMedia Live Gamer 4K offers RGB decode modes throughout, and the Live Gamer Ultra offers it for 1080p60 as well!

While OBS typically operates in the 4:2:0 color space (and that’s all that Nvidia’s NVENC is capable of with the new shared texture implementation as of OBS v23) for streaming purposes - though you can set it to 4:4:4 RGB for recording modes - having a 4:4:4 RGB uncompressed signal still gives you the best results as a source, as you have more information to work with when downscaling, downsampling, and compressing. Garbage in, garbage out!

Format Support

Here’s the overall chart with specific resolution and framerate support (just the max specs listed for now), whether or not HDR is supported, etc. and the actual connection types for each capture card. I tried to specify if there’s a difference between the accepted input/passthrough resolution and framerate and the actual capture framerate. I’ll try to go back through and be more verbose about these details when I have time.


[link to high res copy]

As noted in my review, the ClonerAlliance Flint 4KP capture card has the potential to be used for 1440p60 - however I ran into glitching with it. Perhaps it might be more stable for others.

Notes on Scaler Support
I have noted in the above chart also when resolution and frame rate scaling is supported by the card. There’s two ways to do this - on the card or in the driver. If neither support exists (such as with the Elgato Cam Link cards) then the only option is to manually scale your frame in the OBS canvas window.
As far as I’ve been able to tell (and from asking around in the OBS Discord), there’s no significant or measurable performance impact between scaling it in driver vs on the OBS canvas - however this has been a big concern overall for vMix users specifically, so I’m mentioning it as-is for now.
In the future, as I confirm with manufacturers, I will differentiate between scaling done on-hardware (reduces bandwidth) vs in-driver. I do know for now that virtually all BlackMagic Design, AJA, Epiphan, and Magewell devices have hardware scalers, whereas Elgato’s is done in driver. My guess is that AVerMedia’s is done in driver as well, but I cannot confirm that yet.

Input Latency Testing

This is the big thing I actually started this project in order to test, so it will be my main focus of this documentation. I wanted to track the input latency from HDMI input to Preview in software (OBS and native apps for the specific devices) and see what that data told me.
While this is information that can vary over time and per individual setup - I think it provides an interesting image as to which capture cards are the fastest, and which you might have syncing problems with.
A goal of this project was to be able to provide relatively accurate latency numbers to suggest for setting up delays in OBS in order to sync up your webcam, audio, etc. with your gameplay - but given that these measurements are not static and can change per PC, I’m not sure that’s a great idea. Use this information as you will.

I also began testing to confirm that each capture card truly had realtime (no lag) passthrough on their HDMI feeds. This is not noted visually, as I did not encounter any situation in which this wasn’t the case, but I’ll be sure to update if that changes.

Here’s the latency numbers for all capture cards I have tested thus far, in OBS Studio 23.0.2:

latency update 5-27-19.jpg

Taking off the original Elgato Game Capture HD (which has obscenely high latency that can vary anywhere from a few hundred miliseconds to multiple seconds, this gives you an easier view of the average latency I encountered:

The fastest capture cards within OBS are of no surprise - mostly the high end ones. Though the generic Mokose U70S was a surprise on this list.
Of great surprise here was the BirdDog Studio NDI. This is a NDI (network IP video protocol) encoder/decoder box, so you’d think sending the feed via HDMI into the BirdDog Studio and then over the network to OBS via the NDI plugin would add a lot of latency but…. This thing makes it into the top 10 fastest capture devices by a long shot… impressive and confusing.


Other than the original Elgato Game Capture HD - which is absurdly slow (it and the non-S HD60 have very high latency due to running everything through the on-board H264 compressor, though the HD60 seems to only struggle in slowness in Elgato’s Game Capture apps, not OBS) - there’s not a significant delta (difference) between the fastest capture cards and the slowest - only about 30 to 40ms total range, which is interesting to note.


I also tested to see how input latency in OBS with these devices fared against the native desktop capture applications (where applicable) - such as Elgato’s Game Capture and 4K Capture Utility apps, and AVerMedia’s RECentral. Here you see where the Elgato HD60 becomes the highest latency capture card by a long shot in Elgato Game Capture.
*NOTE: My “Native App” data for BlackMagic DeckLink Mini Recorder 4K is somewhat inaccurate, as this measurement needs to be taken at a specific point at the bottom of the screen, and I could not figure out how to full-screen the preview in BlackMagic Media Express, so the measurement was taken closer to the middle of the screen.


AVerMedia’s RECentral (tested version v4.3.0.34 (Beta)) has latency fairly close to OBS Studio’s, actually beating it with all capture cards except the ExtremeCap UVC. However, this is something that kept counting up over time and may slow while capturing.


Elgato’s software is where things get interesting. They have two different programs for their capture cards - Game Capture, designed for the original Game Capture HD device and used until the 4K60 Pro’s launch, and then the 4K Capture Utility, designed for the 4K60 Pro and backwards compatible. I did not test every device with both apps, as it felt silly to test the newest 4K devices in the 1080p-limited and way-outdated Game Capture app, nor did it make sense to test the original (end-of-life) Game Capture HD or HD60 in 4KCU either.

Elgato Update.jpg

Other than the original HD/HD60 where both devices were slower than OBS (almost by a factor of 7x for the HD60), the Game Capture application is extremely speedy, providing faster render times than OBS Studio. I was impressed. This helps flex the “Instant Gameview” feature that Elgato marketed a lot with the HD60 Pro and HD60 S. I still wouldn’t recommend trying to play anything where timing matters on a preview that has 63+ms of added latency, but it’s neat regardless.
What’s weird, though, is how slow the 4K Capture Utility is. We’re talking 2-3x slower than OBS or Game Capture for most of their capture cards. Hitting 200ms on their flagship 4K60 Pro. This is… bizarre BUT I think it’s a performance-saving thing. They know not everyone’s PCs are cut out for multiple 4K video captures and all that madness, so they probably delay the preview feed to make sure resources are dedicated to a smooth recording. Even in the menus they have an option to show the preview at a reduced framerate and resolution while recording to aid with this, too.
That being said, an even more interesting result was when - just for kicks - I tested the latency of Elgato’s “Stream Link” NDI feature routed back to OBS. This is to let you record a clean feed in Elgato 4KCU while sending a NDI copy of the feed over to OBS Studio for streaming with overlays. Through multiple test sessions, the 4K60 Pro consistently gave me 2ms of input latency routed through this than routed into 4KCU directly.
Yes - I’m saying that HDMI - 4K60 Pro - 4K Capture Utility - Stream Link NDI - into OBS is faster (by a tiny bit) than directly into the 4KCU preview. This is why I think the preview is deliberately delayed.
But even with this, that’s still more than double the input latency of running directly into OBS.

Elgato vs NDI.jpg

I did want to note that all of this testing was done with the Flashback Recording functionality of 4K Capture Utility turned on. It’s possible that turning it off might improve these results, and I will update as I’m able to test this - if that’s the case. (But testing with Game Capture was also done with its Flashback Recording enabled, so it’s a fair comparison there.)

[UPDATE March 20, 2019 4:52 PM - I have removed the original Elgato Game Capture HD and HD60 from my charts. It appears my results were wildly inaccurate (in Elgato's favor, funny enough) and I cannot manually correct that information with this testing hardware. It is my theory that the delay is so long that the tester is reading old frames as new one and thinking the preview is faster than it really is. I cannot compensate for this. I am told the GCHD has an average latency of 1.4ms and the HD60 of 670ms and that's good enough for me. These cards are very old and no longer supported/sold anyway. Apologies for the confusion.]

Notes on “Bitrate” Support

After the original Elgato capture cards (and a couple others) became popular, some users got hooked on the idea of the capture devices having a “maximum bitrate” or “max quality” that it can output. For the original GCHD, this was 30mbps, for the HD60 this was 40mbps. (source)
This doesn’t really have any relevance to OBS Studio usage, as that “max bitrate” was a limitation of what you could set in Elgato’s Game Capture application and not from the device itself. The capture cards themselves cannot limit what bitrate you set in OBS Studio, and the USB 3 and PCIe devices all send completely uncompressed high-bandwidth feeds to OBS to encode from. In lossless mode, I’ve pulled 1gbps+ out of the HD60 Pro!
Due to the “internal encoder” routing nature of the original Game Capture HD and HD60, there may be a pre-compressed maximum bitrate that those two specific devices send to any application, OBS included, but you can still technically go higher in OBS - there will just be diminishing returns since your source is of lower quality. BUT if you’re adding webcams, overlays, etc. there’s still more data being added to the feed, so the choice is yours.

The point being, especially in the modern USB 3/PCIe capture device market - “max bitrate” is an inaccurate, irrelevant metric that doesn’t actually affect you. Don’t worry about it. Just wanted to dispel a long-running myth.

Testing Methodology

In order for data and testing like this to be valuable, the methodology used to obtain them needs to be transparent.

All of my testing was done on my main “Trunks” workstation PC.
  • Intel Core i9-7980XE (18c 36t) w/ all-core OC to 3.89GHz
  • ASUS WS X299 SAGE Motherboard (the one with more USB ports, not 10 gigabit networking)
  • 8x8GB (64GB total) CorsairVengeance LPX DDR4 RAM running at 3600MHz
  • MSI Armor Nvidia GTX 1080ti GPU
  • Misc. 10gigabit NIC, Sonnet USB 3.1 expansion card, NVMe storage, etc.
  • Windows 10 Home x64 version 1809 (latest non-Insider updates as of March 15, 2019)

This is a kind of “best case scenario” for these devices, with plenty of USB bandwidth and PCIe lanes ran directly to the CPU. Your mileage may vary, as always.

To acquire the latency data, I used the Leo Bodnar Video Signal Input Lag Tester. This connects to your device via HDMI and displays a series of flashing bars, a graph showcasing the detected input latency, and currently read input latency. There is a light sensor on the device. Hold the button, press the device to the screen on top of each of bars, and note your input latency.
The 3 bars are 3 different points of the monitor - the top, middle, and bottom. Monitors draw frames from top to bottom, so the top is fastest (usually around 1-3ms) and the bottom is slowest. The smallest (accurate) number that can be displayed at the bottom of the screen is 16ms - as at 60fps, each frame is on-screen for 16.67ms. (This is rounded a bit, the device only claims 1ms accuracy.)
This measures black-to-white latency, which typically takes longer than the useless marketing latency listed for monitors, which is GTG (grey-to-grey).

So to measure capture card latency, I full-screened the software preview from the capture card, connected the lag tester to the capture card input, and measured again. Subtract the monitor’s measured input latency from that of the capture card, and you have a rough estimation of the input latency (with any added software render lag) of the capture device!

The tester I have, specifically, only tests 1080p60 - there may be different results for 4K-compatible devices when sent a 4K signal - however, Leo Bodnar’s 4K tester is over $300 and not something I can afford at this time. If anyone wants to contribute towards this or gift me one, DM me please! I’d love to expand my test results.

For OBS/Software tests, the monitor used was the wonderful Dell UP2718Q. For passthrough testing, I used the LG 27UD68-P.

Determining supported decode modes and scaler support is just a matter of seeing what is exposed to OBS and then discussing potential confusion points with representatives of the devices respective manufacturers. This lead me to discover that Elgato’s driver exposes a RGB mode but that’s not a true RGB signal and should not be used, etc. I’m constantly fact-checking my results and will continue to update this guide as new information becomes available.

Supported resolution/framerate/passthrough specs are a combination of checking the spec sheets for each device and my own testing trying to force modes not listed in the documentation during my individual reviews and follow-ups.

Limitations and Future Testing

I’m not perfect, and my testing isn’t perfect. Perhaps there’s a flaw in my testing methodology you think could be fixed or improved? Let me know.

  • I’m only one person testing this, so attention spans wane and mistakes can be made.
  • I’m only testing on one system, different systems may provide different results
  • I’m not using clean Windows images with each driver/device install
  • I’m only testing the direct capture card into OBS, not with added facecam, overlays, etc. which can increase render frame times
  • The numbers for latency can vary as time progresses or bounce back and forth between two ranges (~75ms and ~98ms, for example). I took whatever was most consistent, or the highest of the two most consistent ranges, and rounded decimals up - but perhaps this is not accurate
  • This whole idea might not be the most accurate way to measure this latency in the first place? WHO KNOWS (seriously - who knows? If you know something better, tell me!)
  • Drivers can provide inaccurate results or change performance. I’m only using the most recent, readily-accessible (or in some cases, especially with the UVC devices, the automatically-installed) drivers. Perhaps different versions change these results
  • I have not yet noted which devices are supported on UVC drivers alone - this should be added
  • I have not noted which devices bypass/ignore HDCP and which versions - this should be added
  • Currently the “Yes” answer for Scaler Support? Includes both driver and hardware solutions - this should be differentiated
  • I have not tested enough cards
  • As mentioned, I’m only testing (due to tester hardware limitations) these devices with a 1080p60 signal and latency may change on the 4k-capable capture cards with a 4K source signal. However, the 4K Lag Tester is over $300 and I will need community support if I’m to purchase such an investment for such a niche, nerdy rabbit hole
  • Perhaps measuring my monitors’ input latency at 1080p60 but running OBS/etc. To test at native 4K60 yields different results than if my monitor was set to 1080p60 for the rest of the tests.
  • As discovered, insanely slow/high latency devices like the HD60/GCHD are so slow that my tester picks up old frames as new frames and yields inaccurately fast results. They have been removed as a result.
  • More, IDK

Submit Capture Cards

Don’t see the capture card you want on this list? Have some lying around you want tested? Work for a manufacturer and want publicity/documentation? Send them to me! I want to test alllllll the capture cards!
You can reach out via DM here, but email is preferred (especially from company representatives) - .
You can also send to my PO Box at:
EposVox PO Box 459 Jeffersonville, IN 47131 USA
(Must be USPS only for that, though.) Make sure you include return address and a note about wanting it back if you ship without warning!
Also keep in mind I’m a one-man-show and take quite a while to get through product inventory. Don’t send it to me expecting it back in a week.

Latest reviews

This is incredible. Very well done research about video capture latency that I have not found in many other places.
EposVox is a treasure and needs to be protected.
EposVox does it again.
What a champ.
I've found so little info on this - so was really pleased to discover this comprehensive resource from the authoritative EposVox, whom I already follow and trust.
This is exactly what I needed! Trying to diagnose OBS latency vs my audio interface to get it all sync'd up!
Thanks, broseph