<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<meta name="generator" content="pandoc" />
<title></title>
<style type="text/css">code{white-space: pre;}</style>
</head>
<body>
<p>Hi again,</p>
<p>On 2016-10-24 17:57, Rémi Denis-Courmont wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> Le maanantaina 24. lokakuuta 2016, 16.27.05 EEST Filip Roséen a écrit :</code></pre>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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`].</code></pre>
</blockquote>
<pre><code> 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.</code></pre>
</blockquote>
<p>I can only refer to what I wrote about the cache in previous replies.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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`.</code></pre>
</blockquote>
<pre><code> And the exact same thing happens with a stream-based access. There is
absolutely no block-specific overhead here.</code></pre>
</blockquote>
<ul>
<li>We do not ask <em>stream-based</em> accessors to give us <code>N</code> bytes of data, where <code>N</code> is a decision made by the <em>accessor</em> itself, in order for us to read a value that is not equivalent to <code>N</code>.</li>
</ul>
<p>If the <em>block-based</em> <em>accessor</em> can only read on even alignments of <code>X</code>, it will have to re-read data suitable for that alignment.</p>
<ul>
<li>We ask streams exposing <code>pf_read</code> for <code>M</code> bytes of data, and they will try to fulfill that request.</li>
</ul>
<p>I fail to see how you can say that it is <em>“[not] block-specific”</em>. The path taken when reading blocks in <code>src/input/stream.c</code> is of course different than the one reading data from streams exposing <code>pf_read</code>.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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.</code></pre>
</blockquote>
<pre><code> That is not a memory copy.</code></pre>
</blockquote>
<p>It is inherently reading data from one place in order to store it in a block, if you want to call that a <em>memory copy</em> or simply <em>writing data into a block</em>, it does not change the fact that we create a new block for the <code>[core]</code> to read.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> 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.</code></pre>
</blockquote>
<ul>
<li>So you are saying that an <em>accessor</em> that works with a remote entity that is block based should do the same logic that we could have had in the core; reading blocks, storing them, and then expose contents through <code>pf_read</code>?</li>
</ul>
<p>If that is what you are saying, then we need to implement a fix for every block-based <em>accessor/stream_filter</em> (legacy and future ones).</p>
<p>To sum things up: We potentially regenerate/write/copy data simply because <code>src/input/stream.c</code> discards it in <code>vlc_stream_Seek</code>;</p>
<ul>
<li>you must agree with me on that at least?</li>
</ul>
<p>Please keep in mind what I wrote about the cache-modules being too early in the stream-chain, and how the problem simply shifts from one place to another if one decides to move it.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> --
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</code></pre>
</blockquote>
</body>
</html>