Failure to decode H.264 and VP9 in YUV422 and YUV444 formats

[Gnurou]

The vp91-2-04-yuv422.webm and vp91-2-04-yuv444.webm are failing with vaEndPicture returning a VA_STATUS_ERROR_INVALID_PARAMETER error.

This is a bit strange as vp93-2-20-10bit-yuv444.webm and vp93-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 and vp93-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.

[Gnurou]

After enabling 4:2:2 and 4:4:4 for H.264 I observe the same phenomenon there as well.

[dwlsalmeida]

@Gnurou we should always test and compare with GStreamer, their scores are (IIRC):

vp8: 60/61 vp9: 302/303 h264: 129/132

Let's ditch ffmpeg as a comparison for VA IMHO.

As for why the tests are failing, I will check with the traces enabled.

[Gnurou]

@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...

[dwlsalmeida]

Cc @ndufresne

But why are chromebooks needed here? I thought we were running ccdec on regular Linux laptops when testing?

[ndufresne]

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.

[Gnurou]

But why are chromebooks needed here? I thought we were running ccdec on regular Linux laptops when testing?

I'm using Chromebooks as my Intel reference platform (no access to Intel hardware otherwise :sweat_smile:) but you are right, at least for the sake of running GStreamer this is not essential.

[Gnurou]

there is of course cloud hosting that offers this

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?

[ndufresne]

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.

[dwlsalmeida]

As @padovan said in #6, there's some internal discussion taking place to check whether we can leverage the Chromebooks at the Collabora lab for this

(I think we should centralize the discussion in that ticket, btw)

[dwlsalmeida]

@Gnurou opened ticket with the intel-media-driver folks. I can also reproduce the problem with GStreamer

https://github.com/intel/media-driver/issues/1683

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.