[vlc-devel] [PATCH 2/2] vlc_block: store per block ancillary

[Denis Charmet]

Hi,

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 
structures?

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
> corruption.

Forgive my lack of formal CS education but what do you mean by 
"non-immediate"?
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.

Regards,
-- 
Denis Charmet - TypX
Le mauvais esprit est un art de vivre