Incorrect EXT-X-KEY data uri value in generated HLS playlist for KEYFORMAT="identity"

[mmilitzer]

System info

Operating System: Fedora 37
Shaka Packager Version: v2.6.1-634af65-release

Issue and steps to reproduce the problem

Packager Command:

packager-linux-x64 in=../test.mp4,stream=audio,output=audio.mp4,drm_label=AUDIO in=../test.mp4,stream=video,output=video.mp4,drm_label=SD --protection_scheme cbcs --enable_raw_key_encryption --keys label=AUDIO:key_id=whatever_key_id:key=whatever_key,label=SD:key_id=whatever_key_id:key=whatever_key --hls_master_playlist_output hls_sample_aes.m3u8

Extra steps to reproduce the problem?

The issue applies to any encrypted HLS not using a DRM (so no "--protection_systems" specified) and where "--hls_key_uri" option is not specified (so that EXT-X-KEY URI is then set to an embedded data uri in the generated HLS playlist).

What is the expected result?

EXT-X-KEY URI should be set to a data uri containing the encryption key in plain text (base64 encoded) so that the HLS is playable in Safari with Shaka player or in the native player.

What happens instead?

The key id gets embedded base64 encoded as the data uri in EXT-X-KEY URI instead of the encryption key itself. In result the generated HLS is not playable anywhere because the encrypted fragments obviously cannot be decrypted with just the key id alone.

The problem appears to be here in the code:

shaka-packager/packager/hls/base/simple_hls_notifier.cc

Line 212 in 80e0240

key_id_string = "0x" + base::HexEncode(key_id.data(), key_id.size());

And I think this bug may be the reason also for other reported issues where users weren't able to get the generated HLS with KEYFORMAT="identity" to play anywhere, e.g. this one: #776