[vlc-devel] [PATCH 2/2] vlc_block: store per block ancillary
remi at remlab.net
Tue Jun 26 13:36:09 CEST 2018
Adding a non-immediate field is simpler if you ignore all the bugs that it potentially introduces silently. But that is not a sane thing to do.
Everytime somebody else tries to change a common compound type in potentially dangerous ways (es_format_t multiple times) you rightfully raise concerns. Same thing here.
Besides, I don't agree that adding a new control or callback is difficult. It requires no changes in most cases, where the side data is not used or not expected.
Le 26 juin 2018 12:18:49 GMT+01:00, Francois Cartegnie <fcvlcdev at free.fr> a écrit :
>Le 26/06/2018 à 12:16, Rémi Denis-Courmont a écrit :
>> I never wrote that we should have different subclasses of block_t
>everywhere. I think it would be a good idea, but it seems overkill
>here, compared to adding a new parameter (like for SPU blending) or a
>new ES output control and packetizer callback.
>Exactly what requires code/handling for reordering, passing and
>extracting data, modify all helpers, and forced me to pick up the
>VideoLAN - VLC Developer
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel