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

[Rémi Denis-Courmont]

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.

Adding a non-immediate field to block_t sounds like a recipe for disaster.

Le 26 juin 2018 10:24:04 GMT+01:00, Francois Cartegnie <fcvlcdev at free.fr> a écrit :
>Le 26/06/2018 à 10:43, Rémi Denis-Courmont a écrit :
>
>> Yeah, if you want to extend the existing generic block data 
>structure, you 
>> can make a sub-class.
>> 
>>> but that is not what we have currently.
>> 
>> It is. Just check all the places that block_t is used for. It's far
>from only 
>> ES coded data.
>> 
>
>That's still generic purpose chained storage.
>
>There's not even a non hybrid storage for "ES coded data".
>
>What does my demuxer or access demux outputs ? Sample ? Blocks ?
>If that's packetized, that's sample data... but non packetized, that's
>raw data. And what happens when reinjecting samples as block into
>packetizers for transcoding ?
>
>Do we really want to add tons of conversion layers everywhere and
>rewrite new block stuff helpers ? Then wait someone to come and tell us
>we can simplify using a generic storage ?
>
>-- 
>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/6cd1ea6f/attachment.html>