I still haven't quite got my head around what the x264 help file says in relation to setting a timebase Vs the timebase it sets or the timebase required.
http://www.chaneru.com/Roku/HLS/X264...s.htm#timebase
The numerator is 'seconds', and the denominator is 'ticks'. Means how many seconds one tick takes.
If passed a rational, it will set the numerator and denominator accordingly.
If passed an integer, and an input timecodes file is set via tcfile-in, it will use the value passed as the numerator, and generate the denominator accordingly.
If passed an integer, and no input timecodes file is set, it will use the value passed as the denominator and generate the 'ticks per frame' from the input video.
I think I was wrong with my initial assessment of what ReClock was doing. Unless the timebase used is incorrect for the video in question, ReClock does seem to settle down eventually and display the correct frame rate, even if initially it displays the wrong frame rate or shows it's trying to estimate it.
The frame rate of the script seems to effect the timebase chosen by the x264 encoder (and the script frame rate appears to be the average frame rate) but the only time ReClock didn't settle down to displaying the correct frame rate or playback wasn't smooth was when I specified a timebase for the encoder myself that probably didn't make sense, so the moral of the story seems to be, give x264 the timecodes file and let it choose the timebase.