Bug 141959 – [GStreamer][HLS] http/tests/media/clearkey/clear-key-hls-aes128.html is timeout since r179641

• Component: Media
• Status: RESOLVED WONTFIX

[Gyuyoung Kim]

SSIA

[Marcos Chavarría Teijeiro (irc: chavaone)]

This test is also failing in GKT since r179641.

[Michael Catanzaro]

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.

[Philippe Normand]

This test is crashing because the clearkey file referenced in the m3u8 file cannot be fetched, because its URI is wrong:

clearkey:crypt0.key

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?

[Philippe Normand]

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?

[Michael Catanzaro]

(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? :(

[Philippe Normand]

(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.

[Jer Noble]

Philipe,

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?

[Philippe Normand]

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?

[Philippe Normand]

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))

[Philippe Normand]

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 :(