-
Notifications
You must be signed in to change notification settings - Fork 347
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[regression][ffmpeg-vaapi][vp8d] decode output corrupt #1028
Comments
This is a regression that started with c383f7e:
|
@uartie This change only impacts the platform which uses SW swizzling(should be >Gen11). So I don't think this issue caused by this change because gen 9.5 (KBL/CFL/WHL/CML ...) are not using SW swizzling. |
I checked on several different KBL, CFL and WHL packages SKUs. Some SKUs did not reproduce... but the others reproduce reliably. I also double-checked before and after patch... and regression always after patch. |
For example, a i7-7700 (KBL) I tested has 100% reproduced regression. But it is fine before the patch. |
Interestingly, on my local KBL Fedora OS development machine, it does not regress before or after this commit. But, if I compile and test in an Ubuntu Bionic Docker container on the same machine, I see the regression after this commit, but not before. Hope this gives some clues. |
Another observation... with Debug build, the issue goes away in container, too. |
But this change does modify some of the code paths taken by gen9.5, right? Perhaps the change exposed a previously dormant multi-thread race condition? Or maybe introduced one by accident? |
@Xiaogang-Li @feiwan1 any update? |
@Xiaogang-Li yes #1048 appears to resolve this issue. Thanks! |
@uartie : is this observation specific to vp8d only or you saw the same on vp9/av1? and did you ever see that on avc/hevc? |
Only vp8d using ffmpeg-vaapi + iHD as far as I've observed over ~2 months since this regression started. |
Also, note that adding -threads 1 to ffmpeg-vaapi does not exhibit this issue. |
DdiMediaUtil_CreateBuffer()->DdiMediaUtil_AllocateBuffer() will use it. Fixes intel#1028. Signed-off-by: Yan Wang <yan.wang@linux.intel.com>
@uartie I have not your VP8 clip. So I cannot reproduce this issue on my local platform. But I find Xiaogang's patch may impact one VP8 special buffer (VAProbabilityBufferType) creation. bUseSysGfxMem is not initialized but will be used in the creation. As you said previously, debug build has no this issue. For debug build, it should be zero/false. But for release build, the value should be undefined/unknown. |
I check it again. MOS_AllocAndZeroMemory should fill zero. Please ignore it. Sorry for this. |
I will continue to investigate it in the next week. Please provide the clip. |
@wangyan42164 you can easily reproduce this issue with the webm vp8 decode test vectors here: https://www.webmproject.org/code/ Here is a basic script that decodes and compares frame md5 differences on those cases. Just clone the test vectors repository (https://chromium.googlesource.com/webm/vp8-test-vectors), rename this script to On my machine, with
|
Oddly, though, I see the same behavior with this test set even before commit c383f7e or after applying #1048... so perhaps this has been a latent issue all along. |
That's interesting. Actually I see that ffmpeg-vaapi creates 2 VAAPI contexts on vp8 decoding with -threads 2 (I don't see such behavior on AVC...):
This does not seem to be right. @xhaihao : can you, please, comment how that can be? Do we face some ffmpeg bug? |
@dvrogozh it is an older ffmpeg-vaapi vp8 decoder issue, we already have a lot of discussion, ffmpeg should fix it inside ffmpeg. |
That's nasty:(. Considering that ffmpeg-vp8 creates 2 configs and driver tries to handle this inside, this means that driver should kind of restore first context inside a second one. Did we miss some key settings from first context which lead to artifacts?
That's 6aed7c3. |
I tried the ffmpeg patch and it fixes this issue on my side. I see the ffmpeg patch was superseded by https://patchwork.ffmpeg.org/project/ffmpeg/patch/1560235949-29164-1-git-send-email-shaofei.wang@intel.com/ and its review has stalled. @xhaihao @sfeiwong @mypopydev @feiwan1 please help to get this ffmpeg patch reviewed so it can be merged. |
ffmpeg patch has been merged (https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/eb6bb8f32fdc9be89cce65869dce9dd950e91be2) I will close after I test it again (assuming it works 😉). |
Also related #190 |
I am running into this issue now while using an i7-11700k. [hevc_vaapi @ 0x55cc823a8480] Failed to end picture encode issue: 24 (internal encoding error). or I get this in most of my conversions: [h264 @ 0x559bb0a4a740] Failed to end picture decode issue: 23 (internal decoding error). ffmpeg -hide_banner -loglevel info -init_hw_device vaapi=vaapi0:/dev/dri/renderD128 -hwaccel vaapi -hwaccel_output_format vaapi -hwaccel_device vaapi0 -i /library/tv/[FILE].mkv -strict -2 -max_muxing_queue_size 2054 -filter_hw_device vaapi0 -vf format=nv12|vaapi,hwupload -map 0:v:0 -map 0:a:0 -map 0:s:0 -map 0:s:1 -c:v:0 hevc_vaapi -c:a:0 copy -c:s:0 copy -c:s:1 copy -y /tmp/unmanic/unmanic_file_conversion-1640504463.512407/[FILE]-WORKING-2.mkv I wasn't able to find what release this was rolled into, but since its over 1 year since the fix maybe its something else? |
We are observing this issue only on gen 9.5 (KBL/CFL/WHL/CML ...). However, some of our gen9.5 platforms don't exhibit this problem. So maybe it's related to SKU or kernel that causes bad driver behavior?
The second frame in threads-default.yuv output is corrupt:
However, if we add
-threads 1
to the ffmpeg pipeline, then we get the expected output:We have many other cases that produce this kind of corrupt behavior, too.
The text was updated successfully, but these errors were encountered: