rtp icon indicating copy to clipboard operation
rtp copied to clipboard

H264 spreader

Open jvary opened this issue 3 years ago • 4 comments

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 avatar Jul 03 '22 16:07 jvary

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

jvary avatar Oct 26 '23 21:10 jvary

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

Sean-Der avatar Oct 26 '23 22:10 Sean-Der

I will review and address all issues myself :)

Sean-Der avatar Oct 26 '23 22:10 Sean-Der

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 ?

jvary avatar Oct 26 '23 22:10 jvary