Closed copy closed 2 years ago
Thanks for this report. I agree that the application should shutdown more cleanly. At the heart of the issue, however, is the fact that your machine does not seem to be able to process the video encoding fast enough, which causes liquidsoap to queue up a lot of data which seems to cause a major failure with the ffmpeg library.
Have you tried with the ffmpeg
command line utility? Do you get a better outcome?
Additionally, if your goal is to pass the media data from the rtmp source to a srt output, you should be able to pass it without reencoding this way:
stream = mksafe(input.rtmp("rtmp://0.0.0.0:53163/"))
url = "srt://server:53162/output"
enc = %ffmpeg(
format="flv",
%audio.copy,
%video.copy)
output.url(url=url, enc, stream)
This will definitively have a much better CPU load on your machine.. 🙂
At the heart of the issue, however, is the fact that your machine does not seem to be able to process the video encoding fast enough, which causes liquidsoap to queue up a lot of data which seems to cause a major failure with the ffmpeg library.
I think my CPU should be powerful enough to decode and re-encode h264 in realtime.
I don't know how to exactly translate the liquidsoap to ffmpeg (after all, I'm learning liquidsoap to avoid having to deal with the ffmpeg command line). The following command that re-encodes the rtmp stream and saves it to a file seems to work fine though (with about 150% CPU usage according to htop; for reference liquidsoap shows about the same usage but as two separate processes).
ffmpeg -f flv -listen 1 -i rtmp://0.0.0.0:53163/ -c:v libx264 -preset veryfast -b:v 1500k -maxrate 1500k -pix_fmt yuv420p -g 30 out.mp4
Additionally, if your goal is to pass the media data from the rtmp source to a srt output, you should be able to pass it without reencoding this way
That's a good idea. On the other hand, it would be nice if liquidsoap could handle re-encoding too, since I'd eventually like to receive h265 or VP9 and re-encode it to h264.
At the heart of the issue, however, is the fact that your machine does not seem to be able to process the video encoding fast enough, which causes liquidsoap to queue up a lot of data which seems to cause a major failure with the ffmpeg library.
I think my CPU should be powerful enough to decode and re-encode h264 in realtime.
I don't know how to exactly translate the liquidsoap to ffmpeg (after all, I'm learning liquidsoap to avoid having to deal with the ffmpeg command line). The following command that re-encodes the rtmp stream and saves it to a file seems to work fine though (with about 150% CPU usage according to htop; for reference liquidsoap shows about the same usage but as two separate processes).
ffmpeg -f flv -listen 1 -i rtmp://0.0.0.0:53163/ -c:v libx264 -preset veryfast -b:v 1500k -maxrate 1500k -pix_fmt yuv420p -g 30 out.mp4
Additionally, if your goal is to pass the media data from the rtmp source to a srt output, you should be able to pass it without reencoding this way
That's a good idea. On the other hand, it would be nice if liquidsoap could handle re-encoding too, since I'd eventually like to receive h265 or VP9 and re-encode it to h264.
Definitely.
If it's not the CPU, I'd suggest to test the rtmp
output. If network communication is too slow, it will also create a catchup with liquidsoap.
For ffmpeg
that should be something like:
ffmpeg -re -f flv -listen 1 -i rtmp://0.0.0.0:53163/ -c:v libx264 -preset veryfast -b:v 1500k -maxrate 1500k -pix_fmt yuv420p -g <uri>
The -re
option tells ffmpeg
to send in real time, like liquidsoap does. Then you should watch the reported speed. It should be around 1x
at all time.
Interestingly, your ffmpeg commands runs slightly slower than 1x. It reports speed=0.963x after leaving it running for two minutes. However, the delay between the input and output doesn't seem to be growing, and it keeps running stably.
If network communication is too slow, it will also create a catchup with liquidsoap.
That makes sense. Is it possible for liquidsoap to catch up by skipping input frames? Something like ffmpeg without the -re
option (which should not be used if the input is a live stream, see https://ffmpeg.org/ffmpeg.html#Advanced-options).
Well, if you run under constantly under 1x
, you are bound to accumulate a growing delay. We have no mechanism for skipping frames at the moment but that's a good idea & I will think about it.
I'm gonna convert this into a discussion and open a feature request for frame dropping.
Describe the bug
I'm trying to stream a camera which has rtmp output to srt. The script below freezes after about two minutes after printing
We must catchup … seconds
many times. Afterwards liquidsoap doesn't terminate cleanly either.To Reproduce
Expected behavior
The stream should not freeze
Version details
Liquidsoap 2.0.2 (see the log for details)
Install method
opam
Logs