This pcap file in cloudshark was captured during a voip mobile app (audio) conversation. https://www.cloudshark.org/captures/8fef0eaa85f4 As we can see, Opus is used as codec. In wireshark, I analyzed the RTP stream, saved as raw file. Then I downloaded opus encode/decoder tool from : http://www.opus-codec.org/downloads/ I encoded the raw file as : "encode.exe --bitrate 16 --raw myrawfile.raw output.opus" Then Tried to play opus file in audacity. What I can get is only the noise. I tried by decoding the opus file into wav and play again. Still no luck. Could you please suggest me where have I gone wrong ? asked 13 May '15, 07:47  Shas |
One Answer:
You want to go the other way, decode from opus to wav. answered 15 May '15, 02:16  Jaap ♦ showing 5 of 7 show 2 more comments |
@Jaap, wireshark doesnt allow saving .opus, does it ? To decode it we need to have .opus file at first. That is the problem, we dont have ,opus file, we have only raw file. Thanks
Raw != WAV. Raw is the binary data in the RTP packets.
The binary data in the RTP packets is Opus encoded sound. Therefore you need to decode the opus encoded data in WAV encoded data.
@Jaap, Thanks for the comment. I couldnt be quiet clear. Yes, I have raw file (already opus encoded), need to make it wav file. but opus decoder takes only .opus file as input to decode and create wav file. Here is the problem, how do we feed raw (opus encoded) but not recognized by opus decoder as opus file in the decoder. Appreciated
The problem with extracting the raw Opus stream is that it is a variable bit rate (VBR) codec. The extracted data needs to be written with some sort of framing such as Ogg or Matroska so the player knows where one frame ends and the next begins.
Indeed. And so opening a whole new can-o-worms.
@Shas,
look here. In short, by extracting the RTP payload from the RTP packets into a continuous stream of bytes, you strip information which the opus decoder needs. As @kjotte wrote, the decoder needs to know where the individual Opus packets (which are not the same as IP packets) begin and end, as they do not contain such information inside themselves and as their size is variable.
The opusdec from the Opus tools can only extract the Opus packets from an ogg file structure which provides, if we limit ourselves to aspects important for Opus, the same service like RTP: encapsulation of the Opus packets into a transport layer which indicates where they begin and end and also includes means to obtain this information also if part of the data gets lost in transport.
So you have three possibilities:
to file an "enhancement" category bug (= wish) at Wireshark Bugzilla, asking for integration of Opus decoder into Wireshark
to ask people at Opus to add support for pcap (pcapng) input files (i.e. Opus packets encapsulated into RTP packets stored in pcap or pcapng formatted file, which you could easily create by using File -> Export Specified Packets in Wireshark after applying a corresponding display filter or by using the same display filter for tshark with -w option)
to write "something" yourself, where the "something" may be an application (script) written using your favourite programming language which would read the pcap(ng) file as above, extract the opus packets from it and save them using the ogg encapsulation, or (if you speak C), the pcap(ng) parser as an extension for the opusdec tool as mentioned above. As also other software than the opusdec can decode ogg-encapsulated Opus streams, the converter application may make sense even if you speak C.
Hm, as there are many possible "link type" encapsulations, you'd need half of Wireshark code to properly parse a pcap(ng) file to reach the packet fields you need. So better to use
tshark.exe -r opus_reverse.pcap -T fields -e rtp.timestamp -e rtp.payload -d udp.port==10758,rtp -E separator=;and use the output line by line to create an .opus (actually, ogg) file. The result of such processing then looks like this: forward direction and reverse direction.