[Webkit-unassigned] [Bug 197417] New: [GStreamer][EME] Encrypted, fragmented MP4s not supported

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Apr 30 09:22:45 PDT 2019


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

            Bug ID: 197417
           Summary: [GStreamer][EME] Encrypted, fragmented MP4s not
                    supported
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKitGTK
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: cturner at igalia.com
                CC: bugs-noreply at webkitgtk.org

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.

-- 
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/20190430/a4ae548e/attachment.html>


More information about the webkit-unassigned mailing list