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

[Rémi Denis-Courmont]

It is not I who used block_t for key events or other strongly typed queue elements. So don't ask me why it's done.

And I already pointed out multiple differences between the proposed ancillary field and the other meta data fields. So the assertion that there are "absolutely" none is falsehood and this mail is "absolutely" wrong.

Le 26 juin 2018 23:25:50 GMT+03:00, Francois Cartegnie <fcvlcdev at free.fr> a écrit :
>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
>_______________________________________________
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
>https://mailman.videolan.org/listinfo/vlc-devel

-- 
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20180627/0cf57bfc/attachment.html>