[vlc-devel] [PATCH 2/2] vlc_block: store per block ancillary
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
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
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.
More information about the vlc-devel