H264 spreader
REQUEST FOR COMMENTS: H264 spreader : reduces the RTP payload size so 3rd parties RTP sources can be properly redirected over SRTP/WebRTC without IP fragmentation.
High level steps:
- Passes RTP content straight if possible
- (if not FUA & not too big)
- might RtpSeq offset if needed
- Splits StapA in sub-nals
- (and then sub-nals in FUA if still too big)
- Splits StandAlone NAL in FUA
- Spreads FUA in smaller FUA, carrying 'trailing data' to maximize the size of each FUA nal.
- (flushing the trailing on RtpSequence discontinuity or change of type)
The steps above handle :
- RtpSeq offset/adjustment of each packet
- Rtp Marker 'delay'
- 'Delay' of FUA 'end' bit if needed.
Advantages vs building whole H264 Frame as you initially proposed:
- many packets just go through after two 'if'
- less memory footprint
- more continuous flow / less data burst
- RTP sequence holes are 'kept', so it is easier to track quality / packet loss
Future improvement: back-buffer to persist between Process(), to avoid making new buffer for each new returned RTP.
Ok, it looks like there is little interest for this PR/feature, so closing it.
Hi @jvary i would like to take this! I am just very overwhelmed with PRs
I will review and address all issues myself :)
Oh! Glad there is interest! We continued development in-house (and fixed 1-2 bugs as well), so I will update this PR. @Sean-Der : question : would you rather have the 'interface' dealing with raw slices (as right-now), or have rtp.Packet in input/output ?