hls: fix for assert failure when using encrypted HLS streams
authorAlex Ashley <bugzilla@ashley-family.net>
Fri, 19 Jul 2013 14:30:42 +0000 (15:30 +0100)
committerTim-Philipp Müller <tim@centricular.net>
Mon, 22 Jul 2013 13:55:17 +0000 (14:55 +0100)
commited16c9c560afb5feac1632a33e4d7fbde621eca0
treefc349e52f2046d2e722190a858a68b3c2de5b10f
parent136aa4614e0db3056aadc70ffb993016b927ea7c
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
ext/hls/Makefile.am
ext/hls/gstfragment.c [deleted file]
ext/hls/gstfragment.h [deleted file]