[vlc-devel] [PATCH 00/17] RFC Split block_t into 2 different data containers

Rémi Denis-Courmont remi at remlab.net
Tue Apr 23 17:32:33 CEST 2019

Le maanantaina 22. huhtikuuta 2019, 20.10.29 EEST Denis Charmet a écrit :
> As discussed previously, this long overdue patch propose to split the
> generic block_t into two different containers which could be specialized
> when needed.
> I propose to use:
> * vlc_data_t for pure data blocks with no timing or discontinuities
> information.
> * vlc_frame_t for timed data with flags.

FWIW, the original names were data buffer and data packet before the block_t 

> The vlc_ prefix has been added to prevent namespace clobbering.
> * Streams will use vlc_data_t while almost everything else will use
> vlc_frame_t.
> * Demux chained will only accept vlc_data_t as input
> This patch is not as complete as it could be since I'd like to be able to
> deprecate the data fifos to only keep the frame fifo. Since, imo, the only
> "data fifo" are more abused than used.

There are not many data FIFO uses. RIST and SatIP accesses and the stream 
FIFO. At least the last one could easily be replaced by ad-hoc code.

But then there are those annoying message queues (VoD, RTSP, Caca...) or other 
queues (Schroedinger) or non-threaded block chain (Shine).

> It also shows that there seem to be too many data structure doing the same
> thing yet slightly differently (block chains, fifo, bitstream reader,
> etc...)

The FIFO is a thread synchronization object - not the other ones with which I 
am not so familiar.

Rémi Denis-Courmont

More information about the vlc-devel mailing list