Quoting Martin Storsjö (2014-11-05 17:47:12) > 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. >
Just dropping the define and the option is fine for me. -- Anton Khirnov _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
