This happens with Chromium HW encoder stack using VA-API.
When this issue happens, the encoder is requested to encode 368x368 visible area stream.
Chromium HW encoder computes the coded size by aligning width and height both 16.
That said,
visible size: 368x368
coded size: 368x368
So the encoder specifies num_macroblocks = ALIGN(368, 16) / 16 * ALIGN(368, 16) / 16. [1]
On the other hand, Chromium HW encoder creates va surface with 384x368 because Chromium HW encoder aligns width by 64 and height by 4. [2, 3]
This settings ends up vaEndPicture() crash because of the assertion,
num_macroblocks == ALIGN(surface.width, 16) / 16 * ALIGN(surface.height, 16) / 16.
This means, no macroblock data must not be surface. I wonder if this check is correct.
If this is true, should I set num_macroblocks to one computed from surface size (384x368)?
Interestingly, this issue doesn't happen on other devices than Baytrail (probably gen6 device).
The easy reproduce step is to use test framework called Tast in ChromiumOS project.
In chromiumos chroot, you should run
$ tast run $DUT_IP video.EncodeAccelH264I420
This is an upstream version about https://bugs.chromium.org/p/chromium/issues/detail?id=1009297#c14.
This happens with Chromium HW encoder stack using VA-API. When this issue happens, the encoder is requested to encode 368x368 visible area stream. Chromium HW encoder computes the coded size by aligning width and height both 16. That said, visible size: 368x368 coded size: 368x368 So the encoder specifies num_macroblocks = ALIGN(368, 16) / 16 * ALIGN(368, 16) / 16. [1] On the other hand, Chromium HW encoder creates va surface with 384x368 because Chromium HW encoder aligns width by 64 and height by 4. [2, 3]
This settings ends up vaEndPicture() crash because of the assertion, num_macroblocks == ALIGN(surface.width, 16) / 16 * ALIGN(surface.height, 16) / 16.
This means, no macroblock data must not be surface. I wonder if this check is correct. If this is true, should I set num_macroblocks to one computed from surface size (384x368)?
Interestingly, this issue doesn't happen on other devices than Baytrail (probably gen6 device).
The easy reproduce step is to use test framework called Tast in ChromiumOS project. In chromiumos chroot, you should run $ tast run $DUT_IP video.EncodeAccelH264I420
[1] https://cs.chromium.org/chromium/src/media/gpu/vaapi/vaapi_video_encode_accelerator.cc?l=933&rcl=1b8a6f47ba236a3043e1d796e24ae1ac4d3c094f [2] https://cs.chromium.org/chromium/src/media/gpu/vaapi/vaapi_video_encode_accelerator.cc?l=382&rcl=1b8a6f47ba236a3043e1d796e24ae1ac4d3c094f [3] https://chromium.googlesource.com/chromiumos/platform/minigbm/+/c062c3b8e12f9a99bd835acaa996602d920e531d/i915.c#239