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

[Rémi Denis-Courmont]

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 :
>> Hi,
>> 
>> 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
>simpler way.
>
>Goto 1
>
>-- 
>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/20180626/ca5e02a7/attachment.html>