Re: [PATCH v2 2/3] [media] allegro: add Allegro DVT video IP core driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> 
> 



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]

  Powered by Linux