Cannot open DShow capture device twice with same settings

[uzyfeo]

Summary of the bug:

When trying to call avformat_open_input function with specific framerate and resolution set for video capture device, it opens without errors. After closing it (cleaning everything up properly) and openning it again with those same settings, device cannot be opened (this particular function returns -5).
We are using ffmpeg libs in few of our MFC applications. This issue started happening recently (about a week back), without a warning or clear cause (same code that worked doesn't seem to cut it anymore). It seems to be a Windows problem (maybe caused by some update) rather then error of the lib itself, but we cannot confirm this.
We used 4.2.1 for a while and recently updated to 4.2.2 version. Thinking it has to do something with newer version, we tried to roll it back to 4.2.1 without success. Note that on this version, it worked before without issues (hence why we think this might not be issue of the lib). We then tried out latest snapshot with same results.

How to reproduce:

Open video capture device with specific supported framerate and resolution with avformat_open_input function. Then, close it and free all ffmpeg resources (to simulate our usage). After this, try to reinitialize everything again the same way and try to open device with those same settings again. Call should fail with return value -5.

[uzyfeo]

We tried to compile ffmpeg ourselves from 4.2.2 sources and use it as static library instead of shared. We compiled it using VS2019 C++ build tools with debug symbols enabled. After we stepped through code, we found out cause of the issue, although as of now not its origin.

During first run, when avformat_open_input is called, AVFormatCtx it initializes has during its passage through dshow_cycle_formats (found in ffmpeg-4.2.2/libavdevice/dshow.c) value of framerate 0.

After reinitializing capture, it has framerate set to 30.00050 or something like that. This casues chack in function dshow_cycle_formats at line

Found out the culprit. Although, further investigation is still pending.
It seems that, for whatever reason, when specifying framerate that should be used, this value is remembered and passed down until program is closed.

Value is preserved in AVFormatCtx under name framerate. I dont know particular structure as of right now or exact details of how it got set and why it did not got reset properly, but will surely have a look in a bit.

I found the problem after stepping through half of the code, investigating each failed function call. Value in this structure, when it works as intended, is 0. When it fails, it fails because this value was set to 30.0035 or something like that, which is just a tad bit above max limit it checks against.

We never set this value explicitly ourselves in AVFormatContext returned by avformat_open_input, so this value must have been set somewhere after that single check and didn't got cleared properly later on or we are accidentally setting something up we should. As said, no direct modifications were done on these values.

Function and check where it fails and it should have not is in ffmpeg-4.2.2/libavdevice/dshow.c@396.
As ctx->framerate is 0 during first run, this check is not performed. After first run, this value is set when it most probably shouldn't, and if it should, that check should take into account floating point errors properly.