[Bug 793221] Add support for ONVIF backchannel

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793221

--- Comment #2 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Tim-Philipp Müller from comment #1)
> Shouldn't there be padding in the new class and instance structures for the
> onvif subclasses? We might want to add more vfuncs in future, for example,
> no?

Good point, I forgot to add that!

> The vfunc extension hack is a bit unfortunate, but still seems better than
> adding 50 new vfuncs just for that extra context parameter. I wonder what
> g-i/bindings make of the #ifdef #else there.

They probably take the case without the #define, I hope they run through cpp
first before parsing the code :) That's how the generated .gir file looks like
in any case.

This would also be the good thing to do, otherwise it would break API of the
bindings, but of course also means that the new variants of the vfuncs are not
available from bindings. But subclassing any of this from bindings is unlikely
to work anyway, the gst-rtsp-server API is not very bindings friendly in that
regard.

> The only alternative I can
> think of is to push the context into thread-local storage before ->vfunc and
> pop it off after.

How did I miss this? I considered this but thought it would be bad because the
number of TLS variables you can have is relatively limited... but
gst-rtsp-server already has this anyway! gst_rtsp_context_push_current(),
gst_rtsp_context_get_current(), etc.

I'll update the patch to use that API instead of all the vfunc uglyness.

> Does the new vfunc define also need to be set in the meson build?

Yes

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.