Best Way To Send HDMI Signal To PC (No Pass Through Required)

[ThePie]

Question

I am looking for suggestions on the best way for a PC to take in a HDMI signal with the lowest amount of latency (near 0ms). Pass thru is not required. A lot of PCIe cards I've come across show off near zero latency from the HDMI IN to OUT port which you can then send to your TV for gaming or what not. I do not need this pass thru feature, as the PC itself will be displaying the signal via the GPU's HDMI Out port. As such, near zero latency is required.



Capture Cards

Datapath VisionSC-UHD2
Elgato 4K60 PRO MK.2
AVERMEDIA LIVE GAMER 4K (GC573)
DIGITNOW 4K60 Pro
Acasis Quad HDMI PCIe Video Capture Card 1080P 60FPS
Black Magic Intensity Pro 4K


Latency Test Devices

LDAT Testing Results Production stopped and was a internal only tool anyway.
Leo Bodnar Video Signal Lag Tester Review Used as a stand-alone device. Can not measure full system latency.

[usually_quiet]

As far as I know, it can't be done. Without a pass-through connection on the capture device, it is necessary to use an HDMI splitter to deliver an HDMI signal to both the PC and a display with minimal latency. (A capture device's HDMI pass-through is implemented via an internal splitter.) Otherwise, the PC must process the HDMI input from the capture device using both hardware and software in order to output it using a GPU's HDMI connection, which will introduce too much latency.

[ThePie]

As far as I know, it can't be done. Without a pass-through connection on the capture device, it is necessary to use an HDMI splitter to deliver an HDMI signal to both the PC and a display with minimal latency. (A capture device's HDMI pass-through is implemented via an internal splitter.) Otherwise, the PC must process the HDMI input from the capture device using both hardware and software in order to output it using a GPU's HDMI connection, which will introduce too much latency.

Its a interesting problem, I mean, devices are outputting a signal to monitors which are inputting outputting the signal and processing the HDMI signal without adding a lot of latency so why would a capture card introduce way more latency then a monitor? Seems a bit strange that there is such a difference in latency.

[Cornucopia]

Monitors do not output, other than DisplayPort pass-through (which is an internal splitter). Monitors have inputs.

Capture cards are doing processing, processing takes buffer & CPU cycles, leading to latency.
Capture cards that have hardware-assisted passthrough should be pretty low latency (on the order of 1-100ms, or a couple of frames' worth) maybe even lower if it is just doing a dumb bitwise copy. But they will never be ZERO, as that isn't possible with digital signals. Especially with consumer signals that expect EDID and HDCP handshake, that alone takes some time.

But you don't really need to worry about whether it is zero or not, you just need it to not lag enough to act out-of-sync per your perception.

Pro units have TBCs/FrameSyncs with GenLock which allows them to buffer enough so all the simultaneous inputs are in sync, so while there may be overall latency even in them, there is no NOTICEABLE lag or desync.

Scott

[Eric-jan]

You should not use HDMI, you should use SDI ! but you need to give better (detailed) info, is the source a consumer device ? or a professional device ? HDCP and handshaking could mess things up, also maximum (and mixed?) frame rates, different HDMI versions, even some brands of equipment can not be compatible through HDMI, Digitalizing just takes time with HDMI, Even the length of a HDMI cable can't be too long, SDI has just better features. you already have a ATEM mini type model switcher ?

btw. TLDR is also not helping you...

[Cornucopia]

@Eric-jan, I call BS.
Yes, SDI is the pro solution and is overall more robust, but there's nothing inherently wrong with HDMI (well, not too much , dammit give me a latching connector!), when done correctly. Of course you should honor HDCP, but that goes for DP and SDI as well as HDMI. Hdmi versions are backwards and forwards compatible, so handshake will find the common denominator, and with legit quality devices that just isn't an issue.
Length vs bandwidth is a challenge with every spec. That's why AVoverIP & HDbaseT have been so popular. As has fiber optic transmission solutions. But I'm pretty sure in these forums we are usually talking about consumer devices, consumer lengths, etc., so the solutions should be within the consumer's reach.


Scott

[ThePie]

...

...

Thank you both for the answers. Its great to get some technical knowledge on the subject.

In regards to HDCP I agree with this fellow, Disable HDCP on Nvidia video cards, but that's another topic.

Pro units have TBCs/FrameSyncs with GenLock which allows them to buffer enough so all the simultaneous inputs are in sync, so while there may be overall latency even in them, there is no NOTICEABLE lag or desync.

This is interesting, what units are out there that do this? Also, are the frames being buffered at the monitor or capture card level or are you referring to devices that would be "sending the signal". I would think if its being buffered at the display, then what you see might not be noticeable anymore but the lag is still present, its just all being delayed at once. Not really sure on this as I would need to see what hardware examples you are talking about.

You should not use HDMI, you should use SDI

SDI being for uncompressed and unencrypted digital video signals.
HDMI being for uncompressed and encrypted (HDCP) or unencrypted.

Well the source is a consumer grade device with a HDMI 2.0 output and that's all.
The HDMI cable will be 3ft, maybe 6ft max? That length of cable should be fine I would assume.

you already have a ATEM mini type model switcher ?

Not sure?

That's why AVoverIP & HDbaseT have been so popular. As has fiber optic transmission solutions.

Is this mainly just for long runs? Wouldn't there be lots of latency introduced with 3 boxes in-between the source and destination?
https://www.matrox.com/en/video/media/guides-articles/fundamentals-of-av-over-ip


P.S.

I do not think the "@" quoting works on this forum. You probably have to quote someone in the reply.

[Eric-jan]

I assume the OP is a gamer and wants to setup a live game stream channel, and the source is a games console, maybe, the OP is better helped in the gamers forums, there will be users, who already solved the problem, and can tell what's possible, and what's not.
sometimes an extra computer is needed, (or a streaming device) to seperate workloads.

[ThePie]

I assume the OP is a gamer and wants to setup a live game stream channel, and the source is a games console, maybe, the OP is better helped in the gamers forums, there will be users, who already solved the problem, and can tell what's possible, and what's not.
sometimes an extra computer is needed, (or a streaming device) to seperate workloads.

OP here. Setup not specific for gaming, but its a valid use case. I have checked several forums. The gaming forum is not exactly the place you go to get technical knowledge...

[usually_quiet]

If the video output from the capture device is uncompressed, you could try this: https://www.youtube.com/watch?v=sTvQ4PBqueA

[ThePie]

If the video output from the capture device is uncompressed, you could try this: https://www.youtube.com/watch?v=sTvQ4PBqueA

Thanks for the post. Have not gotten to the software side yet.

Currently comparing different hardware choices and the latency between them. In regards to Elgato, they have HD60X and 4K60PRO. HD60X is a USB device taking in a HDMI connection and the 4K60PRO is a PCIe device which accepts HDMI. Latency figures are unknown, as they seem to be for most devices...

[Cornucopia]

...

...

Thank you both for the answers. Its great to get some technical knowledge on the subject.

In regards to HDCP I agree with this fellow, Disable HDCP on Nvidia video cards, but that's another topic.

Pro units have TBCs/FrameSyncs with GenLock which allows them to buffer enough so all the simultaneous inputs are in sync, so while there may be overall latency even in them, there is no NOTICEABLE lag or desync.

This is interesting, what units are out there that do this? Also, are the frames being buffered at the monitor or capture card level or are you referring to devices that would be "sending the signal". I would think if its being buffered at the display, then what you see might not be noticeable anymore but the lag is still present, its just all being delayed at once. Not really sure on this as I would need to see what hardware examples you are talking about.

You should not use HDMI, you should use SDI

SDI being for uncompressed and unencrypted digital video signals.
HDMI being for uncompressed and encrypted (HDCP) or unencrypted.

Well the source is a consumer grade device with a HDMI 2.0 output and that's all.
The HDMI cable will be 3ft, maybe 6ft max? That length of cable should be fine I would assume.

you already have a ATEM mini type model switcher ?

Not sure?

That's why AVoverIP & HDbaseT have been so popular. As has fiber optic transmission solutions.

Is this mainly just for long runs? Wouldn't there be lots of latency introduced with 3 boxes in-between the source and destination?
https://www.matrox.com/en/video/media/guides-articles/fundamentals-of-av-over-ip


P.S.

I do not think the "@" quoting works on this forum. You probably have to quote someone in the reply.

1. HDCP: if you are creating content (gameplay, etc. or your own cam productions), there's no need to have HDCP to start with. For pre-produced material (e.g. Hollywood titles), there will be, so your system would have to either fully support it all the way down the line (in which case you wouldn't be able to capture it), or you would have to bypass/defeat it (which gets into gray legal areas in many places).

2. Switcher/Mixers: Yes there are many pro- and semi-pro-level devices out there that incorporate buffering in order to sync multiple sources (while in the processing device). Pro units have genlock to have all devices pre-synced, but they still have frame buffering for time-adjustment uses. Not gonna name them here. Most can be quite expensive. Note: If all units end up lagging the same amount, the only way you can tell it is lagging is by comparing it to live (even then, might not be by much). What use case do you need to do this?

3. Long Runs?: yes, those examples were what would be used with installations that require long runs and extensive routing. I was mentioning they are there for consumer/pro-/semipro- uses esp. when interfacing with HDMI (but they can work to extend other interfaces & protocols). But I was also saying that in many consumer cases, like in yours, length isn't a factor to worry about.

Overall, I am curious what amount of lag you consider to be 1) noticeable and 2) unacceptable? And are you talking about Video-to-Video lag or video-vs.-audio (or both)?

<edit>BTW, I realize @ usage isn't working like on other platforms, but I add them anyway because visually the users here recognize that I/we are referencing another user.</edit>


Scott

[usually_quiet]

If the video output from the capture device is uncompressed, you could try this: https://www.youtube.com/watch?v=sTvQ4PBqueA

Thanks for the post. Have not gotten to the software side yet.

Currently comparing different hardware choices and the latency between them. In regards to Elgato, they have HD60X and 4K60PRO. HD60X is a USB device taking in a HDMI connection and the 4K60PRO is a PCIe device which accepts HDMI. Latency figures are unknown, as they seem to be for most devices...

I found a discussion of methods that could at least be used to compare capture device latency here: https://www.reddit.com/r/Twitch/comments/2g5nbz/question_how_can_i_measure_exact_capture_card/

I say "compare" because any delay introduced by the capture software and the hardware the PC uses to display the clock as well as the delay introduced by the capture device would contribute to the time difference observed.