Hi, > > However that still doesn't let the driver know which buffers will be > > dequeued when. A simple example of this scenario is when the guest is > > done displaying a frame and requeues the buffer back to the decoder. > > Then the decoder will not choose it for decoding next frames into as > > long as the frame in that buffer is still used as a reference frame, > > even if one sends the drain request. > It might be that I'm getting your point wrong, but do you mean some hardware > can mark a buffer as ready to be displayed yet still using the underlying > memory to decode other frames? Yes, this is how I understand Tomasz Figa. > This means, if you occasionally/intentionally > write to the buffer you mess up the whole decoding pipeline. And to avoid this the buffer handling aspect must be clarified in the specification. Is the device allowed to continue using the buffer after finishing decoding and completing the queue request? If so, how do we hand over buffer ownership back to the driver so it can free the pages? drain request? How do we handle re-using buffers? Can the driver simply re-queue them and expect the device figures by itself whenever it can use the buffer or whenever it is still needed as reference frame? cheers, Gerd
