[Webkit-unassigned] [Bug 212588] New: [Safari 13 or later] Bad synchronization between audio and video during playing HLS stream encrypted with AES128 static key

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=212588

            Bug ID: 212588
           Summary: [Safari 13 or later] Bad synchronization between audio
                    and video during playing HLS stream encrypted with
                    AES128 static key
           Product: WebKit
           Version: Safari 13
          Hardware: All
                OS: Other
            Status: NEW
          Severity: Critical
          Priority: P2
         Component: Media
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: yasuhiko at gnzo.com

We are operating a commercial VOD streaming service and using video tag on Safari browser for HLS VOD streaming.

We have been applied AES128 (static key) to HLS VOD stream for content protection and until recently there was no issue.

But recently (after Safari 13 or later), when we play HLS VOD stream encrypted with AES128 (static key) on MAC/iOS safari (below), 

MACBook Pro15' (OS X 10.15.5) Safari 13.1.1
iPad (7th gen OS 13.4.1) Safari 13.1 

Just after play started, synchronization between video and audio is normal, but when I viewing the stream continuously, the synchronization gradually go bad and finally become completely out of sync.

On the old version of safari, using same HLS stream, the issue was not seen.

Old version example:

- iPhone5s(OS:12.4.1 Safari:v12.1.2)
- iPhone6 (OS 12.4.7) Safari 12.1.2
- MacBookAir (OS X:10.11.6 Safari:v11.1.2)

also, on Chrome browser (+HLS native playback plugin) with same HLS stream, the issue was not seen.

example:
- MACBook Pro15' (OS X 10.15.5) chrome83.0.4103.61

The sample HLS stream we used regarding this issue is below:
(a) https://5aeb1e45d40a5.streamlock.net/vodcf6/sync.mp4/playlist.m3u8                  #generated by Wowza Streaming Engine
(b) https://5aeb1e45d40a5.streamlock.net/vodcf6/sample.mp4/playlist.m3u8              #generated by Wowza Streaming Engine
(c) https://hzett.s3-ap-northeast-1.amazonaws.com/200529sampleaes/playlist.m3u8  # generated by AWS mediaconvert

The content of child m3u8 of (a) is below:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:1
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-KEY:METHOD=AES-128,URI="https://hlsauth.gnzo.com/beecluise_allok.php"
#EXTINF:1.0,
media_0.ts
#EXTINF:1.0,
media_1.ts
#EXTINF:1.0,
...

We confirmed that the keyframe interval of (1) is correctly 1sec and HLS chunksize is also 1sec. 
So we think the encoding manner is not cause of this issue.

How to reproduce this issue:
1. prepare HLS VOD stream where AES128 (static key) is applied 
2. play the HLS VOD stream over MAC Safari or iOS devices (version 13 or later) 
(You can use above stream of (a)(b)(c))

We produced stream (a)(b) with Wowza Streaming Engine referring below article with quite simple manner.
https://www.wowza.com/docs/how-to-secure-apple-http-live-streaming-aes-128-external-method
We produced stream (c) with AWS MediaConvert.

Please let us know the workaround. If we can avoid this issue with some encoding parameters of source video or setting of HLS streaming, we will follow it.

In Japan, the share of iPhone/iPad is very large and many OTT provider / streaming service operator using AES128 encryption for content protection over iPhone/iPad.
so this issue is very very critical and urgent.

If more information is needed, please let us know.

Thank you in advance and best regards,

Y. Takano

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200601/fcbbb9f6/attachment.htm>