On 04/27/2013 09:21 PM, Justin Ruggles wrote: > On 04/27/2013 05:14 AM, Luca Barbato wrote: >> From: Anton Khirnov <[email protected]> >> >> Only some formats allows non-monotonous DTS, remuxing to a format >> not supporting it requires overwriting the values to something >> acceptable. >> >> Hack partially based on a commit by Michael Niedermayer <[email protected]> >> Should fix (or work around) bug 458. >> >> Signed-off-by: Luca Barbato <[email protected]> >> --- >> >> Would be probably nicer if we check that the input IS supporting them and >> issue a warning and ask for a sample if it does not. >> >> avconv.c | 22 ++++++++++++++++++++++ >> avconv.h | 2 ++ >> avconv_opt.c | 1 + >> 3 files changed, 25 insertions(+) >> >> diff --git a/avconv.c b/avconv.c >> index 658dadc..c8f0536 100644 >> --- a/avconv.c >> +++ b/avconv.c >> @@ -348,6 +348,28 @@ static void write_frame(AVFormatContext *s, AVPacket >> *pkt, OutputStream *ost) >> bsfc = bsfc->next; >> } >> >> + if (!(s->oformat->flags & AVFMT_NOTIMESTAMPS) && >> + ost->last_mux_dts != AV_NOPTS_VALUE && >> + pkt->dts < ost->last_mux_dts + !(s->oformat->flags & >> AVFMT_TS_NONSTRICT)) { >> + av_log(NULL, AV_LOG_WARNING, >> + "Non-monotonous DTS in output stream %d:%d not supported " >> + "by the output format; " >> + "previous: %"PRId64", current: %"PRId64"; ", >> + ost->file_index, ost->st->index, ost->last_mux_dts, >> pkt->dts); >> + if (exit_on_error) { >> + av_log(NULL, AV_LOG_FATAL, "aborting.\n"); >> + exit(1); >> + } >> + av_log(NULL, AV_LOG_WARNING, "changing to %"PRId64". This may >> result " >> + "in incorrect timestamps in the output file.\n", >> + ost->last_mux_dts + 1); >> + >> + pkt->dts = ost->last_mux_dts + 1; > > Would it be better to not increase by 1 for AVFMT_TS_NONSTRICT?
Better keep the dts as they are when they are the same along a group of packets or just edit them doesn't matter what? first case we'd have same-dts when streamcopying from a non-strict to another non-strict. Second case we'd have overwritten dts unnecessarily. Doesn't seem dangerous to always overwrite. lu _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
