| Message ID | d0840e6a-7f0e-92ff-675c-ea89b7776b67@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
On Tue, 26 Jun 2018, Gyan Doshi wrote: > Many users have queried/complained about the 'Past duration too large' > messages. If the message is useless, then why not remove it entirely? Thanks, Marton
On 26-06-2018 04:29 PM, Marton Balint wrote: >> Many users have queried/complained about the 'Past duration too large' >> messages. > > If the message is useless, then why not remove it entirely? Good question. Don't see the point but Michael added it (4e20e94921) so may have some use for it that I'm missing. Thoughts, Michael? Regards, Gyan
On Tue, Jun 26, 2018 at 05:13:36PM +0530, Gyan Doshi wrote: > > > On 26-06-2018 04:29 PM, Marton Balint wrote: > > >>Many users have queried/complained about the 'Past duration too large' > >>messages. > > > >If the message is useless, then why not remove it entirely? > > Good question. Don't see the point but Michael added it (4e20e94921) so may > have some use for it that I'm missing. > > Thoughts, Michael? I think, the condition shouldnt happen really its a while ago i worked with this part but if when the previous frame is processed the code thinks it it will last at minimum till X and then when processing the next frame that starts significantgly before X. It would seem that something somewhere isnt working correctly [...]
On Wed, 27 Jun 2018, Michael Niedermayer wrote: > On Tue, Jun 26, 2018 at 05:13:36PM +0530, Gyan Doshi wrote: >> >> >> On 26-06-2018 04:29 PM, Marton Balint wrote: >> >>>> Many users have queried/complained about the 'Past duration too large' >>>> messages. >>> >>> If the message is useless, then why not remove it entirely? >> >> Good question. Don't see the point but Michael added it (4e20e94921) so may >> have some use for it that I'm missing. >> >> Thoughts, Michael? > > I think, the condition shouldnt happen really Why not? For CFR output frames are dropped if delta0 < -1.1, but an error is reported if delta0 < -0.6. So delta0 can remain indefinitely between -1.1 and -0.6 spamming the console endlessly. Or am I missing something? > its a while ago i worked with this part but if when the previous frame > is processed the code thinks it it will last at minimum till X and then > when processing the next frame that starts significantgly before X. > It would seem that something somewhere isnt working correctly Maybe we should disable the message for CFR only? Thanks, Marton
On 27-06-2018 06:33 AM, Marton Balint wrote: > > Maybe we should disable the message for CFR only? First question is, who is the message meant for? End-users can't do anything with it. At most, a one-time message is fine, similar to the "More than 1000 frames duplicated" message. Regards, Gyan
On Wed, Jun 27, 2018 at 03:03:02AM +0200, Marton Balint wrote: > > > On Wed, 27 Jun 2018, Michael Niedermayer wrote: > > >On Tue, Jun 26, 2018 at 05:13:36PM +0530, Gyan Doshi wrote: > >> > >> > >>On 26-06-2018 04:29 PM, Marton Balint wrote: > >> > >>>>Many users have queried/complained about the 'Past duration too large' > >>>>messages. > >>> > >>>If the message is useless, then why not remove it entirely? > >> > >>Good question. Don't see the point but Michael added it (4e20e94921) so may > >>have some use for it that I'm missing. > >> > >>Thoughts, Michael? > > > >I think, the condition shouldnt happen really > > Why not? For CFR output frames are dropped if delta0 < -1.1, but an error is > reported if delta0 < -0.6. So delta0 can remain indefinitely between -1.1 > and -0.6 spamming the console endlessly. > > Or am I missing something? well if you have input like timestamps: 1 2 4 5 7 9 durations: 1 2 1 2 1 1 then the warning should never trigger no matter what frame rate convertion is used It was intended IIRC to detect cases where the code misbeahves or where the input/demuxer/parser is badly broken as in: timestamps: 1 2 4 5 7 9 durations: 9 8 1 -3 7 99 Maybe the condition to display the warning is faulty [...]
On 27-06-2018 05:13 PM, Michael Niedermayer wrote: > > It was intended IIRC to detect cases where the code misbeahves or where the > input/demuxer/parser is badly broken as in: > > timestamps: 1 2 4 5 7 9 > durations: 9 8 1 -3 7 99 > > > Maybe the condition to display the warning is faulty It can be triggered by the following command form: ffmpeg -f image2 -framerate X -i images -r Y -vsync vfr out where 0.6*X < Y < X. It always spams my console when I'm saving a live capture to MPEG-TS. This patch is less about the logic and more about a cleaner stderr. Are you planning to revisit the logic? If not, I'd like to push this. Thanks, Gyan
On Wed, 27 Jun 2018, Gyan Doshi wrote: > On 27-06-2018 05:13 PM, Michael Niedermayer wrote: > >> >> It was intended IIRC to detect cases where the code misbeahves or where the >> input/demuxer/parser is badly broken as in: >> >> timestamps: 1 2 4 5 7 9 >> durations: 9 8 1 -3 7 99 >> >> >> Maybe the condition to display the warning is faulty > > It can be triggered by the following command form: > > ffmpeg -f image2 -framerate X -i images -r Y -vsync vfr out > > where 0.6*X < Y < X. > > It always spams my console when I'm saving a live capture to MPEG-TS. > This patch is less about the logic and more about a cleaner stderr. > > Are you planning to revisit the logic? If not, I'd like to push this. If we don't know why it spams the console or nobody is willing to fix it, then decrease loglevel to verbose. I am strongly against adding a command line option for this. Regards, Marton
On Wed, Jun 27, 2018, at 10:00 AM, Marton Balint wrote: > > If we don't know why it spams the console or nobody is willing to fix it, > then decrease loglevel to verbose. I am strongly against adding a command > line option for this. I was just about to give the same suggestion.
On 27-06-2018 11:30 PM, Marton Balint wrote: > > If we don't know why it spams the console or nobody is willing to fix it, > then decrease loglevel to verbose. Will do this instead. Thanks, Gyan
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi index 3717f22d42..c3fc449a38 100644 --- a/doc/ffmpeg.texi +++ b/doc/ffmpeg.texi @@ -1407,6 +1407,9 @@ With -map you can select from which stream the timestamps should be taken. You can leave either video or audio unchanged and sync the remaining stream(s) to the unchanged one. +@item -hide_vsync_warning (@emph{global}) +Don't print video sync warnings about frame duration during rate conversion. + @item -frame_drop_threshold @var{parameter} Frame drop threshold, which specifies how much behind video frames can be before they are dropped. In frame rate units, so 1.0 is one frame. diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c index 8d311a9ac8..2e8450cece 100644 --- a/fftools/ffmpeg.c +++ b/fftools/ffmpeg.c @@ -1121,7 +1121,8 @@ static void do_video_out(OutputFile *of, format_video_sync != VSYNC_PASSTHROUGH && format_video_sync != VSYNC_DROP) { if (delta0 < -0.6) { - av_log(NULL, AV_LOG_WARNING, "Past duration %f too large\n", -delta0); + if (!hide_vsync_warning) + av_log(NULL, AV_LOG_WARNING, "Past duration %f too large\n", -delta0); } else av_log(NULL, AV_LOG_DEBUG, "Clipping frame in rate conversion by %f\n", -delta0); sync_ipts = ost->sync_opts; diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h index eb1eaf6363..aa46d683c8 100644 --- a/fftools/ffmpeg.h +++ b/fftools/ffmpeg.h @@ -606,6 +606,7 @@ extern int frame_bits_per_raw_sample; extern AVIOContext *progress_avio; extern float max_error_rate; extern char *videotoolbox_pixfmt; +extern int hide_vsync_warning; extern int filter_nbthreads; extern int filter_complex_nbthreads; diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c index 58ec13e5a8..9a88f6d3e8 100644 --- a/fftools/ffmpeg_opt.c +++ b/fftools/ffmpeg_opt.c @@ -110,6 +110,7 @@ float max_error_rate = 2.0/3; int filter_nbthreads = 0; int filter_complex_nbthreads = 0; int vstats_version = 2; +int hide_vsync_warning = 0; static int intra_only = 0; @@ -3382,6 +3383,8 @@ const OptionDef options[] = { "add timings for each task" }, { "progress", HAS_ARG | OPT_EXPERT, { .func_arg = opt_progress }, "write program-readable progress information", "url" }, + { "hide_vsync_warning", OPT_BOOL | OPT_EXPERT, { &hide_vsync_warning }, + "don't print video sync warnings" }, { "stdin", OPT_BOOL | OPT_EXPERT, { &stdin_interaction }, "enable or disable interaction on standard input" }, { "timelimit", HAS_ARG | OPT_EXPERT, { .func_arg = opt_timelimit },
Many users have queried/complained about the 'Past duration too large' messages. Regards, Gyan From 9e265308865455c4a61b0cb65840466b4d575670 Mon Sep 17 00:00:00 2001 From: Gyan Doshi <ffmpeg@gyani.pro> Date: Tue, 26 Jun 2018 15:42:04 +0530 Subject: [PATCH] fftools/ffmpeg: add option to hide vsync warnings When transcoding a video stream with a lower-resolution encoding timebase, ffmpeg log can get bloated with video sync warnings viz. "Past duration %f too large". These are not actionable for end-users and can also make the progress readout disappear at times, which is not desirable, like during a live capture. Added option -hide_vsync_warning suppresses these messages. --- doc/ffmpeg.texi | 3 +++ fftools/ffmpeg.c | 3 ++- fftools/ffmpeg.h | 1 + fftools/ffmpeg_opt.c | 3 +++ 4 files changed, 9 insertions(+), 1 deletion(-)