-
Notifications
You must be signed in to change notification settings - Fork 200
chromium: Add v4l2 m2m stateless decode configuration options #864
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
@@ -109,7 +109,7 @@ BUILD_CC:toolchain-clang = "clang" | |||
BUILD_CXX:toolchain-clang = "clang++" | |||
BUILD_LD:toolchain-clang = "clang" | |||
|
|||
PACKAGECONFIG ??= "upower use-egl" | |||
PACKAGECONFIG ??= "upower use-egl use-v4l2" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Personally, I believe that you could add the UDEV rules together with the support, so this works out of box whenever someone enables it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@otavio those udev rules should be in BSP layer (temporarily, read on ...), since they are SoC specific and this layer cannot predict what the BSP layers are doing with udev rules.
There is already an ongoing work in chromium upstream to use the proper /dev/videoN
and /dev/mediaN
nodes , I think that is going to land in chromium 132 or 133 , at which point the udev rules won't be needed at all.
So no, I don't think this layer should be adding any udev rules. The udev rules in the commit message are an example for one specific SoC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree it usually fits in the BSP layer. Since it's harmless, adding the rules for other processors, too, could be a great idea. We can install them without any conditions. They won't have any impact if used with a different processor so that it wouldn't cause any issues.
Also, I appreciate your argument about using proper device names and how those rules may not be needed shortly. That's another good reason why this might be a better fit here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@marex we are now at 132.0.6834.83, I wonder if we should land this PR now
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kraj I think yes , I already rebased it last month and dropped the udev rules part .
Add configuration options to enable hardware video decoding using stateless V4L2 M2M device. This allows offloading e.g. h264 video playback to Hantro VPU on i.MX8MP where this was tested. To make that work, enable 'use-v4l2' and 'proprietary-codecs' PACKAGECONFIG. This commit was implemented with much great help from Jianfeng Liu . Signed-off-by: Marek Vasut <[email protected]>
Add configuration options to enable hardware video decoding using stateless V4L2 M2M device. This allows offloading e.g. h264 video playback to Hantro VPU on i.MX8MP where this was tested. To make that work, enable
use-v4l2
andproprietary-codecs
PACKAGECONFIG.For i.MX8MP the following additional udev rules are mandatory:
This commit was implemented with much great help from Jianfeng Liu .