SimpleConsumer: Opus DTX ignore capabilities

[jmillan]

Tested with mediasoup-demo. Clearly shows ignore logs when there is silence.

RTP sequence numbers are properly handled, no audio cuts are appreciated.

[jmillan]

@nazar-pc, I have added the changes to Rust. Would you please check it? I'm having issues when running cargo test. I didn't have any few days ago.

meson.build:162:0: ERROR: Subproject exists but has no meson.build file

It's pointing to openssl subproject, which does not have the meson.build file.

Update: Please ignore. I've removed the openssl subprojects and build it again. The meson.build file is there.

[jmillan]

Checking those CI failures..

[douglaseel]

@jmillan FYI you can also discard the next packet after a DTX if the RTP Marker bit is not set :)))

[ibc]

Why would the encoder send a "real" Opus audio packet after a DTX if such a packet should be discarded?

[douglaseel]

I don't know why, but it never sends two consecutive DTX packets.
For example: if we have 1 second of silence, it will send a DTX + opus frame + DTX + opus frame + DTX.... I suppose those frames between DTX are used for comfort noise.
The first "real" voice frame after a DTX has the RTP Marker bit set.

[douglaseel]

Just saying, if the goal is to decrease the bandwidth consumption, maybe it might be a good idea to drop those frames too (they are much bigger than DTX)

[ibc]

How standard is that behavior? It looks a bit dangerous to me if we assume that.

[jmillan]

@jmillan FYI you can also discard the next packet after a DTX if the RTP Marker bit is not set :)))

Any reference to the specification?

marker bit in audio is used to indicate the first packet after a silence period. Sending no marked packet after a DTX is not even specified.

[douglaseel]

There is no reference in the specs about this..
But this is exaclty what I've observed with opus/dtx when I've worked with it in the recent past.

[douglaseel]

marker bit in audio is used to indicate the first packet after a silence period. Sending no marked packet after a DTX is not even specified.

BTW,
DTX is a silence period, right?
So, the first voice packet after a silence period should have marker bit set..

The main problem is that they send a non-DTX frame between consecutive DTX without marker bit set. And if the marker bit is not set, it's not the first voice frame after a silence period :))))

[jmillan]

From https://datatracker.ietf.org/doc/html/rfc3551#section-4.1

 For applications which send either no packets or occasional comfort-
   noise packets during silence, the first packet of a talkspurt, that
   is, the first packet after a silence period during which packets have
   not been transmitted contiguously, SHOULD be distinguished by setting
   the marker bit in the RTP data header to one.

It is RECOMMENDED and hence we should not discard packets after a DTX if they come with marker bit unset, otherwise we could be dropping legitimate audio.

[jmillan]

@nazar-pc I mostly assigned you for reviewing the Rust side, in case you don't have the time for a full review.

[nazar-pc]

Rust side is trivial, looks good to me. I can proper review, but probably not until weekend, very busy.

UPD: No idea why it closed with comment 👀

[smoke]

@jmillan Do you have a branch / repo with the mediasoup-demo setup with Opus DTX? I am looking for some examples / demo to experience what this flag does exactly.
Did you test with https://github.com/versatica/mediasoup-demo or was it with https://github.com/Kurento/mediasoup-demos/tree/master/mediasoup-recording? Do you use / test with ffmpeg only or with gstreamer as well?

[ibc]

@smoke plesse don't pollute this already merged PR with questions and direct mentions. Use the public forum instead.