Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Support Opus in WireShark

From: Roland Knall <rknall@xxxxxxxxx>
Date: Mon, 20 Jan 2020 12:44:33 +0100
I can provide some examples if needed, of exactly that. Either multiple OPUS streams, or traces which contain opus and G.711 in the same conversation. Just tell me, if you need a new bug-entry created or have an existing one to attach to.

kind regards
Roland

Am Mo., 20. Jan. 2020 um 12:30 Uhr schrieb Jiří Novák <j.novak@xxxxxxxxxxxx>:
Dear Ryan,

> Using C++ default parameter because I want to use Opus FEC.  When a RTP
> packet lost, I need to use the next packet’s data to recovery the lost
> data. But the decoder module only have data ,can’t get the neighbor
> packet’s information. So I modified  the rtp_audio_stream.cpp to play
> audio and rtp_analysis_dialog.cpp to save the audio.

I understand requirement for additional parameter, I don't understand
why C++, but it is not important.

I'm afraid you will touch one issue - nowadays Wireshark initiates codec
"system wide". Therefore same codec handle receives "pieces" of payload
to decode with no relations to other "pieces". If you have one RTP flow,
it is OK, but for multiple flows it happens that codec receiving pieces
of multiple flows interleaved.
It makes no troubles till now because all currently supported codes are
stateless - there is no relation between sequence of payloads. For Opus
it will make troubles by my opinion - Opus is stateful codec and you
must pass payload pieces to it in order and just for one stream. Once
you will interleave it, it will decode garbage probably.

BTW your need to add FEC flag to function call shows that codec handle
is not aware of stream. If it will be aware of it, FEC flag should be
part of codec state and you don't need to add parameter for it.

Some time ago I got idea to change codec staff to be RTP stream aware,
but as there was no strong need, I postponed it. It looks that there is
right time for it now. I will be happy to cooperate on it.

                                                Best regards,

                                                        Jirka Novak




___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe