packetized vs bytestream in rtp

[Chuck Crisler]

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.

On Thu, Mar 28, 2013 at 2:25 PM, Olivier Crête
<olivier.crete at collabora.com>wrote:

> On Thu, 2013-03-28 at 10:44 -0400, Chuck Crisler wrote:
> > I specifically need rtph264pay to generate packetized data regardless
> > of the input. At least, I *THINK* that is what I need. Currently in
> > converting from MP2T to RTP (when the original source was also RTP)
> > every packet has the marker bit set. I have seen in many traces that
> > rtph264pay is classifying the stream as bytestream. I have tried
> > setting the h264parse element (before the rtph264pay element in the
> > pipeline) to '0' and the access-unit to true, but that generated some
> > internal failure which I did not investigate. I am hoping that by
> > forcing 'packetized' I can get the marker bit set correctly.
> > Everything else if good.
>
> The concept of bytestream vs packetized does not apply to the RTP
> payload format, it is a distinct 3rd format. The RTP packets always
> contain either a full NAL unit, more than one NAL unit or fragments on a
> NAL unit if the NAL unit is larger than the MTU. This should all happen
> automatically from your point of view. The marker bit should be set on
> any RTP packets that represents the end of an Access Unit (which is one
> or more consecutive NAL units that make up a frame).
>
> A bug that made the marker bit be set too often was fixed in
> gst-plugins-good 0.10.31, so make sure you have that version at least.
> --
> Olivier Crête
> olivier.crete at collabora.com
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20130328/d18b70eb/attachment.html>