+jcliang@ who made change to video_ChromeRTCHWEncodeUsed.py most recently.

+achuith@, ihf@ who may know better about the test.

The chrome log that might be related to the test failure:
https://00e9e64bac9f201cf41ea6cf0e116ef271a80cfec831caa197-apidata.googleusercontent.com/download/storage/v1/b/chromeos-autotest-results/o/256529834-chromeos-test%2Fchromeos4-row9-rack10-host7%2Fvideo_ChromeRTCHWEncodeUsed%2Fsysinfo%2Fvar%2Flog_diff%2Fchrome%2Fchrome_20181112-133215?qk=AD5uMEsbV7oDCDr9k6Xm-bkwbI99oylIGCtAsUTgTi33essuzuMtaA5UIOxjSGDYiYrd6c4eGnh10nwMJd1gIZPUZZmLd-0hzCFcDjUlennYyWZxUiy9AohZYVBm5zQLNu1UWuqr9Nja2Xz7VCvkI-TQ7M0fILqgG4eZ9BGavYAdXjCtdwA1w51FvMe6xh6QOe3-zydpP1zwmglBX6kxDYgfRKYARPSYJYCMWjHdGH7pIDn1YZ42InFINwDaLe4PM1Gw6zvYqAecEsmVzrSoP0Kz0zlP-ZnTtl1qIX0bv7kPuzypNafUb5kv0pOR3VTgAeDRyLgElGKFE5N0It5IY9o_fAsBk80HHgPBNWNRR4gj-HhGkPa6B01NpHoyy_o8Gho_p2WepTfLEXKXRZ8YZ5ts-XBLN-pBMLMC6zNKKLq65g_erVjw2tcSnBovUXnHWnv_8y9oBBb3_DjxqFhxfcCYrWqi9TKkzsUH4IXjoAVPoOyhUmMQLEx2h1fDpZYWgsyGF_-dl-xukkqXOId1C-FSW5IFWlxfcyCYFhUcl6bMFwO_ZQePHShYq2M2pR7e00sIq6YjpfpSggc2AdgamN1dXpCp1w8i4aDp_WJD9BrU2qB9oUWws9dbRHDbnVoWiIWSsExVtXEJP9zbUBvEIHFZJyZygRJ4hpD6-nKM4nDBfj2CEIhk7Q2X2QLx8PmJBNjYlZfH2g7AtSDHrU7TRrgMy0wowFxYQQej9Si2p4wsgytmrOAhinEAJt_vBAdmRofO654NU77eGLmZQ4LUqlLeaipJNLMP9-W6xCY3H-79npLNM6nJtV78MIfNPpBGgGNcUfPZkrxtt25adrQ2psaqNyLssx93ld5hmoUcPCZ9WXZ7s3UgxHVL5p2z9IfuTilC70T-cW8PzpliifokaWlhDdHiD2SDGAAu6IjvBpwd5oZdlDq14ZRLnNoZLV5qh7AXoCnyNzpu0WTezkRy2y2wIKPV9CNPIg

Usually that means that somebody broke video inside of Chrome. You will have to bisect Chrome against the test to figure out the change that broke it. Alternatively you can temporarily change the control file from ATTRIBUTES suite:bvt-cq to suite:bvt-perbuild with a TODO to revert, chump it, and assign this issue to the video team.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/a40526be5a2d1307fdb760587bcb743275054d66

commit a40526be5a2d1307fdb760587bcb743275054d66
Author: Weidong Guo <weidongg@chromium.org>
Date: Tue Nov 13 00:21:29 2018

Temporarily change attributes to suite:bvt-perbuild

The change fixed the failure in veyron_minnie-tot-chrome-pfq-informational builder caused by video_ChromeRTCHWEncodeUsed failure. It should be revert when the test failure is fixed.

BUG= chromium:904586 
TEST=None

Change-Id: Ib8646e8626b645650761d612251ded90bb4dc9f1
Reviewed-on: https://chromium-review.googlesource.com/c/1333067
Reviewed-by: Ilja H. Friedel <ihf@chromium.org>
Tested-by: Ilja H. Friedel <ihf@chromium.org>

[modify] https://crrev.com/a40526be5a2d1307fdb760587bcb743275054d66/client/site_tests/video_ChromeRTCHWEncodeUsed/control

Assigning to hiroh@ who's been looking into this issue. Thank you.

I bisected and found crrev.com/c/1323089 is culprit.
The CL breaks v4l2_ioctl on at least minnie (perhaps widely Chrome OS).
assign to phoglund@ and cc others.

If this does not reproduce on all V4L2 devices, this would suggest that there is an issue with v4l2_ioctl, and likely libv4l plugins. If this is not reproducing on kevin, that would suggest an issue with libv4l2 encoder plugin on minnie, that is not present in kevin's plugin?

I think this fails on v4l2_ioctl() for VIDIOC_S_FMT in https://cs.chromium.org/chromium/src/media/gpu/v4l2/v4l2_video_encode_accelerator.cc?l=1068?

Looks like kevin's plugin intercepts S_FMT (https://chromium.googlesource.com/chromiumos/third_party/libv4lplugins/+/master/libv4l-rockchip_v2/libv4l-encplugin-rockchip.c#262), while minnie's does not (https://chromium.googlesource.com/chromiumos/third_party/libv4lplugins/+/master/libv4l-rockchip/libv4l-encplugin-rockchip.c#238).

Could this be a lead?

Can I remove "Restrict-View-Google" label so that tomas.popela@gmail.com is able to view this issue?

Doesn't look like we need to restrict this.

+tomas.poela@gmail.com, who is AUTHORS of the CL.

I still can't access any logs. Can someone paste here the actual error? Or there is no error, but it just started to misbehave? That CL I've done was actually fixing things, because it was only passing the first variadic parameter (and was ignoring the others that were passed to the stub). Could this be a thing that some code now doesn't expect that more parameters are passed to it?

This issue also happens on kevin. So the issue is common when libv4l plugins are used.

Yep, I am investigating the issue. It may be due to the plugin or driver issue.

The test fails because v4l2_ioctl(fd, VIDICO_ENUM_FMT, &v4l2_fmtdesc) is processed properly, so that no pixel format is supported on the device.
In the new below generated code, how are the variadic arguments passed to v4l2_ioctl_ptr?

LIBV4L_PUBLIC int  v4l2_ioctl(int fd, unsigned long int request, ...) {
#define v4l2_ioctl_ptr_variadic(fd, request, ...) v4l2_ioctl_ptr(fd, request, ##__VA_ARGS__)
  return v4l2_ioctl_ptr_variadic(fd, request);
}

It's described in https://chromium-review.googlesource.com/c/chromium/src/+/1323089/2#message-c61213944d107cefdf4a35f407ca860b3fb0f51c and https://chromium-review.googlesource.com/c/chromium/src/+/1323089/2#message-2a07ab7fde31ca216b5313ae4963bb017653cc9e

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cc6ae6a34d49604633b77f030a78a49d8bb89e3d

commit cc6ae6a34d49604633b77f030a78a49d8bb89e3d
Author: Hirokazu Honda <hiroh@chromium.org>
Date: Tue Nov 13 10:27:37 2018

Revert "Add support for variadic arguments in generated stubs"

This reverts commit d27bb5431562964962e8eef4a4374d27290b218d.

Reason for revert: This CL causes HW encoding functionality loss on some Chrome OS devices, minnie and kevin.

Original change's description:
> Add support for variadic arguments in generated stubs
>
> Previously we were using va_list for variadic arguments. The downside
> for this was that only the first value from the variadic argument was
> passed to the original function.
>
> To make it work properly we have to use the __VA_ARGS__ variadic macro
> that was introduces in C99 and is available in all major C/C++
> compilers.
>
> Change-Id: I50652f7348a16214811aaab8af116d78cdb70444
> Reviewed-on: https://chromium-review.googlesource.com/c/1323089
> Reviewed-by: Patrik Höglund <phoglund@chromium.org>
> Reviewed-by: Dirk Pranke <dpranke@chromium.org>
> Commit-Queue: Tomáš Popela <tomas.popela@gmail.com>
> Cr-Commit-Position: refs/heads/master@{#606588}

TBR=phoglund@chromium.org,dpranke@chromium.org,braveyao@chromium.org,brucedawson@chromium.org,tomas.popela@gmail.com

# Not skipping CQ checks because original CL landed > 1 day ago.

Bug:  904586 
Change-Id: I04157ea305decc170d5efd4ba228c92bd4020ef6
Reviewed-on: https://chromium-review.googlesource.com/c/1333013
Commit-Queue: Hirokazu Honda <hiroh@chromium.org>
Reviewed-by: Hirokazu Honda <hiroh@chromium.org>
Cr-Commit-Position: refs/heads/master@{#607545}
[modify] https://crrev.com/cc6ae6a34d49604633b77f030a78a49d8bb89e3d/tools/generate_stubs/generate_stubs.py
[modify] https://crrev.com/cc6ae6a34d49604633b77f030a78a49d8bb89e3d/tools/generate_stubs/generate_stubs_unittest.py

The lastest two runs of veyron_minnie-tot-chrome-pfq-informational are both green, thanks for the fix!

Closing based on stainless results: https://stainless.corp.google.com/search?view=matrix&row=model&col=build&first_date=2018-12-28&last_date=2019-01-03&test=video_ChromeRTCHWEncodeUsed&board=veyron*&exclude_cts=false&exclude_not_run=false&exclude_non_release=true&exclude_au=true&exclude_acts=true&exclude_retried=true&exclude_non_production=false