23.976 as 24 is quite big difference, so I'm not sure if the v-sync correction calculations would be able to correct such big difference (in reference clock side the difference is big ). V-sync correction is targeted for example for HW errors like 23.976 as 23.972 (or for case where audio clock is a bit faster / slowed). Which basicly means that the bias control should be accurate as possible, so I would assume that those are way too big differences.
Isn't the video decoder providing proper sample durations that could be used to detect the real incoming rate?
It's a nice idea, but I've seen situations where the sample durations don't match the sample timestamp deltas.....you could regard those as 'broken' files (or decoders), but red5goahead's example is also a 'broken' file, so which set of FPS values do you trust ?
Tony