Push and pull streaming delay problem

[bjw1107]

I try to use the following commands to pull and forward the video stream. No errors were reported during the encoding and decoding process, but the speed was very slow, speed = 1x, and the frame was also very slow.当我尝试用vlc或者ffplay进行取流的时候，视频需要很长的时候才能显示，而且在播放时有大约2s的延迟，并且存在卡顿现象，请问该如何解决

ffmpeg -hwaccel rkmpp -hwaccel_output_format drm_prime -afbc rga -i rtsp://xxxx/Channels/101 -c:a copy -strict -2 -vf scale_rkrga=w=1920:h=1080:format=nv12:afbc=1 -c:v h264_rkmpp -r 15 -rtsp_transport udp -rc_mode VBR -b:v 1M -maxrate 2M -bufsize 12M -profile:v high -g:v 120 -f rtsp rtsp://xxxx/amera1

[nyanmisaka]

Which chip are you using?

[bjw1107]

rk3588

---Original--- From: @.> Date: Mon, Mar 11, 2024 17:00 PM To: @.>; Cc: @.**@.>; Subject: Re: [nyanmisaka/ffmpeg-rockchip] Push and pull streaming delayproblem (Issue #36)

Which chip are you using?

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>

[nyanmisaka]

You can reduce the latency to a certain extent by disabling async mode in both rkrga filter and rkmpp encoder.

Add :async_depth=0 to scale_rkrga filter and -surfaces 1 to h264_rkmpp encoder.

[bjw1107]

谢谢你的回复，但是我发现还是没有并没有起到很大的效果，用vlc拉流后依然会过很长时间才显示第一帧，然后开始长时间的卡顿，之后恢复到流畅，测试了一下延迟大概在800ms左右，请问如何进一步地降低延迟以及避免一开始的卡顿现象？ hank you for your reply, but I found that it still did not have a great effect. After using vlc to pull the stream, it will still take a long time to display the first frame, and then it will start to freeze for a long time, and then it will return to smoothness. Test The delay is about 800ms. How can I further reduce the delay and avoid the initial lag?

[nyanmisaka]

Can you try this branch? https://github.com/nyanmisaka/ffmpeg-rockchip/commits/refactor-dec-logic/

[bjw1107]

再次感谢您的回复。我尝试了这个方法，这个方法对于减低延迟是有效的，它将延迟从730ms降低到了570ms。但是我又发现了一个新的问题，在长时间的运行后，它的延迟似乎在逐渐增加，在将近5分钟的运行后延迟达到了1400ms，请问有没有解决的方法? Thanks again for your reply. I tried this method and it was effective in reducing the latency, it reduced the latency from 730ms to 570ms. But I discovered a new problem. After running for a long time, its delay seemed to be gradually increasing. After nearly 5 minutes of running, the delay reached 1400ms. Is there any solution?

[nyanmisaka]

I've run out of ideas. This branch adopts the rockchip maintainer's logic to reduce decoder latency.

1400ms sounds abnormal and may be caused by overheating of the chip and frequency reduction. Please check the temperature and use taskset -c 4-7 ffmpeg ... to bind the transcoding task to the cortex-A76 big core.

Alternatively, you can switch to gstreamer-rockchip instead and see if it helps. https://github.com/JeffyCN/rockchip_mirrors/tree/gstreamer-rockchip

[bjw1107]

OK, I got it, I'll try again, thank you very much for your help！

[geiliwanghaichao]

@bjw1107 when you push and pull streaming, just try set protocol tcp mode. eg: ffmpeg -hwaccel rkmpp -hwaccel_output_format drm_prime -afbc rga -f rtsp -rtsp_transport tcp -i rtsp://xxxx/Channels/101 -c:a copy -strict -2 -c:v h264_rkmpp -rc_mode CBR -b:v 400k -f rtsp -rtsp_transport tcp rtsp://xxxx/amera1

[bjw1107]

thank u very much，i will try it

---Original--- From: @.> Date: Fri, Mar 15, 2024 16:39 PM To: @.>; Cc: @.**@.>; Subject: Re: [nyanmisaka/ffmpeg-rockchip] Push and pull streaming delayproblem (Issue #36)

@bjw1107 when you push and pull streaming, just try set protocol tcp mode. eg: ffmpeg -hwaccel rkmpp -hwaccel_output_format drm_prime -afbc rga -f rtsp -rtsp_transport tcp -i rtsp://xxxx/Channels/101 -c:a copy -strict -2 -c:v h264_rkmpp -rc_mode CBR -b:v 400k -f rtsp -rtsp_transport tcp rtsp://xxxx/amera1

— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

[geiliwanghaichao]

@bjw1107 specifiy transmission protocol is TCP, which can alleviate lag and screen flicker issues, but whether there will be cumulative delays requires long-term testing。You can also tell me your test results

[nyanmisaka]

Closing as the decoder latency has been improved in the latest branch.