[vlc-devel] [PATCH] input/stream: do not unconditionally invalidate block on seek
remi at remlab.net
Mon Oct 24 19:43:47 CEST 2016
Le maanantaina 24. lokakuuta 2016, 18.28.31 EEST Filip Roséen a écrit :
> That's not what I said in full, it affects *block-based* streams that
> are being read as if they were *stream-based* given that they create
> blocks that are then discarded (even though a seek refers to content
> of the already available block).
I don´t see a problem there as such. As explained multiples times, this would
lead to data being discarded at some level and regenerated at a lower level.
But that does not intrinsically make it a "problem" that needs solving.
> > > - you must agree with me on that at least?
> > Regenerate, yes, but it is not worth fixing because:
> > - The fix will intrinsically not work for stream-based accesses.
> As already denoted, *stream-based* accessors are not suffering from
> the same kind of problem given that they receive a request for `M`
> bytes of data, not *"give me a block of whatever size you prefer"*.
I can´t agree.
> > - The fix is intrinsically irrelevant for nonseekable accesses.
> Yes, it is irrelevant for *nonseekable* streams, the discussion are
> about the implications of calling `vlc_stream_Seek`.
> > - The problem is, in practice, negligible for fastly seekable streams (but
> > then again, all of them are stream-based at the moment anyway).
> > - The problem is negligible for most demuxer plugins and for all properly
> > multiplexed files.
> > - The prefetch cache filter already solves the problem for slowly seekable
> > streams. Specifically, the prefetch buffer capacity should exceed the size
> > of any reasonable single block. If not, the access should probably be
> > reworked because excessively large blocks will cause performance _other_
> > problems.
> The modules responsible for prefetching/caching data does not apply to
> *stream_filters* that are later in the *stream-chain* (which I have
> already mentioned).
That is complete nonsense. The cache filter is the second most upstream
element in the chain after the access. The whole point is to provide caching
for everything downstream, rather than only the demuxer.
If we moved the cache further downstream, and in particular after any
decompression filters, the prefetch filter would fail to fill its original
design role: to keep draining network buffers to solve congestion problems
with high bit rate network streams.
> > - The fix is at the top of the slippery slope down to entangling caching
> > and generic I/O code.
> Given that you are the author of the relevant implementation within
> `src/input/stream.c` I am very surprised that you just said that,
> especially given the following commit `f388861`.
It is actually very common for demuxers to skip all or part of what they poke.
And this affects all stream types, not just block-based ones. Also AFAIR,
there was already a different incarnation of the same optimization before.
> What I would like is for us to have a common logic related to seeking
> within an already created block, or peeked data. It is basically
> equivalent to the implementation your wrote, so I, once again
> honestly, do not see what argument you are making against such patch.
I think I have made the arguments patently clear at this point.
And depending on how you look at it, the patch either fixes a nonexistent
problem or fixes a real problem in a hopelessly narrow subset of
Nonsponsored VLC developer
More information about the vlc-devel