| HLS (HTTP Live Streaming) is an adaptive streaming technology that uses widely supported HTTP protocols to deliver video and audio content to viewers. This makes it highly accessible and compatible across a vast range of devices and platforms.
Here's a breakdown of why HLS is considered "widely supported": - HTTP: HLS relies on HTTP, which is the foundational protocol for the internet. Nearly all devices and platforms have built-in support for HTTP, making HLS readily accessible.
- Common Formats: HLS uses standard media formats like MP4 and AAC, which are widely supported across devices and browsers.
- Multiple Bitrates: HLS offers multiple bitrates for video and audio, allowing the stream to adapt to varying network conditions and device capabilities. This ensures smooth playback even with limited bandwidth.
- Fragmentation: HLS breaks the video into small fragments, making it efficient for streaming and allowing for faster buffering and playback initiation.
- Apple's Influence: Apple pioneered HLS, and its widespread adoption on iOS devices and Safari browsers has contributed to its popularity.
Secure HLS (HTTP Live Streaming) is widely used for secure streaming services. When mixing encrypted and unencrypted streams within the same HLS playlist, it's crucial to understand the implications and ensure proper implementation. 
This is crucial points when we service with Advertisement. We may have to mix both streams (encrypted/unencrypted):
1. Playlist Security:
- Secure Playlist: If your playlist is encrypted, it's generally considered best practice to encrypt all of the media segments within it. This ensures that the entire stream is protected.
- Unsecured Playlist: If your playlist is unencrypted, you cannot include encrypted media segments. This would create an inconsistent and potentially vulnerable stream.
2. Key Management:
- Encryption Key: For encrypted segments, you need a mechanism to manage the decryption key. This could involve server-side key management, or client-side key exchange using technologies like DRM (Digital Rights Management).
3. Stream Behavior:
- Switching Between Streams: If your stream starts with unencrypted segments and then transitions to encrypted segments, the player needs to be able to:
- Identify the switch: The player must recognize the shift in the playlist's content.
- Obtain the encryption key: If necessary, the player needs to acquire the decryption key to continue playback.
- Smooth Transition: The transition should be seamless for the user, avoiding any disruptions or buffering issues.
In terms of HLS Manifests we should keep in mind is EXT-X-KEY:METHOD right after EXT-X-DISCONTINUITY between transition:
The manifest should contain key information like below when switch from unencrypted to encrypted: #EXTINF:5.000,ad0
plain_stream0009.ts
#EXT-X-DISCONTINUITY
#EXT-X-KEY:METHOD=AES-128,URI="https://foo.net/your_key.cgi?id=....",IV=0x0123456789abcdef0123456789abcdef
#EXTINF:5.000,
encrypted_stream0010.ts
#EXTINF:5.000,
encrypted_stream0011.ts
.
.
.
You should let player aware when switch from encrypted to unencrypted like below:
#EXTINF:5.000,ad0
encrypted_stream0009.ts
#EXTINF:5.000,ad0
encrypted_stream0010.ts
#EXTINF:5.000,ad0
encrypted_stream0011.ts
#EXT-X-DISCONTINUITY
#EXT-X-KEY:METHOD=NONE
#EXTINF:5.000,ad1
plain_stream0012.ts
#EXTINF:5.000,ad1
plain_stream0013.ts
.
.
.
| 
