<div dir="ltr"><div><div><div><div><div><div>I have finally gotten this process to work without resorting to transcoding (which also had problems). The underlying problem seemed to be that the original rtp -> mp2t conversion lost information concerning packet to frame organization because it lost the FU header bytes along with the rtp header bytes. MP2T doesn't have very good organization like that. So in the conversion back to RTP, the code wasn't re-constructing the packets properly.<br>

<br></div>In the h264parse element I added code to do the following.<br><br></div>1. If the type was 28 or 29 (FU-A or FU-B) remove the second FU header byte. It is added later anyway. I scan the entire input buffer assuming multiple possible slices. Record finding a first MB in slice == 0, that signals a new frame.<br>
</div>2. For relevant NALU types (not SPS or PPS), check the first MB in slice. If it is 0, the push the current buffered data to the rtph264payloader. Push the buffer, including the start codes, into the adapter.<br></div>
<div>3. When scanning the adapter data, only stop searching for start codes if the next 'first MB in slice' is 0 (you have a new frame). Otherwise, continue searching. SPS and PPS packets also stop the search so they can be pushed immediately.<br>
</div><div>4. If you found a start code in the adapter buffer && you have a new frame (identified in step #1 above), then you can push the data to the next element. The rtph264payloader does the right thing.<br></div>
<div>
<br></div>The start codes were maintained through the process in the proper places to delineate macroblock boundaries. This process effectively reconstructs the RTP packets exactly like they were in the original form, as verified through packet captures. There are a couple of important caveats.<br>

<br></div>1. You can't change anything, like the MTU size, frame rate, bit rate, etc.<br></div>2. You can't generate I-Frames if the destination requests them. You can send SPS and PPS packets though. That requires that you configure the originating system to periodically send I-Frames, which implies that you have to have good knowledge of how all of the end points are controlled.<br>

<br>The system does work very well with no noticeable overhead, unlike transcoding. It also works properly on all of my other tests where I have MP2T streams that originated elsewhere. I haven't (but should) tested video capture->encode->rtp payload->transmit.<br>
<br>Chuck Crisler<br></div>