<!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 Francois,</p>
<p>While composing this email I noticed that there is a bug in <code>demux/mp4</code> that neither of our two approaches address; I will create a trac-ticket and fix it as soon as possible.</p>
<p>On 2016-11-04 14:55, Francois Cartegnie wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> Le 04/11/2016 à 14:28, Filip Roséen a écrit :</code></pre>
<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> I'm allowed to check if a box exists or not, even if it's unknown.
 Use cases I can think about: encryption test. We don't decode it, but we
 want to check if it applies.</code></pre>
</blockquote>
</blockquote>
<pre><code> ^</code></pre>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> With that said; rejecting the patch by saying that it is wrong due to
 a problem that the implementation already suffers from is in my
 opinion a *strawman* in terms of argumentation.</code></pre>
</blockquote>
<pre><code> The strawman you're pointing to, isn't set in the right place.</code></pre>
</blockquote>
<p>I replied to what you wrote about the patch disrupting the debug diagnostics, and given that your email did not contain any other information my interpretation was that it was the reason for you not liking the changes introduced.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> You're argumenting about a fix, which does not fix the original problem
 (ie the bug reported reduced the enclosing box by one, creating an
 infinite loop due to failed seek and relative position only), and that
 still broken function could be reused.</code></pre>
</blockquote>
<p>It does fix the immediate issue since known boxes contains data that are to be read by the specific <code>ReadBox</code>-handler, if that <code>ReadBox</code>-<em>callback</em> fails to read the contents of the box, it would/should return <code>0</code> (to signal an error) and the box will be discarded (aborting the infinite loop).</p>
<p>There will however be a problem for a <code>ReadBox</code>-handler, responsible for a <strong>known</strong> box-type, that does not (directly or indirectly) consume any data, but I cannot find any such box in the implementation (nor do I think such box would make much sense).</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 the structured debug output should include boxes that fails to
 parse, the implementation should be changed to include this data (not
 treat an unknown box as if it was parsed successfully, in my opinion).</code></pre>
</blockquote>
<pre><code> This is an inherited 'feature' and there's/was no safe mechanism for
 controlling access to data members on corrupt/empty mandatory boxes.</code></pre>
</blockquote>
<p>Then I honestly do not see the point of bringing that up.</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> And in case you still want to discuss about the "regression",</code></pre>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> p_box->e_flags |= BOX_FLAG_INCOMPLETE;</code></pre>
</blockquote>
<pre><code> wouldn't be there if it was to be released on return.</code></pre>
</blockquote>
<p>The <code>BOX_FLAG_INCOMPLETE</code> is only used in order to print the debug-tree, which inherently suffers from the problem described earlier; boxes that fail to parse are not included.</p>
<p>So that “regression” is, in my opinion, just exposing a bug with the debug implementation (not the other way around).</p>
</body>
</html>