GNOME Bugzilla – Bug 503288
rtph264pay does not split multiple NAL units in incoming buffer
Last modified: 2008-05-26 13:59:50 UTC
Please describe the problem: When the incoming GstBuffer (h264 byte stream) contains multiple NAL units, the payloader only scans for the first NAL start code and packages the entire buffer for transmission as a single RTP frame. This can cause interoperability problem at the receiving end if the client does not support H264 byte stream decoding. Steps to reproduce: 1. gst-launch videotestsrc ! x264enc byte-stream=1 bitrate=500 key-int-max=50 ! rtph264pay ! filesink location=/tmp/x264.rtp 2. Examine the x264.rtp. Some of the NAL's are embedded in the same RTP frame Actual results: If the payloader correctly splits all the NAL units, each NAL should have its own RTP frame. This is not so in the file recorded by the above pipeline. x264enc generates SPS/PPS NALs at each IDR interval and they are packaged in the same GstBuffer (3 NALs in one GstBuffer - SPS, PPS and the IDR I slice) Expected results: The payloader should split the GstBuffer at the NAL start code boundary and send each NAL in its own RTP frame. Does this happen every time? No. Other information:
Misinterpretation of the question "Does this happen every time?". The correct answer is "Yes". The bug happens everytime with x264enc's byte stream.
Created attachment 101250 [details] [review] Breaks up multiple NALU in a single GstBuffer for RTP transport The patch proposes to split multiple NALUs in a single GstBuffer so that each NALU is sent in an RTP frame. It patches the latest source on CVS. The patch assumes that NALUs do not span multiple GstBuffers.
Created attachment 102036 [details] [review] Fixes a bug in the original patch when scanning NAL termination The original patch 101250 contains a bug in the NAL scanning code that matches 0.n1.0.n2.1 for 0.0.1. The new patch fixes this bug
Wai-Ming, could you provide your patch as a unified patch ? (cvs diff -up)
Created attachment 102374 [details] [review] Patch submission as unified patch (cvs diff -up) Response to Edward Hervey's request for a unified patch
wim, you've been reviewing the previous patches for rtph264pay, can you review/commit this one ?
This patch is now obsolete, CVS has a property scan-mode, in this case, mode 1==one input buffer contains multiple NAL units, is advised. The reason for having multiple scan modes is to allow for more efficient processing if the source provides single nal units per buffer because then you don't need to scan the complete buffer.