On Wed, Jan 30, 2019 at 12:46 PM Nicolas Dufresne <nicolas@xxxxxxxxxxxx> 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 don't think you would need to do any parsing to detect it. I think the assumption that a buffer only contains 1 frame would still hold. An extra buffer would be used for the remaining part of the current frame and then we would take another buffer for the next frame. Still, I also recall that we assumed that we have 1 buffer per 1 frame for encoders, so indeed it could break some apps. At least it needs some careful analysis, if we want to change it. > > 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. > > Nicolas >
