Skip to content

fix #821: raise default max_packet_size for multitrack support#833

Closed
Ayoub-glitsh wants to merge 1 commit into
roc-streaming:masterfrom
Ayoub-glitsh:fix/821-multitrack-packet-size
Closed

fix #821: raise default max_packet_size for multitrack support#833
Ayoub-glitsh wants to merge 1 commit into
roc-streaming:masterfrom
Ayoub-glitsh:fix/821-multitrack-packet-size

Conversation

@Ayoub-glitsh
Copy link
Copy Markdown

Fixes #821

The default max_packet_size of 2048 bytes is too small for multitrack
audio. For example, 8 channels at 48kHz with the default 5ms packet
length requires ~3904 bytes (240 samples × 8 channels × 2 bytes + RTP
header), causing the packetizer to silently fail with "can't prepare packet".

Changes:

  • Raise ContextConfig default max_packet_size from 2048 to 16384 bytes,
    which covers up to ~34 channels at 48kHz/5ms/16-bit PCM without any
    manual configuration
  • Improve the error message in Packetizer::create_packet_() to include
    payload_size and buffer_capacity, and hint the user to increase
    max_packet_size if they do hit the limit

The default max_packet_size of 2048 bytes is too small for multitrack
audio. For example, 8 channels at 48kHz with the default 5ms packet
length requires ~3904 bytes (240 samples x 8 channels x 2 bytes +
RTP header), causing packetizer to fail with 'can't prepare packet'.

Changes:
- Raise ContextConfig default max_packet_size from 2048 to 16384 bytes,
  which covers up to ~34 channels at 48kHz/5ms/16-bit PCM
- Improve error message in Packetizer::create_packet_() to include
  payload_size and buffer_capacity, and hint to increase max_packet_size
@rocstreaming-bot rocstreaming-bot added the contrib PR not by a maintainer label Apr 24, 2026
@rocstreaming-bot
Copy link
Copy Markdown

🤖 Pull request is not targeted to develop branch, which is usually wrong.
If this was not intentional, please rebase on fresh develop branch, force-push, and re-target pull request using github web interface. Remember to use rebase with force-push instead of regular merge.

@baranovmv
Copy link
Copy Markdown
Member

The should definately be treated, but I'd rather pick a solution that handles possible packet framentations more explicit. Closing this PR, and let's discuss it further in the issue

@baranovmv baranovmv closed this Apr 24, 2026
@Ayoub-glitsh
Copy link
Copy Markdown
Author

Got it, thanks for the quick review!
What did you have in mind for handling the fragmentation side? I want to make sure I'm going in the right direction before reworking it. Happy to rebase on develop once we're aligned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

contrib PR not by a maintainer

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Multitrack packets too big per default ("packetizer: can't prepare packet")

3 participants