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

<br>

Adding a non-immediate field to block_t sounds like a recipe for disaster.<br><br><div class="gmail_quote">Le 26 juin 2018 10:24:04 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 à 10:43, Rémi Denis-Courmont a écrit :<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Yeah, if you want to extend the existing generic block data  structure, you <br> can make a sub-class.<br> <br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> but that is not what we have currently.<br></blockquote> <br> It is. Just check all the places that block_t is used for. It's far from only <br> ES coded data.<br> <br></blockquote><br>That's still generic purpose chained storage.<br><br>There's not even a non hybrid storage for "ES coded data".<br><br>What does my demuxer or access demux outputs ? Sample ? Blocks ?<br>If that's packetized, that's sample data... but non packetized, that's<br>raw data. And what happens when reinjecting samples as block into<br>packetizers for transcoding ?<br><br>Do we really want to add tons of conversion layers everywhere and<br>rewrite new block stuff helpers ? Then wait someone to come and tell us<br>we can simplify using a generic storage ?<br></pre></blockquote></div><br>

-- <br>

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