-
Notifications
You must be signed in to change notification settings - Fork 142
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] SRT Support #392
Comments
I would be happy to contribute support for this, but I wanted to open an issue to discuss alternatives and ensure that this feature is wanted by upstream first. |
@memchk The solution that I finally found was to use ffmpeg on the local machine (to be able to use the local udp stream) and convert it back to f32le (I don't understand what happens since the input is the same as the output) but in this way, when sending it by srt the audio is perfect! RTL_Airband udp_stream output port: 8889 Take ffmpeg output on port 8891 and send via srt on port 8890 and using ffplay on my windows pc I don't know why I have to specify that the stream is a single channel and with a bitrate of 8k, when ffmpeg is using 2 channels and a bitrate of 16k, it's the only way I managed to make it sound perfect. |
Works like a charm using ffmpeg and srt-live-transmit. Thanks very much @OA6DXV! |
Is your feature request related to a problem? If so, please describe.
I use RTLSDR-Airband to provide low-latency access to my airparks CTAF frequency. For this, I run the software dockerized along with liquidsoap to produce a web-consumable HLS stream. Currently this is painful as liquidsoap has effectively deprecated raw UDP support. I use
srt-live-transmit
to convert the raw UDP to SRT locally, then forward to the liquidsoap server.Describe the solution you'd like
Implement the SRT protocol which is natively supported by both liquidsoap and ffmpeg. This gives a better transport than raw UDP (FEC, some ability to handle packet loss, etc.) without greatly complicating the encoding as we can still send raw PCM data.
Describe alternative solutions or features you've considered
We could instead support RTP/RTMP, but SRT has made an effort to be relatively easily integrated, and seems to be the emerging de-facto standard for audio/video transport.
The text was updated successfully, but these errors were encountered: