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

[Rémi Denis-Courmont]

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.

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é.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190220/3b76e8e7/attachment.html>