[vlc-devel] [PATCH 2/2] vlc_block: store per block ancillary
remi at remlab.net
Tue Jun 26 12:16:48 CEST 2018
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
>> 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
>> 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 ?
>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