[vlc-devel] [PATCH 00/17] RFC Split block_t into 2 different data containers
thomas at gllm.fr
Wed Apr 24 16:42:35 CEST 2019
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
> > 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.
> Реми Дёни-Курмон
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
More information about the vlc-devel