Sent from my iPad > On Mar 1, 2019, at 12:21 AM, Nicolas Dufresne <nicolas@xxxxxxxxxxxx> wrote: > > Le jeudi 28 février 2019 à 09:12 +0800, Ayaka a écrit : >>> On Feb 28, 2019, at 5:07 AM, Nicolas Dufresne <nicolas@xxxxxxxxxxxx> wrote: >>> >>> Hi Ayaka, >>> >>>> Le mercredi 27 février 2019 à 23:13 +0800, Ayaka a écrit : >>>> Last time in FOSDEM, kwiboo and I talk some problems of the request >>>> API and stateless decoder, I say the a method to describe a buffer >>>> with many offsets as the buffer meta data would solve the most of >>>> problems we talked, but I have no idea on how to implement it. And I >>>> think a buffer meta describing a buffer with many offsets would solve >>>> this problem as well. >>> >>> for single allocation case, the only supported in-between plane padding >>> is an evenly distributed padding. This padding is communicated to >>> userspace through S_FMT, by extending the width and height. Userspace >>> then reads the display width/height through G_SELECTION API. >> It can solve the partly problem, it is hard to use only width and height to describe a buffer. For hevc and rkvdec decoder in 128bytes mode, it is aligned with 128 bytes plus 128bytes. Sometimes, the padding data may. just less than a component. In that case, only offset would solve this problem. >>> For anything else, the MPLANE structure with one of the multi-plane >>> format can "express" such buffer, though from userspace they are >>> exposed as two memory pointer or DMABuf FDs (which make importation >> The video output(VOP) supports two address for luma and chroma and the new generation of rkvdec supports that as well. But for the general situation, we should think we can only set one DMA address to the device. >>> complicated if the buffer should initially be within a single >>> allocation). I'll leave to kernel dev the task to explain what is >>> feasible there (e.g. sub-buffering, etc.) >> I think it can use the same fd but with a different data_offset in struct v4l2_plane(with a larger number of byteused in the second plane). > > I think Hans said there is problem (something against the spec) in > using data_offset that way. The GStreamer implementation assumes that, > but got told recently that this might not be correct. I'd like Hans to > comment, since I haven't understood the reason yet. > >> >> If I can find a solution to solve this problem, it would be hard to future develop on the stateless media device. Please help on this problem. > > I don't think this is specific to state less CODEC. While more complex, > when dealing with CMA, the kernel can do that math to figure-out if two > memory pointers are from the same allocation. It quite easy if you know > in advance the spacing. > I check only the s5p-mfc use CMA only in media. Also there are two register for the luma and chroma start address. Which is different to the current problem in rockchip platform. > Without being identical, the framework does similar things when trying > to import USERPTR in a CMA based V4L2 driver. > >>> Nicolas >>>
