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

[Denis Charmet]

On 2018-07-08 13:28, Rémi Denis-Courmont wrote:
> Indeed. The problem is the same with all approaches: it cannot work
> generically. The side data will need special case handling, or it will 
> be
> lost.
> 
> Yet François justified the current approach precisely on the basis 
> that it
> would work generically:
> 
> | As mentioned, the amount of code to transmit, manage and rebind
> | sidedata is huge. We can transmit it the simple way along with the
> | referred data.
> 
> I don't believe that.
> 

Yet a type/length/buffer triplet is generic and easily serialisable. I 
don't see why anything more specific should be used.

> There are always the same two objections:
> 
> 1) Until/unless the merger of data_buffer_t and data_packet_t into 
> block_t is
> undone, it bloats the block_t structure for ad-hoc use. In other 
> words, it is
> "out of place".

For me block is more a portmanteau container than a generic buffer. I 
understand your point but re-splitting everything for this is overkill. 
If it is needed couldn't it be done in a second time?

> 2) Unlike new parameter or new call, adding a field hides all the 
> regressions.
> The compiler will not raise warnings or errors. Instead, a tedious 
> audit of
> the block_t-dependent code is needed. If it had been done, we would 
> not have
> found 3 issues already (leak, timeshift, block chain).

Out of band add other constraints as difficult to handle as the current 
proposed solution.
Like updating all the APIs, maintaining a secondary fifo, putting the 
block pointer inside the  side data structure, every time a block is 
popped out of the fifo, we'd need to run through the side fifo to get 
all the side data associated and then ask specifically modules to free 
them or do it in the core at the end.

> I don't deny that it is doable. But it is not straightforward, at 
> least not if
> you factor in all the entailed auditing and fixing, and especially 
> separating
> the other block_t use cases.

Again this could be done in a second time. Features make VLC popular, 
not it's separation of data. Besides this field could be used in the 
future for audio, for example to improve spacialisation when using 360 
videos, it could be used in the sout context to handle the reversed 
case. Does it really bloat a structure when it could be useful at 
several levels?

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