Half the battle is understanding what the V4L2 controls are meant to be set to, and how that maps onto the MMAL encoder.
I'm reading the V4L2 spec such that:
- V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD set to 0 means refresh the complete frame in one I-frame.
- If V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD is non-zero, then the refresh is split over that many frames, based on the algorithm specified in V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD_TYPE.
- Alternatively if V4L2_CID_MPEG_VIDEO_INTRA_REFRESH_PERIOD is 0, then V4L2_CID_MPEG_VIDEO_CYCLIC_INTRA_REFRESH_MB can be set to configure a number of macroblocks to be updated every frame.
The last option I believe can be supported, but needs some consideration as I believe the firmware will work in macroblock rows, and not just macroblocks.
Note that MMAL_PARAMETER_VIDEO_INTRA_REFRESH takes a MMAL_PARAMETER_VIDEO_INTRA_REFRESH_T, not just a single int. I thought we'd been through and added validation of set_parameter struct sizes to all components way back, but that doesn't appear to be the case with video_encode. You're likely to be trying to start the codec with either the vchiq_mmal_port_parameter_set call failing, or the validation failing when the codec is being started.
I think understanding the exact definitions from V4l2 which type of intra refresh is nice but not exactly needed (In the end, those things are hw specific, and in my opinion, not possible to set vendor agnostic).
What I am wondering right now is how I can pass a message of type MMAL_PARAMETER_VIDEO_INTRA_REFRESH_T to mmal in the inux v4l2 driver if neither the struct is defined somewhere and the function definition for mmal_port_parameter_set is also slightly different (single param). Can you help me in this regard ?
Statistics: Posted by Consti10^100 — Wed Jan 24, 2024 3:55 pm