[vlc-devel] [PATCH] input/stream: do not unconditionally invalidate block on seek
filip at atch.se
Mon Oct 24 10:38:03 CEST 2016
On 2016-10-24 11:33, Rémi Denis-Courmont wrote:
> Le maanantaina 24. lokakuuta 2016, 2.13.11 EEST Filip Roséen a écrit :
> > If a seek request happens to refer to a position within the already
> > read block, simply update the block so that it refers to the desired
> > data.
> > There is really no need for us to discard the block, only to ask the
> > underlying stream to give us a new one (when we have the data we want
> > already).
> I don´t see the point. I have spent a lot of time untangling the caching from
> the generic byte stream reader, and this is just starting to bring it back in
> and duplicate functionality.
I agree that we should keep the implementation simple and consise, and
not duplicate functionality; but having the kind of support proposed
is just a extremely minor subset of the functionality within other
parts of the code.. and I think it make sense not to re-read data
(just as we have the functionality in place for peeking).
One could even merge the peeking and block "cache" in
`src/input/stream.c`, making the implementation even less complicated
than it is now.
> If you need to skip forward, call vlc_stream_Read(..., NULL, ...) in the
> demuxer or wherever else needed. That will work even if the stream is not
I guess we should have a major clean-up session, because we have
demuxers (such as `modules/demux/mp4` and `modules/demux/avi`), and
other entities, that does a lot of seeking back and forth, and for
block-based accessors this is killing performance (really bad).
Sure, they can be fixed to not discard already read data, but I find
that having simple management of blocks within `src/input/stream.c` is
not too complex.
> Rémi Denis-Courmont
> Nonsponsored VLC developer
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel