<!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 Rémi,</p>
<p>On 2017-02-07 15:22, Rémi Denis-Courmont wrote:</p>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code> On February 7, 2017 2:15:21 PM GMT+02:00, "Filip Roséen" <filip@atch.se> wrote:</code></pre>
<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;color:#500050">
<pre><code>modules/demux/avformat/mux.c | 48
++++++++++++++++++++++++++++++++++----------
 1 file changed, 37 insertions(+), 11 deletions(-)</code></pre>
<p>Hello,</p>
</blockquote>
<pre><code> AFAIK, the first block is not necessarily the one with the smalledt
 PTS and the smallest DTS. There might not even be such a block.

 So I guess, this patch may cause negative timestamps in certain corner cases.</code></pre>
</blockquote>
<p>Yes, I was thinking the same but when I did some testing it turns out that negative timestamps are, to my initial surprise, handled correctly by <em>avformat</em> (in terms of what it actually generates in the end).</p>
<p>They are adjusted to be starting at zero by <code>mux.c:write_packet</code>, which is called from within <code>av_write_frame</code> (from my skimming of the source code).</p>
<p>Link to documentation for the relevant function where the magic happens:</p>
<ul>
<li>https://ffmpeg.org/doxygen/3.2/mux_8c.html#a35b04d31f9156dd1dbca471d097741d8</li>
<li>https://ffmpeg.org/doxygen/3.2/mux_8c_source.html#l00693</li>
</ul>
<p>I just tried with explicitly making the timestamps negative by modifying the source code in the following way, and the generated output is correct for the containers that I have tested.</p>
<pre><code>diff --git a/modules/demux/avformat/mux.c b/modules/demux/avformat/mux.c
index b2b7bb467d..86cd284180 100644
--- a/modules/demux/avformat/mux.c
+++ b/modules/demux/avformat/mux.c
@@ -376,11 +376,11 @@ static int MuxBlock( sout_mux_t *p_mux, sout_input_t *p_input )
 
     if( p_data->i_pts > 0 )
         pkt.pts = NormalizeTS( &p_input_sys->base_ts.i_pts,
-                                p_stream, p_data->i_pts );
+                                p_stream, p_data->i_pts ) - 1013370;
 
     if( p_data->i_dts > 0 )
         pkt.dts = NormalizeTS( &p_input_sys->base_ts.i_dts,
-                                p_stream, p_data->i_dts );
+                                p_stream, p_data->i_dts ) - 1013370;
 
     /* This is another hack to prevent libavformat from triggering the
      * "non monotone timestamps" check in avformat/utils.c */</code></pre>
<p>The above together with my skimming of the source makes me believe that the behavior for negative timestamps are well-defined for the muxers within <em>avformat</em> that might have issues with such, though if there turns out to be problems that I have yet to encounter I would be happy to polish the patch in some way or another.</p>
<p>Thanks,<br />
Filip Roséen</p>
</body>
</html>