<!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>On 2017-02-21 14:17, Francois Cartegnie wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> Le 07/02/2017 à 13:15, 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> These changes make sure that we start all timestamps at zero by
normalizing each outgoing timestamp to the relative distance from the
first entity received for each stream.</code></pre>
</blockquote>
<pre><code> Seems wrong.
If stream is created late, it should be out of sync then, as the
absolute offset dissapears.
http://streams.videolan.org/samples/V-codecs/h264/hdtv-interlaced/stz_split_top_bottom_field.ts</code></pre>
</blockquote>
<p>The incoming timestamps (as seen by the <em>muxer</em>) are not guaranteed to start at any particular offset, which further means that there is no way to know whether a “stream is created late”.</p>
<p>All the <em>muxer</em> sees is a timestamp, and it will use that as the starting offset for whatever it is muxing. The changes incorporated in the proposed patch does not change any behavior in terms of discontinuity, nor <em>“late starts”</em>.</p>
<p>There is no absolute starting point, all incoming timestamps are relative to each other (not to <code>0</code>), ie. the <em>PCR</em>.</p>
<p>The proposed changes simply adjust the relative starting position so that it is at <code>0</code>, in order to prevent what has already been explained here:</p>
<ul>
<li>https://mailman.videolan.org/pipermail/vlc-devel/2017-February/111420.html</li>
</ul>
<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> + return ( timestamp - *base ) * p_stream->time_base.den /
+ CLOCK_FREQ / p_stream->time_base.num;</code></pre>
</blockquote>
<pre><code> Then what are the guarantees in the code that packet duration is still
correct on output ? PTS(n) - PTS(n-1) == LENGTH(n)</code></pre>
</blockquote>
<p>The line you are referring to above is directly equivalent to what is already in the codebase; if you foresee a problem with the line in question I propose that this is discussed outside of this patch (as the behavior is not new).</p>
</body>
</html>