Replies: 8 comments
-
Screenshot: I have to say this is the worst way to transcode videos for 3 outputs as ffmpeg has to decode it 3 times! Exec is better option where I can decode once, transcode 3 times and push all at once. Logs
used config:
|
Beta Was this translation helpful? Give feedback.
-
ffmpeg log file.
|
Beta Was this translation helpful? Give feedback.
-
What is the latency? |
Beta Was this translation helpful? Give feedback.
-
Latency is over 4-5 seconds (transcoded vs source) |
Beta Was this translation helpful? Give feedback.
-
Is the options work well? |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
In my test, it works well |
Beta Was this translation helpful? Give feedback.
-
Description
There is a huge latency between origin stream and transcoded stream in SRS4. I tested with both transcode option and exec method. I also tested original stream to compare.
SRS Version: srs-server-4.0-r4
SRS Log:
also tested with
Replay
Please describe how to replay the bug?
Step 1: publish a video with OBS using a microtimer with rtmp protocol
Step 2: play transcoded video with ffplay -fflags nobuffer -flags low_delay -i rtmp://xx.domain.com:19356/live/test_720p
Step 3: compare timestamp with OBS and transcoded video playback from srs
Expect
When I test timestamp on original video which is .../live/test and what I see on my OBS, it is under 500 ms which is awesome. However, for transcoded video, time difference is above 10 seconds without ffmpeg -re option, and with ffmpeg -re option it is 4 to 5 seconds which is unacceptable.
When I use a similar method in mediamtx (formerly known as rtsp-simple-server) it works just fine and the latency is minimal.
My server specs: i7-9700K and 64G ram, cpu utilization is around 25% of total system so it's not from ffmpeg transcoding.
Beta Was this translation helpful? Give feedback.
All reactions