This test is also failing in GKT since r179641.
It's also crashing in release builds. First recorded crash I see is r181775, but crashes were quite rare until r190564. Since r190564 it has been crashing almost always.
It crashes in debug builds due to bug #152043.
This test is crashing because the clearkey file referenced in the m3u8 file cannot be fetched, because its URI is wrong:
If I change it to crypt0.key the file is correctly fetched and the test no longer crashes but times out, due to other issues. Anyway, Eric & Jer, can you sched some light on this? Why does the test passes on Mac if the key file URI isn't valid in the first place?
Perhaps this URI is invalid on purpose actually? So that the needkey event is somehow fired and the clearkey data from JS side is actually used instead of the key file?
(In reply to comment #3)
> This test is crashing because the clearkey file referenced in the m3u8 file
> cannot be fetched, because its URI is wrong:
But why does this cause WebKit to crash? :(
(In reply to comment #5)
> (In reply to comment #3)
> > This test is crashing because the clearkey file referenced in the m3u8 file
> > cannot be fetched, because its URI is wrong:
> > clearkey:crypt0.key
> But why does this cause WebKit to crash? :(
The uridownloader fails to retrieve that key file and then hlsdemux tries to decrypt samples without a decryption key configured. It appears this is fixed in the upcoming gst 1.8 series already.
The unrecognized scheme "clearkey:" is a trigger to begin the EME code path. If you change it to just crypt0.key, and your HLS back-end fetches, decrypts, and displays the media stream, there will be no 'needkey' message to signal the client to fetch and add key data through the EME APIs.
In OS X, the AVFoundation APIs give us a notification that there is media data that cannot be retrieved through HTTP(s), providing us the "clearkey:crypt0.key" URI. Perhaps there is something similar in the hlsdemux libraries?
Thanks Jer for the clarification.
Yes I think the same kind of mechanism can be implemented in GStreamer, where the uridownloader would emit an error, relayed by the demuxer to the application and from there the MediaPlayerPrivate could trigger the EME key negotiation, I suppose :)
Was this implemented for test purpose only? Is EME on HLS really used in the wild wild web?
We already get an error but it's not easy just yet to find out this particular error requires the player to trigger the EME license negotiation
0:00:00.151092833 19176 0x7fb798039720 DEBUG uridownloader gsturidownloader.c:397:gst_uri_downloader_set_uri:<uridownloader0> Creating source element for the URI:clearkey:crypt0.key
0:00:00.151157317 19176 0x7fb798039720 WARN uridownloader gsturidownloader.c:505:gst_uri_downloader_fetch_uri_with_range:<uridownloader0> Failed to set URI
0:00:00.151177583 19176 0x7fb798039720 WARN hlsdemux gsthlsdemux.c:520:gst_hls_demux_start_fragment:<hlsdemux0> error: Couldn't retrieve key for decryption
0:00:00.151243550 19176 0x7fb798039720 WARN hlsdemux gsthlsdemux.c:521:gst_hls_demux_start_fragment:<hlsdemux0> Failed to decrypt data
0:00:00.151255035 19176 0x2807790 DEBUG webkitmediaplayer MediaPlayerPrivateGStreamer.cpp:910:handleMessage: Message error received from element hlsdemux0
0:00:00.151298475 19176 0x2807790 ERROR webkitmediaplayer MediaPlayerPrivateGStreamer.cpp:919:handleMessage: Error 9: Couldn't retrieve key for decryption (url=http://localhost:8080/media/resources/hls/clearkey/prog_index.m3u8)
0:00:00.151397993 19176 0x7fb798039770 WARN basesrc gstbasesrc.c:2948:gst_base_src_loop:<appsrc1> error: Internal data flow error.
0:00:00.151417976 19176 0x7fb798039770 WARN basesrc gstbasesrc.c:2948:gst_base_src_loop:<appsrc1> error: streaming task paused, reason error (-5)
0:00:00.151467496 19176 0x7fb798039770 WARN adaptivedemux gstadaptivedemux.c:752:gst_adaptive_demux_handle_message:<hlsdemux0:src_0> Source posted error: 2714:1 Internal data flow error. (/home/phil/WebKit/WebKitBuild/DependenciesGTK/Source/gstreamer/libs/gst/base/gstbasesrc.c(2948): gst_base_src_loop (): /GstPlayBin:play/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstHLSDemux:hlsdemux0/GstBin:srcbin-src_0/WebKitWebSrc:webkitwebsrc0/GstAppSrc:appsrc1:
streaming task paused, reason error (-5))
Or we could make hlsdemux emit a protection event rather than an error, this way decryptors would be added in the pipeline and they would handle decryption key negotiation.
But implying clearkey:key from the m3u8 file means the protection event system ID should be the UUID of the ClearKey scheme is perhaps a bit far fetched :(