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

Rémi Denis-Courmont remi at remlab.net
Sun Jul 8 13:28:38 CEST 2018

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 

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 

> 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

More information about the vlc-devel mailing list