[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