Closed VMFortress closed 1 year ago
You don't need a webcam. Using screen recording plugin can trigger the issue on DG2. https://chrome.google.com/webstore/detail/screen-recorder/hniebljpgcogalllopnjokppmgbhaden
And it produces broken bitstream that cannot be decoded by FFmpeg. screen-capture.7z.zip
[h264 @ 0000021658e5c940] cbp too large (3199971767) at 3 0
[h264 @ 0000021658e5c940] error while decoding MB 3 0
[h264 @ 0000021658e5c940] concealing 8160 DC, 8160 AC, 8160 MV errors in P frame
[h264 @ 0000021658e5c940] cbp too large (3199971767) at 3 0
[h264 @ 0000021658e5c940] error while decoding MB 3 0
[h264 @ 0000021658e5c940] concealing 8160 DC, 8160 AC, 8160 MV errors in P frame
[h264 @ 0000021658e5c940] cbp too large (3199971767) at 3 0
[h264 @ 0000021658e5c940] error while decoding MB 3 0
[h264 @ 0000021658e5c940] concealing 8160 DC, 8160 AC, 8160 MV errors in P frame
[h264 @ 0000021658e5c940] cbp too large (3199971767) at 3 0
[h264 @ 0000021658e5c940] error while decoding MB 3 0
[h264 @ 0000021658e5c940] concealing 8160 DC, 8160 AC, 8160 MV errors in P frame
[h264 @ 0000021658e5c940] cbp too large (3199971767) at 3 0
[h264 @ 0000021658e5c940] error while decoding MB 3 0
[h264 @ 0000021658e5c940] concealing 8160 DC, 8160 AC, 8160 MV errors in P frame
[h264 @ 0000021658e5c940] cbp too large (3199971767) at 3 0
[h264 @ 0000021658e5c940] error while decoding MB 3 0
[h264 @ 0000021658e5c940] concealing 8160 DC, 8160 AC, 8160 MV errors in P frame
Input #0, matroska,webm, from 'R:\screen-capture (1).webm':
Metadata:
encoder : Chrome
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0(eng): Video: h264 (Constrained Baseline), yuv420p(progressive), 1920x1080, SAR 1:1 DAR 16:9, 30.30 fps, 25 tbr, 1k tbn (default)
I doubt there could be some incompatible parameters between the chromium::h264_vaapi_video_encoder_delegate.cc and the DG2 settings in iHD driver.
@daijh could you help take a look?
I found another, slightly more repeatable test that may help finding the issue: https://canonical.github.io/inbrowser-encode-test/
It provides a hardware encode of the same short clip each time and provides a webm for download once finished. It may make it easier for direct comparison.
I attached example h264 encodes from it for DG2 and Skylake here: h264_webm.7z.zip
@VMFortress could you report the issue to chromium as well? Issues - chromium: https://bugs.chromium.org/p/chromium/issues/list
Could you provide the detailed chromium logs, and perhaps VA logs on DG2?
chromium logs
add below extra flags into cmdline.
--vmodule=*/vaapi/*=4,*/media/*=4 --enable-logging=stderr
va logs Chromium Docs - VA-API: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/gpu/vaapi.md
@daijh Chromium issue can be found here: https://bugs.chromium.org/p/chromium/issues/detail?id=1458942
Running LIBVA_TRACE=./dg2_trace.log chromium --enable-accelerated-video-encode --enable-features=VaapiVideoEncoder --vmodule=*/vaapi/*=4,*/media/*=4 --enable-logging=stderr > ./dg2_chromium.log 2>&1
:
about:gpu
page: about_gpu.txtSorry, I don't have a DG2 at hand. The logs showed the iHD driver has error to create the RGBA VASurface. There are indeed a few fixes were landed on both Chromium and iHD regarding to this specify issue.
[1] https://github.com/intel/media-driver/issues/1210 [2] https://chromium-review.googlesource.com/c/chromium/src/+/4637884
Suggest to include those patches to check this issue.
@daijh I had the chance to test again with the latest intel-media-driver and chromium 117.0.5875.0 which should contain the patches mentioned. Unfortunately, there doesn't not seem to be any improvement. Doing the canonical test again, VP9 encodes fine but H264 results in the corrupted output on DG2 but not on Skylake.
Here are the same logs as before for this test:
Hi @VMFortress ,
Please help to try this patch - if it will resolve this issue, we will prepare the official fix.
potential_fix_for_ChromeOs.patch
Need to change one line - https://github.com/intel/media-driver/blob/03f4cde9fb8a88b9b12a9edd5fd5b43f71226ee5/media_driver/linux/common/codec/ddi/media_ddi_encode_avc.cpp#L1299
from "seqParams->GopPicSize = seq->intra_period;" to "seqParams->GopPicSize = seq->intra_period ? seq->intra_period : seq->intra_idr_period;"
If it will not help - we will continue the analysis.
Best regards, Denis
Auto Created VSMGWL-66368 for further analysis.
It does the trick. No issue anymore in my aforementioned screen recording plugin testing.
@DenWolf I can confirm this resolves all my test cases as well!
Great! @nyanmisaka , @VMFortress - thank you very much for a very quick verification and confirming that fix is working on your side! I've started to prepare the official fix, I will provide an updates based here on my progress.
Hi @VMFortress , @nyanmisaka , Fix has been merged into Media driver repo - https://github.com/intel/media-driver/commit/02a5604273ecf385efca0acf16679aec650c95b7
Please help to verify it (or the latest Media Driver OS code-base - for now it's the latest commit) on your side again, thank you.
Best regards, Denis
@DenWolf I compiled the latest source and can confirm again it seems to be working in all my cases.
Thanks for the support! It is very appreciated!
@DenWolf So for so good. Thanks for your help!
Fixed in https://github.com/intel/media-driver/commit/02a5604273ecf385efca0acf16679aec650c95b7 so close it. Please feel free to reopen it if the issue is not resolved on your environment.
Great! @VMFortress , @nyanmisaka - thank you very much for your feedback and verification support!
Which component impacted?
Encode
Is it regression? Good in old configuration?
No, this issue exist a long time
What happened?
It seems DG2 GPUs create corrupted output when using hardware encode on Chromium-based browsers. This does not appear to be an issue on other Intel platforms, including Skylake.
Steps to Reproduce: (Prerequisites: webcam or similar device, DG2 GPU) 1) Use latest libva, gmmlib, and media-driver compiled from source as of June 15th, 2023. 2) Launch a Chromium 114 based browser with the following command:
LIBVA_DRIVER_NAME=iHD chromium --enable-accelerated-video-encode --enable-features=VaapiVideoEncoder
3) Navigate to https://codec-compare.glitch.me/ 4) Leave all settings at default and hit 'Start' 5) Allow webcam permissions in Chromium 6) Observe input compared to single frame of corrupted output 7) Very low usage (typically <1%) of Video and VideoEnhance engines can be seen inintel_gpu_top
.The issue appears in all H264 codecs available but does not occur on AV1 or VP9 codecs in same case.
Additional debugging details provided below.
What's the usage scenario when you are seeing the problem?
Transcode for media delivery
What impacted?
Any websites or Electron-based applications using H264 encoding will be unable to use acceleration. A mainstream example is Discord screenshare running within Chromium.
Debug Information
Logs:
Additional debug info:
VaapiLowPowerEncoderGen9x
in chromiumI am happy to provide any other details requested or peform any tests that may help.
Do you want to contribute a patch to fix the issue?
None