Use of "on-sending-rtcp" signal

[Nicolas Dufresne]

Le dim. 20 janv. 2019 12 h 27, Sebastian Dröge <sebastian at centricular.com>
a écrit :

> On Sun, 2019-01-20 at 10:58 +1100, Matthew Waters wrote:
> > On Sun., 20 Jan. 2019, 10:28 Nicolas Dufresne <nicolas at ndufresne.ca
> > wrote:
> > >
> > > Le sam. 19 janv. 2019 14 h 27, Sebastian Dröge <
> > > sebastian at centricular.com> 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
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20190120/1b1bf041/attachment-0001.html>