<!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>Good evening Rémi,</p>
<p>On 2016-10-24 19:03, 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> Kväll,
Le maanantaina 24. lokakuuta 2016, 17.22.52 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 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`.</code></pre>
</blockquote>
<pre><code> 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:</code></pre>
</blockquote>
<p>That’s not what I said in full, it affects <em>block-based</em> streams that are being read as if they were <em>stream-based</em> given that they create blocks that are then discarded (even though a seek refers to content of the already available block).</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> | (...) 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.</code></pre>
</blockquote>
<p>See next comment.</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> 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?</code></pre>
</blockquote>
<pre><code> Regenerate, yes, but it is not worth fixing because:
- The fix will intrinsically not work for stream-based accesses.</code></pre>
</blockquote>
<p>As already denoted, <em>stream-based</em> accessors are not suffering from the same kind of problem given that they receive a request for <code>M</code> bytes of data, not <em>“give me a block of whatever size you prefer”</em>.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> - The fix is intrinsically irrelevant for nonseekable accesses.</code></pre>
</blockquote>
<p>Yes, it is irrelevant for <em>nonseekable</em> streams, the discussion are about the implications of calling <code>vlc_stream_Seek</code>.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> - 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.</code></pre>
</blockquote>
<p>The modules responsible for prefetching/caching data does not apply to <em>stream_filters</em> that are later in the <em>stream-chain</em> (which I have already mentioned).</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> - The fix is at the top of the slippery slope down to entangling caching and
generic I/O code.</code></pre>
</blockquote>
<p>Given that you are the author of the relevant implementation within <code>src/input/stream.c</code> I am very surprised that you just said that, especially given the following commit <code>f388861</code>.</p>
<p>What I would like is for us to have a common logic related to seeking within an already created block, or peeked data. It is basically equivalent to the implementation your wrote, so I, once again honestly, do not see what argument you are making against such patch.</p>
<p>The current implementation can be simplified, a lot, if we just share the code-path (which I mentioned in one my first replies in this discussion).</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><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.</code></pre>
</blockquote>
<p>It is not related to usage of <em>cache_block</em>, especially given that it is too far up the stream to be of any importance (as I have already described), it is however very much relevant to <em>stream_filters</em> that are block-based (such as the soon to be proposed torrent module).</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> So maybe I should call it premature optimization rather than micro-
optimization.</code></pre>
</blockquote>
<p>Best Regards,<br />
Filip</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>