-
Notifications
You must be signed in to change notification settings - Fork 8
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
Failure to decode H.264 and VP9 in YUV422 and YUV444 formats #17
Comments
After enabling 4:2:2 and 4:4:4 for H.264 I observe the same phenomenon there as well. |
@Gnurou we should always test and compare with GStreamer, their scores are (IIRC): vp8: 60/61 Let's ditch ffmpeg as a comparison for VA IMHO. As for why the tests are failing, I will check with the traces enabled. |
@dwlsalmeida do you know how easy it would be to deploy GStreamer on a Chromebook? We don't have an ebuild for it, and with the plugin system I guess it cannot be as easy as just copying a binary unfortunately... |
Cc @ndufresne But why are chromebooks needed here? I thought we were running ccdec on regular Linux laptops when testing? |
Collabora Lava Labs only host Chromebooks at the moment. But as they are harness and ready to receive jobs, using this through a simple "trigger and wait" type of runner like Mesa is doing seems reasonable. For any test that requires Intel accelerators, there is of course cloud hosting that offers this, and may be used, but as mentioned, none of this is in place, you'll need to create and managed the base OS, kernel etc. |
I'm using Chromebooks as my Intel reference platform (no access to Intel hardware otherwise 😅) but you are right, at least for the sake of running GStreamer this is not essential. |
I am not very aware of cloud offerings tbh, do you mean that there are providers that give direct (or virtualized) access to Intel GPUs that works with libva? |
I'll have to take that back, it seems Google only offers NVIDIA gpus in their cloud instances: https://cloud.google.com/compute/docs/gpus So the only viable option is to rent a dedicated server with a desktop CPU. There is couple of option on Hetzner, which is a provided we use for GStreamer runners on gitlab.freedesktop.org. |
@Gnurou opened ticket with the intel-media-driver folks. I can also reproduce the problem with GStreamer Also, you mentioned H.264, do you have any specific tests where it failed? The gist of this issue is that the intel driver will allocate an internal format automatically, based on the rt_format passed in, but expect a different format once the stream metadata is read. This will cause it to error out. We can fix that by using the pixel format attrib to make the driver select the same value as returned by GetFormat. But honestly, I think this should be solved at the driver level. I can't reproduce this on AMD because either I have no hardware support or mesa has no support for VP9 profile 1. Either way, it does not show up in vainfo, so cros-codecs aborts on my AMD box. |
The
vp91-2-04-yuv422.webm
andvp91-2-04-yuv444.webm
are failing withvaEndPicture
returning aVA_STATUS_ERROR_INVALID_PARAMETER
error.This is a bit strange as
vp93-2-20-10bit-yuv444.webm
andvp93-2-20-12bit-yuv444.webm
, which are also 4:4:4 tests bit with higher bit depth, pass successfully - this suggests that our handling of 4:4:4 is at least correct.On the other hand
vp93-2-20-10bit-yuv422.webm
andvp93-2-20-12bit-yuv422.webm
are also failing.It is unclear whether this is a problem with cros-codecs or VAAPI. On these tests the
FFmpeg-VP9-VAAPI
decoder seems to always fall back to software decoding.The text was updated successfully, but these errors were encountered: