GNOME Bugzilla – Bug 758454
hls: Failure with AES-HLS
Last modified: 2018-11-03 13:43:13 UTC
The following HLS AES streams fail to play with GStreamer 1.6.1. http://sslhls.m6tv.cdn.sfr.net/hls-live/livepkgr/_definst_/m6_hls_aes/m6_hls_aes_856.m3u8 M6 http://sslhls.m6tv.cdn.sfr.net/hls-live/livepkgr/_definst_/m6_music_hits_hls_aes/m6_music_hits_hls_aes_856.m3u8 M6Music http://sslhls.m6tv.cdn.sfr.net/hls-live/livepkgr/_definst_/w9_hls_aes/w9_hls_aes_856.m3u8 W9 http://sslhls.m6tv.cdn.sfr.net/hls-live/livepkgr/_definst_/six_ter_hls_aes/six_ter_hls_aes_856.m3u8 6terHD I am getting errors like the following when trying to play on embeddeed OpenPLi Enigma2 STB. # gst-launch-1.0 playbin uri=http://sslhls.m6tv.cdn.sfr.net/hls-live/livepkgr/_definst_/six_ter_hls_aes/six_ter_hls_aes_856.m3u8 flags=0x47 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0: GStreamer encountered a general stream error. Additional debug info: /opt/openpli/openpligst/build/tmp/work/mips32el-oe-linux/gstreamer1.0-plugins-base/1.6.1-r15/gst-plugins-base-1.6.1/gst/playback/gstdecodebin2.c(4546): gst_decode_bin_expose (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0: all streams without buffers ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... Also trying to play from Windows XP it crashes. state_changed:<souphttpsrc1> notifying about state-changed READY to NULL (VOID_PENDING pending) 0:00:03.775321724 2384 09343410 INFO GST_ELEMENT_PADS gstpad.c:1991:gst_pad_unlink: unlinking souphttpsrc1:src(0934A040) and '':sink(092E2800) 0:00:03.777641292 2384 09343410 INFO GST_ELEMENT_PADS gstpad.c:2045:gst_pad_unlink: unlinked souphttpsrc1:src and '':sink 0:00:03.779903032 2384 09343410 WARN hlsdemux gsthlsdemux.c:529:gst_hls_demux_start_fragment:<hlsdemux0> Failed to decrypt data There is no problem playing those with VLC or Livestreamer (python hls client).
Do they fail everytime with gstreamer? It seems to work in git master, except that it prints some warnings/errors in the console. Could you try with git master and see whether you can still reproduce the failure?
>> Do they fail everytime with gstreamer? Most of the times it doesn't work, it says all streams without buffers. # GST_DEBUG_NO_COLOR=1 GST_DEBUG="*hls*:4,*dvb*:5" gst-launch-1.0 playbin uri=http://sslhls.m6tv.cdn.sfr.net/hls-live/livepkgr/_definst_/m6_musi c_hits_hls_aes/m6_music_hits_hls_aes_856.m3u8 flags=0x47 Setting pipeline to PAUSED ... Pipeline is PREROLLING ... 0:00:02.341904297 4005 0xe799b0 INFO hlsdemux gsthlsdemux.c:372:gst_hls_demux_process_manifest:<hlsdemux0> Changed location: http://sslhls.m6tv.cdn.sfr.net/hls-live/livepkgr/_definst_/m6_music_hits_hls_aes/m6_music_hits_hls_aes_856.m3u8 (base uri: (NULL)) 0:00:03.197764407 4005 0xc24f20 INFO hlsdemux gsthlsdemux.c:454:gst_hls_demux_start_fragment:<hlsdemux0> Fetching key https://sslhls.m6tv.cdn.sfr.net/hls-key/m6_music_hits_hls_aes.bin ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0: GStreamer encountered a general stream error. Additional debug info: gstdecodebin2.c(4535): gst_decode_bin_expose (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0: all streams without buffers ERROR: pipeline doesn't want to preroll. Setting pipeline to NULL ... Freeing pipeline ... Sometimes it does, but after a while I get GAP and EOS and that's the end. 0:00:23.371388772 4170 0x7461eb20 DEBUG dvbvideosink gstdvbvideosink.c:506:gst_dvbvideosink_event:<dvbvideosink0> EVENT gap 0:00:23.371751957 4170 0x7461eb20 DEBUG dvbvideosink gstdvbvideosink.c:506:gst_dvbvideosink_event:<dvbvideosink0> EVENT eos >> Could you try with git master and see whether you can still reproduce the failure? All elements updated to master git but the behaviour is just like 1.6.1 PS. We are using custom sink for embedded OpenPLi Enigma2 boxes, https://github.com/OpenPLi/gst-plugin-dvbmediasink/tree/gst-1.0
Does it work with the upstream GStreamer elements, that is the upstream tsdemux, a decoder from gst-libav and e.g. glimagesink? This might as well be a problem in your element.
Doesn't work for me with git master. gst-play-1.0 http://sslhls.m6tv.cdn.sfr.net/hls-live/livepkgr/_definst_/m6_hls_aes/m6_hls_aes_856.m3u8 Prerolling... (gst-play-1.0:27546): GStreamer-CRITICAL **: Padname video_0101 is not unique in element tsdemux0, not adding WARNING GStreamer encountered a general stream error. WARNING debug information: gstdecodebin2.c(4608): gst_decode_bin_expose (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0: all streams without buffers Redistribute latency... Prerolled. (gst-play-1.0:27546): GStreamer-CRITICAL **: Padname '':video_0101 does not belong to element tsdemux0 when removing (gst-play-1.0:27546): GStreamer-CRITICAL **: Padname video_0101 is not unique in element tsdemux0, not adding 0:00:04.408166286 27546 0x7fb9e8002140 ERROR libav :0:: element type mismatch 1 != 0 WARNING GStreamer encountered a general stream error. WARNING debug information: gstdecodebin2.c(4608): gst_decode_bin_expose (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0: all streams without buffers 0:00:09.253922825 27546 0x7fb9e8002140 ERROR libav :0:: element type mismatch 1 != 0 0:00:09.401327287 27546 0x7fb9e8002140 ERROR libav :0:: element type mismatch 1 != 0 0:00:09.401485390 27546 0x7fb9e8002140 ERROR libav :0:: element type mismatch 1 != 0 0:00:09.471282908 27546 0x7fb9e8002140 ERROR libav :0:: element type mismatch 1 != 0 0:00:09.540954098 27546 0x7fb9e8002140 ERROR libav :0:: element type mismatch 1 != 0 (gst-play-1.0:27546): GStreamer-CRITICAL **: Padname '':video_0101 does not belong to element tsdemux0 when removing (gst-play-1.0:27546): GStreamer-CRITICAL **: Padname video_0101 is not unique in element tsdemux0, not adding 0:00:13.467923118 27546 0x7fba18030a80 ERROR libav :0:: element type mismatch 1 != 0 And no pic shows up.
Also with 1.8, but the first frame shows up here.
Created attachment 328925 [details] [review] tsdemux: Ensure that pad names are actually unique It's unlikely but a pad with the same name might exist already, for example if a new stream is received with the same PIDs but we still need to add new pads and remove the old ones.
Ugly patch but that makes the criticals go away. It still results in > WARNING debug information: gstdecodebin2.c(4617): gst_decode_bin_expose (): /GstPlayBin:playbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0: > all streams without buffers but plays now at least.
Not a blocker as it seems like this has never worked before
Comment on attachment 328925 [details] [review] tsdemux: Ensure that pad names are actually unique A better fix for this is here: https://cgit.freedesktop.org/~bilboed/gst-plugins-bad/commit/?h=streams-rebased&id=6fd7231f7efceb7894f7344fba45129959a94142 Does not apply cleanly at this point but the idea should still apply.
I had a patch somewhere that solved this by renaming pads to be removed prepending "removing_" to the pad name before removing it. I also like Edward's patch but I'd prefer to have a '_' between the generation and the pid for the pad name.
(In reply to Thiago Sousa Santos from comment #10) > I had a patch somewhere that solved this by renaming pads to be removed > prepending "removing_" to the pad name before removing it. You can only really rename pads when they have no parent :) > I also like Edward's patch but I'd prefer to have a '_' between the > generation and the pid for the pad name. Me too!
Merged this one now, with adding the additional underscore: commit e3f5ccb3333f3b22c41e59cf78e4343c99187009 Author: Jan Schmidt <jan@centricular.com> Date: Wed Sep 23 02:51:57 2015 +1000 tsdemux: Change the pad naming scheme to include a generation ID A simple fix for the problem of creating new pads with duplicate names when switching program, easier than the alternative of trying to work out which pads might persist and manage that. See https://bugzilla.gnome.org/show_bug.cgi?id=758454 It seems like there is more work needed for this bug though. It plays but there are warnings and it just gets stuck after a while.
*** Bug 771040 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/issues/327.