Closed jpovixwm closed 11 months ago
I suppose this issue is related to issues 294
@pcslide yes, it looks like the symptoms are the same, only the steps to reproduce we use are different. (And the fact that I'm using an Arc GPU rather than DG1). Were you able to reproduce this on your card using the non-protected VP8 video I linked to? I tried it with the Shaka Player demo page you linked to (https://shaka-player-demo.appspot.com/) and with Edge I can see this behavior with the "Angel One" and "Sintel" samples, of which only the latter is protected. Curiously, it doesn't reproduce with the "Angel One" sample in Brave, only in Edge. Not sure about "Sintel" in Brave, as I have Widevine DRM disabled in Brave and I want to keep it this way.
@jpovixwm Yes, I can reproduce exact same results on DG1 playing non-protected VP8 video.
Hey @jpovixwm thank you for your report!
I will add this information to the bug we have already opened for #294 which is in development stage and we reported we were able to reproduce in DG2 as well. Seems to be exclusive to Win10 as in Win11 it's just not reproducible
Thank you so much for your help!
Karen
Hi all update on this issue. It has been defined as expected behavior as some browsers like Chrome or Edge use SW DRM where needed, and not all titles are protected. This title doesn't show DRM encryption; protection is defined per based on their content license with the studio.
@IGCIT can you help close this one please? ty
Karen
I'm confused. As shown in the screen recording I provided, the third attempt to play any VP8 video completely disables HW accel for the Chromium process. Once this happens, the entire browser becomes slow in general, and the effect can be seen very clearly when scrolling webpages, as it's no longer smooth. The exemplary video I provided, makes no use of DRM. It's just a plain video encoded with VP8. Yet it's enough to crash something in Chromium. The behavior where the third playback attempt (or the third time the video decoding sub-process crashes) is probably just a failsafe mechanism built into Chromium itself, i.e. "If HW decoding fails three times in a short timespan, disable HW accel. altogether for the session". HW acceleration only comes back when the browser process is restarted manually.
Checklist [README]
Application [Required]
Chromium-based browsers (e.g. Chromium, Edge, Brave)
Processor / Processor Number [Required]
AMD Ryzen 9 5900X
Graphic Card [Required]
Intel Arc A750 LE
GPU Driver Version [Required]
Rendering API [Required]
Windows Build Number [Required]
Other Windows build number
No response
Intel System Support Utility report
igcit_ssu.txt
Description and steps to reproduce [Required]
Viewing VP8 videos in Chromium-based browsers with hardware acceleration enabled causes the browser's window to go black for a split-second when starting playback. This behavior repeats for the next two attempts to load such video, and the final (third) time causes the browser to disable all HW acceleration altogether.
A video demonstrating the issue in Edge 114.0.1823.51: https://github.com/IGCIT/Intel-GPU-Community-Issue-Tracker-IGCIT/assets/53523617/fc0fe08c-56e5-4b93-8a69-23b64f15359a Link to the original VP8 video that was used in the repro above: https://upload.wikimedia.org/wikipedia/commons/1/18/3D_rendering_of_a_micro_CT_scan_of_a_piece_of_dried_leaf..ogv
NB: I've already performed a clean installation of the 4499 driver with the help of DDU 18.0.6.4. This issue also appears with older drivers and also with an ASRock Arc A380 Challenger ITX in the same PC. (I no longer have the A380 as I've returned it and got the current A750 LE instead)
Device / Platform
MSI X370 Gaming Pro Carbon
Crash dumps [Required, if applicable]
No response
Application / Windows logs
No response