Will Opus be delivered into multiple rtp packets in webrtc?

25 views
Skip to first unread message

yishen wang

unread,
Nov 7, 2021, 12:50:57 AMNov 7
to discuss-webrtc
Hi, I am new to webrtc audio transportation(compare to video).There are `Mark bit` in RTP header that we can tell whether a frame is finished. But An opus frame is so small that we can deliver it into a rtp packet. 
I wonder Is it possible that an OPUS frame will be delivered by multiple rtp packets in some special situations?( like Opus uses code 3  packet that multiple Frames in an Opus Packet , it make an Opus packet too big ). 

And  Does  `Mark bit`  Rtp header play a role in webrtc Audio Rtp Packet transportation?

thanks!

Philipp Hancke

unread,
Nov 7, 2021, 2:19:46 AMNov 7
to discuss...@googlegroups.com
does not define a way to split frames into multiple packets (like e.g. defined for VP8 or other video codecs; but note that this definition from RFC 3551 is only for video).

In theory the highest bitrate of 510kbit/sec with a maximum size of 1275  bytes (https://datatracker.ietf.org/doc/html/rfc6716) exceeds the ~1200 bytes available in practice if you assume 20ms/50 packets per second.
But at the same time you'll want to go for 10ms frames in that case.


--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/dc5c57d8-4416-450d-ba5d-1fb483b6f813n%40googlegroups.com.

Roman Shpount

unread,
Nov 7, 2021, 2:29:20 AMNov 7
to discuss-webrtc
The marker bit in RTP header (I assume you are talking about rhw marker bit) has a different purpose for audio than for video (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. The marker bit in all other packets is zero. The beginning of a talkspurt MAY be used to adjust the playout delay to reflect changing network delays. Applications without silence suppression MUST set the marker bit to zero.

So, unless, you use DTX transmission, which is not recommended for OPUS (https://datatracker.ietf.org/doc/html/rfc7587#section-3.1.3), you should always set the RTP marker bit to zero for all packets.
Reply all
Reply to author
Forward
0 new messages