[wip] Rework backend for Linux 5.14 #38
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This can be used to reduce number of issued ioctls, by setting multiple controls at once. Signed-off-by: Philipp Zabel <[email protected]>
This can be used to query codec mode controls, such as decode mode and start code for h.264. Signed-off-by: Philipp Zabel <[email protected]>
Update to the merged stateless h.264 kernel interface, as of commit
c3adb85745ca ("media: uapi: h264: Get rid of the p0/b0/b1 ref-lists").
Signed-off-by: Philipp Zabel <[email protected]>
Signed-off-by: Philipp Zabel <[email protected]>
Signed-off-by: Philipp Zabel <[email protected]>
If the driver reports that it expects H.264 Annex B start codes, provide them. Signed-off-by: Philipp Zabel <[email protected]>
Signed-off-by: Philipp Zabel <[email protected]>
Signed-off-by: Philipp Zabel <[email protected]>
Signed-off-by: Philipp Zabel <[email protected]>
Signed-off-by: Philipp Zabel <[email protected]>
Signed-off-by: Philipp Zabel <[email protected]>
This commit reworks the codebase so that it builds and functions in Linux 5.14. This comes with the following caveat: - V4L2_PIX_FMT_H264_SLICE is currently hardcoded as the pixel format for all output streams in surface.c . You will need to do some significant refactoring to get it working with the rest of the codecs.
|
@noneucat hi I've tried to use this branch and update locally kernel to 5.14-rc7. I passed -I to 5.14 kernel headers but I'm getting following issue: |
|
@nandra Hmm, I will have to look at what's going on there. In the meanwhile, if an earlier version is OK, this branch at least builds with 5.13.7. |
|
@noneucat how do you build? Using meson or autotools? How do you pass path to 5.14 kernel headers? Thanks. |
|
I fetched 5.14 kernel sources then run and after that I run make: Maybe it's still use old kernel headers? Thanks |
|
Seems to be issue with |
|
I started looking into this tonight because I really want VA-API on my PinePhone. I have done some dirty hacks on my fork with a bunch of printf statements all over the place to track down where the issues occur. When using mpv as documented here: https://xnux.eu/devices/feature/cedrus-pp.html the VAAPI seems to work but the video playback is choppy. With VLC, on the other hand, it fails and reverts to "libplacebo" which seems to just be CPU rendering. I added some printouts and noticed that VLC is calling RequestCreateSurfaces2 with a count of 36 surfaces. It loops through the first 32 buffers just fine, then it errors out. I bypassed the error check just to see if it would initialize successfully in VLC and it does, except with 4 out of 36 buffers being nonexistent the video playback is glitchy and after a second of video or so it turns funny colors and gets garbled. Every once in a while it hits a keyframe and looks good again for a few frames. I then dug through the Linux source code, tracing back from the create buffers call: This calls the VIDIOC_CREATE_BUFS ioctl which seems to ultimately end up here: https://elixir.bootlin.com/linux/latest/source/drivers/media/common/videobuf2/videobuf2-core.c#L903 The line in question is: VB2_MAX_FRAME is 32. I think q->num_buffers is the number of already-existing buffers, which is zero in this case. This means if VLC requests 36 surfaces, the kernel driver seems to create 32 buffers, causing the buffer query to fail once it hits index 32 in RequestCreateSurfaces2: Anyone know why VLC seems to be requesting 36 surfaces? This seems too high from my brief investigation, but I've really never looked into this code before. I looked on the VLC side (VLC git sources): This seems to be calling "vaCreateSurfaces" instead of "vaCreateSurfaces2". The argument list seems to match the "2" version of this function. That said, I hacked the vtable to set both "vaCreateSurfaces" and "vaCreateSurfaces2" to point to RequestCreateSurfaces2 and yet it didn't change the behavior, still requesting 36 surfaces and erroring (or displaying corrupt video). |
|
This is the log with the latest commit on my fork. It "succeeds" because I commented out some of the return value checks that would've returned an error status. |
|
Should your fork also work with 5.15 @noneucat ? Its not building for me with Linux 5.15.23: |
In the VIDIOC_CREATE_BUFS ioctl description: So v4l2_create_buffers return success, but it create only 32 buffers instead of 36. |
|
It doesn't work with Linux 5.17.5-2 any more :( |
|
I tried to update just the mpeg2 portions of the code to 5.15+ headers (stubbing out h264 and hevc) since it seemed fairly straightforward, but maybe I was a bit too optimistic because it doesn't seem to work with mpv, this is what I get:
This apparently originates from the v4l2_set_format function, but I'm not sure what |
|
@Zapeth is there any chance you're using selinux in enforce mode? |
|
Not to my knowledge, no (I'm using a Pinephone with plasma-mobile on postmarketOS stable). Though a get format request seems to work, |
|
After some more troubleshooting I figured out what the issue is. Unfortunately I don't think its something that can be fixed in just the libva-v4l2-request code. but I'll write it here anyways in case someone wants to move this forward: The current code of the cedrus driver in the kernel has this constraint: torvalds/linux@8c60827#diff-79ca51b85b54b005649c31a334cc85c637aeea052cfca9cbf673869b6e66bdc2R317-R324 As written in the marked comment, this basically means that format changes to And this is exactly what happens on the mpv->ffmpeg side of things here, which boils down to the following calls to the v4l2-request backend:
As I said, I don't think this is fixable in just the libva-v4l2-request code (unless you hardcode the OUTPUT format, which was done in this PR). but if someone wants to pursue this further I'd be happy to give more information. |
|
it works with the new kernel 5.15 ...6.2?????? |
Closed
|
@Zapeth On my side, I've managed libva-v4l2-request to build by:
No runtime tests yet.... |
|
@kwizart Hello, I used your modified lipva-v4l2-request, successfully compiled and installed in kernel version 6.6 After execution, a kernel crash occurred The only picture I was able to capture before the crash was as follows： The log seems to say run hardware decoding, but I don't know how to fix the crash This is the message printed by the serial port at the time of the crash, which looks like a memory crash |
Did you get this get this patch working with Linux 5.14 and mpv? Can you play 4K h264 videos OK? In one of your older posts you said you ran |
Yep in-between, I wasn't able to succeed with runtime tests either using modern kernel (6.6+). |
|
@kwizart |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is intended to fix builds against 5.14, as well as get all decoders into a good working state. It currently builds, but only decodes H.264 video in its current state; however, the fix should be relatively simple (detailed in acbdfb1).
Thanks to @wolfallein, @pH5, and everyone else in #35 for much of the initial work and investigation!