search

mpromonet / v4l2rtspserver

RTSP Server for V4L2 device capture supporting HEVC/H264/JPEG/VP8/VP9
The Unlicense
1.86k stars 428 forks source link

Trouble with 2 second delay in video stream #202

Closed tachang closed 4 years ago

tachang commented 4 years ago

I am getting a 2 second delay in the video stream and trying to track down where it is coming from. I am using v4l2loopback and some C code to feed it frames constantly. It seems to be working.

When I start up the rtsp server I see roughly a 2 second delay. This is fairly long so trying to see where the frame is in queue or what is going on.

Here is a video where you can see the timestamp is "stuck" after a certain point. Is this normal behavior? At this point I haven't even connected to the RTSP stream. My frame server process is just feeding frames (like a webcam would do)

https://www.loom.com/share/0409f9e222d84838a0a8572b2380dd7f

tachang commented 4 years ago

Another oddity is that when I do -vv I am unable to connect to the stream but when I do only a single verbosity flag I am able to connect.

tachang commented 4 years ago

Another oddity is that when I do -vv I am unable to connect to the stream but when I do only a single verbosity flag I am able to connect.

Oh this is the result of the debug statement printing out and slowing things down enough that the queue never empties. In other words this is a non-issue.

mpromonet commented 4 years ago

Hi,

It may depends on the way you feed the v4l2loopback, the way you display the RTSP stream (especially if it buffered), resolution, the network,.... usually on a LAN network it is more about 300ms...

Best Regards, Michel.

tachang commented 4 years ago

I am on a wifi network. However I would expect the response time to be way lower than what I am seeing. Maybe this is unrealistic?

My "feeder" program is feeding frames to the v4l2loopback device at about 28fps:

https://github.com/openmiko/ingenic_videocap/blob/master/src/capture.c#L276 (not latest code. I implemented a timer)

I guess the camera itself could take time to encode the images. Hard to actually benchmark this.

tachang commented 4 years ago

It doesn't seem to be normal for a camera sensor to buffer over 1s before sending it to the hardware encoding engine. That just seems like a lot of time. You'd need to keep those images in memory.

tachang commented 4 years ago

Okay I feel stupid. I simply looked around in VLC and found the rtsp-caching parameter and set it to lower latency. I believe this probably forces VLC to use a smaller buffer and that helped tremendously.

Should've just done that first before going around analyzing C source code.