
<!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-wrap;}

      span.smallcaps{font-variant: small-caps;}

      span.underline{text-decoration: underline;}

      div.column{display: inline-block; vertical-align: top; width: 50%;}

  </style>

</head>

<body>

<p>Hi again,</p>

<p>I just now realized that the below commit message somewhat misleadingly uses the term <em>“decoder”</em> in the below quoted section.</p>

<p>On 2018-07-16 05:19, Filip Roséen wrote:</p>

<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">

<pre><code> This works fine in cases where the PCR is updated often enough to

 almost match the track's frames, but in cases where another track is

 preventing the PCR from updating frequently enough (video track with

 long blocks of many matroska-frames), the PCR would be too far in the

 past to base the outgoing block's DTS on. As a result, the decoder

 would think the outgoing blocks were coming in too early and employ

 counter meassures to prevent unwanted drift.</code></pre>

</blockquote>

<p>It is between the actual <em>decoder</em> and the destined <em>audio output</em> this drift prevention is taking place, more specifically in <code>aout_DecSynchronize</code> invoked from <code>aout_Play</code>.</p>

<p>Attached to this message is an updated commit that instead uses <em>"the core</em>" to more accurately describe where this drift prevention is taking place, without going into extensive detail.</p>

<p>Sorry for the inconvience.</p>

<p>Best Regards,<br />

Filip</p>

</body>

</html>