HACK: Route v4l2m2m codecs to rkmpp via ENV variable #6
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.
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 #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.