"Freezes" transcoding RTP g.711 stream to mp3

[sagonzal]

Hi,

I am trying to connect to a live RTP stream of g.711 audio from an intercom and then output it as an mp3 file.

FFmpeg version
N-86996-g931c0ac95c-Reino cross-compiled for Windows 64 w/ pthreads and debug=3 enabled

command:
ffmpeg -re -f mulaw -i rtp://10.200.1.14:32760 -sample_rate 44100 -filter:a "asetrate=9000" -acodec libmp3lame -ar 44100 live-rtp-g711-toMP3.mp3 -report

output: “live-rtp-g711-toMP3.mp3”
report: “live-rtp-g711-toMP3-REPORT.log”
gdb backtrace: “live-rtp-g711-toMP3-BACKTRACE.txt”

With this command, the window “freezes” after printing “[udp @ 0000002c748241e0] end receive buffer size reported is 65536”.
The command line will stay that way indefinitely until I enter ctrl+c (q doesn’t work), after which it seems to say that nothing was written to the output, and the output file produced is indeed empty/unplayable.

Unfortunately I cannot provide access to th live rtp stream, as it requires VPN access. I saw something about using ffplay if my output isn’t reproducable, but I’m not sure how to do that. If it’s needed could you please give more details on how to do this?

However I can say that, using Wireshark, I have confirmed that there is traffic coming through port 32760 — packets using the RTP protocol and g.711U payload type, as expected (attached screenshot “wireshark-RTP-g711-traffic.png”). I Analyzed and Saved the data from Wireshark as a "synchronized forward stream audio” in the .raw format, then used the same command with the .raw input instead of an RTP stream, and that works:

command:
ffmpeg -re -f mulaw -i wireshark-rtp-g711-syncedRAW.raw -sample_rate 44100 -filter:a "asetrate=9000" -acodec libmp3lame -ar 44100 wireshark-rtp-g711-syncedRAW-toMP3.mp3 -report

input: “wireshark-rtp-g711-syncedRAW.raw”
output: “wireshark-rtp-g711-syncedRAW-toMP3.mp3”
report: “wireshark-rtp-g711-syncedRAW-toMP3-REPORT.log”

I don’t know why the command works with the saved audio from Wireshark but not with a live stream. I’m very new to FFmpeg so I apologize if this is just a user error.

I would appreciate any light that can shed on this problem!

Thanks very much,

Sara

[sagonzal]

gdb backtrace of error

[sagonzal]

live rtp-g711-toMP3 REPORT

[sagonzal]

live rtp g711 to MP3 output

[sagonzal]

screenshot of live rtp g711 traffic on Wireshark

[sagonzal]

input for 2nd command: .raw synced rtp-g711 audio from Wireshark

[sagonzal]

output for 2nd command: resulting mp3 audio from .raw file

[sagonzal]

generated report from 2nd command (.raw rtp-g711 to mp3)

[cehoyos]

Why are you using asetrate and why do you think the input signal has a frequency of 9kHz?

[sagonzal]

Truthfully, I’m not entirely certain. My command used to just be:

ffmpeg -re -f mulaw -i rtp://10.200.1.14:32760 -acodec libmp3lame live-rtp-g711-toMP3.mp3 -report

only it didn't work with live intercom audio (0 packets read/encoded, etc.), and with the Wireshark audio resulted in an mp3 that sounded very high-pitched and fast. After adding sample_rate and asetrate of 9000, the mp3 sounded "normal". I figured the same could be applied to the intercom audio.

I should note that when I spoke with the company that makes the intercoms, I was told that the g.711 audio stream would send as either 7kHz or, more likely, as 3.4kHz. I haven’t gotten those rates to work for me with either rtp or .raw input.

[cehoyos]

Please test the following:

$ ffmpeg -f mulaw -ar 8k -i rtp://10.200.1.14:32760 out.mp3

And please avoid cross-posting.

[sagonzal]

Hi sorry for the delay I went ahead and tried out your command. I will attach the results as "ffmpeg-test-#655-out.mp3" and "ffmpeg-test-#655-report.log". The results seem to be similar to before.

[sagonzal]

ffmpeg recommended test for ticket #655: output

[sagonzal]

ffmpeg recommended test for ticket #655: report