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

[mkanet]

Yeah, I know. The only reason I had it in the first place is to prevent unnecessary refresh rate changes; since my TV go "black" for about a second every time it does that. I will try both that way and changing only for 720.

But honestly, try just treating GREEN and YELLOW the same in the script. I don't think it will cause any problems.

 

[Jong]

Sorry, I don't understand.

 

[Jong]

Are you sure the source material is actually 30p? I wouldn't trust anything in file properties. What is the show? Just because it was broadcast as 1080i does not mean it is not really 24p material with 3:2 pulldown. Sounds more like a combination of incorrect cadence detection, with some de-interlacers and, possibly, with LAV, it being cleverer than you need or want it to be.

Cadence detection can sometimes be justifiably hard eg. when channel graphics (normally 30p) are overlayed on 24p material. Most de-interlacers will then switch to 30p for a bit causing judder @24p.

Jong, check your PM. I sent you the link to a sample clip.

Well that clip could not have been a better example of what I was talking about! It's a movie, so clearly 24p, with overlayed graphics, which normally throws off cadence detection.

 

[mkanet]

Nevermind Jong, I was being stupid.

Actually, I think that it's not such a good idea to change the refresh rate EVERY single time. I think it might be better to live with keeping non cinema media either at 60 or 59. Sorry to bother you about this. The normal script works fine. I will continue to use the latest one without resolution check.

Thanks again!

Sorry, I don't understand.

 

[mkanet]

The TV shows on the same channel are using the same format. Do you think those would also be 24P? I have never seen TV channels broadcast at 24P.

Is there any way to uniquely identify these TV channels and switch to 24Hz? I haven't been able to find anything unique about them.

Well that clip could not have been a better example of what I was talking about! It's a movie, so clearly 24p, with overlayed graphics, which normally throws off cadence detection.

 

[Jong]

Nevermind Jong, I was being stupid.

Actually, I think that it's not such a good idea to change the refresh rate EVERY single time. I think it might be better to live with keeping non cinema media either at 60 or 59. Sorry to bother you about this. The normal script works fine. I will continue to use the latest one without resolution check.

Thanks again!

I'm still not quite sure what you mean. Adding the same mediatype checks to GREEN should not lead to any extra changes. In the vast majority of cases, of course, the "newtimings" selected will be the same as the current ones, so no change will happen. The only time this will not be true is when switching between 720p material and 1080i. And here you want to change.

Of course, if you are happy stick with the current script, but if I am reading your posts correctly it seems you may be worrying unnecessarily.

 

[Jong]

The TV shows on the same channel are using the same format. Do you think those would also be 24P? I have never seen TV channels broadcast at 24P.

Is there any way to uniquely identify these TV channels and switch to 24Hz? I haven't been able to find anything unique about them.

Sports, chat shows etc. are normally "video" ie. truly interlaced and will be de-interlaced to 30p.

Movies and most TV Drama (Fringe, True Blood etc. etc.) are originally 24p so they add 3:2 pulldown to broadcast @59.940Hz.

So everything is broadcast @59.940Hz, but 24p material has 3:2 pulldown inserted that can be removed on playback.

The deinterlacer should spot the 3:2 cadence and restore the original 24p frames, but overlayed video content from the studio normally messes that up for the duration of the graphic. Other broadcast glitches can also temporarily throw the cadence and cause the de-interlacer to switch back to 30p for a while.

 

[mkanet]

Jong, I just verified... I definitely need to change refresh rate for 720p to 60 and 59 for 1080i.

However, I have no idea how to "treat GREEN and YELLOW the same". Could you please tell me how to change this?

I'm still not quite sure what you mean. Adding the same mediatype checks to GREEN should not lead to any extra changes. In the vast majority of cases, of course, the "newtimings" selected will be the same as the current ones, so no change will happen. The only time this will not be true is when switching between 720p material and 1080i. And here you want to change.

Of course, if you are happy stick with the current script, but if I am reading your posts correctly it seems you may be worrying unnecessarily.

 

[Jong]

Here's a new script

 

[mkanet]

Jong, I can't thank you enough... I'll let you know tomorrow..

Here's a new script

 

[mkanet]

Jong, dont kill me. But that last script is VERY screwed up. You should probably test it. As a test, I decided to play 1080i video. My display and video card was already on the right refresh rate (59hz). The refresh rate changed at least 2 times in the script before it finally switched to the final refresh rate. I even increased the delay for "flip-flop"; however, that had no affect.

BTW: I changed the default refresh rate to 59 (from 60) since most videos I play are 59.

See below sequence of steps:

Here's a new script

 

[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]

Edit: new version uploaded. Made some changes which should aid diagnostic and also make it easy to add delay for normal refresh rate changes, if needed.

 

[mkanet]

Hi Jong, a little bit good news. The latest script doesn't change refresh rates if my refresh rate is already 59hz when starting playback of 1080i video clip.

The script is also able to switch to 24hz correctly.

However, the script doesn't change refresh rate to 60 (from 59) when 720 clip starts. Please see attached log file.

I am using the latest VB script files with logging enabled (without debug dialog boxes). I didn't change anything in the VB scripts. I let the logging run for a minute at least before I stopped the player.

Thanks for all your time and patience.

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]

Can you send me a bit of that same video?

 

[mkanet]

Check your PM. It's just a standard ATSC 720p video. Reclock detects it as 720 for it's height if I use debug. Thanks!!

Can you send me a bit of that same video?

 

[Jong]

Hmm, as far as I can see the script is working. It's hard to directly compare because you have NVidia and I have ATI, but my ATI card does not like switching between 59Hz and 60Hz. It does not fully distinguish them. I suspect NVidia is having a similar problem. If you have another refresh rate tool that definitely works you might try using that instead of SDF.

Here I had similar problems to you switching from 59Hz to 60Hz, even using the ATI profile tool, but I could see from traces that the right calls were being made. By changing the timing so I was swapping between 60Hz to 75Hz (I'm testing on a desktop system) it worked perfectly.

At this point, unless you have another comand line tool that definitely works, all I can think of is going between 59Hz and 60hz via 24Hz, which would obviously involve two refresh rate changes, say 4 secs apart. Pretty nasty, but we're running out of options!

 

[mkanet]

Hi Jong, thanks for looking at it. However, just so you know, SetDisplayFrequency.exe doesnt have any problems switching between 59hz and 60hz on my machine when I do it from the command line. I dont have any issues switching between 59 and 60 using other command line tools as well.

Hmm, as far as I can see the script is working. It's hard to directly compare because you have NVidia and I have ATI, but my ATI card does not like switching between 59Hz and 60Hz. It does not fully distinguish them. I suspect NVidia is having a similar problem. If you have another refresh rate tool that definitely works you might try using that instead of SDF.

Here I had similar problems to you switching from 59Hz to 60Hz, even using the ATI profile tool, but I could see from traces that the right calls were being made. By changing the timing so I was swapping between 60Hz to 75Hz (I'm testing on a desktop system) it worked perfectly.

At this point, unless you have another comand line tool that definitely works, all I can think of is going between 59Hz and 60hz via 24Hz, which would obviously involve two refresh rate changes, say 4 secs apart. Pretty nasty, but we're running out of options!

 

[Jong]

OK! Try this script in place of the usual. It should popup a dialogue box just before each refresh rate switch saying what it it doing.

Does it try to switch to 60Hz?

 

[mkanet]

I am VERY curious to know what happens too. I will let you know as soon as I get home from work in 7 hours! Thanks so much.

OK! Try this script in place of the usual. It should popup a dialogue box just before each refresh rate switch saying what it it doing.

Does it try to switch to 60Hz?