[vlc-devel] [PATCH 4/4] avcodec: va: get the picture to send to the vout during Extract() not Get()

[Steve Lhomme]

On Wed, Nov 30, 2016 at 6:08 PM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le keskiviikkona 30. marraskuuta 2016, 9.03.34 EET Steve Lhomme a écrit :
>> On Tue, Nov 29, 2016 at 5:48 PM, Rémi Denis-Courmont <remi at remlab.net>
> wrote:
>> > Le tiistaina 29. marraskuuta 2016, 14.19.38 EET Steve Lhomme a écrit :
>> >> In some cases the decoder pool is stuck on picture_pool_Wait() because
>> >> the
>> >> va keeps requesting referenced pictures without outputing anything (yet).
>> >
>> > I have not seen this in recent times and the problem is in no way specific
>> > to hardware acceleration in any case.
>>
>> It it related to the fact the library we use (libavcodec) requires all
>> decoding buffers to be allocated and provided at once for DVXA2 and
>> D3D11VA.
>
> No. That wouldn´t cause a deadlock; that would just make the pool empty or
> close to empty.
>
>> And there's at least a good reason for that, the pool must
>> provide the pictures in LIFO order.
>
> The pool used to be FIFO order. Now it´s constant order, which reduces
> (demand-paged) memory usage if reference count is over-estimated, and at least
> theoretically improves locality.
>
> This is irrelevant here. Neither LIFO nor FIFO order, nor any other order
> provide any useful warranty for anything since picture buffers can be released
> asynchronously by various components (decoder, filters, splitter and output).
> In other words, the design is purely down to statistical optimization.
>
>> The surface copying in Direct3D is
>> asynchronous and when a B frame is decoded it's released right away by
>> the decoder and possibly reused for the next decoding, if the pool
>> provides pictures in FIFO order.
>
> You can influence the order by abusing either the picture context or the
> picture pool lock function. But I expect that to become intractable and be
> removed in VLC 4.0 as part of pool rework.
>
> Regardless...
>
>> That results in glitches or crashes.
>
> ...then your code is racy and broken regardless. And this patch does not fix
> that problem.

No, it's due to the fact that CopySubResource is asynchronous so you
may display something that is not finished copying. And also, as
explained above that a released "internal" picture that was also
CopySubResource to another one might be reused right away by the
decoder (FIFO) even though the copy is not finished.

>> Would the picture pool change be OK with you ?
>
> No.

I think changing the design of DXVA2 in libavcodec is my best hope. It
will also get rid of the CopySubResource in Extract, which is good
savings on the GPU side.

> --
> Rémi Denis-Courmont
> https://www.remlab.net/
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel