problems converting from rtp to mp2t to rtp - solved

[Chuck Crisler]

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.

In the h264parse element I added code to do the following.

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.
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.
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.
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.

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.

1. You can't change anything, like the MTU size, frame rate, bit rate, etc.
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.

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.

Chuck Crisler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130411/9eda3352/attachment.html>