H264/RTP and setcaps

[Chuck Crisler]

I am trying to merge some custom changes into gstrtph264pay.c and depay.c. I
am working with gst-plugins-good version 0.10.14 and porting changes from
0.10.10. In pay_setcaps, if the code can't find a structure value named
'codec_data', then the packetized data member is set to false (and you miss
most of the initialization), which is happening in my implementation. Where
should this value be set and what is the significance of it?

Thank you,
Chuck Crisler

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Jarosław Przybyłowicz]

W dniu 2011-04-11 23:54, Chuck Crisler pisze:

> I am trying to merge some custom changes into gstrtph264pay.c and
> depay.c. I am working with gst-plugins-good version 0.10.14 and
> porting changes from 0.10.10. In pay_setcaps, if the code can't find a
> structure value named 'codec_data', then the packetized data member is
> set to false (and you miss most of the initialization), which is
> happening in my implementation. Where should this value be set and
> what is the significance of it?
>
> Thank you,
> Chuck Crisler
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

Hi,

codec_data is required to properly decode video stream (it's all about
SPS and PPS parameters). If codec_data is not set on caps, then the only
possible place where it can be found is directly in the stream (that's
why initialization is missing - h264 decoder need to figure sps and pps
parameters directly from the bytestream itself).

I hope this explains everything,

Jaroslaw

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Chuck Crisler]

Also, are caps structures shared between pay/depay pairs? What are the uses
of these code pairs?

Again, Thank You
----- Original Message -----
From: "Chuck Crisler" <[hidden email]>
To: <[hidden email]>
Sent: Monday, April 11, 2011 5:54 PM
Subject: H264/RTP and setcaps

>I am trying to merge some custom changes into gstrtph264pay.c and depay.c.
>I am working with gst-plugins-good version 0.10.14 and porting changes from
>0.10.10. In pay_setcaps, if the code can't find a structure value named
>'codec_data', then the packetized data member is set to false (and you miss
>most of the initialization), which is happening in my implementation. Where
>should this value be set and what is the significance of it?
>
> Thank you,
> Chuck Crisler
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Jarosław Przybyłowicz]

W dniu 2011-04-12 00:01, Chuck Crisler pisze:
> Also, are caps structures shared between pay/depay pairs? What are the
> uses of these code pairs?
>
> Again, Thank You
>
Not directly, codec_data is coded as sprop-parameter-set (that is a
base64 representation) in rtph264pay element.
On the rtph264depay they are decoded from sprop-parameter-set of the
incoming caps.

Regards,

Jaroslaw

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Chuck Crisler]

OK, but the rtph264pay setcaps function looks for the codec_data and makes a
significant decision based on it but I can't find where that is set
anywhere. It just doesn't seem right (which means that I don't understand
what is really happening).

----- Original Message -----
From: "Jaroslaw Przybylowicz" <[hidden email]>
To: "Discussion of the development of and with GStreamer"
<[hidden email]>
Sent: Monday, April 11, 2011 6:07 PM
Subject: Re: H264/RTP and setcaps

>W dniu 2011-04-12 00:01, Chuck Crisler pisze:
>> Also, are caps structures shared between pay/depay pairs? What are the
>> uses of these code pairs?
>>
>> Again, Thank You
>>
> Not directly, codec_data is coded as sprop-parameter-set (that is a base64
> representation) in rtph264pay element.
> On the rtph264depay they are decoded from sprop-parameter-set of the
> incoming caps.
>
> Regards,
>
> Jaroslaw
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Olivier Crête-2]

On Mon, 2011-04-11 at 18:14 -0400, Chuck Crisler wrote:
> OK, but the rtph264pay setcaps function looks for the codec_data and
> makes a
> significant decision based on it but I can't find where that is set
> anywhere. It just doesn't seem right (which means that I don't
> understand
> what is really happening).

In the RTP payloader, if the codec_data is in the caps, it needs to
create NAL units for it and output it as buffers. If it's not in the
caps, then it comes in the data stream pre-packages in NAL units and
they can be treated like any other NALU.

--
Olivier Crête
[hidden email]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Jarosław Przybyłowicz]

W dniu 2011-04-12 00:14, Chuck Crisler pisze:
> OK, but the rtph264pay setcaps function looks for the codec_data and
> makes a significant decision based on it but I can't find where that
> is set anywhere. It just doesn't seem right (which means that I don't
> understand what is really happening).
This decision is based on input type. If codec_data is set, then input
buffers are treated as a bytestream (so it needs to by parsed before
putting them into RTP packets). Otherwise each buffer is assumed to
contain a NALU which does not need such parsing.

_______________________________________________
gstreamer-devel mailing list
[hidden email]
http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel