Ok, let me try my post again now I've had my coffee...
First off; there is a setting in settings.xml file that will allow btv to display the frame rate on the screen. Can't recall the name off hand but stop btv, edit that file and look for something like displayfps in that file and restart it.
Second; It probably won't help
You may find that btv renders exactly at the frame rate you set your monitor refresh too and you still get jerky video. The main reason being is that your video is recorded at 29.97 frames per second ( 59.94 fields as shorty mentioned) and not 30 fps. However, most video card resolutions don't offer this as a standard video output option. Most drivers allow you to override but still tend to select integer frame rates unless you use something like powerstrip or the custom resolution panels of the drivers to hand tweak the pixel clock frequency.
However, unless you run a genlocked system (which I'm not going to go into here) even if the video said 29.97 and your monitor said 29.97 ... you will still drift. Clock oscillators have a +/- tolerance so no two clock rates will ever match 100%. The closer the recording and display frequencies the better, but ultimately you have a situation where the recording say takes 16 ms and the playback takes 16.1ms per frame (made up numbers). Thus every frame that .1ms difference accrues and will eventually total a complete frame's time. This causes a frame to be replicated or dropped depending on which one is ahead.
And this is problematic for anything like smooth scrolling ticker bars. If you are literally showing the raw capture video frames what you will end up doing is presenting the bar in position A at frame time 0, showing position A at frame time 1, and showing position C at frame time 2. Position B gets skipped, so what you see on screen is an object jumping from A to C erratically. It looks like it paused in position A and then rapidly lept to C instead of smoothly moving.
The key thing to note is that this effect happens even if the renderer is displaying perfectly at 100% frame rate. There are work arounds for this issue, but they are all a trade off of some kind.
The main options that a video application has are:
#1/ Ignore the fact it was recorded at 29.97 fps and pretend it was 30fps - or whatever the monitor is running at or an integer factor of it. You then just play the video back using the gpu/monitor vsync to swap frames. This avoids the frame replication/dropping issues but has one down side. You're running the video faster that it should be and for the audio to stay in sync you have to accelerate that as well. This gives you a increase in pitch of the audio unless you do this fancy shifting of frequencies at the same time (more cpu overhead).
Most basic video players I believe use this method of rendering and ignore the accuracy of the 29.97 vs 30fps frame rates.
#2/ You do the frame replication and keep the audio at the right speed. As mentioned, this has jumpy scrolling artifacts
#3/ You do the frame replication as in #2 but rather than render the frames directly as they were stored, you process the before and after frames and estimate the difference between the two at the time the frame is displayed.
This is rather cpu intensive and is similar to doing a de-interlacing on the image but requires rather more analysis of the image to get it right.
#4/ Set your video mode to an exact multiple of the captured video rate. 29.97 or 59.94 fps etc. While this doesn't eliminate the jerkyness due to clock drift - the closer you can get the display to the capture rate, the less often the jump will occur. Chances are you'll never notice.
if you combine #1 and #4 then you can make the audio shift neglible, display video as it should be without having to process 'inbetween frames' and so on.
Now.. things get a little more hairy when you have interlaced video sources as Shorty mentions. Because it's an odd and even field - the dropping/duplicating a field is far more trouble some. Not only do you get a temporal issue as described above, but you also get a spatial problem in that if you drop a field, all of a sudden you're either swapping odd/even lines on the output video or you've missed a field update - leaving old video data on screen while the new field is rendered making tearing visible.
The perfect video display system would match up the captured video lines exactly 1:1 for the display video resolution. It would also match up video clocks perfectly so there is no drift or neglible rate difference at least.
And note, all this is for a properly done system to avoid effects. I'm not even noting any possible design flaws that might cause jerkiness above and beyond this