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

[Jean-Baptiste Kempf]

On Tue, 26 Jun 2018, at 10:43, Rémi Denis-Courmont wrote:
> Le lundi 25 juin 2018, 13:14:25 EEST Jean-Baptiste Kempf a écrit :
> > 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.
> > 
> > It is not a generic data_structure, since it contains flags (deinterlacing,
> > I/P/B, tff/bff, etc..) and has pts and dts or preroll.
> 
> Flags is actually the most generic of all meta-data field in there, as it 
> carries the generic corrupt flag and the mostly generic discontinuity flag. 
> The remaining space is left for ad-hoc use for convenience.

Absolutely not. 14 flags out of 14 are about video/audio/demux data.

> If anything, the least generic of the grandfathered fields is DTS.

i_dts, i_pts and i_length are vlc_tick_t

> > If we want to have a block as a generic input data structure, we can have a
> > different structure,
> 
> Yeah, if you want to extend the existing generic block data  structure, you 
> can make a sub-class.

You removed the audio sample structure, IIRC. You cannot then claim that block is generic.

> > but that is not what we have currently.
> 
> It is.

It is not. At least 5 fields out of 11 are video/audio/demux specific.
And it has always been like that, since 10 years+

> Just check all the places that block_t is used for. It's far from only 
> ES coded data.

How is that a justification?
Misusing a structure and then claiming that we cannot extend it for its original purpose is not good.

Also, noone said it was ES coded data only, but also input_stream data.
And that's good because we need ancillary in both ES and input_stream data.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734