[vlc-devel] [PATCH 2/2] vlc_block: store per block ancillary
remi at remlab.net
Sun Jul 8 17:40:14 CEST 2018
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.
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
> 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.
More information about the vlc-devel