<div dir="ltr"><div class="gmail_quote"><div dir="ltr"><div>Hi</div><div><br></div><div>I have an embedded target where I am unable to upgrade the gstreamer installation higher than 12.3 due to a kernel with proprietary drivers not available in recent versions and a resulting problem with updating yocto to a recent version as well. <br></div><div><br></div><div>On this target I need to rtp a h264 stream from a camera interfaced using the v4l2src. I therefore use the following pipeline to determine if the data sent on RTP is correct:</div><div><br></div><div>gst-launch-1.0 v4l2src device=/dev/video1 ! video/x-h264, width=1920, height=1080, framerate=10/1 ! tee name=t t. ! queue ! filesink location=/home/dtc/testfilev4l2.dat t. ! queue ! rtph264pay name=pay0 ! filesink location=/home/dtc/testfilepay.dat</div><div><br></div><div>When I then look at the binary file testfilepay.dat I see the following:</div><div><br></div><div> <div> <div style="color:rgb(212,212,212);background-color:rgb(30,30,30);font-family:Consolas,"Courier New",monospace;font-weight:normal;font-size:12px;line-height:16px;white-space:pre-wrap"><div><span style="color:rgb(86,156,214)"> Offset: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F </span></div><div><span style="color:rgb(86,156,214)">00000000:</span><span style="color:rgb(212,212,212)"> <span style="color:rgb(255,0,0)">80 60 28 B5 40 5B 2F CD 7A 3E 18 90 67</span> 4D 40 29 </span><span style="color:rgb(106,153,85)"> .`(5@[/Mz>..gM@)</span></div><div><span style="color:rgb(86,156,214)">00000010:</span><span style="color:rgb(212,212,212)"> 96 54 03 C0 11 3F 2A <span style="color:rgb(255,0,0)">80 60 28 B6 40 5B 2F CD 7A</span> </span><span style="color:rgb(106,153,85)"> .T.@.?*.`(6@[/Mz</span></div><div><span style="color:rgb(86,156,214)">00000020:</span><span style="color:rgb(212,212,212)"> <span style="color:rgb(255,0,0)">3E 18 90 68</span> EE 38 80 <span style="color:rgb(255,0,0)">80 60 28 B7 40 5B 2F CD 7A</span> </span><span style="color:rgb(106,153,85)"> >..hn8..`(7@[/Mz</span></div><div><span style="color:rgb(86,156,214)">00000030:</span><span style="color:rgb(212,212,212)"> <span style="color:rgb(255,0,0)">3E 18 90 7C 85</span> <span style="color:rgb(255,0,255)">00 00 01 67 4D 40 29 96 54 03 C0</span> </span><span style="color:rgb(106,153,85)"> >..|....gM@).T.@</span></div><div><span style="color:rgb(86,156,214)">00000040:</span><span style="color:rgb(212,212,212)"> <span style="color:rgb(255,0,255)">11 3F 2A 00 00 00 01 68 EE 38 80 00 00 00 01 65</span> </span><span style="color:rgb(106,153,85)"> .?*....hn8.....e</span></div><div><span style="color:rgb(86,156,214)">00000050:</span><span style="color:rgb(212,212,212)"> 88 80 40 02 FF FE 04 18 70 29 1B 5D 15 CC 05 E9 </span><span style="color:rgb(106,153,85)"> ..@..~..p).].L.i</span></div></div></div> </div><div><br></div><div>What I see from the about it that the two first NALs of the h264 stream is parsed correctly and the 00 00 00 01 h264 header is removed and replaced with an RTP header (marked in read above). However, for the third NAL (an 0x65 NAL) it seems that it starts copying from the input stream 27 bytes too early resulting in both the two first NALs to be duplicated into the stream where the second time they appear they are prepended with the h264 header 00 00 00 01 or 00 00 01 and the header of the third NAL to be copied incorrectly (all this is marked with pink above). In other words all the 27 bytes marked with pink above should be removed.<br></div><div><br></div><div>I have then investigated in the rtph264payload source code how this happens and what I have found is that the payload is doing the following to each input buffer:<br></div><div><br></div><div>1. The input buffer to the element in pushed into an GstAdapter<br></div><div>2. Then the full GstAdapter is searched through in order to determine the start position of all the NALs<br></div><div>3. Then for each of the NALs a buffer is taken from from the adapter with gst_adapter_take_buffer<br></div><div>4. These buffers are then parsed to determine which type of NAL is contained within and how big the buffer is<br></div><div>5. If the buffer size is below the mtu size of the system:<br></div><div> 5.1. Make a new GstBuffer with the correct header<br></div><div> 5.2. Append the buffer taken from the adapter to the new GstBuffer with gst_buffer_append()</div><div> 5.3. Send that new buffer out on the src pad</div><div>6. If the buffer size is above the mtu size of the system:</div><div> 6.1. Make a new GstBuffer with the correct header</div><div> 6.2. Copy the correct part of the buffer taken from the adapter into the new buffer using gst_buffer_copy_into()</div><div> 6.3. Send the new buffer out on the src pad</div><div> 6.4. Determine if all the buffer taken from the GstAdapter has been copied to output buffers and if not then go back to 6.1</div><div><br></div><div>I have also determined that the problem seems to be that the gst_buffer_copy_into() seems to disregard that the buffer taken from the GstAdapter does not start at the start of the adapter. In other words, when we use gst_buffer_copy_info() to copy from the buffer taken from the GstAdapter with an offset of zero it starts at offset 0 relative to the start of the data pushed into the adapter even though 27 bytes have been taken or flushed from the adapter before this.</div><div><br></div><div>Does anyone know of a way to make the function gst_buffer_copy_into respect the offset of the input buffer instead of starting at the start of the adapter?</div><div><br></div><div>Kind regards</div><div><br></div><div>Andreas Corneliussen<br></div><div><div><br></div></div></div> </div></div>