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.

[email protected]

[jvary]

Not sure where this struct/file should go ? Top folder ? A new internal package ?

[jvary]

I added ‘stretchr/testify’ to get more concise tests. However, I get the feeling it will be frown upon because it brings too many dependencies ?

[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 ?