197417 2019-04-30 09:22:45 -0700 [GStreamer][EME] Encrypted, fragmented MP4s not supported 2026-04-01 07:59:05 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build Unspecified Unspecified RESOLVED FIXED P2 Normal --- 210644 1 cturner webkit-unassigned bugs-noreply philn oldest_to_newest 1531543 0 cturner 2019-04-30 09:22:45 -0700 Placeholder bug to record a number of issues affecting encrypted, fragmented MP4s. There are at least two WPT's that show this problem, clearkey-mp4-playback-temporary-encrypted-clear.https.html clearkey-mp4-playback-temporary-clear-encrypted.https.html And their *-drm equivalents. These are files that contain an encrypted track, followed by a clear one and vice versa respectively. The current GStreamer behaviour is to try and reconfigure the src pad caps from qtdemux to transition from application/x-cenc -> video/x-h264 and vice versa respectively. This reconfiguration is not supported by decodebin2, it can't dynamically change it's pipeline topology at runtime like that. Decodebin3 should support that, but it at least has bugs dealing with this situation, and we're not ready to use it in MSE at the moment anyway, so that's a non-starter. An attempt was made to modify qtdemux to treat a new fragmented track whose protection status differs from the preceding track as deserving of a new src pad. That works to the extent that decodebin2 will create a second DecodeChain, and autoplug an appropriate pipeline for the new situation, however WK MSE does not allow demuxers to do this for the same SourceBuffer: connectDemuxerSrcPadToAppsinkFromStreamingThread: Only one stream per SourceBuffer is allowed! Ignoring stream 2 by adding a black hole probe So we have some options: 1) Wait until we can turn decodebin3 on always, even in MSE and fix any bugs there blocking this behaviour from working. 2) Modify qtdemux to expose a new pad (stalled in https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/merge_requests/180) and then modify MSE to allow multiple streams per SourceBuffer. 3) Create a new bin handling video/x-h264 (and friends) *as well as* application/x-cenc with a rank higher than decodebin2. This new bin would essentially wrap decodebin2, and if necessary shove a decryptor in front of the decodebin2 when necessary (and remove it when necessary as fragments change protection status). The large downside here is you'd now have a bin-within-a-bin for every non-encrypted video. Proxypads introduce non-neglible performance hit, and it's just a pretty gross hack when the above two options would result in a cleaner codebase. These sorts of files don't *appear* to be that popular in the wild, so I'm personally happy to wait for either 1 or 2. 3 is an option if an emergency case comes up where this needs implementing. 2195908 1 philn 2026-04-01 07:59:05 -0700 These are mostly passing for a while now, some occasional flakiness but I guess no one is surprised by that anymore... https://results.webkit.org/?suite=layout-tests&suite=layout-tests&test=imported%2Fw3c%2Fweb-platform-tests%2Fencrypted-media%2Fclearkey-mp4-playback-temporary-clear-encrypted.https.html&test=imported%2Fw3c%2Fweb-platform-tests%2Fencrypted-media%2Fclearkey-mp4-playback-temporary-encrypted-clear.https.html&platform=GTK&platform=WPE