Кстати, в некоторых VFR'ах где у контейнера не указан max.fps (например у дампов mpeg-ts с перископа, да и в остальных случаях когда данное значение хоть и указано но не достигается), необходимо высчитывать максимальный фпс:
Делается, это просто, опять таки через файл таймкодов:
1000 делим на (значение вычесть пред.значение), получим межкадровый фпс.
Из получившегося массива находим максимальное, но которое не будет больше 30, 60 (ибо могут быть быстрые кадры с 1000fps)
В последующем, при открытии потока с найденной частотой кадров, VFR будет преобразован к более правильно-единой частоте кадров, для того, чтобы не было лишних дублей для GameDropFix'a.
По сути делается, это через эксель, но неплохо бы иметь такой-же правильный подход к преобразованию VFR to CFR на автоматике и в самом ависинте.
К примеру, зачем уплавнять VFR до 30fps, если поток имеет максимум ~27fps т.е. три якобы 'лишних' кадра GameDropFix посчитает дропом, когда как мог-бы 'дропфикснуть' уже 24fps, но увы 30fps(минус три) планка, и скрипт дропфиксит уже нормальные кадры 
А на следующем этапе (по желанию) эти 27fps уже CFR, можно спокойно поднять до ровных 30fps.
--- --- ---
Исходя из первого возникает еще одна идейка, но куда сложнее, сегментированный дроп фикс:
Плагин проводит анализ файла таймкодов, и на основе него смотрит изменения в частоте кадров, в соотвецтвии с максимальным межкадровым фпс,
и если за 1 секунду времени, на взятом промежутке частота кадров намного ниже межкадрового фпс, то межкадровый фпс для данного промежутка вычисляется дополнительно и в соответствии с ним производится дропфикс.
т.е. производится VFR to FixVFR, но необходимо чтобы этот плагин создавал новый файл таймкодов для нового потока, и уже используя его мюксовать FixVFR.
Схематичный график:
http://s019.radikal.ru/i602/1608/8e/f96facbdb445.png
p.s. Чувствую, с моими идеями, просто avsi файлом не обойтись, тут уже на целый dll тянет 
