packetized vs bytestream in rtp

[Olivier Crête]

On Thu, 2013-03-28 at 14:54 -0400, Chuck Crisler wrote:
> Actually, as I have been working on this over time I have come to
> realize that the current gstreamer (or any RTP code) cannot possibly
> work. There is important information in the first RTP stream that is
> lost in the conversion to MP2T. Specifically the fact that there are
> multiple RTP packets required for the frame which is signaled via the
> FU-A construct. However, that seems to be OK for the MP2T. When the
> conversion back to RTP is made, it is only processing those MP2T
> packets that were created from each single RTP packet in the original
> stream. I don't think that there is any way in the normal scheme to
> correct that. I think that to correct it I will need to modify
> h264parse (my first element in the conversion back to RTP) to collect
> input buffers until the first_mb_in_slice == zero. Then the previous
> data can be processed and pushed out as a single buffer for rtph264pay
> to process. I have seen other places in the code of both elements that
> make that same assumption, so it seems safe to me.

I'm not sure I understand exactly what you mean, but rtph264depay will
merge back FU-A and FU-B packets into a single GStreamer buffer (or drop
them completely if any part is missing), if you control the encoding,
you are strongly advised to make the NAL unit smaller than the MTU.

I think you want to collect all of the buffers in an access unit (where
first_mb_in_slice == zero), then rtph264depay can do that for you if the
caps afterwards having "alignment=au". You should never need to have
h264parse after rtph264depay.

-- 
Olivier Crête
olivier.crete at collabora.com