packetized vs bytestream in rtp

[Tim-Philipp Müller]

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