
<html><head></head><body>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.<br>

<br>

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.<br>

<br>

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.<br><br><div class="gmail_quote">Le 26 juin 2018 12:18:49 GMT+01:00, Francois Cartegnie <fcvlcdev@free.fr> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">Le 26/06/2018 à 12:16, Rémi Denis-Courmont a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Hi,<br> <br> 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.<br></blockquote><br>Exactly what requires code/handling for reordering, passing and<br>extracting data, modify all helpers, and forced me to pick up the<br>simpler way.<br><br>Goto 1<br></pre></blockquote></div><br>

-- <br>

Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>