[vlc-devel] [PATCH 2/2] vlc_block: store per block ancillary
typx at dinauz.org
Tue Jun 26 23:32:57 CEST 2018
On 2018-06-25 12:14, Jean-Baptiste Kempf wrote:
> On Tue, 19 Jun 2018, at 19:22, Rémi Denis-Courmont wrote:
>> This is out of place. Block_t is a generic data structure, not some
>> codec internal.
> If we want to have a block as a generic input data structure, we can
> have a different structure, but that is not what we have currently.
I feel like the debate is slowly drifting from its point... May I ask
what is so fondamentaly wrong to add something that look to me like
generic side data to a block?
From my own perspective, and yes I have a demux bias, the block_t has
always been misnamed block and should be considered a frame more than a
generic block. If I take lavfc example AVFrames have side data. I mean
it's still the easiest way for everyone to handle it.
Sure we could have an ANCILLARY_ES or whatever and synchronize it with
the other ES using pts but we'd need to know how to properly route it in
the core to its rightful owner. It can be easily ignored by "simple"
We could rename block_t to frame_t (and I would love it) but then
should we keep block_t? If so what happens to all the block code? Do we
Right now François' solution doesn't seem too bad for me. I might be
missing some part of the picture but if you could list all the problems
of which you can think then I'm sure we can all come up with a good
solution that would be satisfying for everybody.
Denis Charmet - TypX
Le mauvais esprit est un art de vivre
More information about the vlc-devel