upnorthsox
Veteran
But if that's the case then the frame count should still be accurate as it's counting one morphed (for lack of a better word) frame instead of one frame split in two.
Frame Rate Analysis Thread (Simple Rules Post #2)
- Thread starter grandmaster
- Start date
- Status
But if that's the case then the frame count should still be accurate as it's counting one morphed (for lack of a better word) frame instead of one frame split in two.
how you count frames? you compare all the pixel of the frame with the previous frame and if there are difference you increase counter?
why not just compare a little horisontal band of pixel (some line or just one line of pixel) always at the same place (on the top in preference), the result will be not disturb by tearing if the V-sync isn't disable for frame under 16.6ms (it's always the case)
but don't use too static sequence of course
why not just compare a little horisontal band of pixel (some line or just one line of pixel) always at the same place (on the top in preference), the result will be not disturb by tearing if the V-sync isn't disable for frame under 16.6ms (it's always the case)
but don't use too static sequence of course
Last edited by a moderator:
Just a random thought:
For each line:
Calculate if differences to previous frame is 0
Calculate if differences to next frame is 0
Should be fast to calculate, you are doing sequential read with early break, which should be really early for fast moving games, cars, or games moving the camera continously to simulate head bob, FPSs.
Classify frame as:
- Z: zero common lines
- P: common lines with Previous frame
- N: common lines with Next frame
- B: common lines with both frames
State machine (array):
State: Previous frame classification
Input: Current frame classification
Transition action: value to add to frame counter
Now fill in the table, f.ex.: Z->Z = +1
Maybe this would work, or maybe more state is needed, like both previous frame classifications or the max,min (Y coordinate) of identical lines.
The implementation and validation is left as an exercise to the reader.
Some games may need to adjust the Y-window to check, if they have horizontal slow changing borders (health meters or whatevers).
For each line:
Calculate if differences to previous frame is 0
Calculate if differences to next frame is 0
Should be fast to calculate, you are doing sequential read with early break, which should be really early for fast moving games, cars, or games moving the camera continously to simulate head bob, FPSs.
Classify frame as:
- Z: zero common lines
- P: common lines with Previous frame
- N: common lines with Next frame
- B: common lines with both frames
State machine (array):
State: Previous frame classification
Input: Current frame classification
Transition action: value to add to frame counter
Now fill in the table, f.ex.: Z->Z = +1
Maybe this would work, or maybe more state is needed, like both previous frame classifications or the max,min (Y coordinate) of identical lines.
The implementation and validation is left as an exercise to the reader.
Some games may need to adjust the Y-window to check, if they have horizontal slow changing borders (health meters or whatevers).
grandmaster
Veteran
That's an interesting idea Quaz, although I think knowing how many captured frames there are that are torn should be built in.
The tool allows me to compare any area of any size from the captured video by using an Avisynth script.
I re-ran the Race Driver intro tests (race sections are too static in my chosen area), but choosing around 70 lines of video from the bottom. The tearing typically rears its ugly head on the top or middle sections.
BMW Intro
Old
360: 33.167fps
PS3: 50.492fps
New
360: 30.000fps
PS3: 27.705fps
Nissan Intro Test
Old
360: 30.000fps
PS3: 30.000fps
New
360: 30.00fps
PS3: 30.00fps
Mustang Intro Test
Old
360: 30.087fps
PS3: 36.348fps
New
360: 30.087fps
PS3: 29.913fps
The last 360 result is interesting... no matter where I move the tested area, that's the result.
As the discussion has moved on, I think I'll change the first post. Once methodology has been established, we can use the initial post to place results.
The tool allows me to compare any area of any size from the captured video by using an Avisynth script.
I re-ran the Race Driver intro tests (race sections are too static in my chosen area), but choosing around 70 lines of video from the bottom. The tearing typically rears its ugly head on the top or middle sections.
BMW Intro
Old
360: 33.167fps
PS3: 50.492fps
New
360: 30.000fps
PS3: 27.705fps
Nissan Intro Test
Old
360: 30.000fps
PS3: 30.000fps
New
360: 30.00fps
PS3: 30.00fps
Mustang Intro Test
Old
360: 30.087fps
PS3: 36.348fps
New
360: 30.087fps
PS3: 29.913fps
The last 360 result is interesting... no matter where I move the tested area, that's the result.
As the discussion has moved on, I think I'll change the first post. Once methodology has been established, we can use the initial post to place results.
Last edited by a moderator:
i think you can used less than 70 line, less line = more precise estimate
test with 10 line or even one line if it's raw HDMI lossless video (and not necessary at the top, it's not important because frame teared length is over 16.6ms, the important it's to used always the same lines, with just one line on the middle of the frame you will have a good estimate)
test with 10 line or even one line if it's raw HDMI lossless video (and not necessary at the top, it's not important because frame teared length is over 16.6ms, the important it's to used always the same lines, with just one line on the middle of the frame you will have a good estimate)
Last edited by a moderator:
interesting...any chance of re-running the GTA now to 'correct' the X360 scores?
grandmaster
Veteran
I quickly re-did the shorter clips and there was basically no difference. I did the shorter ones as I could look through those frame-by-frame for tearing - I saw none.
Less lines also equals much more chance of a duplicate. Accuracy goes out of the window on the GTA material for example, regardless of console.
Less lines also equals much more chance of a duplicate. Accuracy goes out of the window on the GTA material for example, regardless of console.
Last edited by a moderator:
even just one line is still 1280 pixels, 24bit each and lossless, if it's not static sequence how the same line can product the same 1280 results in two different frame? probability is null
you have tested?
70 line is still + or - 10% error on teared frame
It has to be a well tweaked heuristics comparison, comparing subsequent lines and looking for a sharp discontinuity. It will have to be tweaked per-game, because in some games (static cameras, static background, moving objects) the tearing will result in much less discontinuity. Any video compression/motion compensation specialists here?
grandmaster
Veteran
It's more difficult than you would think! Especially with the GTA captures. I'll drop you a line about this.
Would it be preferable (or even feasible) to pre-select x amount of random pixels to sample from the first frame, and then continue to sample those same pixels in following frames? The reason I ask is because I figure with any single line of pixels there's still always a possibility that the scene will remain static across any given straight line from frame to frame, no matter how many pixels that line contains. I'm not saying this will always be the case or even commonly, just trying to help determine the best method for the sake of accuracy is all.
aaronspink
Veteran
The problem occurs if that 1 line doesn't change between actual frames. Take for instance just standing around in GTA, if that line is from a location that isn't changing you have issues. 70 lines lessens the probability of that, but the real key is looking at the video and selecting the right location.
The comparison band also probably wants, in general, to either be the top 1/4 of the screen or bottom 1/4 of the screen as they will be least affected by the tearing.
How about two diagonal lines? (a cross figure) (x=0,y=0) x++, y++, and (x=capture.buffer.x, y=0) x--, y++.
Quaz could think about writing an algorithm for detecting different types of AA as well, which could be interesting for detecting games that have adaptive AA (like Forza 2 if I remember correctly).
Quaz could think about writing an algorithm for detecting different types of AA as well, which could be interesting for detecting games that have adaptive AA (like Forza 2 if I remember correctly).
grandmaster
Veteran
The gameplay trailer will be encoded to 29.97fps as that's the spec of Xbox Live Marketplace video. What the actual framerate of the game is we don't know until we have an uncompressed image to play with.
Betanumerical
Veteran
Would it be possible to write a algorithm to workout native resolution? Would be a bit tricky count steps though.
- Status