-
-
Notifications
You must be signed in to change notification settings - Fork 213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Configurable limits - Refactor current options #643
Configurable limits - Refactor current options #643
Conversation
@gavv Would like some early feedback. |
Thanks for PR and kudos for kibibyte :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here are a few comments.
🤖 The latest upstream change made this pull request unmergeable. Please resolve the merge conflicts. |
🤖 The latest upstream change made this pull request unmergeable. Please resolve the merge conflicts. |
Hi, I'm preparing 0.3.0 release and have rebased develop on master (this workflow is described here). Please reset develop in your fork to up-to-date version and rebase your PR on that. (You can use |
fc114b1
to
d8fd2fc
Compare
All good. Thanks. |
Great, please ping me when it's ready for review. |
See what you think if my latest changes. |
In current implementation roc-recv is broken:
|
OK. Ready for another glance. Thanks for your guidance. |
Thanks for update. I tested new version, deduction of max frame size on roc-recv works, but deduction of max packet size on roc-send doesn't. Works:
Doesn't work:
I guess we forgot to take header(s) size into account. For bare RTP, header is 12 bytes (see src/internal_modules/roc_rtp/headers.h). When FEC is enabled, it's 6 more bytes for additional FEC footer (see src/internal_modules/roc_fec/headers.h). When we add encryption, DTLS may add 13 more bytes, and SRTP may add 10 bytes, AFAIK. Also, some codecs may require aligning packets, currently they may add up to 7 bytes padding to the beginning. 12 + 6 + 13 + 7 = 38. I think we could add, say, 64 bytes, to leave some extra space, just in case. Another concern: we forgot to think about FEC (repair) packets, which should also fit into max packet size. Their size is proportional to the byte size of media packet, but generally we don't know the coefficient. So our formula should be: We should test that our formula works with different protocols ( |
src/tools/roc_send/main.cpp
Outdated
if (!args.max_packet_size_given) { | ||
// TODO(gh-608): take size from --packet-encoding instead of assuming 2 bytes per | ||
// sample |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please reorder code in roc-send so that max_packet_size_given checks would be grouped together, like you did in roc-recv?
Like:
if (max_packet_size_given) {
...
} else {
...
}
It's much easier to follow the code when these "if" and "else" for every option are in one place.
(Sorry that I didn't notice it in previous reviews).
🤖 The latest upstream change made this pull request unmergeable. Please resolve the merge conflicts. |
Sorry for conflicts, I think it's caused by 9bd9888 |
298e462
to
e376f72
Compare
OK. I've made the extra 64 bytes change to roc_send and all the changes requested. With roc_recv at 50ms, I can see roc_send work at 1ms, 5ms, 10ms - the audio comes through. But, at 50ms, and 100ms - The audio does not come through, and I see this in roc_recv, which I don't understand yet.
I expected at least 50ms to work. |
Oh, if you use big packet len on sender, you also need big max packet size on receiver. (Until we implement rtsp, it needs manual configuration) |
Oh sorry, I was confused. The 50ms roc_recv frame len is nothing to do with 50ms roc_send packet len. OK. Got it to work. --max-packet-size 32K on roc_recv seems to have worked. |
48825f2
to
f72a0ef
Compare
FYI: #654 |
Why
For #610
This is the first part to refactor existing options.
What
Testing