[DBMandrake]

Thanks for sample. The file has timestamps that differ by 40ms (i.e. 25fps), but once a second the difference is 80ms, so there are only actually 24 frames per second.

This seems to be an ugly way of converting 24 fps content to 25 fps. I'm not sure if this was done at source (i.e. on Blu-Ray or by Broadcaster) or in some subsequent conversion.
I can ignore the double length frame differences which stops the unwanted switching.
But you will always have judder on panning shots due to the once a second timestamp jumps.

Ah, that makes perfect sense.

I doubt its mastered like that on a Blu-ray, but I could easily see an over the air broadcaster doing shoddy frame rate "conversion" or whoever encoded it didn't know that trying to convert frame rate is a "bad idea ™".

It really frustrates me how often individuals encoding video screw up the frame rate by attempting unnecessary conversions, and because they're usually testing it on a computer monitor that couldn't display the native frame rate anyway without the player doing pull down they don't realise how much they're messing it up...

(For a good example of commercially mastered video with totally messed up encoding though - look at the PAL Babylon 5 DVD's - live footage was all recorded at 24fps 16:9 on film, but all the CGI and composite shots were rendered at 60i NTSC, (4:3) so in a composite shot on the PAL discs you have 24p film that is cropped to 4:3 then converted to 60i with 3:2 pull down, composited and/or mixed with CGI, frame rate converted and scaled to 50i PAL and cropped again to 16:9 ! What a mess...Live only shots are sped up from 24p to 25p and encoded as is in 16:9 progressive so look far better than the composite/CGI shots)

I've noticed a lot of supposed 25fps material recently which has a small pause once a second, so unfortunately I think shoddy conversion from 24fps to 25fps is actually quite common in some places...

I tried a few other clips which have this same visual cadence of a brief pause once a second on pans and they did not trigger this frame rate switching bug - I don't have anything to analyse the frames (can you recommend a good free program that will go a bit deeper than just showing the container fields ?) but I would guess that in those cases there are actually 25 frames and a constant 40ms timestamp - but the 25th frame is just a duplicate of the 24th so visually the glitch looks the same, whereas in my sample file it just tells the player to wait twice as long after the 24th frame to fill out the gap...

I wonder if there is some way to reliably detect either method and have the player actually treat it as 24fps material by discarding the duplicate frame and re-sampling the sound speed to match ? Lots of potential for things to go wrong of course...