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

[Rémi Denis-Courmont]

Le maanantaina 24. lokakuuta 2016, 16.27.05 EEST Filip Roséen a écrit :
> I am talking about the *memory copy/write* that inherently must take
> place in order for a block-based content *"generator"* to create a
> `block_t` that is then living inside `src/input/stream.c`.
> 
>     [ block access ] -> [ block cache ] -> [core] -> [ stream reader ]
>             ^- A                ^- B                       ^- C
>     /**
>      * A + B is somewhat redundant to the example, we could have left
>      * out B and have the same behavior, but it is added to better
>      * reflect how the previous discussion.
>      *
>      * One should however keep in mind that there might be any number
>      * of stream_filters between "[core]" and "[stream reader]", and
>      * if these are block-based things get worse.
>      **/
> 
>  In the above `B` is simply a cache that will cache all the blocks
>  that are generated by `A`, the `[core]` is the implementation within
>  `src/input/stream.c`, and `C` is something reading using
>  `vlc_stream_Read`.
> 
>  Imagine we are att offset zero, and `B` generates blocks `1 MB` in
>  size, a block having `p_block->i_buffer = 1024*1024` would end up in
>  `[core`].

 There is zero overhead compared to stream-based access. In both cases, we 
seek the underlying stream, and read the data. Also in case of caching, if 
buffers allow, in both cases, we just move the cursor within the cache.

>  If `C` wants to read `256` bytes at offset zero, and then `256 bytes`
>  at offset `524 288` it would (probably) do something as the below
>  (even though it could use skipping, but it has no way of knowing that
>  `B` has `N` as "chunk size"):
> 
>      vlc_stream_Read( src, buf_1, 256 ); /* (1) */
>      vlc_stream_Seek( src, 524288 );     /* (2) */
>      vlc_stream_Read( src, buf_2, 256 ); /* (3) */
> 
> Given that we currently, unconditionally, invalidate read blocks in
> `[core]` during `vlc_stream_Seek`, at `(3)` we would have to ask `B`
> to create a new block which the `[core]` transparently will use to
> feed `C`.

And the exact same thing happens with a stream-based access. There is 
absolutely no block-specific overhead here.

> In other words, `B` will "regenerate" contents that was already
> available at `(1)`, and for *accessors/stream_filters* that can only
> fetch chunks of `N` bytes of data upstream, it would have to fetch `N`
> bytes, even though reading stream is only interested in a smaller
> subset.

That is not a memory copy. If B performs memory copy internally, then it 
should probably be stream-based in the first place. And regardless, that´s a 
problem of the access implementation, not the core.

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