[vlc-devel] [vlc-commits] decoder: make decoder_Clean() public

[Steve Lhomme]

On 20/02/2019 12:30, Rémi Denis-Courmont wrote:
> We agreed that each decoder will have its own picture buffer 
> management, a.k.a. pool. I don't think we said that the decoder core 
> would take care of it; in fact, I'm pretty sure we said it wouldn't, 
> at least not always.

We said the va pool will have to take care of it, yes. The rest was up 
in the air. But IMO rather that changing all the decoders we have it's 
better to keep them working with an external pool that they don't know 
about, for now.

>
> Le 20 février 2019 13:17:37 GMT+02:00, Steve Lhomme <robux4 at ycbcr.xyz> 
> a écrit :
>
>     On 20/02/2019 11:23, Rémi Denis-Courmont wrote:
>
>         Hi, I don't think that there is a question whether there
>         should always be a pool, because it now depends on the decoder
>         plugin. 
>
>
>     That's not the direction I took. I thought we agreed on the previous
>     workshop that decoders will have their own pool. Each of them.
>
>
>         We don't know what the decoder does or does not do internally,
>         so there are no ways to generically allocate a pool outside on
>         a systematic basis. 
>
>
>     I agree, except we live fine with that for now with a pool "large"
>     enough that handled elsewhere, just by providing the DPB size and
>     i_extra_picture_buffers. I don't think we're planning to get rid of
>     these for now.
>
>     Also the current decoder_NewPicture taping in the pool from the vout, is
>     using picture_pool_Wait() meaning if it has used more than its DBP +
>     extra pictures, it will wait for new pictures. This allows a kind of
>     rate control for the decoder and avoid allocating all the memory of the
>     system if the decoder is faster to decode than the vout can handle. I
>     think we should keep that safety for all decoders.
>
>     Also we agreed that the format (metadata) change will now be handled by
>     signaling a change downstream, not by resetting everything. That will
>     impact how a potential pool would be used but that handling can be
>     centralized in decoder_UpdateVideoFormat(), rather than leaving each of
>     the 26 decoders deal with it. All they do is call
>     decoder_UpdateVideoFormat, decoder_NewPicture and decoder_QueueVideo.
>     They don't have to be changed at all for the change to push.
>
>     >
>
>         And it would be insane to allocate a whole pool for image
>         decoders, especially considering that pictures tend to be
>         larger than video frames. Image decoders should allocate their
>         picture explicitly. No, the first question is what would the
>         determinant be to allocate a pool for the decoder or let the
>         decoder manage its pool. Le 20 février 2019 12:01:52
>         GMT+02:00, Steve Lhomme <robux4 at ycbcr.xyz> a écrit : On
>         20/02/2019 09:56, Thomas Guillem wrote: Please, send future
>         decoder patches on the ML first. BTW do we agree on my 13+1
>         patchset, generalizing the work on the output format passed to
>         update_format() ? Later this format will be the one used for
>         the decoder pool. And possibly set on dec->fmt_out.video,
>         although in my branch I kept a separate one to check the pool
>         format against it.
>         ------------------------------------------------------------------------
>         vlc-devel mailing list To unsubscribe or modify your
>         subscription options:
>         https://mailman.videolan.org/listinfo/vlc-devel -- Envoyé de
>         mon appareil Android avec Courriel K-9 Mail. Veuillez excuser
>         ma brièveté.
>         ------------------------------------------------------------------------
>         vlc-devel mailing list To unsubscribe or modify your
>         subscription options:
>         https://mailman.videolan.org/listinfo/vlc-devel 
>
>     ------------------------------------------------------------------------
>     vlc-devel mailing list
>     To unsubscribe or modify your subscription options:
>     https://mailman.videolan.org/listinfo/vlc-devel
>
>
> -- 
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez 
> excuser ma brièveté.
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel