Use of "on-sending-rtcp" signal

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Use of "on-sending-rtcp" signal

Philippe Lalevée
Hello
I still have problems when using on-sending-rtcp/on-receiving signals (I would like to send RTCP packets of APP type).

After having configured callbacks both for these signals (on the rtpsession object as mentioned by Sebastian) and for probes in rtcp pads, I have the following behavior on the talker side: in the two callbacks, I only have RR and SDES packets, and never SR packets, while I see SR packets with the probe callback, and whereas I see them in the listener side in the "on_receiving_rtcp" callback. Symmetrically, I have the same problem on the listener side.

Another problem is that APP packets are not transmitted from the talker to the listener. Here is shortened the sequence of instructions called in the on-sending-rtcp callback function:
- gst_rtcp_buffer_map(buffer, GST_MAP_READWRITE, &rtcp)
- gst_rtcp_buffer_add_packet(&rtcp, GST_RTCP_TYPE_APP, &packet)
- gst_rtcp_packet_app_set_subtype(&packet, subtype)
- gst_rtcp_packet_app_set_ssrc(&packet, ssrc)
- gst_rtcp_packet_app_set_name(&packet, name)
- gst_rtcp_packet_app_set_data_length (&packet, len)
- data = gst_rtcp_packet_app_get_data(&packet)
- GST_WRITE_UINT32_BE(data, value)
- ...
- return TRUE

Do I have to do something special at the end of the function, before the return instruction, for the packet to be taken into account? otherwise what could be the problem?

Thank you for your help
Philippe Lalevée



_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of "on-sending-rtcp" signal

Nicolas Dufresne-5
Le samedi 19 janvier 2019 à 17:06 +0100, Philippe Lalevée a écrit :
> Hello
> I still have problems when using on-sending-rtcp/on-receiving signals
> (I would like to send RTCP packets of APP type).

The RTPSession API isn't public, I'm not sure it is correct to use this
from an application. I believe you should better describe what you are
trying to do. It might be described in the original thread, but you
seem to have create a new thread, which means it's harder to find the
context.

regards,
Nicolas

>
> After having configured callbacks both for these signals (on the
> rtpsession object as mentioned by Sebastian) and for probes in rtcp
> pads, I have the following behavior on the talker side: in the two
> callbacks, I only have RR and SDES packets, and never SR packets,
> while I see SR packets with the probe callback, and whereas I see
> them in the listener side in the "on_receiving_rtcp" callback.
> Symmetrically, I have the same problem on the listener side.
>
> Another problem is that APP packets are not transmitted from the
> talker to the listener. Here is shortened the sequence of
> instructions called in the on-sending-rtcp callback function:
> - gst_rtcp_buffer_map(buffer, GST_MAP_READWRITE, &rtcp)
> - gst_rtcp_buffer_add_packet(&rtcp, GST_RTCP_TYPE_APP, &packet)
> - gst_rtcp_packet_app_set_subtype(&packet, subtype)
> - gst_rtcp_packet_app_set_ssrc(&packet, ssrc)
> - gst_rtcp_packet_app_set_name(&packet, name)
> - gst_rtcp_packet_app_set_data_length (&packet, len)
> - data = gst_rtcp_packet_app_get_data(&packet)
> - GST_WRITE_UINT32_BE(data, value)
> - ...
> - return TRUE
>
> Do I have to do something special at the end of the function, before
> the return instruction, for the packet to be taken into account?
> otherwise what could be the problem?


Did you unmap you RtcpBuffer ? What is this function you are
implementing ? What is it supposed to do ?
>
> Thank you for your help
> Philippe Lalevée
>
>
> _______________________________________________
> gstreamer-devel mailing list
> [hidden email]
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of "on-sending-rtcp" signal

Philippe Lalevée-2
Hi Nicolas,
I agree that I would like to do is not public. But if we execute "gst-inspect-1.0 rtpbin", we have an "element action" (get-internal-session) which returns a RTPSession. In a previous mail, I mentioned that include files to use RTPSession related stuff are not present in libgstreamer-plugins-good1.0-dev package.

What I am trying to do is to implement RTCP AVB (type 208) packets (IEEE1733, see http://www.networksorcery.com/enp/protocol/rtcp.htm for instance). For that, my first idea was to use APP packets to transmit AVB data from a talker to listeners, in order that talker and listeners no longer use NTP, but PTP clock.

As it's pretty urgent, I wanted to avoid developing gstreamer extensions (anyway I do not have the skills for that). That's why I try to use on-sending-rtcp signal, to retrieve before they are sent the buffers of RTCP packets, and in them, to add APP packets with the sequence of function calls, indicated in my mail.

Would there be other ways to do that?
Best
Philippe

Le 19/01/2019 à 17:38, Nicolas Dufresne a écrit :
Le samedi 19 janvier 2019 à 17:06 +0100, Philippe Lalevée a écrit :
Hello
I still have problems when using on-sending-rtcp/on-receiving signals
(I would like to send RTCP packets of APP type). 
The RTPSession API isn't public, I'm not sure it is correct to use this
from an application. I believe you should better describe what you are
trying to do. It might be described in the original thread, but you
seem to have create a new thread, which means it's harder to find the
context.

regards,
Nicolas

After having configured callbacks both for these signals (on the
rtpsession object as mentioned by Sebastian) and for probes in rtcp
pads, I have the following behavior on the talker side: in the two
callbacks, I only have RR and SDES packets, and never SR packets,
while I see SR packets with the probe callback, and whereas I see
them in the listener side in the "on_receiving_rtcp" callback.
Symmetrically, I have the same problem on the listener side.

Another problem is that APP packets are not transmitted from the
talker to the listener. Here is shortened the sequence of
instructions called in the on-sending-rtcp callback function:
- gst_rtcp_buffer_map(buffer, GST_MAP_READWRITE, &rtcp)
- gst_rtcp_buffer_add_packet(&rtcp, GST_RTCP_TYPE_APP, &packet)
- gst_rtcp_packet_app_set_subtype(&packet, subtype)
- gst_rtcp_packet_app_set_ssrc(&packet, ssrc)
- gst_rtcp_packet_app_set_name(&packet, name)
- gst_rtcp_packet_app_set_data_length (&packet, len)
- data = gst_rtcp_packet_app_get_data(&packet)
- GST_WRITE_UINT32_BE(data, value)
- ...
- return TRUE

Do I have to do something special at the end of the function, before
the return instruction, for the packet to be taken into account?
otherwise what could be the problem?

Did you unmap you RtcpBuffer ? What is this function you are
implementing ? What is it supposed to do ?
Thank you for your help
Philippe Lalevée


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

    

--
Logo MINES Saint-Étienne
Philippe LALEVÉE
Directeur du Campus Georges Charpak Provence
Directeur du Centre Microélectronique de Provence
Président de la Plate-forme Micro-PackS
+33 4 42 61 67 15 / +33 6 23 02 15 01
[hidden email]
@CampusCharpak #ISMIN @p_lalevee
Campus Georges Charpak Provence
880 route de Mimet, F-13541 Gardanne Cedex
Assistante CGCP : [hidden email]         (+33 442616620)
Assistante CMP :   [hidden email] (+33 442616610)
Inspiring
                  Innovation - Since
 1816

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of "on-sending-rtcp" signal

Philippe Lalevée-2
Sorry, I did not see the answer at the end of the message. Indeed, I had forgotten to unmap the GstRTCPBuffer... I see now APP packets on the talker side. Thank you very much.

Finally, I wonder if I am not mistaken in the meaning of the signals. Everything happens as if on-sending-rtcp was actually called when receiving RTCP packets and vice versa for on-receiving-rtcp. I will try by reversing the roles.

Philippe

Le 19/01/2019 à 18:29, Philippe Lalevée a écrit :
Hi Nicolas,
I agree that I would like to do is not public. But if we execute "gst-inspect-1.0 rtpbin", we have an "element action" (get-internal-session) which returns a RTPSession. In a previous mail, I mentioned that include files to use RTPSession related stuff are not present in libgstreamer-plugins-good1.0-dev package.

What I am trying to do is to implement RTCP AVB (type 208) packets (IEEE1733, see http://www.networksorcery.com/enp/protocol/rtcp.htm for instance). For that, my first idea was to use APP packets to transmit AVB data from a talker to listeners, in order that talker and listeners no longer use NTP, but PTP clock.

As it's pretty urgent, I wanted to avoid developing gstreamer extensions (anyway I do not have the skills for that). That's why I try to use on-sending-rtcp signal, to retrieve before they are sent the buffers of RTCP packets, and in them, to add APP packets with the sequence of function calls, indicated in my mail.

Would there be other ways to do that?
Best
Philippe

Le 19/01/2019 à 17:38, Nicolas Dufresne a écrit :
Le samedi 19 janvier 2019 à 17:06 +0100, Philippe Lalevée a écrit :
Hello
I still have problems when using on-sending-rtcp/on-receiving signals
(I would like to send RTCP packets of APP type). 
The RTPSession API isn't public, I'm not sure it is correct to use this
from an application. I believe you should better describe what you are
trying to do. It might be described in the original thread, but you
seem to have create a new thread, which means it's harder to find the
context.

regards,
Nicolas

After having configured callbacks both for these signals (on the
rtpsession object as mentioned by Sebastian) and for probes in rtcp
pads, I have the following behavior on the talker side: in the two
callbacks, I only have RR and SDES packets, and never SR packets,
while I see SR packets with the probe callback, and whereas I see
them in the listener side in the "on_receiving_rtcp" callback.
Symmetrically, I have the same problem on the listener side.

Another problem is that APP packets are not transmitted from the
talker to the listener. Here is shortened the sequence of
instructions called in the on-sending-rtcp callback function:
- gst_rtcp_buffer_map(buffer, GST_MAP_READWRITE, &rtcp)
- gst_rtcp_buffer_add_packet(&rtcp, GST_RTCP_TYPE_APP, &packet)
- gst_rtcp_packet_app_set_subtype(&packet, subtype)
- gst_rtcp_packet_app_set_ssrc(&packet, ssrc)
- gst_rtcp_packet_app_set_name(&packet, name)
- gst_rtcp_packet_app_set_data_length (&packet, len)
- data = gst_rtcp_packet_app_get_data(&packet)
- GST_WRITE_UINT32_BE(data, value)
- ...
- return TRUE

Do I have to do something special at the end of the function, before
the return instruction, for the packet to be taken into account?
otherwise what could be the problem?
Did you unmap you RtcpBuffer ? What is this function you are
implementing ? What is it supposed to do ?
Thank you for your help
Philippe Lalevée


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

--
Logo MINES Saint-Étienne
Philippe LALEVÉE
Directeur du Campus Georges Charpak Provence
Directeur du Centre Microélectronique de Provence
Président de la Plate-forme Micro-PackS
+33 4 42 61 67 15 / +33 6 23 02 15 01
[hidden email]
@CampusCharpak #ISMIN @p_lalevee
Campus Georges Charpak Provence
880 route de Mimet, F-13541 Gardanne Cedex
Assistante CGCP : [hidden email]         (+33 442616620)
Assistante CMP :   [hidden email] (+33 442616610)
Inspiring

                    Innovation - Since
 1816

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

--
Logo MINES Saint-Étienne
Philippe LALEVÉE
Directeur du Campus Georges Charpak Provence
Directeur du Centre Microélectronique de Provence
Président de la Plate-forme Micro-PackS
+33 4 42 61 67 15 / +33 6 23 02 15 01
[hidden email]
@CampusCharpak #ISMIN @p_lalevee
Campus Georges Charpak Provence
880 route de Mimet, F-13541 Gardanne Cedex
Assistante CGCP : [hidden email]         (+33 442616620)
Assistante CMP :   [hidden email] (+33 442616610)
Inspiring
                  Innovation - Since
 1816

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of "on-sending-rtcp" signal

Sebastian Dröge-3
In reply to this post by Nicolas Dufresne-5
On Sat, 2019-01-19 at 11:38 -0500, Nicolas Dufresne wrote:
> Le samedi 19 janvier 2019 à 17:06 +0100, Philippe Lalevée a écrit :
> > Hello I still have problems when using on-sending-rtcp/on-receiving
> > signals (I would like to send RTCP packets of APP type).
>
> The RTPSession API isn't public, I'm not sure it is correct to use
> this from an application. I believe you should better describe what
> you are trying to do.

The rtpsession API is public, i.e. the signals and properties on the
"internal-session" object of the rtpsession GStreamer element. People
are using these in their applications for various things :)

And the signals Philippe are mentioned can be used for including custom
RTCP packets or receiving them. Not sure what the problem is he's
running into though, a testcase (with code) to run and show the problem
would probably help. But it seems he solved it already if I understand
the last message correctly.

--
Sebastian Dröge, Centricular Ltd · https://www.centricular.com


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

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Use of "on-sending-rtcp" signal

Nicolas Dufresne-5


Le sam. 19 janv. 2019 14 h 27, Sebastian Dröge <[hidden email]> a écrit :
On Sat, 2019-01-19 at 11:38 -0500, Nicolas Dufresne wrote:
> Le samedi 19 janvier 2019 à 17:06 +0100, Philippe Lalevée a écrit :
> > Hello I still have problems when using on-sending-rtcp/on-receiving
> > signals (I would like to send RTCP packets of APP type).
>
> The RTPSession API isn't public, I'm not sure it is correct to use
> this from an application. I believe you should better describe what
> you are trying to do.

I don't agree. The API being public would mean we install the appropriate header. These things are not event in GST namespace. As we expose the opaque object as a GObject, yes, we have made public the properties and signal, but we don't document it. I totally disagree with having to maintain API stability here for our internal RTP helpers.


The rtpsession API is public, i.e. the signals and properties on the
"internal-session" object of the rtpsession GStreamer element. People
are using these in their applications for various things :)

And the signals Philippe are mentioned can be used for including custom
RTCP packets or receiving them. Not sure what the problem is he's
running into though, a testcase (with code) to run and show the problem
would probably help. But it seems he solved it already if I understand
the last message correctly.

--
Sebastian Dröge, Centricular Ltd · https://www.centricular.com

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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of "on-sending-rtcp" signal

Philippe Lalevée-2
In reply to this post by Sebastian Dröge-3
Le 19/01/2019 à 20:13, Sebastian Dröge a écrit :
On Sat, 2019-01-19 at 11:38 -0500, Nicolas Dufresne wrote:
Le samedi 19 janvier 2019 à 17:06 +0100, Philippe Lalevée a écrit :
Hello I still have problems when using on-sending-rtcp/on-receiving
signals (I would like to send RTCP packets of APP type). 
The RTPSession API isn't public, I'm not sure it is correct to use
this from an application. I believe you should better describe what
you are trying to do.
The rtpsession API is public, i.e. the signals and properties on the
"internal-session" object of the rtpsession GStreamer element. People
are using these in their applications for various things :)

And the signals Philippe are mentioned can be used for including custom
RTCP packets or receiving them. Not sure what the problem is he's
running into though, a testcase (with code) to run and show the problem
would probably help. But it seems he solved it already if I understand
the last message correctly.
Unfortunately, that is not the case... What is solved is the transmission of APP packets from the listener to the talker, but not from the talker to the listener. My code is based on gst-plugins-good/tests/examples/rtp/{client-PCMA.c,server-alsasrc-PCMA.c}, see included test-rtcp.tar.xz. After doing make, on a machine B, execute './gst_recv IP_A, and on the machine A, execute ./gst_send <file>.mp3 IP_B.

Traces on machine A :
>on_sending_rtcp: (sess:1823933232,early:0,size:60)
> #packets: 2
>  packet: type 201, RR ssrc: 77451595
>  packet: type 202
> packet added: #packets: 3
> buffer unmap...

<on_receiving_rtcp: (sess:1823933232,size:124)
< #packets: 3
<  packet: type 201, RR ssrc: 3024040777
<  packet: type 202
packet: type 204
< **** packets to process... soon ****
In bold, we can see that an APP packet is received.

Traces on machine B:
<on_receiving_rtcp: (sess:475169152,size:80)
< #packets: 2
<  packet: type 200, SR ssrc: 4086197064, rtp ts: 4010357965
<  packet: type 202
< **** packets to process... soon ****

>on_sending_rtcp: (sess:475169152,early:0,size:80)
> #packets: 2
>  packet: type 201, RR ssrc: 3024040777
>  packet: type 202
> packet added: #packets: 3
> buffer unmap...
Traces in green show that transmission is OK from the listener (which sends an RR packet) to the talker (which receives the same RR packet). But, as you can see in red, the talker sends an RR packet (that is strange) while the listener receives an SR packet with different data, and there is no APP packet.
The questions are then why the talker sends an RR packet here ? and why the listener receives an SR reports ?
Thanks
Philippe

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

test-rtcp.tar.xz (20K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Use of "on-sending-rtcp" signal

Matthew Waters
In reply to this post by Nicolas Dufresne-5
On Sun., 20 Jan. 2019, 10:28 Nicolas Dufresne <[hidden email] wrote:


Le sam. 19 janv. 2019 14 h 27, Sebastian Dröge <[hidden email]> a écrit :
On Sat, 2019-01-19 at 11:38 -0500, Nicolas Dufresne wrote:
> Le samedi 19 janvier 2019 à 17:06 +0100, Philippe Lalevée a écrit :
> > Hello I still have problems when using on-sending-rtcp/on-receiving
> > signals (I would like to send RTCP packets of APP type).
>
> The RTPSession API isn't public, I'm not sure it is correct to use
> this from an application. I believe you should better describe what
> you are trying to do.

I don't agree. The API being public would mean we install the appropriate header. These things are not event in GST namespace. As we expose the opaque object as a GObject, yes, we have made public the properties and signal, but we don't document it. I totally disagree with having to maintain API stability here for our internal RTP helpers.

What makes you think the internal API as exposed through the GObject properties and signals is not public?  My understanding is that it is public API.  Just because there is no header, doesn't mean the API is not public.  How do you explain element properties then or even GObject properties in general which require no headers for use.

Documentation of the internal rtpsession isn't exposed presumably due to limitations in gtk-doc however it is written for public use.


The rtpsession API is public, i.e. the signals and properties on the
"internal-session" object of the rtpsession GStreamer element. People
are using these in their applications for various things :)

And the signals Philippe are mentioned can be used for including custom
RTCP packets or receiving them. Not sure what the problem is he's
running into though, a testcase (with code) to run and show the problem
would probably help. But it seems he solved it already if I understand
the last message correctly.

--
Sebastian Dröge, Centricular Ltd · https://www.centricular.com

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

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of "on-sending-rtcp" signal

Sebastian Dröge-3
On Sun, 2019-01-20 at 10:58 +1100, Matthew Waters wrote:

> On Sun., 20 Jan. 2019, 10:28 Nicolas Dufresne <[hidden email]
> wrote:
> >
> > Le sam. 19 janv. 2019 14 h 27, Sebastian Dröge <
> > [hidden email]> a écrit :
> > > On Sat, 2019-01-19 at 11:38 -0500, Nicolas Dufresne wrote:
> > > > Le samedi 19 janvier 2019 à 17:06 +0100, Philippe Lalevée a
> > > écrit :
> > > > > Hello I still have problems when using on-sending-rtcp/on-
> > > receiving
> > > > > signals (I would like to send RTCP packets of APP type).
> > > >
> > > > The RTPSession API isn't public, I'm not sure it is correct to
> > > use
> > > > this from an application. I believe you should better describe
> > > what
> > > > you are trying to do.
> >
> > I don't agree. The API being public would mean we install the
> > appropriate header. These things are not event in GST namespace. As
> > we expose the opaque object as a GObject, yes, we have made public
> > the properties and signal, but we don't document it. I totally
> > disagree with having to maintain API stability here for our
> > internal RTP helpers.
>
> What makes you think the internal API as exposed through the GObject
> properties and signals is not public?  My understanding is that it is
> public API.  Just because there is no header, doesn't mean the API is
> not public.  How do you explain element properties then or even
> GObject properties in general which require no headers for use.
>
> Documentation of the internal rtpsession isn't exposed presumably due
> to limitations in gtk-doc however it is written for public use.
Also why would there otherwise be the "internal-session" GObject
property on the rtpsession element, or the "get-internal-session"
action signals on rtpbin?

It's public API just like the properties and signals on the rtpsource
objects, and even if it was not intended as such (which is not the case
from what I understand) it would be too late now to change it in
incompatible ways. There's too much code depending on them.

The parts that are not public API are not exposed via GObject
properties/signals and are only accessible internally via private C
API.

--
Sebastian Dröge, Centricular Ltd · https://www.centricular.com

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

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Use of "on-sending-rtcp" signal

Nicolas Dufresne-5


Le dim. 20 janv. 2019 12 h 27, Sebastian Dröge <[hidden email]> a écrit :
On Sun, 2019-01-20 at 10:58 +1100, Matthew Waters wrote:
> On Sun., 20 Jan. 2019, 10:28 Nicolas Dufresne <[hidden email]
> wrote:
> >
> > Le sam. 19 janv. 2019 14 h 27, Sebastian Dröge <
> > [hidden email]> a écrit :
> > > On Sat, 2019-01-19 at 11:38 -0500, Nicolas Dufresne wrote:
> > > > Le samedi 19 janvier 2019 à 17:06 +0100, Philippe Lalevée a
> > > écrit :
> > > > > Hello I still have problems when using on-sending-rtcp/on-
> > > receiving
> > > > > signals (I would like to send RTCP packets of APP type).
> > > >
> > > > The RTPSession API isn't public, I'm not sure it is correct to
> > > use
> > > > this from an application. I believe you should better describe
> > > what
> > > > you are trying to do.
> >
> > I don't agree. The API being public would mean we install the
> > appropriate header. These things are not event in GST namespace. As
> > we expose the opaque object as a GObject, yes, we have made public
> > the properties and signal, but we don't document it. I totally
> > disagree with having to maintain API stability here for our
> > internal RTP helpers.
>
> What makes you think the internal API as exposed through the GObject
> properties and signals is not public?  My understanding is that it is
> public API.  Just because there is no header, doesn't mean the API is
> not public.  How do you explain element properties then or even
> GObject properties in general which require no headers for use.
>
> Documentation of the internal rtpsession isn't exposed presumably due
> to limitations in gtk-doc however it is written for public use.

Also why would there otherwise be the "internal-session" GObject
property on the rtpsession element, or the "get-internal-session"
action signals on rtpbin?

It's public API just like the properties and signals on the rtpsource
objects, and even if it was not intended as such (which is not the case
from what I understand) it would be too late now to change it in
incompatible ways. There's too much code depending on them.

The parts that are not public API are not exposed via GObject
properties/signals and are only accessible internally via private C
API.

Then I would say it's time to make a real effort and document these thing. I don't see any productive way we can support users of this here without. GTK doc limitation is a wrong argument, we have elements documentation, which does not have a C API.

I strongly prefer saying it's not officially supported then repeating myself over and over due to lack of documentation / proper committment to make this un-ambiguously public.



--
Sebastian Dröge, Centricular Ltd · https://www.centricular.com
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: Use of "on-sending-rtcp" signal

Philippe Lalevée-2
In reply to this post by Philippe Lalevée-2
I finally was able to use these signals to add APP RTCP packets. My problems came from programming faults, especially by erroneously configuring caps of an udpsrc plugin.
After having read the comments of Nicolas, I have replaced RTPSession by a simple GObject, and all was still fine. I would only like to add that without reading, and trying to understand codes in gst-plugins-base and gst-plugins-good, I would never been able to succeed. Next step for me: implement AVB RTCP packets...
Anyway, thank you very much for these exchanges and probably future.
Philippe

Le 20/01/2019 à 00:30, Philippe Lalevée a écrit :
Le 19/01/2019 à 20:13, Sebastian Dröge a écrit :
On Sat, 2019-01-19 at 11:38 -0500, Nicolas Dufresne wrote:
Le samedi 19 janvier 2019 à 17:06 +0100, Philippe Lalevée a écrit :
Hello I still have problems when using on-sending-rtcp/on-receiving
signals (I would like to send RTCP packets of APP type). 
The RTPSession API isn't public, I'm not sure it is correct to use
this from an application. I believe you should better describe what
you are trying to do.
The rtpsession API is public, i.e. the signals and properties on the
"internal-session" object of the rtpsession GStreamer element. People
are using these in their applications for various things :)

And the signals Philippe are mentioned can be used for including custom
RTCP packets or receiving them. Not sure what the problem is he's
running into though, a testcase (with code) to run and show the problem
would probably help. But it seems he solved it already if I understand
the last message correctly.
Unfortunately, that is not the case... What is solved is the transmission of APP packets from the listener to the talker, but not from the talker to the listener. My code is based on gst-plugins-good/tests/examples/rtp/{client-PCMA.c,server-alsasrc-PCMA.c}, see included test-rtcp.tar.xz. After doing make, on a machine B, execute './gst_recv IP_A, and on the machine A, execute ./gst_send <file>.mp3 IP_B.

Traces on machine A :
>on_sending_rtcp: (sess:1823933232,early:0,size:60)
> #packets: 2
>  packet: type 201, RR ssrc: 77451595
>  packet: type 202
> packet added: #packets: 3
> buffer unmap...

<on_receiving_rtcp: (sess:1823933232,size:124)
< #packets: 3
<  packet: type 201, RR ssrc: 3024040777
<  packet: type 202
packet: type 204
< **** packets to process... soon ****
In bold, we can see that an APP packet is received.

Traces on machine B:
<on_receiving_rtcp: (sess:475169152,size:80)
< #packets: 2
<  packet: type 200, SR ssrc: 4086197064, rtp ts: 4010357965
<  packet: type 202
< **** packets to process... soon ****

>on_sending_rtcp: (sess:475169152,early:0,size:80)
> #packets: 2
>  packet: type 201, RR ssrc: 3024040777
>  packet: type 202
> packet added: #packets: 3
> buffer unmap...
Traces in green show that transmission is OK from the listener (which sends an RR packet) to the talker (which receives the same RR packet). But, as you can see in red, the talker sends an RR packet (that is strange) while the listener receives an SR packet with different data, and there is no APP packet.
The questions are then why the talker sends an RR packet here ? and why the listener receives an SR reports ?
Thanks
Philippe

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

--
Logo MINES Saint-Étienne
Philippe LALEVÉE
Directeur du Campus Georges Charpak Provence
Directeur du Centre Microélectronique de Provence
Président de la Plate-forme Micro-PackS
+33 4 42 61 67 15 / +33 6 23 02 15 01
[hidden email]
@CampusCharpak #ISMIN @p_lalevee
Campus Georges Charpak Provence
880 route de Mimet, F-13541 Gardanne Cedex
Assistante CGCP : [hidden email]         (+33 442616620)
Assistante CMP :   [hidden email] (+33 442616610)
Inspiring
                  Innovation - Since
 1816

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