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

[Thomas Guillem]

Hello TypX,

I also 2 other issues with this RFC:
 - Drop of flags in vlc_data_t: sadly, there will be no ways for accesses to report a discontinuity. I know it is broken in VLC 3.0 since flags are lost in stream filters, but there are a lot of requests to bring back the ability for accesses to notify a discontinuity. We should fix it for 4.0 and therefore keep this flag.
 - Code duplication between data.c and frame.c and also between data_helper.h and frame_helper.h: This code is far from trivial and should not be duplicated. We don't want to fix 2 files each time we need to fix a bug. The only way I see to solve this issue is to include vlc_data_t from vlc_frame_t and have generic vlc_data_t functions working with vlc_frame_t.

I know that you already spend a lot of time in this (not fun) patch set, that is why I propose to continue your work by fixing the 2 points I mentioned. What do you think ?

Best,


On Tue, Apr 23, 2019, at 17:32, Rémi Denis-Courmont wrote:
> 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 
> unification.
> 
> > 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
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel