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 |
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 |
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, NicolasAfter 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 |
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, --
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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 |
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: 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.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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)In bold, we can see that an APP packet is received. Traces on machine B: <on_receiving_rtcp: (sess:475169152,size:80)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 |
In reply to this post by Nicolas Dufresne-5
On Sun., 20 Jan. 2019, 10:28 Nicolas Dufresne <[hidden email] wrote:
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.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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. 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 |
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: 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.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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 : --
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |