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

[Francois Cartegnie]

Le 26/06/2018 à 19:58, Rémi Denis-Courmont a écrit :

> And this plain patently false. The corrupt flag used in input stream and 
> discontinuity flag used in audio output. Just like I already wrote.


> It is. block_t has been used for input stream for at least 15 years. It's even 
> (ab)used for key events nowadays (also not me).

How come key events (from demux?) be related to ES sample sidedata ?
That does not fit.

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


> Indeed. block_t  is a blob of binary data, with a few pieces of immediate 
> meta-data. This patch misuses it as an associative array of blobs.

There's absolutely not difference from BLOCK_TYPE or BLOCK_*_FIELD
flags. Every flag enumerates a value where a field storage would make
more sense, we can't extend anything without running out of flags.
Sidedata is sidedata, 1 byte or 8 bytes timestamp. We just need storage.

>> 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.
> 
> Even leaving aside design/taste considerations, input streams do not use 
> block_t internally and do not treat block boundaries as meaningful, so there 
> are no ways that this will work.

Just like some flags or timestamps values are only meaningful between
some modules, data lifetime being limited by some known boundaries is
expected and wanted (decoder must handle or forward, otherwise be
passively dropped).

-- 
Francois Cartegnie
VideoLAN - VLC Developer