I was waiting for the resolution of https://github.com/gpac/gpac/issues/2526 but since there has been no progress for some time, I would also like to ask about preparation of FairPlay DRM content in mpeg-ts container with GPAC. Trying it with the latest 2.3-DEV-rev479-g941a0891-master downloaded today.

Using simple command `gpac -i source.mp4 cecrypt:cfile=drm.xml -o playlist.m3u8:segdur=3:profile=live:template=seg:muxtype=ts` where HLS SAES-based drm.xml consists of

```
<?xml version="1.0" encoding="UTF-8"?>
<GPACDRM type="HLS SAES">
        <DRMInfo type="pssh" version="1" >
                <BS ID128="94CE86FB07FF4F43ADB893D2FA968CA2" />
 		<BS value="1" bits="32"/>
                <BS ID128="ecae683de67a9c182f54ea704b4b5961" />
        </DRMInfo>
        <CrypTrack isEncrypted="1" constant_IV_size="16" constant_IV="0x712ecac8f88a44114cdd0f65f3812c60" saiSavedBox="senc">
                <key KID="0xecae683de67a9c182f54ea704b4b5961" value="0x{128-bit key}" hlsInfo='URI="skd://ecae683d-e67a-9c18-2f54-ea704b4b5961",KEYFORMAT="com.apple.streamingkeydelivery",KEYFORMATVERSIONS="1"'/>
        </CrypTrack>
</GPACDRM>
```

does not generate proper sample-AES encrypted content usable with FairPlay DRM. Safari and Apple native players consider the HLS content corrupted and unplayable, it's not even recognized after loading the first TS segment, the error occurs immediately and no license is even requested.

I cannot claim that the following is everything causing the issue, there might be more but it might be a good start. What I see is:

- The TS segments are missing private_data_indicator according to https://developer.apple.com/library/archive/documentation/AudioVideo/Conceptual/HLS_Sample_Encryption/TransportStreamSignaling/TransportStreamSignaling.html

- The m3u8 playlists must be `EXT-X-VERSION: 5` as minimum when using `METHOD=SAMPLE-AES`, `KEYFORMAT` and `KEYFORMATVERSIONS` attributes required for FairPlay, see https://developer.apple.com/documentation/http-live-streaming/about-the-ext-x-version-tag

- When preparing FairPlay content, the `IV` atribute should not be usually part of the `EXT-X-KEY` tag. IV is negotiated within the FairPlay license itself at least from my own experience. Some toggle might be needed for this, whether to add it to the playlist or not.


When I was playing with the fmp4 counterpart by using the same drm.xml but just replacing type `"HLS SAES"` with `"cbcs"` and not using `muxtype=ts` in the commandline, it was faring a bit better. EXT-X-VERSION in m3u8 playlists was automatically set to 6, it was recognizable as a whole as "usable" content, however, only audio track was decryptable, video track remained scrambled. I assume the reason being the warning message from GPAC while packaging: `Using cbcs pattern mode on-video track is disabled in GPAC, using whole-block full encryption`. Not sure why the exception in GPAC for video tracks. Correctly working audio in this example seems to prove that the pattern mode is the way to go.

All in all, can you please comment whether my configuration should yield the expected results or are there errors on my side somewhere? Searching for https://github.com/gpac/gpac/issues?q=fairplay , reading wiki and examples in the repo did not provide complete answers.
Otherwise could you please try to get GPAC suite closer to expectations of Apple?
FairPlay content in mpeg-ts based HLS
This is a GitHub Issue
repo:gpac
owner:gpac
Title : FairPlay content in mpeg-ts based HLS
Issue date:

--- start body ---
I was waiting for the resolution of https://github.com/gpac/gpac/issues/2526 but since there has been no progress for some time, I would also like to ask about preparation of FairPlay DRM content in mpeg-ts container with GPAC. Trying it with the latest 2.3-DEV-rev479-g941a0891-master downloaded today.

Using simple command `gpac -i source.mp4 cecrypt:cfile=drm.xml -o playlist.m3u8:segdur=3:profile=live:template=seg:muxtype=ts` where HLS SAES-based drm.xml consists of

```
<?xml version="1.0" encoding="UTF-8"?>
<GPACDRM type="HLS SAES">
        <DRMInfo type="pssh" version="1" >
                <BS ID128="94CE86FB07FF4F43ADB893D2FA968CA2" />
 		<BS value="1" bits="32"/>
                <BS ID128="ecae683de67a9c182f54ea704b4b5961" />
        </DRMInfo>
        <CrypTrack isEncrypted="1" constant_IV_size="16" constant_IV="0x712ecac8f88a44114cdd0f65f3812c60" saiSavedBox="senc">
                <key KID="0xecae683de67a9c182f54ea704b4b5961" value="0x{128-bit key}" hlsInfo='URI="skd://ecae683d-e67a-9c18-2f54-ea704b4b5961",KEYFORMAT="com.apple.streamingkeydelivery",KEYFORMATVERSIONS="1"'/>
        </CrypTrack>
</GPACDRM>
```

does not generate proper sample-AES encrypted content usable with FairPlay DRM. Safari and Apple native players consider the HLS content corrupted and unplayable, it's not even recognized after loading the first TS segment, the error occurs immediately and no license is even requested.

I cannot claim that the following is everything causing the issue, there might be more but it might be a good start. What I see is:

- The TS segments are missing private_data_indicator according to https://developer.apple.com/library/archive/documentation/AudioVideo/Conceptual/HLS_Sample_Encryption/TransportStreamSignaling/TransportStreamSignaling.html

- The m3u8 playlists must be `EXT-X-VERSION: 5` as minimum when using `METHOD=SAMPLE-AES`, `KEYFORMAT` and `KEYFORMATVERSIONS` attributes required for FairPlay, see https://developer.apple.com/documentation/http-live-streaming/about-the-ext-x-version-tag

- When preparing FairPlay content, the `IV` atribute should not be usually part of the `EXT-X-KEY` tag. IV is negotiated within the FairPlay license itself at least from my own experience. Some toggle might be needed for this, whether to add it to the playlist or not.


When I was playing with the fmp4 counterpart by using the same drm.xml but just replacing type `"HLS SAES"` with `"cbcs"` and not using `muxtype=ts` in the commandline, it was faring a bit better. EXT-X-VERSION in m3u8 playlists was automatically set to 6, it was recognizable as a whole as "usable" content, however, only audio track was decryptable, video track remained scrambled. I assume the reason being the warning message from GPAC while packaging: `Using cbcs pattern mode on-video track is disabled in GPAC, using whole-block full encryption`. Not sure why the exception in GPAC for video tracks. Correctly working audio in this example seems to prove that the pattern mode is the way to go.

All in all, can you please comment whether my configuration should yield the expected results or are there errors on my side somewhere? Searching for https://github.com/gpac/gpac/issues?q=fairplay , reading wiki and examples in the repo did not provide complete answers.
Otherwise could you please try to get GPAC suite closer to expectations of Apple?
--- end body ---
