Hi Boris, On Wed, Jun 19, 2019 at 9:15 PM Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx> wrote: [snip] > @@ -533,10 +535,21 @@ hantro_queue_setup(struct vb2_queue *vq, unsigned int *num_buffers, > return -EINVAL; > } > > + /* The H264 decoder needs extra size on the output buffer. */ > + if (ctx->vpu_src_fmt->fourcc == V4L2_PIX_FMT_H264_SLICE_RAW) > + extra_size0 = 128 * DIV_ROUND_UP(pixfmt->width, 16) * > + DIV_ROUND_UP(pixfmt->height, 16); > + I wonder if this shouldn't be accounted for already in the sizeimage returned by TRY_/S_FMT, so that the application can know the required buffer size if it uses some external allocator and DMABUF memory type. I know we had it like this in our downstream code, but it wasn't the problem because we use minigbm, where we explicitly add the same padding in the rockchip backend. Any thoughts? Best regards, Tomasz
