Frame Rate Analysis 101: New tools, more data

Time for a quick refresher course on frame rate analysis based on feedback from the Digital Foundry forum (ie. "please explain the graphs"), combined with a debut outing for a new revised version of our frame detection tools.

The principal of frame rate detection is remarkably straightforward... in theory at least. With the Xbox 360 and PlayStation 3 (and indeed PC) giving us pure digital outputs to capture from, ascertaining how many times the output changes in any given second is a simple matter of counting unique frames from the 60Hz source. It honestly is as simple as that for a great many games. The only real skill required is making sure that the clips chosen do not include any static screens loading screens, pause screens, that kind of thing. Because of the level of accuracy involved when you have 921,600 pixels to scan in a 720p capture, you can be remarkably precise in what is a unique frame and what isn't. Indeed, even a sample of 1280 pixels from a single line scan is usually enough to get an accurate result. It's rare to non-existent that what the eye perceives to be a static screen during gameplay actually is one.

Analysis of analogue sources such as Wii (and indeed compressed video) is more difficult. The difference between duplicate frames is no longer zero per cent. The key here is to find the new threshold (it's usually closer to one per cent) and search through the video for all readings in the region of that new threshold and discern by eye if it's a dupe or not and adjust the read-out accordingly. It is thankless and long-winded work.

After the analysis phase, it is a matter of presenting the data. We choose to use graphs overlaid over the original footage. The centre line of the graph is the frame currently being analysed, and a frame rate counter (updated from a 60Hz sample every half-second) is planted elsewhere on the screen.

All of which works great on v-synced software where the original analyser is as good as the day we made it. But things are tricker when it comes to games without v-sync. Torn frames register as unique frames when clearly they are not. The old tool wa cajoled via two passes to identify torn frames, but not the actual location of the tear, which has a big impact on the perception of image quality while it will be different for each person and their individual perceptions, typically the closer to the centre the tear is, the more noticeable it becomes. Finding tear locations required implementation of a brand new algorithm, formulated by DF associate MazingerDUDE, following up and enhancing some interesting FPS detection work by the Japan-based ps360.

So, here's some Resident Evil 5 on Xbox 360, concentrating on the part of the game where tearing is most impactful: the Savannah shoot-out. While in this case overall FPS results are the same as our first tool, obviously there is more data presented on where the v-sync tear occurs as opposed to just saying that there is a torn frame or not. Can the tool solve the great Capcom/Xbox 360/1080p tearing riddle? We're actually looking into this but as the tear itself is being upscaled and softened it defies automated analysis, though by now the real question is not question of whether it tears more, but why.

The chaingun blast-a-thon is 'the place to be' for finding tearing within the Xbox 360 build of Resident Evil 5. And then measuring it.

Where the new tool has clear advantages is in a rare breed of game: games capped at 60 FPS with tearing (think: WipEout HD or any LEGO game). The tool internally reconstitutes each frame to give us a running total of unique frames, and thus an unerringly accurate result. If you want to see perhaps the most bat-shit insane example of such a game released in recent times, step forward Call of Juarez 2: Bound in Blood on Xbox 360. It's quite 'special'.

Call of Juarez 2's v-sync issues were one of the major reasons we had to update our tools.

I'm currently looking at this game for Face-Off 21, and it seems that developer Techland has opted to go for as fast a frame rate as possible at the expense of image quality. Rather than v-syncing at 30FPS, the game generally seems to run at around 35-40FPS, albeit with a ginormous amount of tearing.

So how does this all fit in with the sort of day-to-day work we do at Digital Foundry aside from a bit more accuracy in a tiny proportion of games? Well, a pleasant addition to the new tool is that all the video composite work that we traditionally we use Adobe After Effects for has been rolled into the same code and is hugely faster (about six to eight times swifter than AE). So while the Face-Off videos embedded into the articles won't change, we can give the HD clickthroughs some bonus goodies with no extra effort from ourselves: not full FPS analysis (which would cover up too much detail), but maybe torn frame indicators on-screen and unobtrusive frame rate counters would help maximise the additional real estate we get from the 720p resolution...

Comments (32)

Comments for this article are now closed, but please feel free to continue chatting on the forum!

  • Loading... hold tight!