Minimal delay when streaming a low movement scene

[digitaltos]

I might be approaching the problem from the wrong direction, so I wanted to run my setup by you. This is what 2 days of Googling got me.

TLDR: I want to stream a low movement scene (eg. a small led blinking, nothing else moves) with a sub-second delay. I tried OBS for streaming with the best options I could find, but it is far from ideal.

The problem
(Simplified) I have an LED in a remote location, that I can turn on and off over the internet. I want a live feed of this LED in a format I can use with OBS or VLC. (very minimal movement on the screen, we can go crazy optimizing the encoding) I want to keep everything inside my VPN, so public streaming is out. The live feed should be as fast as possible, I am aiming for 1-2 seconds of delay.

My not so good solution

• Cheap laptop (low-end i5 CPU, no GPU, 4GB RAM) on the remote location
• VPN (5 mbps up and down) (It's plenty enough. Looking at the webcam feed over Remote Desktop, the delay is less than 1 sec)
• Integrated webcam points at the LED
• Webcam feed goes to OBS
• OBS streams over RTSP (with this plugin)
• Settings below

14:08:23.949: [DShow Device: 'Webcam (built-in)'] settings updated:
14:08:23.949:     video device: USB Video Device
14:08:23.949:     video path: \\?\usb#vid_046d&pid_0809&mi_00#7&3471ceb1&0&0000#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global
14:08:23.949:     resolution: 800x600
14:08:23.949:     flip: 0
14:08:23.949:     fps: 23.98 (interval: 417083)
14:08:23.949:     format: YUY2
14:08:35.318: ---------------------------------
14:08:35.319: [x264 encoder: 'streaming_h264'] preset: ultrafast
14:08:35.319: [x264 encoder: 'streaming_h264'] tune: stillimage
14:08:35.319: [x264 encoder: 'streaming_h264'] settings:
14:08:35.319:     rate_control: ABR
14:08:35.319:     bitrate:      1000
14:08:35.319:     buffer size:  0
14:08:35.319:     crf:          0
14:08:35.319:     fps_num:      24000
14:08:35.319:     fps_den:      1001
14:08:35.319:     width:        800
14:08:35.319:     height:       600
14:08:35.319:     keyint:       250
14:08:35.319:
14:08:35.320: [x264 encoder: 'streaming_h264'] VBV maxrate specified, but no bufsize, ignored

This config gives me about a 2 sec delay over the network, but the image is sometimes glitchy (I turn ON the led, I see the led glowing, then the stream glitches so I see it turned off, I wait 5-10 sec and it seems to be turned on. Not acceptable for me.)

On the encoding side, I was tweaking h264 settings but this was the best I got. On the networking side, I tried the srt protocol, which kinda crashed OBS (but it was kinda the same speed before crashing); and also NDI, which did not work (could not see the server over VPN). Keep in mind that I need to have a simple way to connect to the stream via OBS or VLC with any device on the network.

Questions
Is my approach even feasible? What would be the optimal network protocol for this task? Is there a better software for this than OBS? No, using RDP is not a solution for me.

 

[digitaltos]

bur another idea use VLC stream the cam direct with RTSP in 800x600 to your obs session so you only have the pure picture without rescaling

Thanks for the replies.

CBR is sometimes better, sometimes worse (regarding the glitchy led flickering). QOS is not an option for me. Higher bitrate with higher FPS was a bit better. Makes sense.

It is getting dark in the remote location, so there are all kind of glitches and artifacts there. I might need to postpone tweaking OBS until there is an ideal amount of light there. RDP is nice and crisp of course. So annoying...

Oh, right, VLC. I actually tried streaming with that first, but I couldn't set it up properly. I'll give it another go.

 

[digitaltos]

Bump. VLC sees a blurry image from the webcam, OBS is at least able to tweak the image.

I have realized how the lighting and the scenery affects the compression, but I will tweak the lighting anyways for things to look more pretty.

Still, more input on more h264 tweaks or a (free) software alternative is much appreciated. I mean, so far the best option is having the webcam fullscreen on the remote laptop, then sharing that screen over RDP (1080p 30 FPS...), which sounds sooo wrong.