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

[Rémi Denis-Courmont]

Le sunnuntaina 8. heinäkuuta 2018, 14.03.21 EEST Denis Charmet a écrit :
> I feel like we are splitting hair for the sake of theory. I proposed
> some kind of generic solution but at some point we'll have to trust the
> decoder/packetizer to deal with those side data, or ignore them and let
> the helpers duplicate them and pass them for the other step.
> 
> Because the issue will be the same with out of band data because either
> the packetizer will know about the wanted ancillary and handle them or
> let them be and create new block but then the link between the out of
> band side datas and the original block will be lost and the next step
> won't be able to handle them.

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.

> (...) if the solutions are somehow equivalent why not stick to the one
> proposed?

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

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

> Provided the patch handles blockchain and timeshift serialization?

> IMO putting them inside the structure, and duplicate it on split if not
> handled is the easiest way to ensure that the linking between the block
> and its side data is maintained and passed throughout the chain.

Certainly, if both objections were addressed, then the side data field could 
work.

> I wouldn't mind using the out of band way but I just cannot figure out
> a way to do it, while the in structure seems quite straightforward to
> me.

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.

-- 
Rémi Denis-Courmont
http://www.remlab.net/