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

[Thomas Guillem]

On Wed, Apr 24, 2019, at 16:23, Rémi Denis-Courmont wrote:
> Le keskiviikkona 24. huhtikuuta 2019, 16.57.15 EEST Thomas Guillem a écrit :
> > 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.
> 
> That's a feature. You cannot have flags in a byte stream as you've reminded 
> already.
> 
> > 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.
> 
> That was not "broken in VLC 3.0". The only stream_t function that could 
> preserve packet boundaries, and thus flags, is vlc_stream_ReadBlock() which was 
> introduced in 3.0, much later than stream filters.
> 
> Besides, even before streams filters existed, the stream buffering code in the 
> core did much the same as stream filters do today. This is really as old as the 
> stream_t abstraction.

OK, it didn't work either in VLC 2.2, but why are so many access modules setting up block flags ?
I really think the accesses flags should be forwarded.

> 
> So there never was an option to pass flags there. In particular, what V4L2 
> access does is just cargo cult from the V4L2 access_demux.
> 
> > We should fix it for 4.0
> > and therefore keep this flag.
> 
> I completely disagree. That is an impossible/inconsistent requirement.
> 
> If you have packets with flags, don't use the the stream abstraction. Even if 
> that worked through stream filters, it would confuse the demuxers behind it. So 
> you need tight coupling anyway.
> 
> -- 
> Реми Дёни-Курмон
> http://www.remlab.net/
> 
> 
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel