Github #34 reported that it wasn't possible to playback an encrypted stream using Safari or VLC on a Mac.
Reproducing the info in that ticket here for posterity, but this also needs fixing.
User Report
created encrypted parts using
hls-stream-creater.sh -i ./small.mp4 -e -s 10 ./
it created successfully but now its not playing.
m3u8 file contents:
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-ALLOW-CACHE:YES
#EXT-X-KEY:METHOD=AES-128,URI=small.mp4.key
#EXT-X-TARGETDURATION:6
#EXTINF:5.600000,
small.mp4_00000.ts
#EXT-X-ENDLIST
Developer tools in Safari simply reports
Failed to load resource: Plug-in handled load
Investigation details are provided in comments below, but the root cause has boiled down to the keyfile not being in quotes.
Activity
2019-11-16 12:16:18
2019-11-16 12:17:24
Key-length is correct
Segment decrypts happily enough using the key
and actually, VLC playback works fine for me:
2019-11-16 12:19:09
It's truncating letters off the key-filename:
I noticed truncation in users output but assumed it might've been copy paste.
Verified on my webserver that it is requesting the truncated version
Dumping the file out as hex it looks ok
But, if we take the relevant line and try and convert it back the issue becomes apparent
The end of that looks ok, hex `79` is dec 121 ("y" in ascii) and `0a` is a line break. Let's iterate over the hex and convert to dec then
Dumping those to chars
Looks ok...
Converting one way and back works fine
Perhaps the earlier test was a false positive then?
This is ridiculous. I hate macs.
Going back to basics, what if we quote the keyfile name
VLC works. And so does Safari....
FFS
2019-11-16 12:27:22
Making the change
Running a new mux
Tested playback on a Mac
- Playback of http://scratch.holly.home/before/lua_string_split.mp4.m3u8 fails in the same manner.
- Playback of http://scratch.holly.home/after/lua_string_split.mp4.m3u8 fails in the same manner.
Committing as
2019-11-16 12:28:58
Webhook User-Agent
View Commit
2019-11-16 12:36:49
Looks like the initial draft said the same, so this has probably always been wrong.
It was unquoted when added back in https://github.com/bentasker/HLS-Stream-Creator/commit/bb3cce4febdbcc59ca33c304ae34a6168d310169
So, the codebase wasn't spec compliant (although blindly trimming first and last char is a bloody stupid way to be dealing with a quoted string....)
2019-11-16 12:38:29
2019-11-16 12:38:36
2019-11-16 12:38:36
2019-11-16 12:38:40
2019-11-17 10:10:31
We see the key get extracted in file
So, the key's URI ends up as a
Although we don't currently write any others in with HLS-Stream-Creator, now would be a good time to see what other attributes will get first/last chars chomped off by VLC
So, thats
-
-
-
-
And now, getting back on topic, let's verify how
So, breaking that down
- If length < 2 just return an empty string
- create
- create
- Iterate over each char, if the char is a backslash, check whether there's a subsequent char, if not stop iterating
- push the char into
- Turn the output stream back into type
So the codebase is definitely stripping off the first and last char (assuming that they'll be quotes). Not particularly defensive there, but ok.
But why didn't my Linux box also break?
Ahh, it's really old. But, it achieved playback so there must be something in there. Worth a quick gander - sources for VLC 2.2.2 are at http://download.videolan.org/pub/videolan/vlc/2.2.2/vlc-2.2.2.tar.xz
Completely different location in this one, function
It's a long function, but it includes an explicit check to see whether it's a quoted string (actually, technically just whether it starts with a double quote, there's no check for the last char)
So, it'll work quite happily with an unquoted string as we'll never enter that conditional block. Means they've made the later "improved" versions more fragile... sadness
2019-11-17 10:25:01
2019-11-22 09:11:43