[vlc-devel] Software decoding in Hardware buffers

[Thomas Guillem]

On Thu, Aug 8, 2019, at 15:14, John Cox wrote:
> Hi
> 
> >Hi,
> >
> >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
> the "display"

Wow,  that is great.
So maybe we should not port the actual MMAL code to the push model, disable the module, and wait for your contribution that will be lot easier to port.

> 
> Regards
> 
> JC
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel