How to broadcast on a TV with a HDMI cable (help)

[xDogz]

Hello , I'm using OBS Studio since a while but i am only using it to record my screen/voice on my pc and on twitch.
In a few weeks i have to host a concert in my high school , and i have a camera and templates and i want to do the same as real concerts (e.g eurovision) , so i want to stream on a tv thanks to a HDMI cable (= no delay) (and not using YT/Twitch), but idk how to do? Is there a guide for this I have seen yet?
TIA :)

 

[koala]

HDMI means the device is showing up as ordinary monitor to Windows. After connecting, configure Windows to extend the Windows desktop to use the new monitor if it doesn't automatically use it.
Then, in OBS, you can cast the preview, any scene and any source to any monitor by right-clicking it->Fullscreen projector->choose the monitor.

 

[Tomasz Góral]

Without lags ?
not possible.
In my setup i got BMD Quad HDMI and BMD Mini Recorder 4K (maximum 5 HDMI or 4HDMI and 1 SDI input) my delay is 150ms.
If i use mixer like ATEM mini i got 60-80 ms lags.
Every TV has input lags from 20 to 60 ms.

 

[bcoyle]

HDMI means the device is showing up as ordinary monitor to Windows. After connecting, configure Windows to extend the Windows desktop to use the new monitor if it doesn't automatically use it.
Then, in OBS, you can cast the preview, any scene and any source to any monitor by right-clicking it->Fullscreen projector->choose the monitor.

the projector only displays the video, you have to go under setting audio , change the audo monitor to that device also

 

[AaronD]

the projector only displays the video, you have to go under setting audio , change the audo monitor to that device also

...and be aware that there's a longstanding bug in OBS's Monitor, that causes a boundlessly-increasing buffer (delay) when the sample rates don't match *exactly*.

If both OBS (on the CPU) and the selected audio device use the same nominal sample rate AND the same physical clock, then everything's good.

But if the sound card uses its own physical clock, even for the same nominal setting (a fair number of them do), then it *will* drift out of sync and eventually cause the buffer to fill up or run out. Then the "networking mentality" that OBS's Monitor is written with, increases the buffer with the idea of allowing enough space for dropped and resent packets to slot in before they're needed, so that it's smooth at the expense of latency. Problem is, latency is death here, and "dropped packets" aren't a thing either at this point in the system.

If you don't have that problem, great! But if you do, then the solution is to send OBS's Monitor to a virtual thing, just to guarantee that it uses the same clock, and then send that virtual thing to the actual destination. Essentially, move the problem to something else, which then handles it correctly.

 

[bcoyle]

...and be aware that there's a longstanding bug in OBS's Monitor, that causes a boundlessly-increasing buffer (delay) when the sample rates don't match *exactly*.

If both OBS (on the CPU) and the selected audio device use the same nominal sample rate AND the same physical clock, then everything's good.

But if the sound card uses its own physical clock, even for the same nominal setting (a fair number of them do), then it *will* drift out of sync and eventually cause the buffer to fill up or run out. Then the "networking mentality" that OBS's Monitor is written with, increases the buffer with the idea of allowing enough space for dropped and resent packets to slot in before they're needed, so that it's smooth at the expense of latency. Problem is, latency is death here, and "dropped packets" aren't a thing either at this point in the system.

If you don't have that problem, great! But if you do, then the solution is to send OBS's Monitor to a virtual thing, just to guarantee that it uses the same clock, and then send that virtual thing to the actual destination. Essentially, move the problem to something else, which then handles it correctly.

Thanks Arron. In my test , i'm sending the audio to the same dongle that is doing the video, so hopefully I don't get run out. I'll keep in mind you solution if my users run into trouble. Thanks Again., Bill