Hi Nicolas, On 2/4/22 22:17, Nicolas Dufresne wrote: > Hi Stanimir, > > I know you were looking for some ways to pass back data post encoding per frame > in V4L2 a while ago, but I think I lost track. I *think* you were looking for a > way to pass back HDR10+ metadata from the decoder. I'm currently trying design a The size of HDR10plus metadata (taken from ffmpeg, ATSC 2094-40) is ~12KB. The other encoder metadata which I want also to have is encoder ROI which depends on the encoding resolution and my calculations shows up that for 8k resolution I need metadata buffer of 272KB (h264) and 68KB for hevc. With the numbers above I want to say that we need some scalable solution for input/output metadata. V4L2 controls are not such solution. My experiments with passing through v4l2 compound control raw data (16/32KB) shows that the copy to/from userspace is interrupted many times which impacts badly performance on higher framerates (>= 460 fps). > a way to pass back SVC encoded frame info (layer(s)_id and references). This itis > somewhat similar, for each frames being encoded I need some information from the > encoder, so I can pass it back to the RTP payloader. This issue was fixed in > AV1, but VP9 is still pretty important. > > On my side, I was thinking that a driver could stack the data per encoded buffer > internally, and update a control state at DQBUF(capture) time. This should not > be racy, as the next update will stay pending till the next DQBUF, but I'm > worried of the overhead and maybe complexity. What is the size of the data you want to pass from kernel to userspace? Even that it is not racy on 60fps, on becoming actual 460fps and beyond it will be. That's why I think v4l2 controls is not an option for the near future. The only clean option (not adding additional complexities in client for synchronization data <-> metadata is to have a metadata buffer attached to data buffer. The other option is a separate video node for metadata but I'm not happy with this - this complicates driver and client implementations. And the third option is to change request API and v4l2 controls framework to deal with dmabuf instead of copy to/from user. > > your feedback would be welcome, > Nicolas -- regards, Stan
