[vlc-devel] [PATCH 2/2] vlc_block: store per block ancillary
Denis Charmet
typx at dinauz.org
Sat Jul 7 23:17:44 CEST 2018
Hi again,
On 2018-07-07 21:40, RĂ©mi Denis-Courmont wrote:
> Err? *All* block allocators provide their own pf_release. That's the
> whole
> point of pf_release being a function pointer.
I meant not using the helper allocator/releasers but fair enough :)
>
> But reassigning side data to the right block in block chain - uh??
>
Well gathered blocks could append all their side data and split block
could duplicate their side data at split but I get your point.
> AFAIK, there are basically two ways to pass them out of band:
> - at ES output:
> - new control, or
> - new parameter to send callback control,
> - at packetizer and decoder levels:
> - new optional callback, or
> - new parameter to decode/packetize callback.
>
> New control and new callback would most certainly require much less
> code churn
> than new parameters.
Sorry if that's obvious to you but I really cannot picture how to make
it work as a control+callback.
- How would you link a block that will be put in the fifo and it's side
data?
- Where would it be stored while waiting for the decoder/packetizer?
- What should release it?
> Also ES timeshift needs to serialize/deserialize. Again, the side data
> won't
> magically pass through just by adding a new block_t field.
>
But wouldn't serializing/deserializing risk to lose the reference to
its needed side data as well?
> If we had a specific enough structure, I would be fine with adding it
> there.
> But it won't be any easier than the other approaches. IMO, it just
> makes
> missing handling harder to spot, as the compiler won't warn.
Well there is still one last option. Pass them a block flagged as
PREROLL in the same fifo
Regards,
--
Denis Charmet - TypX
Le mauvais esprit est un art de vivre
More information about the vlc-devel
mailing list