[FFmpeg-devel] [PATCH] avfilter/buffersrc: print relevant info when skipping filter reinit

[Carl Eugen Hoyos]

2019-01-26 5:42 GMT+01:00, Gyan <ffmpeg at gyani.pro>:
>
>
> On 26-01-2019 01:17 AM, Carl Eugen Hoyos wrote:
>> 2019-01-25 14:02 GMT+01:00, Gyan <ffmpeg at gyani.pro>:
>>> On 25-01-2019 06:25 PM, Carl Eugen Hoyos wrote:
>>>> 2019-01-25 13:52 GMT+01:00, Gyan <ffmpeg at gyani.pro>:
>>>>> On 25-01-2019 06:11 PM, Carl Eugen Hoyos wrote:
>>>>>> 2019-01-25 13:35 GMT+01:00, Gyan <ffmpeg at 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