Hi Miguel,

The output frame is actually passed to the IP's client:

https://cs.chromium.org/chromium/src/media/gpu/v4l2/v4l2_image_processor.cc?type=cs&q=DmabufFds%5C(%5C)&sq=package:chromium&g=0&l=711

https://cs.chromium.org/chromium/src/media/gpu/v4l2/v4l2_image_processor.cc?type=cs&q=DmabufFds%5C(%5C)&sq=package:chromium&g=0&l=882

So it is necessary beyond just wrapping the DMA bufs. I think this bug can therefore be closed.

#1: but that's for the output part, right? IIUC, we have sth like:

   v4l2deco --[a]--> image processor --[b]--> output-to-client 

and the one you mention is only [b]. Two things:

- the interchange in [a] wraps the DmaBufs into a videoFrame:
[1] https://cs.chromium.org/chromium/src/media/gpu/v4l2/v4l2_video_decode_accelerator.cc?type=cs&sq=package:chromium&g=0&l=2453
which is kept as the |input_frame| of the |job_record|; 
[2] https://cs.chromium.org/chromium/src/media/gpu/v4l2/v4l2_image_processor.cc?type=cs&q=DmabufFds%5C(%5C)&sq=package:chromium&g=0&l=289
This job record is processed and eventually finished, which
is the code you post:
[3] https://cs.chromium.org/chromium/src/media/gpu/v4l2/v4l2_image_processor.cc?type=cs&q=DmabufFds%5C(%5C)&sq=package:chromium&g=0&l=711
The VideoFrame created in [1] is one of the short lived objects
target of this Issue.

- Regarding [b], "The output frame is actually passed to the IP's client", 
but the VideoDecodeAccelerator::Client doesn't use VideoFrame, it uses
Pictures:
[4] https://cs.chromium.org/chromium/src/media/video/video_decode_accelerator.h?g=0&l=219
hence the callback, if we follow a little bit more to FrameProcessed()
[5] https://cs.chromium.org/chromium/src/media/gpu/v4l2/v4l2_video_decode_accelerator.cc?type=cs&sq=package:chromium&g=0&l=2664
the |frame| goes unused ! Because we need to create a Picture etc

So none of the interchanges [a] or [b] really need VideoFrames, and
the wrapper could be removed...

Ah, I should also mentioned that the V4L2 encoder also makes use of the image processor:

https://cs.chromium.org/chromium/src/media/gpu/v4l2/v4l2_video_encode_accelerator.cc?q=v4l2_video_encode&sq=package:chromium&g=0&l=285

In this case, the VideoFrame that is used as ImageProcessor's input is backed by user-allocated memory. That's why using VideoFrame is useful, it allows us to abstract the backing storage. As you can see the V4L2 IP has code to manage both cases:

https://cs.chromium.org/chromium/src/media/gpu/v4l2/v4l2_image_processor.cc?sq=package:chromium&g=0&l=751

We are also about to merge non-V4L2 implementations of the ImageProcessor interface, some of which do not produce DMA-BUF backed output buffers. This makes it all the more useful to use VideoFrame for both input and output of this interface.