-
Notifications
You must be signed in to change notification settings - Fork 851
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
Add support for RTP input in srt-live-transmit #2848
Conversation
Could you please also update the srt-live-transmit.md document with the new media type and its specifics like not actually parsing RTP you described here? |
Addressed via 3075b8e |
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## master #2848 +/- ##
==========================================
- Coverage 67.04% 67.02% -0.02%
==========================================
Files 102 102
Lines 20368 20368
==========================================
- Hits 13656 13652 -4
- Misses 6712 6716 +4 ☔ View full report in Codecov by Sentry. |
…faults to 12 when using the RTP medium
Sorry that I have spread the review comments so long in time. It should be everything this time. |
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.
@davemevans Thanks for the contribution!
Introduce a new Source type that considers RTP separately to UDP.
The intention is to drop bytes from the head of the input buffer. This enables the RTP header to be dropped for use cases where the receiving end cannot accept RTP. The default behaviour is to skip the first 12 bytes. Where
rtpheadersize
is set, the number of bytes to skip can be varied, to deal with extended RTP headers for example.No effort is made in this initial implementation to attempt to parse the RTP headers in any way eg for reordering, extracting timing, detecting length.
This goes some way to addressing #136.