Can reclock tell the difference between an ATSC 1080i and ATSC 720p video format?

[mkanet]

Jong, I appologize. This last reclock.zip is PERFECT. It was 4am this morning when I was testing it. I wasn't realizing that the reason it was not changing was because my refresh rate was already 60hz!

I am so sorry. It is working 100% perfectly changing 720 to 60.000hz, 1080 to 59.940, and 23.976 to 24.000Hz without any flip-flopping.

This a just perfect. I cant thank you enough for all your help.

All problems resolved and working consistently!

Originally Posted by Jong

OK. Bare with me. Of course I'm not able to test on your system and with your video, so some amount of experimentation is inevitable. And Reclock is not really supposed to differentiate between 59Hz and 60Hz, so we are pushing the envelope a bit! With luck though we can get something that works.

My last minute script was a little too rushed. Working off your example, the logs and description the script seems to be working as written:

- Display originally on 59Hz
- Video arrives initially as NTSC so display is switched by RunEvent to 60Hz (I don't think you changed this in the script, did you?)
- Video then changes to NTSC(2x) with 1080 height so display is switched by RunEvent to 59Hz

If you had changed the timing for NTSC to your new default of 59Hz all would have been OK, I think.

But it occurred to me just after turning off the computer that we don't really need/want to be changing rates on GREEN except with these tricky NTSC(2x) videos, so we can safely remove all "cases" but NTSC(2x) from GREEN. If I'd done that in the first place you would not have seen that first refresh rate change when the video briefly appears as NTSC, but then we might not have noticed you had not changed the timings for NTSC to your new default.

However: the more rates you use the more possible refresh rate changes we might see. For example, it is just about possible you might get a 720 height video that initially looks NTSC(2x), so we switch from 59Hz to 60Hz, but then cadence detection kicks in and we switch to 24Hz. Only testing will tell if this is a real issue (normally I think it would go from NTSC to CINEMA, which should be fine).

We could add a delay to ALL refresh rate changes, not just QUIT. This might eliminate some unnecessary switching but still might not catch them all (cadence detection can take an indeterminate time) and would mean that the refresh rate switch would happen a noticeable time after playback starts, which might be distracting. So it is a balance of evils really.

Try this script and see if it helps. If you still experience switches of rates that you can't bare please zip up a free running log (not with debugging) and a copy of the script you are using (in case you have made any changes )and we can try adding the delay to all changes, but there are no guarantees you will like that better!

[Jong]

Great news! Phew.