xiph / opus-tools

A set of tools to encode, inspect, and decode audio in the Opus format.
https://opus-codec.org/
Other
218 stars 79 forks source link

opusrtp with payload type of 111 #25

Closed gardenia closed 5 years ago

gardenia commented 6 years ago

rtpdump.opus.zip

opusrtp_out.txt Hi,

I'm not claiming this is a bug but I would appreciate your guidance/expertise on the following:

I have a pcap of an opus RTP stream (captured from webrtc).

the SDP file for the RTP stream specified the codec as:

rtpmap:111 opus/48000/2

I attempted to use opusrtp to extract the audio from the capture but opusrtp is hard-wired to accept only accept one specific RTP payload type (OPUS_PAYLOAD_TYPE = 120).

I then speculatively tried changing the OPUS_PAYLOAD_TYPE constant definition 111 to see what would happen. What occured next was a fairly sensible looking console output with a rtpdump.opus being created. However, that opus file seems to be potentially garbled (it was not intelligible to opusdec when I tried to extract the audio as a wav).

I have attached the opusrtp console output and the resulting rtpdump.opus

I can also send you the original pcap I passed to opusrtp if that would be useful.

My question is:

Any help / guidance would be appreciated.

Thanks,

PS - I'm tagging @giavac for his input (as he seems to be the original author of opusrtp ) just in case he is not a follower of issues in this repo. I hope that is ok. but maybe this issue is more of an opus question than an RTP / pcap question?

rillian commented 6 years ago

IIRC the payload type can be whatever the SDP says it is (dynamic values can be 96-127, inclusive) so changing it should work fine. I just picked whatever the webrtc.org code was sending at the time.

As for why the dump is coming out corrupt, I don't know.

mark4o commented 6 years ago

opusrtp now accepts a payload type as an argument (-t payload_type), and if only one dynamic payload type was captured then there is no need to specify it, as it will lock onto the first plausible payload type that it sees. Even with the correct payload type, the output audio could be garbled if you capture multiple simultaneous RTP sessions using that payload type or the packets are out of order.