On Tue, 29 Jan 2019 22:46:15 -0500, Nicolas Dufresne wrote: > Le mercredi 23 janvier 2019 à 15:17 +0100, Michael Tretter a écrit : > > > I have a patch pending that allows an encoder to spread the compressed > > > output over multiple buffers: > > > > > > https://patchwork.linuxtv.org/patch/53536/ > > > > > > I wonder if this encoder would be able to use it. > > > > I don't think that the encoder could use this, because of how the > > PUT_STREAM_BUFFER and the ENCODE_FRAME command are working: The > > ENCODE_FRAME will always write the compressed output to a single buffer. > > > > However, if I stop passing the vb2 buffers to the encoder, use an > > internal buffer pool for the encoder stream buffers and copy the > > compressed buffer from the internal buffers to the vb2 buffers, I can > > spread the output over multiple buffers. That would also allow me, to > > get rid of putting filler nal units in front of the compressed data. > > > > I will try to implement it that way. > > As explained in my previous email, this will break current userspace > expectation, and will force userspace into parsing the following frame > to find the end of it (adding 1 frame latency). > > I have used a lot the vendor driver for this platform and it has always > been able possible to get the frame size right, so this should be > possible here too. The vendor driver estimates the compressed buffer size based on the width, height, chroma mode and bit depth of the stream. The v4l2 currently uses the dimensions for the estimate and adds some margin for the SPS/PPS nals and for the partition table. The driver does not care about the chroma mode and bit depth, yet. A partition table at the end of the buffer contains the start and size of the encoded frame in the encoded buffer after it has been encoded. The vendor driver uses this information later to copy the actual data out of the buffers. Instead of copying, I copy a filler nal into the capture buffer and that's something I would be able to avoid by using internal buffers instead of passing the capture buffers to the VCU. If the buffer size is not sufficient, the VCU will signal an error and the driver should be able to trigger a re-negotiation or do the necessary things to get a larger buffer. However, I didn't test or implement any of this and this should come later. So, yes, getting the frame size right should be possible and that's what the driver in the current state tries to do. Michael > > Nicolas > >
