Opened 10 years ago
Closed 8 years ago
#12486 closed Bug Report - General (Won't Fix)
IPTV Recorder HLS AES-128 Problem
| Reported by: | Owned by: | stuartm | |
|---|---|---|---|
| Priority: | critical | Milestone: | 0.28.2 |
| Component: | MythTV - General | Version: | 0.27-fixes |
| Severity: | high | Keywords: | HLS AES |
| Cc: | Ticket locked: | no |
Description
I am unable to get the IPTV recorder to work with HLS AES-128 encrypted TS streams (such as this one: playertest.longtailvideo.com/adaptive/oceans_aes/oceans_aes.m3u8). The IPTV recorder works fine with unencrypted HLS streams.
I have compiled with the "USING_LIBCRYPTO" option and have libcrypto installed. Additional debugging shows that in HLSReader.cpp, the statement on line 1297 "if (segment.HasKeyPath())" is returning false even though the stream has the #EXT-KEY-KEY manifest entry that was successfully parsed by myth (and logged as an AES stream in mythtvbackend).
Debugging backend logs also shows that the ts segments are downloading fine, but there is no attempt to download the AES keys.
Attachments (2)
Change History (11)
by , 10 years ago
| Attachment: | backendlog.txt.gz added |
|---|
comment:1 by , 10 years ago
I have fixed this issue and will provide details and patch later after some more testing.
by , 10 years ago
| Attachment: | hls-aes-decode.patch added |
|---|
comment:2 by , 10 years ago
Attached is the patch. This will resolve the issue of myth not downloading the AES-128 Keys on encrypted segments.
comment:3 by , 10 years ago
| Milestone: | unknown → 0.28 |
|---|---|
| Owner: | set to |
| Status: | new → accepted |
follow-up: 6 comment:4 by , 10 years ago
this seems wrong to me.
With HLS a key can be defined per stream ; per segment or for the entire hls.
While your patch may fix it for you, it likely breaks it where the key is defined per segment
comment:6 by , 10 years ago
Replying to jyavenard:
this seems wrong to me.
With HLS a key can be defined per stream ; per segment or for the entire hls.
While your patch may fix it for you, it likely breaks it where the key is defined per segment
Actually, I was wondering about that, however, my testing was with streams that rotate keys every 10min and the patch works perfectly. When the key rotates, the playlist (for a given ABR representation) has 2 key entries. Each EXT-X-KEY sets the key for the segments below it (until the next EXT-X-KEY entry). This should be able to handle the worst case where each segment has its own key (designated with its own preceeding EXT-X-KEY entry).
comment:8 by , 9 years ago
| Milestone: | 0.28.1 → 0.28.2 |
|---|
Moving remaining open 0.28.1 tickets to 0.28.2
comment:9 by , 8 years ago
| Resolution: | → Won't Fix |
|---|---|
| Status: | accepted → closed |
Closing any remaining tickets for 0.28, if the issue persists, feel free to reopen and align to v29 or master
backend log