[vlc-devel] [RFC 0/1] Let decoders decide over DPB size.

[Martin Storsjö]

On Fri, 23 Aug 2013, Rémi Denis-Courmont wrote:

> Le vendredi 23 août 2013 17:38:45 Julian Scheel a écrit :
>
>> Doing this on a embedded system with few
>> memory being available this is likely to fail for high resolution videos.
>
> I disagree. If you cannot allocate as many and as large buffers as the decoder 
> requires, then fundamentally, you cannot decode the video. Period.
>
> If you want to allocate the memory from the GPU, you can do that in the video 
> output. Since the VDPAU patchset, you can also do that from the decoder, on 
> condition that the memory is not mapped on the CPU.
>
>> While working with the omx modules I ran into this problem on Tegra 2 as
>> well as Raspberry Pi platforms, because both did not have enough memory to
>> store 24 or more full 1080p frames in the GPU memory. But as they do not
>> require the dpb to be stored in the picture pool, but deal with it
>> internally it is in fact possible to remove the dpb_size form the picture
>> pool and run with a much smaller picture pool without any issues.
>
> I believe that is a problem within the OMX decoder. It would seem to perform 
> indirect rendering. This is slow, and indeed wasteful of memory space, 
> especially on low-end systems.

Yes, it does (more or less) indirect rendering. With how things are done 
right now, we copy data from the decoder-allocated buffer into an output 
buffer (from a picture pool or ideally from the vout directly), but Julian 
is trying to use the mode where we provide the buffer to write into, 
hopefully sparing at least one memcpy.

As far as I understand the OMX specs, I'm not sure if you actually can do 
real full direct rendering where the external buffers are used as internal 
DPB at all.


So on the Raspberry Pi, the codec internally allocates all the DPB buffers 
regardless of what buffer modes you use, and then there's not enough 
memory to allocate a full set of DPB buffers in the vout, and even if 
there was enough memory, you couldn't really use this as internal buffers 
for the codec as in avcodec.

// Martin