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
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.
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 flagFFMPEG_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:
/dev/video[n]
device, it does not matter what it is, it is only needed for firefox to be fooled./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 originalv4l2test
binary. This is how we fool the FF that there is actually a v4l2m2m device where there is notLaunch 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.