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

[Rémi Denis-Courmont]

Le sunnuntaina 8. heinäkuuta 2018, 18.24.30 EEST Denis Charmet a écrit :
> 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.

Sure.

But the logic to map a side data or a piece of it, to a block cannot be 
generalized. It seems entirely dependent on the underlying codec and/or type 
of side data.

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

I don't think that knowingly introducing bugs is acceptable, or even viable 
for an open-source project.

> Features make VLC popular, not it's separation of data.

And crashes and leaks get it panned - even when it is not even caused by a VLC 
bug.

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

I never said it was bloating the audio or sout case. To the contrary, I 
specifically stated in this very thread that it made sense to use the same 
type for audio post-decoder and pre-decoder.

The offending uses are non-timed, such as stream/access.

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