On Wed, 5 Nov 2014, Anton Khirnov wrote:

Quoting Martin Storsjö (2014-11-04 15:38:09)
From: Michael Niedermayer <[email protected]>

This is the same logic as is invoked on AVFMT_TS_NEGATIVE,
but which can be enabled/disabled manually, or can be enabled
in muxers which only need it in certain conditions.

Also allow using the same mechanis to force streams to start
at 0.

This includes documentation by Stefano Sabatini, Clément Bœsch
and Michael Niedermayer.
---
 doc/muxers.texi             | 26 ++++++++++++++++++++++++++
 libavformat/avformat.h      | 18 +++++++++++++++++-
 libavformat/mux.c           | 12 ++++++++++--
 libavformat/options_table.h |  5 +++++
 libavformat/version.h       |  2 +-
 5 files changed, 59 insertions(+), 4 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 6d2c495..ede7786 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -16,6 +16,32 @@ with the options @code{--enable-muxer=@var{MUXER}} /
 The option @code{-formats} of the av* tools will display the list of
 enabled muxers.

+Some of the generic, muxer independent options are:
+
+@table @option
+@item avoid_negative_ts @var{integer} (@emph{output})
+
+Possible values:
+@table @samp
+@item make_non_negative
+Shift timestamps to make them non-negative.
+Also note that this affects only leading negative timestamps, and not
+non-monotonic negative timestamps.
+@item make_zero
+Shift timestamps so that the first timestamp is 0.
+@item auto (default)
+Enables shifting when required by the target format.
+@item disabled
+Disables shifting of timestamp.
+@end table
+
+When shifting is enabled, all output timestamps are shifted by the
+same amount. Audio, video, and subtitles desynching and relative
+timestamp differences are preserved compared to how they would have
+been without shifting.
+@end table
+
+
 A description of some of the currently available muxers follows.

 @anchor{crc}
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index f28186f..172e59e 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -429,7 +429,10 @@ typedef struct AVProbeData {
                                         timestamps. If not set the timestamp
                                         will be shifted in av_write_frame and
                                         av_interleaved_write_frame so they
-                                        start from 0. */
+                                        start from 0.
+                                        The user or muxer can override this 
through
+                                        AVFormatContext.avoid_negative_ts
+                                        */

 /**
  * @addtogroup lavf_encoding
@@ -1198,6 +1201,19 @@ typedef struct AVFormatContext {
      */
     int max_ts_probe;

+    /**
+     * Avoid negative timestamps during muxing.
+     * Any value of the AVFMT_AVOID_NEG_TS_* constants.
+     * Note, this only works when interleave_packet_per_dts is in use.
+     * - muxing: Set by user
+     * - demuxing: unused
+     */
+    int avoid_negative_ts;
+#define AVFMT_AVOID_NEG_TS_AUTO             -1 ///< Enabled when required by 
target format
+#define AVFMT_AVOID_NEG_TS_DISABLED          0 ///< Do not change timestamps
+#define AVFMT_AVOID_NEG_TS_MAKE_NON_NEGATIVE 1 ///< Shift timestamps so they 
are non negative
+#define AVFMT_AVOID_NEG_TS_MAKE_ZERO         2 ///< Shift timestamps so that 
they start at 0

I'm wondering if allowing the callers to override the format flag and
pass negative timestamps to the muxer that explicitly do not support
that is such a great idea. Is there any conceivable use case for that?

Hmm, mostly for debugging I guess, so I do see the point that it might make sense not to expose that as an option.

How would you suggest making the variable behave in that case, since we'd still want to have that as a possible state for the variable? Just remove the define and the option table entry and leave it at that? If we'd change it to be outside of the allowed avoption range, we'd have to renumber the items, and the current numbering (<0, 0, >0) kinda feels natural.

// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to