[PR #6] [CLOSED] HACK: Route v4l2m2m codecs to rkmpp via ENV variable #234

New issue

Closed

opened 2025-12-23 10:36:31 +01:00 by backuprepo · 0 comments

backuprepo commented

2025-12-23 10:36:31 +01:00

Owner

📋 Pull Request Information

Original PR: https://github.com/nyanmisaka/ffmpeg-rockchip/pull/6
Author: @hbiyik
Created: 1/10/2024
Status: ❌ Closed

Base: master ← Head: ffmpeg-rockchip-v4l2m2m-routing

📝 Commits (1)

ef5fb26 HACK: Route v4l2m2m codecs to rkmpp via ENV variable

📊 Changes

1 file changed (+22 additions, -0 deletions)

View changed files

📝 libavcodec/allcodecs.c (+22 -0)

📄 Description

So this allows firefox (or any other app user v4l2m2m with ffmpeg, vlc?) to import DRMPrime frames from rkmpp* decoders/encoders directly. So it is kind of 0 copy for the browser which is very cool.

I am not proud of the hack since it is in the middle of ffmpeg code but it works. May be there is cleaner way to do this.

How this works: Firefox has enabled v4l2m2m support for raspberry pi, and it uses ffmpeg to communicate with V4l2 interface, Firefox does not ioctl itself, instead just imports the AVCodec, but initially it executes a binary called v4l2test to query capabilites of a target device. With the env flag FFMPEG_RKMPP_DEC_V4L2M2M=1 ffmpeg routes the v4l2 encoders or decoder to rkmpp variants, and with PR https://github.com/nyanmisaka/ffmpeg-rockchip/pull/1 RKMPP codecs provide the DRMPRime frames with HwFramesContext, they do not need to initialized with AVdevice or v4l2device at all. So rkmpp decoders/encoders act as v4l2m2m av codecs.

How to test:

Make sure you have a /dev/video[n] device, it does not matter what it is, it is only needed for firefox to be fooled.
Compile the ffmpeg from here . Basically it is this repo with PRs merged.
Download firefox >=116, make sure it is linked against ffmpeg 6.1. (Normally firefox has a wrapper around different versions of ffmpeg but just dont risk it).
Replace the /usr/lib/firefox/v4l2test with below python script. You can do the same with shell as well. It would be a good idea to backup the original v4l2testbinary. This is how we fool the FF that there is actually a v4l2m2m device where there is not

#!/usr/bin/python
import sys

print(f"RKMPP Routing v4l2m2m to mpp with args {sys.argv[1:]}", file=sys.stderr)
print("V4L2_SUPPORTED", file=sys.stdout)
print("TRUE", file=sys.stdout)
print("V4L2_CAPTURE_FMTS", file=sys.stdout)
print("NV12", file=sys.stdout)
print("V4L2_OUTPUT_FMTS", file=sys.stdout)
print("H264 VP9 AV1 HEVC", file=sys.stdout)

Launch the firefox with RDD security sandbox disabled, v4l2 routed to mpp as below.

MOZ_DISABLE_RDD_SANDBOX=1 FFMPEG_RKMPP_DEC_V4L2M2M=1 firefox

Currently only h264 seems to be allowed with that flow, there seems to be VP9 hevc and AV1 or other codecs support but it seems they are blocked somewhere (some config value?). I think this can be tackled somehow and we can have a fully functional browser with HW Decoding / Encoding Enabled.

Above SS is a H264 1080p@60 SS from twitch, there seems to be an offset issue somewhere, see above color displacement, again this can also be tackled.

I am sending this PR not to be merged actually it is quite ugly, but to show the benefits of mainlining, If at least the decoder and encoder of this codec would be mainlined, we could easily PR the firefox to enable other codecs through some configs. Just wanted to show the potential here.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/nyanmisaka/ffmpeg-rockchip/pull/6 **Author:** [@hbiyik](https://github.com/hbiyik) **Created:** 1/10/2024 **Status:** ❌ Closed **Base:** `master` ← **Head:** `ffmpeg-rockchip-v4l2m2m-routing` --- ### 📝 Commits (1) - [`ef5fb26`](https://github.com/nyanmisaka/ffmpeg-rockchip/commit/ef5fb2699d0362ac70e82e5c2527d2a097ad3076) HACK: Route v4l2m2m codecs to rkmpp via ENV variable ### 📊 Changes **1 file changed** (+22 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `libavcodec/allcodecs.c` (+22 -0) </details> ### 📄 Description ![Screenshot from 2024-01-10 22-27-17](https://github.com/nyanmisaka/ffmpeg-rockchip/assets/24766436/ce38a3c7-4af5-4f1f-b126-39dfd054669d) ![Screenshot from 2024-01-10 22-27-30](https://github.com/nyanmisaka/ffmpeg-rockchip/assets/24766436/7249e4e0-7ae0-4e9a-b38e-8e629e60020d) So this allows firefox (or any other app user v4l2m2m with ffmpeg, vlc?) to import DRMPrime frames from rkmpp* decoders/encoders directly. So it is kind of 0 copy for the browser which is very cool. I am not proud of the hack since it is in the middle of ffmpeg code but it works. May be there is cleaner way to do this. How this works: Firefox has enabled v4l2m2m support for raspberry pi, and it uses ffmpeg to communicate with V4l2 interface, Firefox does not ioctl itself, instead just imports the AVCodec, but initially it executes a binary called `v4l2test` to query capabilites of a target device. With the env flag `FFMPEG_RKMPP_DEC_V4L2M2M=1` ffmpeg routes the v4l2 encoders or decoder to rkmpp variants, and with PR https://github.com/nyanmisaka/ffmpeg-rockchip/pull/1 RKMPP codecs provide the DRMPRime frames with HwFramesContext, they do not need to initialized with AVdevice or v4l2device at all. So rkmpp decoders/encoders act as v4l2m2m av codecs. How to test: - Make sure you have a `/dev/video[n]` device, it does not matter what it is, it is only needed for firefox to be fooled. - Compile the ffmpeg from [here ](https://github.com/hbiyik/ffmpeg-rockchip). Basically it is this repo with PRs merged. - Download firefox >=116, make sure it is linked against ffmpeg 6.1. (Normally firefox has a wrapper around different versions of ffmpeg but just dont risk it). - Replace the `/usr/lib/firefox/v4l2test` with below python script. You can do the same with shell as well. It would be a good idea to backup the original `v4l2test`binary. This is how we fool the FF that there is actually a v4l2m2m device where there is not ```python #!/usr/bin/python import sys print(f"RKMPP Routing v4l2m2m to mpp with args {sys.argv[1:]}", file=sys.stderr) print("V4L2_SUPPORTED", file=sys.stdout) print("TRUE", file=sys.stdout) print("V4L2_CAPTURE_FMTS", file=sys.stdout) print("NV12", file=sys.stdout) print("V4L2_OUTPUT_FMTS", file=sys.stdout) print("H264 VP9 AV1 HEVC", file=sys.stdout) ``` Launch the firefox with RDD security sandbox disabled, v4l2 routed to mpp as below. `MOZ_DISABLE_RDD_SANDBOX=1 FFMPEG_RKMPP_DEC_V4L2M2M=1 firefox` Currently only h264 seems to be allowed with that flow, there seems to be VP9 hevc and AV1 or other codecs support but it seems they are blocked somewhere (some config value?). I think this can be tackled somehow and we can have a fully functional browser with HW Decoding / Encoding Enabled. Above SS is a H264 1080p@60 SS from twitch, there seems to be an offset issue somewhere, see above color displacement, again this can also be tackled. I am sending this PR not to be merged actually it is quite ugly, but to show the benefits of mainlining, If at least the decoder and encoder of this codec would be mainlined, we could easily PR the firefox to enable other codecs through some configs. Just wanted to show the potential here. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>