Stop the refresh rate FUD

[CiNcH]

[nevcairiel]

You're mis-interpreting the numbers.

The value after "Refresh Rate" is what is important, thats what your hardware does. And 23.97648 is pretty OK i would say.

The "Frame rate" is independent of the hardware, the first number is the avg fps it calculated from the incoming frames, which can vary quite a bit depending on the jitter of the timestamps (in MKV quite badly), the second is the "locked" framerate, basically a long-time average which it locked on for presentation. All the numbers in the first row are based on the actual file you're playing, no hardware has any influence there.

Ideally, "Refresh Rate" should match the second value in the "Frame Rate" column as best as it can. No file will actually be 23.973, thats just a fluke in the stats and a rather common mis-interpretation of the OSD.

Note that madVR does a better and more accurate job at measuring the refresh rate.

I also don't believe Audio and Video truely run on the same clock, even with a HDMI output. There wouldn't be as many issues with it as there are if that was the case.

[cyberbeing]

I'm not sure that's correct nevcairiel. AFAIK the playback framerate is skewed by the Audio Clock, which in CiNcH's case seems to result in 23.973fps. To get perfect playback on his system he needs a refresh rate of 23.973Hz. Relock works around this problem by instead skewing the reference clock, so it's in sync with your refresh rate.

This is similar to the refresh rate compensation I talked about in the madVR thread here:
http://forum.doom9.org/showpost.php?p=1581585&postcount=13402

Basically if your audio reference clock (i.e. audio playback rate which video playback rate is synced to) runs slow, you need a lower refresh rate to be in sync, and if it runs fast, you need a higher refresh rate to be in sync.

An exact 23.9760239760Hz refresh rate is usually the last thing you want, as I've yet to see consumer grade audio hardware which produces a perfect reference audio clock (which also requires a CPU which produces a perfect system clock) with non-existent skew on the PC. The rules may be different if you bitstream audio or output A/V via HDMI, I don't know, as I've never tested such a setup.

[madshi]

today we have a common output for audio and video, HDMI. Audio and video output is driven by a common oscillator.
Is that a guess or a fact? Has it been documented anywhere that ATI, NVidia and Intel are using the same hardware clock for audio and video?

[CiNcH]

Is that a guess or a fact?
I just played around with a Radeon HD 6570 and my modification of the DVBViewer EVR Custom Presenter. I used HDMI for audio (PCM) and the audio renderer provided the reference clock within the DirectShow graph. The frame timestamps (based on the graph clock) and VSync times did not drift. I measured this over hours and there was not a single overrun. Whereas with any other graph clock source (except for ReClock) the two do drift apart from each other (like with onboard sound, an ASUS Xonar DX or the "system clock").

So I pretty much believe that at least for my Radeon HD 6570 there is a common oscillator. Maybe I shouldn't have made a general assumption.

[madshi]

I did hope that a common hardware clock might be used, but I'm not sure it really is. It would be great, of course, but often companies are not as clever as we would like them to be. The clocks not drifting on your Radeon might be a sign that a common clock is used, but it could also be happy chance. And then there's older Radeon generation cards, and all generation NVidia cards and Intel. So I'm a bit afraid of basing HTPC software design on the hope that clocks might no longer drift. Another problem is that not all HTPC people are running audio through the main HDMI output. There are still many HTPC users running audio through separate audio cards, through analog outputs, through SPDIF output, through Firewire output, or even through a cloned secondary HDMI output of the GPU. Personally, I'll soon switch to Firewire audio out. So I think we should still design the software in such a way that it can handle drifting clocks, even if *maybe* in ideal conditions it doesn't, anymore.

FWIW, madVR tries to measure the audio clock deviation from the system clock, and in addition to that the exact vsync refresh rate (based on system clock again). Unfortunately measuring the exact audio clock deviation is very difficult because it jitters like crazy. So the results are not really all that reliable.

[CiNcH]

So I think we should still design the software in such a way that it can handle drifting clocks, even if *maybe* in ideal conditions it doesn't, anymore.
FWIW, madVR tries to measure the audio clock deviation from the system clock, and in addition to that the exact vsync refresh rate (based on system clock again). Unfortunately measuring the exact audio clock deviation is very difficult because it jitters like crazy. So the results are not really all that reliable.
I render frames relative to the VSync and just check the frame timestamp/VSync drift. If they are off by more than one frame interval I either drop or repeat a frame.

[nevcairiel]

If by "frame timestamps" you are referring to the timestamps provided by the decoder, then those are not based on any clock, just on the data in the file/stream, which in a proper file should be a very consistent behaviour.

[CiNcH]

If by "frame timestamps" you are referring to the timestamps provided by the decoder, then those are not based on any clock, just on the data in the file/stream, which in a proper file should be a very consistent behaviour.
I haven't been playing around with that for some time now. You are right. I wasn't clear on that... What I actually meant is the time that passes between rendering frames based on the MFClock inside the EVR (which again is based on the reference clock of the graph) and the MFSample timestamps and the time between consecutive VSync's. This interval is not exactly the same if MFClock and VSync clock are distinct. So actually the rendering/present based on the MFClock and the respective VSync drift (or maybe not).

[ramicio]

Dumb. You can't judge by one picture. The frame rates jump around. You're still at the mercy of the display device's clock. ReClock introduces its own insane problems, like the annoying audio loss at the beginning of playback. I don't get why they can't get the information and determine how to play it back from the file before playback begins. There are instances where I want seamless playback. I can achieve this without ReClock, but then I have a frame being repeated every so often.

[CiNcH]

You can't judge by one picture.
LoL. I measured and compared the interval over hours of course, the MFClock's frame interval and the VSync interval (at 23.976 fps/Hz and 50 fps/Hz). Jitter has of course been taken into account when calculating the drift.

I am not that dumb that I think that I can calculate a drift by just comparing two consecutive frame and VSync times ;) .

[CiNcH]

Here is a little more information about the test with my renderer...

If you take a look at the attached image, the 'Sample/Render-Offset' is the interesting piece of information. My renderer always renders frames relative to the VSync. So the render time is tied to the VSync. In this case 16ms before the VSync, the rendering of a frame is startet (see 'VSync Offset') (for 50 fps material, 20ms frame interval). The sample time is the intended MFClock time. So if this offset does not drift, MFClock and VSync generation are most likely based on the same oscillator.

[CiNcH]

I finished building my Ivy Bridge based HTPC last week. HDMI audio works via the onboard ALC898 controller (mainboard is a MSI Z77A-GD65). I actually thought that HDMI audio is handled by the CPU itself. So in this case, we will most likely be seeing different clock domains as madshi already assumed.

I am sure however that at least my discrete HD 6570 uses a common clock for audio and video.

[madshi]

Too bad. Not having to worry about different clocks would have been too good to be true, I guess...

[CiNcH]

Hi madshi,

did a quick test with the HD 4000 and VBIOS 2137 today...

Frame times based on the reference clock (EVR MFClock) being provided by the HDMI audio renderer filter slowly drift apart from the VSync times. I also verified it with the EVR Custom inside MPC-HC. The green curve is slowly drifting apart from the red one.

madVR registers a refresh rate of 23.97241Hz and a clock deviation of 0.00151%. Guess this is the clock deviation between the graph reference clock and the VSync based clock? The calculated frame dropping rate is 1 every 4.17 minutes.

Too bad. You were right :( .

How about creating a custom timing with less invisible lines (front/back porch) to decrease the frame interval slightly, hence increase the refresh rate? Anybody ever done that?

If anybody is interested I can try my HD 6570 again and verify whether there is a clock deviation...

[madshi]

madVR registers a refresh rate of 23.97241Hz and a clock deviation of 0.00151%. Guess this is the clock deviation between the graph reference clock and the VSync based clock?
Yes.

How about creating a custom timing with less invisible lines (front/back porch) to decrease the frame interval slightly, hence increase the refresh rate? Anybody ever done that?
Yes, I've tried things like that. The first thing to change is always the pixel clock. Unfortunately you can only adjust it in rather big steps. So next thing to try is to play with the other parameters. The problem is that you really need to do looooong testing to know what exactly you need to aim for. The clock deviation calculation of madVR is not very reliable, unless you let it run very long, and ideally measure it multiple times to check if you get the same results every time... :( Then when you created a custom timing, you'll have to run a 2-3 hour movie and check whether you got along without a frame drop/repeat, just to confirm that everything is as expected.

If anybody is interested I can try my HD 6570 again and verify whether there is a clock deviation...
If it's not too much trouble, I'd find it interesting.

[CiNcH]

If it's not too much trouble, I'd find it interesting.
madVR quickly jumps to several hours for the frame drop rate. Pretty much looks like a common oscillator. This was verified by another person using the same passive 'SAPPHIRE Ultimate HD 6570'. So this is no coincidence.

[madshi]

Well, maybe AMD got clever (for a change) and really is using the same oscillator for newer cards. That would be very nice, of course.

[CiNcH]

Yes, I've tried things like that. The first thing to change is always the pixel clock. Unfortunately you can only adjust it in rather big steps. So next thing to try is to play with the other parameters. The problem is that you really need to do looooong testing to know what exactly you need to aim for. The clock deviation calculation of madVR is not very reliable, unless you let it run very long, and ideally measure it multiple times to check if you get the same results every time... Then when you created a custom timing, you'll have to run a 2-3 hour movie and check whether you got along without a frame drop/repeat, just to confirm that everything is as expected.
How close did you get? Which GPU did you try it with? Do you have some numbers for 1080p @ 23.976Hz to start with?

[madshi]

It was too long ago, I don't remember the exact details, unfortunately. I think I used PowerStrip with my old ATI card.

[CiNcH]

It was too long ago, I don't remember the exact details, unfortunately. I think I used PowerStrip with my old ATI card.
Me too. When I tried to do 71.X Hz on my 720p projector.