Closed mcfiredrill closed 2 years ago
Recorded a short video just now , maybe this helps?
https://user-images.githubusercontent.com/66243/153077843-4841766e-4302-4f75-a41e-f265816fba74.mp4
At the end I said "maybe input.ffmpeg is too slow" but who knows, could be issue with my nginx-rtmp config or output.file.hls settings... Thanks as always for making liquidsoap!
I'm thinking this issue has to do with ffmpeg, or perhaps the output.file.hls settings I have here.
I get the same results (lots of underruns) using a single video
single('single.mp4')
.
I can create a very stable stream using testsrc.
s = mux_audio(video.testsrc(), audio=noise())
Thanks for reporting this one. I've had similar issues, will investigate.
Pretty sure it's coming from input.ffmpeg
, I've had the same issue just doing input.ffmpeg
to a sound card output.
So, a little investigation reveals what's going on here I believe.
You can set settings.ffmpeg.log.verbosity.set("info")
in the script to see more details.
First, I tested with https://stream.radiofrance.fr/fip/fip.m3u8
, which is a top-level m3u8 playlist. With this one, it was clear that input.ffmpeg
was lagging each time ffmpeg was reloading the playlist to fetch the next segments leading to hicups in the playback.
Then, using https://stream.radiofrance.fr/fip/fip_hifi.m3u8
, which points to a specific sub-stream of the top-level playlist. With this, the input was processing the new segments fast enough and no hicups were observed.
Next, I tested with https://stream.radiofrance.fr/fip/fip.m3u8
but this time, wrapping the input.ffmpeg
into a buffer
to force it into its own clock and this seemed to also remove the hicups.
What this points out to is that the ffmpeg hls demuxer is not processing new segments fast enough when using a full hls playlist with all streams. Also, for some reason, our current use of its API returns the lowest quality stream when using the top-level playlist. We'll have to investigate wether this is an issue on our side or on the ffmpeg side.
I'd suggest to either or both:
buffer
.Let us know if that helps!
I've been meaning to test this again after the recent optimizations pushed to v2.0.4-preview
and I'm happy to report that this isn't happening again. Seems like the optimizations also took care of whatever was dragging the ffmpeg processing!
Describe the bug I'm trying to input an HLS stream with input.ffmpeg and output another HLS stream. I plan on muxing audio etc later, this is just the simplest possible test case.
Even though the HLS input stream is running on my local machine, I'm still seeing constant underruns and the resulting stream playback is choppy.
To Reproduce
The input HLS stream is coming from an ngnix-rtmp server that I'm running locally in Docker. I'm streaming content to it with OBS locally.
Liquidsoap's HLS output is sent to /tmp/hls where I test it with
ffplay -i live.m3u8
. The resulting playback is smooth for a few seconds then becomes quite choppy.You can also see constant underruns in the logs.
Expected behavior Since the input HLS stream is all coming from the same machine, I wouldn't expect any underruns to occur. I'd expect smooth playback just like if I do
ffplay -i http://localhost:8080/hls/datafruits.m3u8
.Version details
Install method opam install gavl ffmpeg taglib mad lame ogg vorbis cry samplerate ocurl liquidsoap -y