H264 spreader

[jvary]

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.

jvary@genetec.com

[jvary]

Ok, it looks like there is little interest for this PR/feature, so closing it.

[Sean-Der]

Hi @jvary i would like to take this! I am just very overwhelmed with PRs

[Sean-Der]

I will review and address all issues myself :)

[jvary]

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 ?