Encrypted video with clear lead should set "encrypted" to "true" in about:media-internals |
||||
Issue descriptionChrome Version : 63.0.3228.0 OS Version: 9992.0.0 What steps will reproduce the problem? 1. Play a encrypted video with clear lead (eg. https://storage.googleapis.com/biograf-video-files/videos/ttt-ep-2/mp4/v-1080p-4500k-libx264.mp4) 2. Go to about:media-internals 3. Check video_is_encrypted value What is the expected result? It should be true. What happens instead of that? It is false. There is maybe no way at the very beginning to know that this video is encrypted yet. If so, it would be nice to add a MEDIA_LOG when first encrypted media segment occurs.
,
Oct 4 2017
give to xhwang@ to answer question in c#1 and triage this bug.
,
Oct 4 2017
Encrypted MP4 with SRC playback is not supported yet. See issue 170793 that tracks this. With that, I think what happens is that the current demuxer is ignoring the encryption related box, so the media pipeline is just treating the video stream as unencrypted. It plays the first ~10 seconds without problems, then when the decoder hits encrypted data, it starts to generate garbage. I can repro this on my Linux box. If we want to avoid decoding garbage, probably our demuxer should throw an error when it hits encryption boxes and cannot parse them, instead of just ignores them.
,
Oct 5 2017
Could we at least raise a warning message in DevTools that points to issue 170793?
,
Oct 5 2017
The problem is that if we don't have proper demuxer support, we don't even know that particular mp4 file is encrypted. If we can detect this and fail playback, then we have many options to notify developers or users. That said, it's very rare in practice that people use EME + SRC. That's why issue 170793 has always been lower priority.
,
Oct 17 2017
,
Jul 23
|
||||
►
Sign in to add a comment |
||||
Comment 1 by fbeaufort@chromium.org
, Oct 2 2017