<!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>I appreciate you taking time to answer my questions, even though it has now become evident that I do not agree with what you were referring to as a regression (missing debug data).</p>
<p>On 2016-11-04 12:58, 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 à 12:07, 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> Sure, there might be unknown boxes which we cannot handle - but I
still fail to see how the patch would lead to a regression related to
how those boxes are handled.</code></pre>
</blockquote>
<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 style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> From my understanding other boxes can signal errors in the same way as
`MP4_ReadBox_default` would if the patch is applied, so I must be
missing something.</code></pre>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> | | + udta size 83 offset 600
| | | + creq size 36 offset 608
| | | + cenc size 39 offset 644 (????)</code></pre>
</blockquote>
<pre><code> Could you point me in the direction of a failure related to the patch
so that I properly understand why such thing should not be done (not
now, nor in the future)?</code></pre>
</blockquote>
<pre><code> I'll send a patch to remove every structured debug output from mkv.
I hope you won't be too annoyed to debug later issues.</code></pre>
</blockquote>
<p>I’d argue that this is a flaw in the code that handles the box-dumping (and other debug logs), not the return-value of <code>MP4_ReadBox_default</code>.</p>
<p>I also do not see the relevance of even mentioning removing structured output from some unrelated demuxer.</p>
<hr style="height:1px;margin-bottom:20px;background-color:#ddd;color:#ddd" />
<h3 id="why-i-do-not-agree-that-the-problem-is-specific-to-the-patch">Why I do not agree that the <em>“problem”</em> is specific to the patch</h3>
<p>The structured debug output will <strong>not</strong> contain boxes that fail to parse in either case, even if this is a known box; so what you are describing is, in my opinion, not specific to the patch we are currently discussing.</p>
<p>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 <em>strawman</em> in terms of argumentation.</p>
<p>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).</p>
<hr style="height:1px;margin-bottom:20px;background-color:#ddd;color:#ddd" />
<p>Best Regards,<br />
Filip</p>
</body>
</html>