[Fluster] vp80-00-comprehensive-006 failure

[Gnurou]

$ python fluster.py run -d cros-codecs-VP8 -tv vp80-00-comprehensive-006
****************************************************************************************************
Running test suite VP8-TEST-VECTORS with decoder cros-codecs-VP8
Test vectors vp80-00-comprehensive-006
Using 12 parallel job(s)
****************************************************************************************************

[TEST SUITE      ] (DECODER        ) TEST VECTOR               ... RESULT
----------------------------------------------------------------------
[VP8-TEST-VECTORS] (cros-codecs-VP8) vp80-00-comprehensive-006 ... Fail

=======================================================================
FAIL: vp80-00-comprehensive-006 (cros-codecs-VP8.VP8-TEST-VECTORS)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/mnt/stateful_partition/fluster/fluster/test.py", line 106, in _test
    self.test_vector.name,
AssertionError: '2d5fa3ec2f88404ae7b305c1074036f4' != '0c345d46643d9da1e1369e8ceb98e122'
- 2d5fa3ec2f88404ae7b305c1074036f4
+ 0c345d46643d9da1e1369e8ceb98e122
 : vp80-00-comprehensive-006

Ran 0/1 tests successfully               in 0.205 secs

The resulting output is visually close to the expected result, but as if the image was offset a little. It's also not a full-pixel shift, the values of most pixels are slightly different, and that from the first frame,as if the image was zoomed it just a little bit.

The bitstream has the unusual resolution of 175x143 (vs the usual 176x144), this is probably related.

[Gnurou]

Looking at the decoded frames with YUView, it is clear that there is some scaling applied by the hardware.

[Gnurou]

Thinking about it, this is possibly happening through the VAImage rather than decoding itself?

[dwlsalmeida]

@Gnurou on it

[Gnurou]

vp80-00-comprehensive-014 also appears to be failing for the same reason.

[dwlsalmeida]

@Gnurou So when we said that GStreamer/ffmpeg-VAAPI are passing these tests, there's one detail left out.

both GStreamer and ffmpeg ask for NV12 during VAImage creation. They then convert the data into I420 themselves, at a later point.

It may be that decoding to I420 is broken specifically for odd resolutions at the VA-API driver level, I am not sure. For these 175x143 videos, the output seems almost the same, but it has a minor shift, as if some minor scaling took place at some point.

I420 VAImage works fine when the width and height are powers of 2, however.

What do you want to do here? From past experience, diving into intel-media-driver is a massive time sink for little gain..

[dwlsalmeida]

maybe @ndufresne may have some insight if he's not too busy, I will attach the YUV output.

Unfortunately, there's nothing different at the VA_TRACE level. We are sending the driver the exact same inputs..

[dwlsalmeida]

output.tar.gz

[ndufresne]

The wrong output is scale up in a way that isn't just a scaling / postproc artifact, and is blurred too. Its proprietary code, so its hard to tell what going on, as you notice, in GStreamer we force NV12 as anything else straight from the decoder is massively broken and Intel have not care fixing, perhaps its better now, but to me its not really worth it.

In gst we have code to calculat I420 MD5 from NV12 source, I'm sure you could do that same, or simply add a hand written converter.

[Gnurou]

Thanks - I'll try to render a NV12 frame and convert it to I420 to see if the problem is indeed in the driver. If it is, I guess we should report the bug instead of diving into it ourselves.

[dwlsalmeida]

This is now passing on Intel thanks to #25