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

Steve Lhomme robux4 at ycbcr.xyz
Wed Feb 20 10:56:49 CET 2019


On 20/02/2019 09:56, Thomas Guillem wrote:
> Please,  send future decoder patches on the ML first.

Agreed. I didn't realise how mess it could be until I had to dig.

> This part is really tricky. You can see, that in the past, Rémi and me always went through the ML when touching the decoder (and we disagreed a lot).
>
> On Wed, Feb 20, 2019, at 09:10, Steve Lhomme wrote:
>> On 20/02/2019 09:01, Steve Lhomme wrote:
>>> On 19/02/2019 15:10, Rémi Denis-Courmont wrote:
>>>> Hi,
>>>>
>>>> I violently agree that there should be a clear separation between the
>>>> generic ("owner") functions, and the ES output functions.
>>>>
>>>> However, I think it makes more sense to keep the (vlc_)dec(oder)_
>>>> prefix for the generic case, and (vlc_)input_dec(oder)_ prefix for
>>>> the ES output.
> I see 3 different decoder API:
> - vlc_dec_: used by decoder modules (currently: decoder_*())
> - vlc_input_dec: used by es_out.c and implemented in input/decoder.c (but could be used by other modules) (currently: input_Decoder*())
> - vlc_dec_owner: your new helpers that could be used by modules. (currently (decoder_*())

I agree. This can be done independently of the work on push. For now I 
put the pool/video context in decoder_t which is something we need to 
discuss. For example the image decoder had no pool and just allocated 
pictures when asked. Do we want to always have a pool ? IMO it's less 
complex to always have it, but that means more memory used by the 
thumbnailer.

>
> Maybe we don't need vlc_dec_owner and always go through vlc_input_dec for every modules.
>



More information about the vlc-devel mailing list