So markerbit should be set at "start" of talkspurt. Is it true that the first packet in a talkspurt is 1 byte?

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

I might have read some details wrong, i actually added it at the end of a talk spurt, fixed that

You can rename this file to test_talk_startspurt: https://github.com/algesten/str0m/blob/main/tests/rtp_to_frame.rs

Then validate that marker bit get's added.

Ideally test the different combinations of rtp/frame api.

@algesten should some api be added for this, so in case dtx is set to false marker bit will never be set and it will not be negotiated over sdp.

Can we really auto-detect talk spurts without some audio analysis? I mean just because there's some noise on the line, doesn't mean there is a talk spurt starting. How does libWebRTC do this? (or pion if they support it)

Can we really auto-detect talk spurts without some audio analysis? I mean just because there's some noise on the line, doesn't mean there is a talk spurt starting. How does libWebRTC do this? (or pion if they support it)

Audio analysis is done in Opus so it will handle this.

I need to double check the packet pattern that Opus emits not sure this logic will work.

I don't think Pion supports this, best would be to check how libwebrtc set the marker bit on Opus packages.

I took the inspiration from rtpopuspayloader

so in case dtx is set to false marker bit will never be set and it will not be negotiated over sdp.

I was thinking of passing down the UseDtx flag from sdp to codec but never found any other codec doing it, so skipped it for now. I did see something like H264CodecExtra to pass down options to de packetizer should something like that exists for packetizer as well?

Or probably at the start of initialising the struct codec params can be passed

I didn't find a way to get access to previous packet inside the opus packetizer, since we don't cache it (something about audio packets not being nackable), so i changed the implementation a bit.

I have also added a rtp level test for the same.

For doing this only when dtx is enabled: we have FormatParams::use_dtx inside CodecSpec, maybe a simple solution would be impl this around here

For doing this only when dtx is enabled: we have FormatParams::use_dtx inside CodecSpec, maybe a simple solution would be impl this around here

str0m/src/packet/payload.rs

Line 58 in 5c4c9d5

let marker = self.pack.is_marker(data.as_slice(), previous_data, last);

passing the CodecSpec down from the caller ?

That would mean all the packetizers would need to accept it, and its more like a initialising info thats once set would not change, we can pass it down at the start somehow

@ramyak-mehra when we instantiate the packetizer, the fmtp parameters are available:

            Payloader::new(params.spec)

The spec here is CodecSpec, which has a field for FormatParams, which in turn has the use_dtx setting.

I think all is in place for that already.

while we can pass it down i want to understand the rational behing passing extra_codec_params in each depacketize call.
Are there para meters that change with each packet thats why its there? Do we want to enable both kinds of approach passing down with each call as well as at initilizing?

That would mean all the packetizers would need to accept

No. I meant it can be done from the caller of is_marker(). Like: marker = if audio && !dtx { false } else { packetizer…

while we can pass it down i want to understand the rational behing passing extra_codec_params in each depacketize call. Are there para meters that change with each packet thats why its there? Do we want to enable both kinds of approach passing down with each call as well as at initilizing?

I don't understand why we are talking about the depacketizer? This PR is about the packetizer, right?

No. I meant it can be done from the caller of is_marker(). Like: marker = if audio && !dtx { false } else { packetizer…

I mean that this has nothing to do with the code calling the packetizer. The use_dtx function is dependent on which packetizer we are talking about. This should be passed into creating the OpusPacketizer (as I illustrated above), and be remembered internally for that packetizer only.

If we do it via OpusPacketizer constructor I think we have take care of dynamic updates somehow. DTX can be activated and deactivated via js apis and user settings during an ongoing call. Currently payloaders are stored based on (pt, rid) so if an SDP renegotiation changes a:fmtp:... adding usedtx I am afraid we would not pick up the change, or do we ?.

We can just ignore the sdp use_dtx, if it's off the decoder on the other side should just ignore the marker bit.

Thogh I am not sure how do we handle sdp re negotiations in this library will take a look

I think we have take care of dynamic updates somehow. DTX can be activated and deactivated via js apis and user settings during an ongoing call.

Thogh I am not sure how do we handle sdp re negotiations in this library will take a look

I'm not convinced this is an attribute that can be changed runtime. AFAIK, the only thing you can change on an already negotiated m-line is the direction.

However even if it can be changed runtime, why would you want that? I think we can just say str0m does not change this dynamically and we could potentially detect dynamic changes and reject them in incoming SDP.

Updated the PR to pass down use_dtx and added tests on the packetizer itself.
On a side note:
I see we create a new payloader everytime we want to write. Seems a bit redundant though or am i missing something?