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

[Gyan]

On 26-01-2019 06:40 PM, Carl Eugen Hoyos wrote:
> 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?

Yes, so is your answer to my Q above, yes?

>>>> 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.

Casual users won't see this message as info or warning as it requires an 
undocumented option to be set.

>> Either users grasp the meaning and act upon it themselves,
>> or they can show it to others who do.
> Interesting approach...

If the entire log had to be understandable by all users, it would be 
very short. The user isn't meant to be the only reader of the log. As 
many posters to ffmpeg-user or trac have realized when you post 
"complete, uncut /console/ output /missing/"

>> 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?
Yes, by happenstance.  buffersrc can't predict in advance, and there may 
not be further messages from the filterchain even when output is 
unexpected, hence the warning (and link/frame info).

Try feeding a few images of different sizes to the crop filter with 
reinit disabled, where the crop size is smaller than the first image but 
larger than some of the others. Then examine the output frames. Only the 
existing info level message is shown, with no warnings from downstream.

Gyan