GNOME Bugzilla – Bug 704555
hlsdemux: cannot register existing type GstFragment when using encrypted HLS streams
Last modified: 2013-07-22 14:00:37 UTC
Created attachment 249638 [details] [review] Patch to delete duplicate of gstfragment class When using an HLS encrypted stream, an assertion failure is thrown: (gst-launch-1.0:31028): GLib-GObject-WARNING **: cannot register existing type `GstFragment' (gst-launch-1.0:31028): GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed Eventually tracked this down to the call gst_fragment_new() in function gst_hls_demux_decrypt_fragment in ext/hls/gsthlsdemux.c. The GstFragment class is defined in ext/hls/gstfragment.c and in gst-libs/gst/uridownloader/gstfragment.c. Having two class definitions with the same name causes the assert failure when trying to allocate GstFragment. Deleting the version from hls and editing the Makefile.am solves this assert failure.
Thanks, pushed: commit ed16c9c560afb5feac1632a33e4d7fbde621eca0 Author: Alex Ashley <bugzilla@ashley-family.net> Date: Fri Jul 19 15:30:42 2013 +0100 hls: fix for assert failure when using encrypted HLS streams When using an HLS encrypted stream, an assertion failure is thrown: (gst-launch-1.0:31028): GLib-GObject-WARNING **: cannot register existing type `GstFragment' (gst-launch-1.0:31028): GLib-CRITICAL **: g_once_init_leave: assertion `result != 0' failed Eventually tracked this down to the call gst_fragment_new() in function gst_hls_demux_decrypt_fragment. The GstFragment class is defined in ext/hls/gstfragment.c and in gst-libs/gst/uridownloader/gstfragment.c. Having two class definitions with the same name causes the assert failure when trying to allocate GstFragment. Deleting the version from hls and editing the Makefile.am solves this assert failure. https://bugzilla.gnome.org/show_bug.cgi?id=704555 (this silly little mini-library should just go away, but that's independent of this issue of course).