packetized vs bytestream in rtp

[Chuck Crisler]

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.

BTW - my problem yesterday turned out to be multiple serious bugs in the
iDoubs package actually sending out RTP packets with 0 0 1 due to searching
for 0 0 0 1 in the encoded buffer (the encoder embedded 0 0 1 to delineate
slices), and consequently not ever finding or replacing any of the embedded
start codes.

On Thu, Mar 28, 2013 at 10:16 AM, Tim-Philipp Müller <t.i.m at zen.co.uk>wrote:

> On Thu, 2013-03-28 at 10:00 -0400, Chuck Crisler wrote:
>
> Hi Chuck,
>
> > In the rtph264pay element, the packetized structure member is set to
> > true iff codec_data is specified. Why? I realize that in many uses,
> > when this element is used the sprops data is available and can be
> > supplied. In many cases where the sprops data isn't available, the
> > stream should be bytestream. However, the application programmer knows
> > the use of the element in the pipeline, so the element should allow a
> > property (such as bytestream in the h264parse element) that allows the
> > user to set the type, with the current behavior as the default if
> > nothing is set. In many use cases, including video conferencing, you
> > don't know the codec data apriori, or even care. Also, while a stream
> > is running, the resolution often changes, invalidating the sprops
> > data. However, those changes are signaled in the bitstream.
>
> Sorry, but what exactly is the problem you are trying to solve or use
> case you're trying to support, and that rtph264pay doesn't handle
> currently?
>
> rtph264pay accepts both byte-stream and AVC as input.
>
> The presence of a codec_data field implies that the input is AVC, which
> will be nicely packetised.
>
> If the input is byte-stream format, the codec data (SPS/PPS) will be
> signalled in the byte stream.
>
> Cheers
>  -Tim
>
> _______________________________________________
> 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/d8196723/attachment.html>