[vlc-devel] Software decoding in Hardware buffers
jc at kynesim.co.uk
Thu Aug 8 14:55:10 CEST 2019
>I'm looking at the display pool in the MMAL (Raspberry Pi) code and it
>seems that we currently decode in "hardware" buffers all the time.
>Either the opaque decoder output, or when the decoder outputs I420.
>In push we don't to use this pool anymore. The decoder will have its own
>pool and the display just deals with what it receives. In most cases
>that means copy from CPU memory to GPU memory. This doesn't work with a
>SoC like on the Raspberry Pi where the memory is the same and can be
>used directly from both sides.
>The idea was that current decoders continue to use decoder_NewPicture()
>as they used to. The pictures will come from the decoder video context,
>if there's one (hardware decoding) or from picture_NewFromFormat() if
>there's none. That means for MMAL we would need to copy this CPU
>allocated memory to the "port allocated" memory (the mechanism to get
>buffers from the display). Given the limited resources that's something
>we should avoid.
>I think we should have a third way to provide pictures: from the decoder
>device. In case of software decoding there is no video context, but
>there is a decoder device (A MMAL one in this case).
>So I suggests the decoders (and filters) get their output picture from:
>- the video context if there is one
>- the decoder device if there is one and it has an allocator
>- picture_NewFromFormat() otherwise
>Any opinion ?
I'm sure I should have an opinion (though I'm not quite sure what it is)
as I've get a substantial rewrite of the entire mmal/Pi modules here,
which I intended to upstream when it was a bit closer to finished (it is
currently in use as the default shipped with Pis but there is still work
to be done before I want it set in anything like stone).
There are a number of buffer types that I now pass around - all
currently declared as h/w though some have a plausible existance in CPU
memory (though not all). All end up as having their actual allocation
done at source (decoder or filter) though the picture_t is allocated by
More information about the vlc-devel