<!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>I think we can agree on the fact that we do not agree about the semantics of how to treat unread clusters of unknown size.</p>
<p>My primary objective was to fix the crash, if you want to change the semantics of <code>EnsureDuration</code> (which you approved in the previous patch-set) I will not be overly excited, but as long as the crash is fixed.. it’s better than nothing.</p>
<p>Thanks,<br />
Filip Roséen</p>
<p>On 2016-11-02 09:50, Steve Lhomme wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> If the source is not being update/appended while reading (a finite
size file) then you know where the end is and you can fully parse the
file.</code></pre>
</blockquote>
<p>Of course, when the stream is fully exhausted we can seek back to the beginning and play the file; but my reasoning is precisely not to exhaust a stream where an non-finite cluster is present.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> That has nothing to do with the fact the muxer didn't know the end
when it wrote the data.</code></pre>
</blockquote>
<p>The fact that the <em>muxer</em> did not know, or was not clever enough to fill in that piece of data after the cluster was created, should not cause us to potentially run into issues where playback does not start within a reasonable amount of time, or not at all, because we are waiting for <code>EnsureDuration</code> to finish.</p>
<p>I rather eliminate all <em>false-positives</em> and not exhaust clusters where the size is inherently unknown, than to start running through the stream (when we have no idea where we will stop).</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> So far we rely on STREAM_CAN_FASTSEEK in EnsureDuration to tell in
which case we are. It may not be perfect but that's closer to not
parsing the duration for a fully written file.</code></pre>
</blockquote>
<p><code>EnsureDuration</code> is a <strong>hack</strong> to get a duration for files that does not include such in its metadata, and with that I don’t think we should invoke usage of this hack in places where we cannot prove (to <code>100%</code>) that the stream actually is finite (if the size of a cluster is not there, nothing states that we will get to the end).</p>
</body>
</html>