<!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,</p>
<p>On 2016-11-02 10:29, Steve Lhomme wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> To summarize the issue, is STREAM_CAN_FASTSEEK_FORWARD needed ?</code></pre>
</blockquote>
<p>No, what one could argue is necessary is a straight-forward way to know whether a stream has a finite size or not (which would lead to problems in terms of implementation, since there’s nothing that really guarantees this for all/most accessors).</p>
<p>Also, it is not really about “seeking forward” given that we need to exhaust (somewhat byte-wise) every cluster stumbled upon in order to find the next one (since we cannot read the cluster header, and then simply jump to the end of it). I am not sure how <em>libmatroska</em>/<em>libebml</em> handles this internally.</p>
<p><code>STREAM_CAN_FASTSEEK_FORWARD</code> sounds more like <code>STREAM_CAN_FASTSKIP</code>, but I really don’t think that we need more controls in that regard; this particular issue boils down to semantics, not the current state of <code>stream_t</code>.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> As you say, it's a way to know the duration even if it's not written
 specifically. So that's already a fringe case. If the file is
 particularly badly muxed, then too bad it's normal that it doesn't
 play quickly. But we shouldn't remove the feature of knowing the
 duration of a fully written file just to avoid to read bad files too
 much. The same applies for a file with no duration and no Cues. All
 Clusters and the whole last Cluster will need to be parsed. And that
 has nothing to do with the finite size. It has everything to do with
 how fast we can seek through all these data.</code></pre>
</blockquote>
<p>Yes, we already try to compensate for a badly muxed stream, should we then take another step in the “let’s save the muxer” direction, and forgive it for generating clusters with a non-finite size (where the decision to not specifying the size might actually be a valid one)?</p>
<p>In my opinion the theory behind my argumentation holds ground; if a cluster has no size, expecting it to end might be practically possible, but in theory it is not.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> So yes, f2756634ed3601fa7c00e974533f68fcbbb12d06 is wrong IMO too. I
 overlooked it.</code></pre>
</blockquote>
<p>If anything I think it should be an opt-in option if we decide to query non-finite clusters for their duration (in order to get the duration of the entire file).</p>
</body>
</html>