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

Rémi Denis-Courmont remi at remlab.net
Wed Jun 27 13:11:00 CEST 2018


block_t is *originally* the *merger* of the data/PES packet type (what you call frame) and the generic raw binary data buffer type. Contrary to allegations, this was not done by me. It even predates my involvement with VLC at all. Thus the same type is used for multiple different things.

At the time the only extras from the second to the first were two times (DTS, PTS) and two flags, so I *guess* it was not considered a concern.

But adding a whole new associative array is *way* beyond the scope of a data buffer, especially when it is only for some corner cases. See also The Blob / The God object.

Not only that but block_t is not designed to cope with non-immediate writable metadata fields. That causes leaks abd possibly heap corruption.

And even when all the boilerplate is added to fix those leaks (it's not so easy anymore). Then there is still the problem that you cannot "generically" pass side data through the block_t users. Things like block chain, timeshift, packetizers will need to handle it explicitly (it's even harder than fixing the leaks).

I find it rather ironic that, after complaining so much about non-immediate field mishandling in es_format_t, the same class of hurdles is proposed for block_t. And it's much worse here, seen as there are many more block-based helpers than format-based.

Le 27 juin 2018 00:32:57 GMT+03:00, Denis Charmet <typx at dinauz.org> a écrit :
>On 2018-06-25 12:14, Jean-Baptiste Kempf wrote:
>> On Tue, 19 Jun 2018, at 19:22, Rémi Denis-Courmont wrote:
>>> This is out of place. Block_t is a generic data structure, not some 
>>> demux/
>>> codec internal.
>> [...]
>> If we want to have a block as a generic input data structure, we can
>> have a different structure, but that is not what we have currently.
>I feel like the debate is slowly drifting from its point... May I ask 
>what is so fondamentaly wrong to add something that look to me like 
>generic side data to a block?
> From my own perspective, and yes I have a demux bias, the block_t has 
>always been misnamed block and should be considered a frame more than a
>generic block. If I take lavfc example AVFrames have side data. I mean 
>it's still the easiest way for everyone to handle it.
>Sure we could have an ANCILLARY_ES or whatever and synchronize it with 
>the other ES using pts but we'd need to know how to properly route it
>the core to its rightful owner. It can be easily ignored by "simple" 
>We could rename block_t to frame_t (and I would love it) but then 
>should we keep block_t? If so what happens to all the block code? Do we
>duplicate it?
>Right now François' solution doesn't seem too bad for me. I might be 
>missing some part of the picture but if you could list all the problems
>of which you can think then I'm sure we can all come up with a good 
>solution that would be satisfying for everybody.
>Denis Charmet - TypX
>Le mauvais esprit est un art de vivre
>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...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20180627/3b2209c0/attachment.html>

More information about the vlc-devel mailing list