[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