[vlc-devel] Direct3D9 + DXVA direct rendering

Steve Lhomme robux4 at videolabs.io
Tue Apr 14 10:05:57 CEST 2015

On Tue, Apr 14, 2015 at 9:41 AM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 2015-04-14 09:03, Steve Lhomme a écrit :
>>> Reference counting a picture pool makes no sense at this point though.
>>> The
>>> pool is destroyed when its video output or video conversion filter is
>>> destroyed. Even if the pool were not destroyed, there would be no ways to
>>> allocate pictures from it. So it might as well be destroyed.
>>> The pictures within the pool are reference counted instead. Pictures will
>>> in
>>> some corner cases outlive their pool.
>> The surfaces in the picture_t are resources that belong to the D3D9
>> device.
> So what? It is not the first occurence of (pooled) picture resources
> depending on a device context. Again, the only reason to have a reference to
> the pool is to allocate picture from it. There is no point in allocating
> pictures from the pool of a destroyed video output or video conversion
> filter. Thus there is no point having (externally visible) reference
> counting for pools.
>> But I have to dig deeper
>> there. I may end up just using a simple picture_pool_t that will
>> allocate surfaces one by one when it needs more.
> Been there, done that. Decoding will fail unrecoverably if the GPU runs out
> of memory. You MUST reserve all necessary resources ahead of time
> *especially* when using dedicated hardware.
>> Rather than a large
>> fixed size I need now. If resource handling is done properly in the
>> pool then that problem will be solved.

For decoders we can predict how much buffers will be needed based on
the codec. But for the display FIFO it's hard to tell. With 4 buffers
I get the video out of sync with audio. With 8 it's okay on some
samples but not others. So for now I use as much as the decoder needs,
but IMO that's probably too much. I'd rather have something dynamic
that stabilizes to the lowest amount it needs by itself.

I'd also like to know why the frames are so late when there's less
buffers available. How is the display FIFO pace controlled ? Is it by
the decoder speed, which in this case is insanely fast ?


More information about the vlc-devel mailing list