[PATCH] lavf/mux: do not fail in case of non monotonically increasing DTS values for data packets
Disable monotonicity test for data packets. Data packets are not supposed to be decoded by FFmpeg, and this checks cause conversion failure with some files with non strictly monotonous timestamps. --- libavformat/mux.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/libavformat/mux.c b/libavformat/mux.c index 9101925..f714168 100644 --- a/libavformat/mux.c +++ b/libavformat/mux.c @@ -486,10 +486,11 @@ static int compute_pkt_fields2(AVFormatContext *s, AVStream *st, AVPacket *pkt) pkt->dts = st->pts_buffer[0]; } - if (st->cur_dts && st->cur_dts != AV_NOPTS_VALUE && + if ((st->codec->codec_type != AVMEDIA_TYPE_DATA) && + (st->cur_dts && st->cur_dts != AV_NOPTS_VALUE && ((!(s->oformat->flags & AVFMT_TS_NONSTRICT) && st->codec->codec_type != AVMEDIA_TYPE_SUBTITLE && - st->cur_dts >= pkt->dts) || st->cur_dts > pkt->dts)) { + st->cur_dts >= pkt->dts) || st->cur_dts > pkt->dts))) { av_log(s, AV_LOG_ERROR, "Application provided invalid, non monotonically increasing dts to muxer in stream %d: %s >= %s\n", st->index, av_ts2str(st->cur_dts), av_ts2str(pkt->dts)); -- 1.8.3.2
On Thu, Apr 30, 2015 at 02:20:52PM +0200, Stefano Sabatini wrote:
Disable monotonicity test for data packets. Data packets are not supposed to be decoded by FFmpeg, and this checks cause conversion failure with some files with non strictly monotonous timestamps. --- libavformat/mux.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
most muxers will not work with packets which arent ordered no matter what type the packets are [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator
On date Thursday 2015-04-30 16:24:08 +0200, Michael Niedermayer encoded:
On Thu, Apr 30, 2015 at 02:20:52PM +0200, Stefano Sabatini wrote:
Disable monotonicity test for data packets. Data packets are not supposed to be decoded by FFmpeg, and this checks cause conversion failure with some files with non strictly monotonous timestamps. --- libavformat/mux.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
most muxers will not work with packets which arent ordered no matter what type the packets are
Fine, I will drop the patch. The application level can take care of that if needed (by sorting the misordered packets). -- FFmpeg = Frenzy & Fundamentalist Muttering Plastic Enhancing Geisha
On date Friday 2015-05-01 19:10:17 +0200, Stefano Sabatini encoded:
On date Thursday 2015-04-30 16:24:08 +0200, Michael Niedermayer encoded:
On Thu, Apr 30, 2015 at 02:20:52PM +0200, Stefano Sabatini wrote:
Disable monotonicity test for data packets. Data packets are not supposed to be decoded by FFmpeg, and this checks cause conversion failure with some files with non strictly monotonous timestamps. --- libavformat/mux.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
most muxers will not work with packets which arent ordered no matter what type the packets are
Fine, I will drop the patch. The application level can take care of that if needed (by sorting the misordered packets).
I have an use case with data packets that have the same PTS (which makes sense in that specific case). Since I want to fix this issue, and dropping the check inconditionally may not be acceptable, I propose the following variants: * I add an option to drop strict monotonicity checks on data packets * I enable a format level capability which disables the strict monotonicity requirement for data packets depending on the format What do you find acceptable? -- FFmpeg = Faithless Fantastic Most Prodigious Explosive Generator
On date Saturday 2016-02-13 18:46:55 +0100, Stefano Sabatini encoded:
On date Friday 2015-05-01 19:10:17 +0200, Stefano Sabatini encoded:
On date Thursday 2015-04-30 16:24:08 +0200, Michael Niedermayer encoded:
On Thu, Apr 30, 2015 at 02:20:52PM +0200, Stefano Sabatini wrote:
Disable monotonicity test for data packets. Data packets are not supposed to be decoded by FFmpeg, and this checks cause conversion failure with some files with non strictly monotonous timestamps. --- libavformat/mux.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
most muxers will not work with packets which arent ordered no matter what type the packets are
Fine, I will drop the patch. The application level can take care of that if needed (by sorting the misordered packets).
I have an use case with data packets that have the same PTS (which makes sense in that specific case). Since I want to fix this issue, and dropping the check inconditionally may not be acceptable, I propose the following variants:
* I add an option to drop strict monotonicity checks on data packets
* I enable a format level capability which disables the strict monotonicity requirement for data packets depending on the format
What do you find acceptable?
Ping. -- FFmpeg = Forgiving Forgiving Mournful Pitiful Enhancing Ghost
On Tue, Feb 23, 2016 at 07:34:16PM +0100, Stefano Sabatini wrote:
On date Saturday 2016-02-13 18:46:55 +0100, Stefano Sabatini encoded:
On date Friday 2015-05-01 19:10:17 +0200, Stefano Sabatini encoded:
On date Thursday 2015-04-30 16:24:08 +0200, Michael Niedermayer encoded:
On Thu, Apr 30, 2015 at 02:20:52PM +0200, Stefano Sabatini wrote:
Disable monotonicity test for data packets. Data packets are not supposed to be decoded by FFmpeg, and this checks cause conversion failure with some files with non strictly monotonous timestamps. --- libavformat/mux.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
most muxers will not work with packets which arent ordered no matter what type the packets are
Fine, I will drop the patch. The application level can take care of that if needed (by sorting the misordered packets).
I have an use case with data packets that have the same PTS (which makes sense in that specific case). Since I want to fix this issue, and dropping the check inconditionally may not be acceptable, I propose the following variants:
* I add an option to drop strict monotonicity checks on data packets
* I enable a format level capability which disables the strict monotonicity requirement for data packets depending on the format
What do you find acceptable?
i think its fine to treat data the same as subtitles
Ping. -- FFmpeg = Forgiving Forgiving Mournful Pitiful Enhancing Ghost _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB DNS cache poisoning attacks, popular search engine, Google internet authority dont be evil, please
On date Tuesday 2016-02-23 20:32:23 +0100, Michael Niedermayer encoded:
On Tue, Feb 23, 2016 at 07:34:16PM +0100, Stefano Sabatini wrote: [...]
I have an use case with data packets that have the same PTS (which makes sense in that specific case). Since I want to fix this issue, and dropping the check inconditionally may not be acceptable, I propose the following variants:
* I add an option to drop strict monotonicity checks on data packets
* I enable a format level capability which disables the strict monotonicity requirement for data packets depending on the format
What do you find acceptable?
i think its fine to treat data the same as subtitles
In general, we can assume that makes no sense to have more than one packet with the same PTS/DTS for audio or video and for the same stream. As for subtitles, I'm not sure we should accept that as well, but at least in theory I can imagine an use case with multiple packets (and thus frames) conveying text information pertaining to the same time and stream. As for data, I think we can safely assume several piece of generic data in different packets but with the same timestamp, since they are meant to be processed by an automated agent. So, while the check makes sense for audio and video, in the case of subtitles and data we are in the fuzzy area. In principle, I agree with the fact that data and subtitles should be treated in the same way, so I propose the following options: 1. disable the strict monotonicity check for both data and subtitles inconditionally 2. add a libavformat muxing option to disable strictness in the timestamps monotonicity check for both data and subtitles 3. generalize 2. and provide a libavformat muxing option to disable strictness in the timestamps monotonicity check for some selection of output streams (e.g. using stream specifiers) I have no special preference, so I'd leave this decision to the libavformat maintainer (which I believe it's still you ;-)). In case any of these solutions is not considered acceptable, I need to come with an application level solution (but this would mean that ffmpeg the tool cannot be used for that). -- FFmpeg = Fast and Formidable MultiPurpose Efficient Goblin
Le septidi 7 ventôse, an CCXXIV, Stefano Sabatini a écrit :
As for subtitles, I'm not sure we should accept that as well, but at least in theory I can imagine an use case with multiple packets (and thus frames) conveying text information pertaining to the same time and stream.
Simultaneous subtitles happens in practice quite frequently with ASS: people talking at the same time, background dialog, translation of visible signs and other texts, karaoke and translation of songs, credits, etc. The strict monotonicity test was initially bypassed by merging the ASS dialog events together, but this was an ugly hack and Clément is trying to finally get rid of its last traces. Regards, -- Nicolas George
On Thu, Feb 25, 2016 at 01:11:36PM +0100, Stefano Sabatini wrote:
On date Tuesday 2016-02-23 20:32:23 +0100, Michael Niedermayer encoded:
On Tue, Feb 23, 2016 at 07:34:16PM +0100, Stefano Sabatini wrote: [...]
I have an use case with data packets that have the same PTS (which makes sense in that specific case). Since I want to fix this issue, and dropping the check inconditionally may not be acceptable, I propose the following variants:
* I add an option to drop strict monotonicity checks on data packets
* I enable a format level capability which disables the strict monotonicity requirement for data packets depending on the format
What do you find acceptable?
i think its fine to treat data the same as subtitles
In general, we can assume that makes no sense to have more than one packet with the same PTS/DTS for audio or video and for the same stream.
As for subtitles, I'm not sure we should accept that as well, but at least in theory I can imagine an use case with multiple packets (and thus frames) conveying text information pertaining to the same time and stream. As for data, I think we can safely assume several piece of generic data in different packets but with the same timestamp, since they are meant to be processed by an automated agent.
So, while the check makes sense for audio and video, in the case of subtitles and data we are in the fuzzy area. In principle, I agree with the fact that data and subtitles should be treated in the same way, so I propose the following options:
1. disable the strict monotonicity check for both data and subtitles inconditionally
yes, do with data what is done with subtitles already IIRC
2. add a libavformat muxing option to disable strictness in the timestamps monotonicity check for both data and subtitles
3. generalize 2. and provide a libavformat muxing option to disable strictness in the timestamps monotonicity check for some selection of output streams (e.g. using stream specifiers)
I have no special preference, so I'd leave this decision to the libavformat maintainer (which I believe it's still you ;-)).
In case any of these solutions is not considered acceptable, I need to come with an application level solution (but this would mean that ffmpeg the tool cannot be used for that). -- FFmpeg = Fast and Formidable MultiPurpose Efficient Goblin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
-- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong.
On date Thursday 2016-02-25 13:41:02 +0100, Michael Niedermayer encoded:
On Thu, Feb 25, 2016 at 01:11:36PM +0100, Stefano Sabatini wrote: [...]
So, while the check makes sense for audio and video, in the case of subtitles and data we are in the fuzzy area. In principle, I agree with the fact that data and subtitles should be treated in the same way, so I propose the following options:
1. disable the strict monotonicity check for both data and subtitles inconditionally
yes, do with data what is done with subtitles already IIRC
See attached patch. [...] -- FFmpeg = Fiendish and Fierce Mastering Political Empowered Geisha
On Thu, Feb 25, 2016 at 07:02:31PM +0100, Stefano Sabatini wrote:
On date Thursday 2016-02-25 13:41:02 +0100, Michael Niedermayer encoded:
On Thu, Feb 25, 2016 at 01:11:36PM +0100, Stefano Sabatini wrote: [...]
So, while the check makes sense for audio and video, in the case of subtitles and data we are in the fuzzy area. In principle, I agree with the fact that data and subtitles should be treated in the same way, so I propose the following options:
1. disable the strict monotonicity check for both data and subtitles inconditionally
yes, do with data what is done with subtitles already IIRC
See attached patch.
[...] -- FFmpeg = Fiendish and Fierce Mastering Political Empowered Geisha
mux.c | 1 + 1 file changed, 1 insertion(+) 28a1647f5cd7b49f6fe439777af61241adf5c19f 0001-lavf-mux-do-not-fail-in-case-of-non-strictly-monoton.patch From 0996189555f4a2402b396801da318b4ffcfb1a13 Mon Sep 17 00:00:00 2001 From: Stefano Sabatini <stefasab@gmail.com> Date: Thu, 17 Dec 2015 20:51:42 +0100 Subject: [PATCH] lavf/mux: do not fail in case of non strictly monotonically increasing DTS values for data packets
Consistent with what we already do with subtitles since ac08c5c0adcb7f2f9b5ea3eb473d1c2b9659aab2.
LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better.
On date Friday 2016-02-26 01:52:47 +0100, Michael Niedermayer encoded:
On Thu, Feb 25, 2016 at 07:02:31PM +0100, Stefano Sabatini wrote: [...]
From 0996189555f4a2402b396801da318b4ffcfb1a13 Mon Sep 17 00:00:00 2001 From: Stefano Sabatini <stefasab@gmail.com> Date: Thu, 17 Dec 2015 20:51:42 +0100 Subject: [PATCH] lavf/mux: do not fail in case of non strictly monotonically increasing DTS values for data packets
Consistent with what we already do with subtitles since ac08c5c0adcb7f2f9b5ea3eb473d1c2b9659aab2.
LGTM
Applied, thanks. -- FFmpeg = Free & Fanciful Mortal Pacific Evangelical Gangster
participants (4)
-
Michael Niedermayer -
Michael Niedermayer -
Nicolas George -
Stefano Sabatini