2019-01-26 5:42 GMT+01:00, Gyan <ffm...@gyani.pro>: > > > On 26-01-2019 01:17 AM, Carl Eugen Hoyos wrote: >> 2019-01-25 14:02 GMT+01:00, Gyan <ffm...@gyani.pro>: >>> On 25-01-2019 06:25 PM, Carl Eugen Hoyos wrote: >>>> 2019-01-25 13:52 GMT+01:00, Gyan <ffm...@gyani.pro>: >>>>> On 25-01-2019 06:11 PM, Carl Eugen Hoyos wrote: >>>>>> 2019-01-25 13:35 GMT+01:00, Gyan <ffm...@gyani.pro>: >>>>>> >>>>>>> + av_log(s, AV_LOG_WARNING, "Changing video frame >>>>>>> properties on the fly is not supported by all filters.\n");\ >>>>>> In which situations is this new warning shown? >>>>> e.g. >>>>> -reinit_filter 0 -i ChangingResolutions.mp4 -vf somefilter ... >>>> Is it only shown if the filter does not support re-initialization? >>>> >>> No. As the existing msgs indicate, it is always printed when >>> _some_ frame properties have changed. >> I may misunderstand but I believe that no warning should be >> shown in this case. > > Are you objecting to the loglevel? Because a message was > _always_ shown - I just added a line with metadata and changed > the loglevel of the existing message to warning, which the > character of the message warrants.
Do we agree that without your patch no warning is shown while with your patch a warning is shown? >>> The new addition allows the user to discover which properties >>> those are, with timestamp. They can then choose to continue, >>> allow reinit or partition the input (if viable) as appropriate. >> It appears to me that the only thing the message would do is >> to confuse users that do not understand the warning (but see >> above). > > Most casual users don't understand most of the warnings. This seems to support my objections to the patch. > Either users grasp the meaning and act upon it themselves, > or they can show it to others who do. Interesting approach... > I see no benefit to fatal or unusual changes remaining opaque. > This hardly even adds to the verbosity. Let me rephrase my original questions: Are there command lines for which the warning is shown although the (video) filter chain will work as expected? Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
