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

[Rémi Denis-Courmont]

	Kväll,

Le maanantaina 24. lokakuuta 2016, 17.22.52 EEST Filip Roséen a écrit :
> I fail to see how you can say that it is *"[not] block-specific"*. The
> path taken when reading blocks in `src/input/stream.c` is of course
> different than the one reading data from streams exposing `pf_read`.

I say it s not block-specific because it is not block-specific. You said, more 
or less, that the problem affects input streams that require excessively slow 
seeking during normal playback:

| (...) we have demuxers (such as `modules/demux/mp4` and
| `modules/demux/avi`), and other entities, that does (sic) a lot of seeking
| back and forth, and for block-based accessors this is killing performance
| (really bad).

Badly multiplexed MP4 and AVI files are certainly are not limited to block-
based accesses.

> To sum things up: We potentially regenerate/write/copy data simply
> because `src/input/stream.c` discards it in `vlc_stream_Seek`;
> 
>  - 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.

- The fix is intrinsically irrelevant for nonseekable accesses.

- 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 fix is at the top of the slippery slope down to entangling caching and 
generic I/O code.

This patch is specific to pipelines using cache_block (or no cache at all) 
with seekable stream and pathological multiplexing. To put stuff into 
perspective, exactly zero valid combinations of access and demuxer plugins 
would benefit from this patch in the current code base. Indeed, I believe only 
the DVB and MMS access use cache_block at the moment. DVB is not seekable, and 
MMS (ASF) does not normally require seeking.

So maybe I should call it premature optimization rather than micro-
optimization.

-- 
Rémi Denis-Courmont
Nonsponsored VLC developer
http://www.remlab.net/CV.pdf