[FFmpeg-cvslog] avformat/mux: set avoid_negative_ts based on flags if not overridden by user or muxer

[Michael Niedermayer]

On Wed, Oct 16, 2013 at 04:07:41PM +0200, Nicolas George wrote:
> Le septidi 7 floréal, an CCXXI, Michael Niedermayer a écrit :
> > ffmpeg | branch: master | Michael Niedermayer <michaelni at gmx.at> | Fri Apr 26 11:52:51 2013 +0200| [eba33396f007dc373678adea6c1a4b1a50373263] | committer: Michael Niedermayer
> > 
> > avformat/mux: set avoid_negative_ts based on flags if not overridden by user or muxer
> > 
> > This changes the default to avoid negative timestamps.
> 
> I suggest we consider reverting that: the files produced by the actual
> avoid_negative_ts code, which seem to come from the fork, look bogus.

the original code was from me:
the current code is a combination of both implementations features
and bugfixes (in theory at least)

commit 3ba0dab76ac32f0c9f50c916a73bc64e43c1fdf9
Author: Michael Niedermayer <michaelni at gmx.at>
Date:   Wed Sep 26 15:55:16 2012 +0200

    lavf: Add support offset timestamps on muxing.

    This allows avoiding negative timestamps.

    Signed-off-by: Michael Niedermayer <michaelni at gmx.at>

----
commit c2cb01d418dd18e1cf997c038d37378d773121be
Author: Luca Barbato <lu_zero at gentoo.org>
Date:   Wed Apr 3 14:11:10 2013 +0200

    lavf: introduce AVFMT_TS_NEGATIVE

    Most formats do not support negative timestamps, shift them to avoid
    unexpected behaviour and a number of bad crashes.

    CC:libav-stable at libav.org

    Signed-off-by: Anton Khirnov <anton at khirnov.net>
    Signed-off-by: Luca Barbato <lu_zero at gentoo.org>



> 
> For example:
> 
> ./ffmpeg_g -lavfi testsrc=d=1 -c libx264 -preset veryfast -crf 20 \
>   -avoid_negative_ts 1 -y /tmp/testout.mkv
> 
> produces this:
> 
> packet|stream_index=0|pts_time=0.080000|dts_time=N/A
> packet|stream_index=0|pts_time=0.240000|dts_time=N/A
> packet|stream_index=0|pts_time=0.160000|dts_time=0.080000
> packet|stream_index=0|pts_time=0.120000|dts_time=0.120000
> packet|stream_index=0|pts_time=0.200000|dts_time=0.160000
> packet|stream_index=0|pts_time=0.400000|dts_time=0.200000
> 
> and this:
> 
> format|start_time=0.000000|duration=1.080000
> 
> The start_time and duration seems clearly wrong.

id guess thats because of
libavformat/matroskadec.c:        st->start_time = 0;

does matroska require the start time to be 0 ? if not then the
line above looks suspect, OTOH, if it does need the first pts to be
0 then it actually does need timestamps to be shifted to achive that
theres no gurantee that the muxer input starts with pts=0

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-cvslog/attachments/20131017/f1f2efc7/attachment.asc>