-
Notifications
You must be signed in to change notification settings - Fork 8.1k
video: introduction of STM32 VENC driver for H264 hardware video compression #92884
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
video: introduction of STM32 VENC driver for H264 hardware video compression #92884
Conversation
|
The following west manifest projects have changed revision in this Pull Request:
✅ All manifest checks OK Note: This message is automatically posted and updated by the Manifest GitHub Action. |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for preparing VENC!
This will really make video over network on Zephyr interesting.
It seems like Zephyr lacks a few APIs from Linux (no H.264 format definition, no planar API for NV12...), so if anything feels like missing, let us know so that the missing API can be provided in parallel.
No specific processing is necessary currently as part of the stm32_dcmipp_isp_start function hence remove the assert(0) currently preventing stop of the isp. Signed-off-by: Alain Volmat <[email protected]>
Allow to call HAL_DCMIPP_PIPE_SetConfig when the pipe state is READY. Currently it is only possible to use this function if the pipe state is RESET and ERROR states. Indeed, it is possible to reconfigure the PIPE as soon as the pipe is not currently being used, aka in the READY state. With that done, it becomes possible to change the PIPE configuration between two use-cases without having to DeInit / Init the HAL_DCMIPP or use the unitary pixel packer functions. Signed-off-by: Alain Volmat <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
First round of comment, driver aside.
Please split the PR and do a specific PR for the first commits that are not directly linked to the VENC driver. These can be reviewed and integrated faster.
For the changes on the sample, I let video team decide if this should be kept within the tcpserver sample or split into a different sample
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some pending comments, not sure why they were missing
a32b1da to
deac1fb
Compare
|
@josuah all is OK including CI build, could you approve and remove DNM label ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Quoting #92884 (comment)
Otherwise, I can make an enhancement commit and rebase #97197 if this one is merged first.
So looks like everybody is aligned on merging this now.
|
Everybody is rushing for the release, so CI seems pretty busy and "PR Metadata Check / Preventing Merging (pull_request)" job will start in a few minutes. [EDIT: it's https://www.githubstatus.com/ is orange] |
d1a963b
Add H264 pixel format support. Signed-off-by: Mohammad Massoudi <[email protected]>
Add size field to the video_format structure which needs to be set by the driver and exposed to the application. For uncompressed formats, this is the size of the raw data buffer in bytes, which could be the whole raw image or a portion of the raw image in cases the receiver / dma supports it. For compressed formats, this is the estimated maximum number of bytes required to hold a complete compressed frame. Signed-off-by: Hugues Fruchet <[email protected]> Signed-off-by: Phi Bang Nguyen <[email protected]>
Document introduction of the new size field inside video_format struct as visible on the <zephyr/drivers/video.h> header. Signed-off-by: Hugues Fruchet <[email protected]>
Addition of description for the STM32 Video encoder (VENC). Signed-off-by: Hugues Fruchet <[email protected]>
The STM32 video encoder (VENC) peripheral is a hardware accelerator allowing to compress RGB/YUV frames into H264 video bitstream chunks. Signed-off-by: Hugues Fruchet <[email protected]>
Add node describing the venc in stm32n6.dtsi Signed-off-by: Hugues Fruchet <[email protected]>
Required to build VIDEO_STM32_VENC. Signed-off-by: Erwan Gouriou <[email protected]> Signed-off-by: Hugues Fruchet <[email protected]>
d1a963b to
4907906
Compare
|
Rebased on main to fix merge conflict in doc/releases/release-notes-4.3.rst |
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the late nitpicking comments, none are blocking. I'm fine getting the current series merged.



This PR introduces H264 hardware video compression thanks to VENC peripheral of STM32N6.
A new stm32 video encoder driver has been introduced which relies on vc8000nanoe software stack [1].
This is a first basic porting to enable H264 encoding use-case.
RAM memory resources required by VENC encoding process are allocated in external PSRAM, camera frames
captured by DCMIPP and encoded by VENC are also allocated in external PSRAM.
The video encoder driver currently lack of controls to configure the encoding process, default configuration
targets H264 1080p 2Mb/s constant bitrate.
In order to test, the tcpserversink video sample has been enhanced to support video compression in order to stream small H264 compressed video chunks instead of big raw uncompressed images [2].
[1] zephyrproject-rtos/hal_stm32#295
[2] #95862