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

[Denis Charmet]

Hi,

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 
>> demux/
>> 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" 
modules.

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

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.

Regards,
-- 
Denis Charmet - TypX
Le mauvais esprit est un art de vivre