Frame Rate Tester

[grandpaken]

How do you tell the actual frame rate we're capturing at? Is the jerkiness of scrolling news banners due to dropped frames or delayed frames...meaning if you're getting 30 fps but they come in spurts of 5 frames then a slight delay then the next 5 frames how can we measure it? Are there any free tools to test the frame rate in BTV?

[Bigbird999]

Not sure if it is applicable, but gamers use a utility like AtiTools to set custom 3D configutrations for each game. It can display the frame rate while you are playing. You would have to be running BTV in 3D like games for it to work.

BB

[queonda]

If you want to check video files (already recorded), you might be able to use g-spot. Another thing to try is Zoomplayer, I believe there is an option to display FPS while you are playing a video. As for doing it within BTV, don't know if that's possible.

[merrypig]

Hmm. I wrote a long post about this yesterday and can't find it today.. Did I really forget to hit submit? *pout*

[not_Shorty]

I suppose this could be any one of the several issues that has been discussed here time and again regarding news tickers. I'd say the news ticker problem is generally just an interlacing/deinterlacing issue. TV is interlaced, 60 fields per second. You might as well think of it as 60 frames per second though, because more or less that's what it really is. Each field only makes up half of the frame, because each field is either the odd lines or the even lines. But you have to remember, each field really is a seperate moment in time. It is not two halves of the same picture. It is two seperate pictures, that only contain 1/2 the resolution you think they do. This is why news tickers look funky after you deinterlace the picture, because you're combining two seperate moments in time into one picture. This is also why sports seems jerky, you're taking a 60fps stream of data and crunching it down into a 30fps stream of data. If you're watching the recorded mpeg, and not a showsqueeze copy that's been deinterlaced, you can actually watch it without deinterlacing provided you use overlay rather than the 3D renderer. And if you do so the picture will look every bit as good as the actual TV picture does, because you're not ruining it by deinterlacing it. Of course, you also have to match your video card's output to the actual video signal, which means maxing out overscan and using 640x480 so that your 480 line signal is matching up with your 480 line picture. This works insanely well with my geforce3 card, using TVTool to overscan properly. This also works with the gffx5200 cards I've setup for other people, with the overscan setting in the drivers maxed out as far as it will go, and the deflicker setting cranked all the way down to the bottom, and then moving it up exactly one notch with the cursor key. Probably works just fine with newer geforce cards too, but I haven't tried it. <fanboy>And I'd never touch an ATI card. </fanboy>

Originally Posted by grandpaken

How do you tell the actual frame rate we're capturing at? Is the jerkiness of scrolling news banners due to dropped frames or delayed frames...meaning if you're getting 30 fps but they come in spurts of 5 frames then a slight delay then the next 5 frames how can we measure it? Are there any free tools to test the frame rate in BTV?

[merrypig]

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

[not_Shorty]

And, of course, there's that pesky Xenu...

[merrypig]

[grandpaken]

Merrypig and Shorty
I would be up all night writing a reply like you guys did. Anyhoo.. Let's just call it a "Hardware" limitation and live with the jerky banners. I was just curious as to what the cause was which you did in precise 10,000 words or less. It sounds like the solution would take more effort than most people, including myself, want to put forth. The only time it bothers me in sports is when the football is in the air or a putt is rolling to the cup.

I did play with the AITTool program but couldn't get it to display the framerate for BTV. Since it isn't going to matter anyway I'll just take a nap this afternoon instead of frustraiting myself.

Thanks to everyone for the help.

[merrypig]

Heh, well it's more meant as a gentle prod at SS to do things right and a reassurance that the end user can't really do a whole lot to fix things themselves.

Two things will mitigate the issue though.

- Use something like the advanced timing control panels or powerstrip to set as close to the native frame rate as possible.

- Or select a video monitor refresh rate where the rate is an integer multiple of the original video rate as possible.

That is; 60hz will work better than 75Hz when showing 59.94 fields/s ntsc video but of course some monitors make that look too flickery to watch as the phosphor persistance is too low. you can go up to 90hz perhaps on some monitors which gets you close to 3x the 29.97 frame rate but we're starting to get away from the ideal again with recurring jumpyness.

I personally just run at 60hz and it looks fine on my projector I also don't waste my htpc/projector bulb on watching news shows with tickers so I don't notice the jerkiness too much.

[grandpaken]

Originally Posted by merrypig

Heh, well it's more meant as a gentle prod at SS to do things right and a reassurance that the end user can't really do a whole lot to fix things themselves.

That is; 60hz will work better than 75Hz when showing 59.94 fields/s ntsc video but of course some monitors make that look too flickery to watch as the phosphor persistance is too low. you can go up to 90hz perhaps on some monitors which gets you close to 3x the 29.97 frame rate but we're starting to get away from the ideal again with recurring jumpyness.

I don't have much choice other than to use 30/60hz on my 5 yr old HD CRT RPTV. Before I upgraded my video card to a x1600 I spent days tweeking my AIW8500DV with powerstrip and there was little to no improvement in the jitters but it did fix the overscan issues. The x1600 doesn't need powerstrip plus it actually shows the PC during post which the 8500 didn't do until XP loaded the component driver. I think there are too many hardware options in capture cards for Snapstream to come out with a "One app for all" solution to the jitters. As a business it doesn't make sense to put tons of resources on a minor issue.