Clarification regarding segment-encrypted HLS and MSE/EME

I would be grateful for your advice with regard to MSE / EME compatibility with segment-encrypted HLS (i.e. MPEG-TS) content, which is the de-facto standard for encryption of HLS content in many scenarios.

In this encryption mode - which is one of the two official encryption schemes defined by the HLS standard - the entire segment (file) is encrypted. I believe that a manifest file then provides one or more EXT-X-KEY tags to specify the attributes required to generate a key request and thereby allow the content to be decrypted.

This appears to make it incompatible with MSE / EME for the following reasons:


1)      The UA has no access to the plaintext manifest file and key attributes within.

2)      The MSE API does not require the application to signal the presence of encrypted content as the UA is expected to determine it programmatically. As a result, the UA cannot identify the type of segment (initialisation or media) or otherwise parse it as there is no plaintext portion to allow the segment to be probed.

3)      The MSE API does not require the application to signal segment boundaries, therefore it would not be possible to decrypt content where each segment is encrypted with a different key (as the UA would need to delimit each segment to decrypt it successfully).

My assumption is therefore that MSE and EME are not designed with segment-encrypted HLS content in mind. Indeed, the answer may be rather obvious as the MSE specification states:
"It must be possible to identify segment boundaries and segment type (initialization or media) by examining the byte stream alone."

So my first question is whether my understanding is correct. If so, it may be useful to either state in the specification that segment-encrypted content is implicitly not supported, or else consider whether there is good reason to adapt the API to cater for it.

My second (related) question is whether an entry for MPEG-TS is due to be added to the Encrypted Media Extensions Stream Format and Initialization Data Format Registry<https://dvcs.w3.org/hg/html-media/raw-file/default/encrypted-media/initdata-format-registry.html> in the near future, which no doubt would help to clarify this issue and raise awareness.

Thank you for your time.

Regards,
Simon Warner