I wrote a tool to show which of the MP4 files you gave me is the most VFR-ish. It is 20170720_191239.mp4. The frame rate is 29.97 declared. The first timestamp is 0 and the second is 4202. It should be 2997, so it is 1205 too large. But 1205 is not a full frame (2997) so we can't dup this one. Then the stamps oscillate around a delta of 2997 (some a wee bit short and some a wee bit long). About 3/4 of the way through there is a delta of 5259, which is 2262. The accumulated deviation is now about 1205+2262=3467, which is larger than 2997, so we can dup a frame here. The rest of the stream has only the wee deviations around 2997.
Now using ffmpeg to convert to CFR, we find that is exactly what is done, and the final converted stream has one extra frame inserted at the point. This is certainly not very VFR-ish, and I wish you had some more highly VFR-ish files. Nevertheless, I will come to an interim conclusion: The way to convert is to track the accumulated deviation and insert a frame when it exceeds one frame time, then adjust the accumulated deviation accordingly. This is just what the existing converters like ffmpeg do. Now the question is whether there is any advantage to CUDA-izing the process. I do not see anything in the algorithm that would benefit. The gain from trying to include this processing in DGSource() is small compared to having a separate filter or preprocessing with ffmpeg. So tentatively I'm going to decide not to do anything.
Note that there is no difference perceptually between showing a frame for 100ms versus showing the same frame twice for 50ms each. I do not see how interpolation can be relevant here. It would just introduce things that are not present in the source.
You are welcome to try to convince me otherwise.
![Wink ;)](./images/smilies/icon_e_wink.gif)