Chrome Working On JPEG Encode Accelerator With VA-API/V4L2 Support

[microcode]

...the V4L2 code is using a lot of extensions and API not present in any Linux distro.

Could you elaborate on that? Is the associated kernel code not intended to be upstreamed? That doesn't seem like a very Google thing, or generally very practical.

[Ardje]

Well, it is not compatible. We can activate the VAAPI acceleration in Chromium, but the V4L2 code is using a lot of extensions and API not present in any Linux distro.

I don't know vaapi, as it is only for a very select set of systems.
But I know a lot of v4l2. m2m has been long part of the v4l2 subsystem, largely introduced by samsung for their range of encoders and decoders.
Among them is jpg encoder, decoder, scalers, rotaters, colorspace converters, h26[345] encoders and decoders, vp8 and vp9, and a lot more with off course zero-copy support.
But these are all standard in the linux kernel, and for a few years already.
So what did google need more than what was already widely available? Are they extending v4l2 m2m?
On another note, userspace support from standaard libraries like ffmpeg and gstreamer has been lagging. I know samsung put an effort into getting a chromium build with gstreamer support so that it can use hardware accelerated decoding.

[carewolf]

Could you elaborate on that? Is the associated kernel code not intended to be upstreamed? That doesn't seem like a very Google thing, or generally very practical.

I don't know the specifics of that. A little over a year ago I wrote a few patches enabling hardware accelerated decoding on Linux in our Chromium based project. Enabling the VAAPI part was easy, but when trying to enable V4L2 based accelerators I ran into many symbols and functions not available by my upto-date v4l2 headers. When I googled these missing symbols, the only hits on google was the call-sites in Chromium. That is to say that nowhere indexed by Google were these symbols defined. I took that to mean they were entirely proprietary and not open source.

Ofcourse they could have upstreamed it in the meantime. But so far all other projects doing the same as I did (enabling hardware accelerated decoding) has also stuck to the VAAPI parts, and not touched the V4L2 parts.

[microcode]

I took that to mean they were entirely proprietary and not open source.

Well, that would be a violation of the GPL. If it's not in the upstream kernel, it's probably in the google downstream kernels. Check out those kernels if you want to find it.

[carewolf]

Well, that would be a violation of the GPL. If it's not in the upstream kernel, it's probably in the google downstream kernels. Check out those kernels if you want to find it.

If they were public their repositories would likely be indexed by Google. In theory Google just has to send the source code to owners of a ChromeOS products, since I don't own one I can't demand the sources. Plus I am SURE they mean to upstream it, they might just have gotten around to it yet... (That is how Apple gets around violating the LGPL of WebKit).

[microcode]

If they were public their repositories would likely be indexed by Google. In theory Google just has to send the source code to owners of a ChromeOS products, since I don't own one I can't demand the sources. Plus I am SURE they mean to upstream it, they might just have gotten around to it yet... (That is how Apple gets around violating the LGPL of WebKit).

They literally have a whole website for publishing the full sources for every open source package on the Chromebook. Stop jerking yourself off and actually check things before saying them.
https://chromium.googlesource.com/ << This website has all the stuff, scanner drivers, mesa, and crucially: the kernels for every Chromebook.
https://chromium.googlesource.com/ch...y/kernel/+refs << Here you see a repo with all the stable kernel branches for every Chromebook. For example, I'm typing this on an Acer C720P (codename peppy) so the branch that they probably ship for ChromeOS on it is https://chromium.googlesource.com/ch...o_peppy-4389.B

Incidentally, this website also has the source code for all of the boot firmware for every Chromebook, and the whole source code of the browser (including the bits that integrate with plugins).

No vendor is perfect, but Google is at least better than all other vendors, and they make an effort (because in the case of Chromebooks, openness is good for business).

[carewolf]

They literally have a whole website for publishing the full sources for every open source package on the Chromebook. Stop jerking yourself off and actually check things before saying them.
https://chromium.googlesource.com/ << This website has all the stuff, scanner drivers, mesa, and crucially: the kernels for every Chromebook.
https://chromium.googlesource.com/ch...y/kernel/+refs << Here you see a repo with all the stable kernel branches for every Chromebook. For example, I'm typing this on an Acer C720P (codename peppy) so the branch that they probably ship for ChromeOS on it is https://chromium.googlesource.com/ch...o_peppy-4389.B

Incidentally, this website also has the source code for all of the boot firmware for every Chromebook, and the whole source code of the browser (including the bits that integrate with plugins).

No vendor is perfect, but Google is at least better than all other vendors, and they make an effort (because in the case of Chromebooks, openness is good for business).

Okay, then tell me where in https://chromium.googlesource.com/ch...ux/videodev2.h the symbols V4L2_PIX_FMT_MT21, V4L2_PIX_FMT_H264_SLICE, V4L2_PIX_FMT_VP8_FRAME, V4L2_PIX_FMT_VP9_FRAME and DRM_FORMAT_MT21 are defined?

I admit it is fewer missing symbols than it used to be, so they will probably appear in a release soon, but they are still not indexed by google, and not found in latest chromeOS sources. So they have probably always been using unreleased headers without bothering with backwards compatibility in Chromium, but that generally just makes it hard to use for people not on the Google's internal HEAD of ChromeOS, or not using ChromeOS.

[microcode]

Okay, then tell me where in https://chromium.googlesource.com/ch...ux/videodev2.h the symbols V4L2_PIX_FMT_MT21, V4L2_PIX_FMT_H264_SLICE, V4L2_PIX_FMT_VP8_FRAME, V4L2_PIX_FMT_VP9_FRAME and DRM_FORMAT_MT21 are defined?

I admit it is fewer missing symbols than it used to be, so they will probably appear in a release soon, but they are still not indexed by google, and not found in latest chromeOS sources. So they have probably always been using unreleased headers without bothering with backwards compatibility in Chromium, but that generally just makes it hard to use for people not on the Google's internal HEAD of ChromeOS, or not using ChromeOS.

V4L2_PIX_FMT_H264_SLICE is probably in a Rockchip-specific (Veyron?) kernel branch, if anywhere. Very weird that they reference the symbols there.

[microcode]

Okay, then tell me where in https://chromium.googlesource.com/ch...ux/videodev2.h the symbols V4L2_PIX_FMT_MT21, V4L2_PIX_FMT_H264_SLICE, V4L2_PIX_FMT_VP8_FRAME, V4L2_PIX_FMT_VP9_FRAME and DRM_FORMAT_MT21 are defined?

I admit it is fewer missing symbols than it used to be, so they will probably appear in a release soon, but they are still not indexed by google, and not found in latest chromeOS sources. So they have probably always been using unreleased headers without bothering with backwards compatibility in Chromium, but that generally just makes it hard to use for people not on the Google's internal HEAD of ChromeOS, or not using ChromeOS.

Found it: https://chromium.googlesource.com/ch...ideodev2.h#419
It's currently specific to that rockchip chipset which apparently hasn't seen a Chrome OS device since 2014.

[microcode]

Okay, then tell me where in https://chromium.googlesource.com/ch...ux/videodev2.h the symbols V4L2_PIX_FMT_MT21, V4L2_PIX_FMT_H264_SLICE, V4L2_PIX_FMT_VP8_FRAME, V4L2_PIX_FMT_VP9_FRAME and DRM_FORMAT_MT21 are defined?

I admit it is fewer missing symbols than it used to be, so they will probably appear in a release soon, but they are still not indexed by google, and not found in latest chromeOS sources. So they have probably always been using unreleased headers without bothering with backwards compatibility in Chromium, but that generally just makes it hard to use for people not on the Google's internal HEAD of ChromeOS, or not using ChromeOS.

It's too bad that Google shut down their public codesearch node, but it is actively developed, and you can set up your own node (If you have enough disk space and RAM). A public instance of this probably costs tens of thousands of dollars a month to operate, so I can see why they weren't so keen.

https://chromium.googlesource.com/chromium/codesearch/