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.no...@netsystem.cz >: > 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@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
