Re: [FFmpeg-devel] [PATCH] lavf/mux: do not fail in case of non monotonically increasing DTS values for data packets

2016-02-26 Thread Stefano Sabatini 
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 
> > 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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mux: do not fail in case of non monotonically increasing DTS values for data packets

2016-02-25 Thread Michael Niedermayer 
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 
> 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.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mux: do not fail in case of non monotonically increasing DTS values for data packets

2016-02-25 Thread Stefano Sabatini 
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
>From 0996189555f4a2402b396801da318b4ffcfb1a13 Mon Sep 17 00:00:00 2001
From: Stefano Sabatini 
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.
---
 libavformat/mux.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 789c811..eb0b973 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -554,6 +554,7 @@ static int compute_muxer_pkt_fields(AVFormatContext *s, AVStream *st, AVPacket *
 if (st->cur_dts && st->cur_dts != AV_NOPTS_VALUE &&
 ((!(s->oformat->flags & AVFMT_TS_NONSTRICT) &&
   st->codec->codec_type != AVMEDIA_TYPE_SUBTITLE &&
+  st->codec->codec_type != AVMEDIA_TYPE_DATA &&
   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",
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mux: do not fail in case of non monotonically increasing DTS values for data packets

2016-02-25 Thread Michael Niedermayer 
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.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mux: do not fail in case of non monotonically increasing DTS values for data packets

2016-02-25 Thread Nicolas George 
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


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mux: do not fail in case of non monotonically increasing DTS values for data packets

2016-02-25 Thread Stefano Sabatini 
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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mux: do not fail in case of non monotonically increasing DTS values for data packets

2016-02-23 Thread Michael Niedermayer 
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


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mux: do not fail in case of non monotonically increasing DTS values for data packets

2016-02-23 Thread Stefano Sabatini 
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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mux: do not fail in case of non monotonically increasing DTS values for data packets

2016-02-13 Thread Stefano Sabatini 
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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mux: do not fail in case of non monotonically increasing DTS values for data packets

2015-05-01 Thread Stefano Sabatini 
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
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mux: do not fail in case of non monotonically increasing DTS values for data packets

2015-04-30 Thread Michael Niedermayer 
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


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel