[vlc-devel] [PATCH] input/stream: do not unconditionally invalidate block on seek

[Filip Roséen]

Hi Remi

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 
> readable.

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
> http://www.remlab.net/CV.pdf
> 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20161024/d283392d/attachment.html>