Do FairPlay and AVPlayer support Clear Lead?

I think you can create the playlist with the clear ones and mark the EXT-X-KEY for the start of encrypted ones:

#EXTM3U

#EXT-X-TARGETDURATION:10

#EXT-X-MEDIA-SEQUENCE:1

#EXTINF:10,

01.ts

#EXT-X-KEY:METHOD=SAMPLE-AES,KEYFORMAT="com.apple.streamingkeydelivery",KEYFORMATVERSIONS="1",URI="skd://1"

#EXTINF:10,

02.ts

#EXTINF:10,

03.ts

**EDIT - the #EXT-X-DISCONTINUITY tag is not required, so long as the timestamp sequence, GOP etc. are continuous.

Hi Noam,

achibana's answer is mostly correct, but the one change is the potential need to insert an #EXT-X-DISCONTINUITY tag ahead of the #EXT-X-KEY tag to indicate the significant change at that point, as follows:

#EXTM3U
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:1
#EXTINF:10,
01.ts
#EXT-X-DISCONTINUITY
#EXT-X-KEY:METHOD=SAMPLE-AES,KEYFORMAT="com.apple.streamingkeydelivery",KEYFORMATVERSIONS="1",URI="skd://1"
#EXTINF:10,
02.ts
#EXTINF:10,
03.ts

AVPlayer will start playing without waiting for the response. Would recommend the inclusion of at least one target duration, if not more.

Note that you can cause the key request to be completely asynchronous from playback using the AVContentKeySession approach, which would allow you to prefetch the keys separate from the actual playback session, which is the pattern that many developers are now taking in order to reduce complexity and dependencies at playback time.

Thanks achibana and TidBits.

Won't the DISCONTINUITY cause a disturbance? Is AVPlayer "smart" enough to avoid that cut because the chunk parameters (bitrate, resolution, codecs) are identical?

Hi Noam,

All that the discontinuity tag indicates is that there is a change present, and the presence of the tag should cause no disturbance at all.

TidBits, another question on this - how would it look like with fMP4?

With fMP4 we're currently outputting one EXT-X-MAP tag at the beginning, and the mp4 it links to indicates that the media is encrypted (has format=encv in the stsd atom + has schm/schi/tenc atoms). The question is whether we can stay with one such init mp4, containing the encryption info, or we have to create 2 init mp4, one for clear and one for encrypted.

With DASH we are creating a single init mp4, with an stsd atom that has two records - one for encrypted, and one for clear. Each segment is referencing either the clear or encrypted record using the sample_description_index field in the tfhd atom.

Should we do the same here? And, if we do that, does it actually matter where we put the EXT-X-KEY in the manifest?

Thank you!

Eran

Hi Eran,

Having one track with two sample descriptions, one encrypted and one not, should work.

You should still ensure that the EXT-X-KEY tag is at the correct place in the manifest, indicating the transition from unencrypted to encrypted content.

Thanks,

Josh

Thanks Josh!

Works for us with fMP4 & two sample descriptions (even without discontinuity), with MPEG-TS however, it isn't working for us.

I thought maybe it's because we are currently using the same MPEG-TS pid/sid for the clear content and the encrypted content.

I tried to work around it by adding discontinuity, but it didn't help.

Any chance you have some sample stream that uses MPEG-TS + SAMPLE-AES + clear lead?

Thank you!

Eran

Hey Eran,

Unfortunately we don't have any such samples. But you could certainly request us to create some in the future at bugreporter.apple.com

It should work for MPEG-TS, though. And a discontinuity shouldn't be required. It should only necessitate the insertion of the KEY tag when the transition occurs.

You could also file a bug with us at bugreporter.apple.com to investigate - please ensure you first install the core media logging profile on your device, available at the following URL, and then reboot your device before reproducing the issue:

https://developer.apple.com/bug-reporting/profiles-and-logs/?name=coremedia

If you can include sample content in the bug report, that would be very helpful as well.

Many thanks,

Josh

Hi TidBits,

We are delivering audio-only HLS streams with fMP4. The first segments are unencrypted, and the remaining segments are encrypted. The CMAF header pointed to by the EXT-X-MAP contains one ´trak´ box with one ´enca´ sample description and one ´mp4a´ sample description, in that order.

The approach suggested here by signaling an EXT-X-KEY with METHOD=SAMPLE-AES before the encrypted segments makes playback start before the license is received, which is great. However, when playing the content in Safari on both macOS and iOS, there's an audible glitch when the player transitions from an encrypted to an unencrypted segment (it is particularly audible if the audio signal is a sine-wave). We deliver the same segments to Chrome using MPEG-DASH, and that glitch is not present when playing the content there.

Sadly, we haven't been able to test this using AVPlayer yet.

The playlists we serve looks like this:

#EXTM3U

#EXT-X-VERSION:7

#EXT-X-PLAYLIST-TYPE:VOD

#EXT-X-TARGETDURATION:4

#EXT-X-MEDIA-SEQUENCE:0

#EXT-X-INDEPENDENT-SEGMENTS

#EXT-X-KEY:METHOD=NONE

#EXT-X-MAP:URI="0.mp4"

#EXTINF:3.993832,

1.mp4

#EXTINF:3.993832,

2.mp4

#EXTINF:3.993832,

3.mp4

#EXTINF:3.993832,

4.mp4

#EXTINF:3.993832,

5.mp4

#EXT-X-KEY:METHOD=SAMPLE-AES,URI="skd://something",KEYFORMAT="com.apple.streamingkeydelivery",KEYFORMATVERSIONS="1"

#EXTINF:3.2972336,

6.mp4

#EXT-X-ENDLIST

Is it a known issue that Safari produce an audible glitch in scenarios such as this? Do you see any problems with our playlist, or do you suspect that we have a problem with our packager?

I'd be happy to provide an example using segments from our packager if you have time to look into that.

This isn't an issue I've heard of before. Likely there's an issue at that transition point in the encoding or packaging.

You could try inserting a discontinuity tag at that point and see if that makes a difference.

If that doesn't help and you can't find anything obvious, please do file a bug at bugreporter.apple.com with a link to sample content and detailed repro steps.

Hi,

I doubt that it's an encoding issue since we always use them same encoded file, but when we vary the clear lead duration in our packager, the artifact is always heard when transitioning from an unprotected to a protected segment.

We deliver the same encrypted segments to Chrome (encrypted with cbcs), and there they play without an audible artifact on the unencrypted-encrypted boundary, so I'm reasonably confident that our packager isn't completely out of spec at least (I've also tried shaka-packager and its output has the same artifact).

I also tried inserting a discontinuity tag at the transition point, but it didn't seem to have an effect.

ISO 23001-7 (CENC) indicates that one could have one 'enca' sample description entry, and supply a 'sgpd' with 'seig' grouping type and 'isProtected=0x0' in a fragment's 'traf' to indicate that the samples in a fragment is unencrypted. However, most packagers I've used seem to have both 'enca' and 'mp4a' sample description entries, and indicating in the 'tfhd' which of sample description to use, thereby omitting the 'sgpd' with 'seig' grouping. What is Apple's recommended way of signalling unprotected samples in a protected track?

Do you have any examples of HLS with fMP4 and a clear lead? And is there any plan to implement support for clear lead in the mediafilesegmenter?

We've also tried playing the same stream on AVPlayer on iOS, and the same artifact is audible there. Is there anything we need to be aware of when developing our player, so that it handles a mix of protected and unprotected segments seamlessly?

(I reported this as a bug back on in the middle of March to hopefully get some help, but haven't heard anything yet.)

@gebn Have you figure out some solution or workaround for the glitch issue, when the player transitions from an encrypted to an unencrypted segment? It is still present. Am I right that the bug reported to Apple is not public?