Le mercredi 23 janvier 2019 à 19:02 +0900, Tomasz Figa a écrit : > On Sun, Nov 18, 2018 at 10:34 AM Nicolas Dufresne <nico...@ndufresne.ca> > wrote: > > Le samedi 17 novembre 2018 à 12:37 +0100, Hans Verkuil a écrit : > > > > > Does V4L2_CID_MIN_BUFFERS_FOR_CAPTURE make any sense for encoders? > > > > > > > > We do account for it in GStreamer (the capture/output handling is > > > > generic), but I don't know if it's being used anywhere. > > > > > > Do you use this value directly for REQBUFS, or do you use it as the > > > minimum > > > value but in practice use more buffers? > > > > We add more buffers to that value. We assume this value is what will be > > held by the driver, hence without adding some buffers, the driver would > > go idle as soon as one is dequeued. We also need to allocate for the > > importing driver. > > > > In general, if we have a pipeline with Driver A sending to Driver B, > > both driver will require a certain amount of buffers to operate. E.g. > > with DRM display, the driver will hold on 1 buffer (the scannout > > buffer). > > > > In GStreamer, it's implemented generically, so we do: > > > > MIN_BUFFERS_FOR + remote_min + 1 > > > > If only MIN_BUFFERS_FOR was allocated, ignoring remote driver > > requirement, the streaming will likely get stuck. > > What happens if the driver doesn't report it?
If the driver does not report it because it does not use it (I think CODA decoder is like that), there is no issue. If the driver do not report but needs extra, the driver will end up growing count in REQBUFS, so the end result will be under-allocation since the remote requirement won't be accounted. Streaming will hang. A good example is transcoding, you encoder will never have enough frames to reproduce an output, because the decoder is waiting for his frame to come back. Only solution to that would be a memcpy(), or double allocation (redoing REQBUFS later on). The MIN_BUFFERS_FOR announcement is the optimal way, avoiding copies and allocating twice. > > Best regards, > Tomasz
