liquidsoap icon indicating copy to clipboard operation
liquidsoap copied to clipboard

A way to change the connection timeout length for input.ffmpeg

Open Russsgithub opened this issue 2 years ago • 6 comments

Is your feature request related to a problem? Please describe. I'm trying to run multiple instances of input.ffmpeg(rtp) and input.http() created through the harbor server, each outputting to icecast.

I'm using this at the moment

input.ffmpeg(id=id, max_buffer=10., log_overfull=false, int_args=[("reorder_queue_size", 0)], format="rtp", udp://127.0.0.1:40000?reuse=1&overrun_nonfatal=1")

If I create one of each type with the rtp input waiting all is good. If i give the rtp input something to listen to all is good. The problem comes when I stop the feeding rtp stream, when the http stream hangs until input.ffmpeg reaches it's connection timeout and it's icecast output is closed, then the http input streams again.

Describe the solution you'd like Could adjusting the connection timeout length for input.ffmpeg be a possible addition that could happen?

I've tried to do this with ffmpeg and have had no success as of yet, so don't know how to go about this.

Russsgithub avatar Apr 28 '22 17:04 Russsgithub

Hi,

input.ffmepg should be capable of interrupting its connection when shutting down. Could you share more of:

  • Your liquidsoap and ocaml-ffmpeg versions
  • Steps to reproduce

Thanks!

toots avatar May 03 '22 19:05 toots

##Input.ffmpeg seems to block the queue with rtp, so setting more generic queues prevents this. 
settings.scheduler.generic_queues.set(8)

input_buffer = ref(5.)

rtp_address = "127.0.0.1:40000"

out_pass = "hackme"

out_url = "127.0.0.1"

s = input.ffmpeg(id=string.id("1"), max_buffer=!input_buffer, log_overfull=false, format="rtp", "udp://127.0.0.1:40000?reuse=1&overrun_nonfatal=1")

http = input.http(id=string.id("2"), poll_delay=2., max_buffer=!input_buffer, "https://radio.millicent.org")

out_rtp = output.icecast(id=string.id("3"),icy_metadata="true", fallible=true, format="audio/aac" , %fdkaac(channels=2, samplerate=48000, bitrate=320, bandwidth=20000,afterburner=true, transmux="adts", aot="mpeg4_aac_lc", sbr_mode=false), host="#{out_url}", password="#{out_pass}", mount="test", s)

out_http = output.icecast(id=string.id("4"),icy_metadata="true", fallible=true, format="audio/aac" , %fdkaac(channels=2, samplerate=48000, bitrate=320, bandwidth=20000,afterburner=true, transmux="adts", aot="mpeg4_aac_lc", sbr_mode=false), host="#{out_url}", password="#{out_pass}", mount="test2", http)

If I use this script with an rtp source available at 127.0.0.1:40000 I have two icecast streams that are listenable to.

If I stop the rtp source the http stream 'hangs/blocks' for 9.98 seconds until Avutil calls an error at connection timeout, as below, when it pops back up again..

I think the 9.98 has to be the socket timeout, so wondered if reducing it to as small as possible might stop the interruption of the other stream. To be honest I'm not sure this will work as I think it will timeout straight away if the rtp source is not feeding the input which is not what i want.

2022/05/06 11:19:33 [3_0:3] Connection setup was successful.
2022/05/06 11:19:51 [1_0:2] Feeding failed: Avutil.Error(Connection timed out)
2022/05/06 11:19:51 [3_0:3] Source failed (no more tracks) stopping output...
2022/05/06 11:19:51 [3_0:3] Closing connection...
2022/05/06 11:19:51 [clock.main:2] We must catchup 9.98 seconds!

Liquidsoap 2.1 (github main) and latest release version of ocaml-ffmeg

Thanks

Russsgithub avatar May 06 '22 11:05 Russsgithub

I think that this should be fixed now, I pushed some changes in ocaml-ffmpeg yesterday related to this issue. Could you check again with the latest GH actions build here: https://github.com/savonet/liquidsoap/actions/runs/2286711699

toots avatar May 07 '22 15:05 toots

@toots

OK, that looks flash .. :) but confusing.

I guess I'd uninstall the opam version and then install the deb file ?

If it's the same code as the latest github pushes to liq and ocaml-ffmpeg then then issue is still present.

Russsgithub avatar May 07 '22 18:05 Russsgithub

Latest deb above should have the fix, yes. At least the one I thought.

Either you install via opam in which case you'll need to pin the latest ocaml-ffmpeg or grab the .deb above.

toots avatar May 07 '22 18:05 toots

OK, no it didn't change the situation.

Russsgithub avatar May 07 '22 18:05 Russsgithub