[vlc-devel] [PATCH 2/2] vlc_block: store per block ancillary
typx at dinauz.org
Wed Jun 27 14:54:31 CEST 2018
On 2018-06-27 13:11, Rémi Denis-Courmont wrote:
> But adding a whole new associative array is *way* beyond the scope
> of a data buffer, especially when it is only for some corner cases.
> See also The Blob / The God object.
Isn't VLC all about handling corner cases :). I think we all agree that
we need a way to handle that and the debate is just about the how.
So do you think that we should re-split block into more specific data
I would conceptually agree with this, I'm just afraid of the amount of
work it implies with the duplication/evolution of all the helpers.
> Not only that but block_t is not designed to cope with non-immediate
> writable metadata fields. That causes leaks abd possibly heap
Forgive my lack of formal CS education but what do you mean by
If the block releasing function properly cleans those side data, why
would it leak and/or corrupt the heap?
Or do you fear that duplication, removal
> And even when all the boilerplate is added to fix those leaks (it's
> not so easy anymore). Then there is still the problem that you cannot
> "generically" pass side data through the block_t users. Things like
> block chain, timeshift, packetizers will need to handle it explicitly
> (it's even harder than fixing the leaks).
I don't mind the out-of-band way, I just don't see how we could
reliably link those data to the relevant frame considering that
multimedia is sheer madness, unless we add a generic UID field to the
block, but then should the module ask the core "give me all the data
linked to this UID".
Or could it be achieved with an es_out_send_side_data API to keep it
attached to their mother ES... But then how to keep them in the fifo,
when should we release them if they are not consumed by a module.
Denis Charmet - TypX
Le mauvais esprit est un art de vivre
More information about the vlc-devel