Opened 8 months ago
Last modified 8 months ago
#6625 new defect
"Freezes" transcoding RTP g.711 stream to mp3
Reported by: | sagonzal | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | undetermined |
Version: | unspecified | Keywords: | rtp |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
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
Attachments (9)
Change History (13)
Changed 8 months ago by sagonzal
comment:1 Changed 8 months ago by cehoyos
- Keywords g.711 removed
Why are you using asetrate and why do you think the input signal has a frequency of 9kHz?
comment:2 Changed 8 months ago by 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.
comment:3 Changed 8 months ago by cehoyos
Please test the following:
$ ffmpeg -f mulaw -ar 8k -i rtp://10.200.1.14:32760 out.mp3
And please avoid cross-posting.
gdb backtrace of error