I want my plugin to have one "public" (registered) element, GstHtspSrc, that acts as a URI handler which chooses between two different source elements depending on the path of the URL. This is because tvheadend's HTS protocol has major differences depending on whether it's streaming live TV (pushes packet messages) or a recording (client reads chunks of a file in mpeg transport stream format on demand).
The latter src element seemed easy enough to implement by basing it on filesrc, but I thought the easiest way to test it would be to write a preliminary version of GstHtspSrc which derives from GstHtspRecordingSrc (which in turn derives from GstBaseSrc) and implements GstUriHandler for it instead of diving straight into the extra complication of a manager element. The trouble is my plugin isn't working. It causes gst-inspect-1.0 to hang when I call gst_element_register on GstHtspRecordingSrc. It seems to be stuck in a loop of: 0:00:09.116526506 324933 0x55bbe89c7e00 LOG GST_PLUGIN_LOADING gstpluginloader.c:1027:exchange_packets: Poll res = 0. 0 bytes pending for write 0:00:09.116557976 324933 0x55bbe89c7e00 DEBUG GST_POLL gstpoll.c:1241:gst_poll_fd_has_error: 0x55bbe8bee800: fd (fd:8, idx:2) 0 0:00:09.116565199 324933 0x55bbe89c7e00 DEBUG GST_POLL gstpoll.c:1266:gst_poll_fd_can_read_unlocked: 0x55bbe8bee800: fd (fd:8, idx:2) 0 0:00:09.116571431 324933 0x55bbe89c7e00 DEBUG GST_POLL gstpoll.c:1195:gst_poll_fd_has_closed: 0x55bbe8bee800: fd (fd:8, idx:2) 0 0:00:09.116578815 324933 0x55bbe89c7e00 DEBUG GST_POLL gstpoll.c:1414:gst_poll_wait: 0x55bbe8bee800: timeout :0:00:01.000000000 and never ultimately returns from gst_element_register. I thought the problem could be caused by deriving from an unregistered element class. So I tried calling gst_element_register on the base class, GstHtspRecordingSrc, before the subclass GstHtspSrc. The registration of GstHtspRecordingSrc succeeds, but GstHtspSrc still fails. If I don't try to register GstHtspSrc, gst-inspect runs successfully and shows my plugin to be present with that element. I've also added debugging to gst_htsp_src_class_init and seen that it never gets called. So the only explanation seems to be that gst doesn't like that GstHtspSrc is derived from another element in the same plugin, whether or not the base element is registered first. Is this a known limitation? TH _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Never mind, I eventually discovered I'd derived GstHtspSrc from itself in G_DEFINE_TYPE_WITH_CODE. Doh. I suppose that must cause a deadlock somewhere in GObject, otherwise I would have expected it to use a chunk of CPU for a while then crash from too much recursion. On Sun, 27 Sep 2020 at 19:26, Tony Houghton <[hidden email]> wrote:
TH _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |