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

[mkanet]

Currently, I use Reclock to change vertical refresh rates that my TV likes better for certain video formats. I noticed that Reclock wants to use NTSC (2x) for both 1080i and 720p source video

For whatever reason, my TV seems to prefer 1920x1080@60Hz for 720p video and 1920x1080@59.94 for 1080i. Otherwise, I see a little bit of stuttering when using frame rate interpolation on my TV.

Is there a way in the VB script to tell the difference between 720p and 1080i; and, switch to the appropriate frequency? If I could do this, I could even switch to the native resolution of 1280x720p if I wanted to.

 

[theshadowrunner]

Is there a way in the VB script to tell the difference between 720p and 1080i

Almost, ReClock understands "sourceHeight" argument from VBScript.
A sample that could help:

Set objArgs = WScript.Arguments
sourceHeight = objArgs(11)
Set wshShell = CreateObject("WScript.Shell")

If eventName = "YELLOW" Then
If sourceHeight <= 720 Then
etc...

,and, switch to the appropriate frequency? If I could do this, I could even switch to the native resolution of 1280x720p if I wanted to.

Not sure, depends on how you have your ATI/NVIDIA driver setup.

 

[mkanet]

I'm not that great at VB, I was wondering someone could please tell me the easiest way to make this work. I tried it two different ways; both seem to get ignored in the default SetDisplayFrequency.exe script:


All I want to do is when yellow condition is met and:
if there is NTSC(2x) and 720p then newTimings = "60"
if there is NTSC(2x) and 1080p then newTimings = "59"


sourceHeight = objArgs(11) (defined in the correct place in the script)

Method #1:

If eventName = "YELLOW" Then

            Case "NTSC(2x)"
		If sourceHeight = 1080 Then
                newTimings = "59"
		End if

            Case "NTSC(2x)"
             If sourceHeight = 720 Then
                newTimings = "60"
		End if
End If

Method #2

If eventName = "YELLOW" Then
            Case "NTSC(2x)"
                Call ResCheck()
End If

Sub ResCheck()
    If sourceHeight = 1080 Then
    newTimings = "59"
    End if

    If sourceHeight = 720 Then
    newTimings = "60"
    End if
End Sub

 

[Jong]

The whole script would help But you aren't selecting the argument to use in your case statement. I'm surprised the script doesn't throw an error. I'll bash something out later.

 

[Jong]

Here you go.

Note: the sourceheight is not always 720 for 720p video or 1080 for 1080i/p video. Other than in Blu-ray, black bars are not normally encoded, so a 2.35:1 video @720p will have a vertical height of 544. So I've set this to check for height <=720.

Note 2: this will also affect SD, so if you want a different rate for that you need to add a separate IF statement to catch it. Hopefully though it will now be obvious what to do.

Note 3: FYI, Reclock does not "want to use NTSC (2x) for both 1080i and 720p", it is merely reporting what it is given. It seems Sage is frame doubling the video to 2xNTSC (I've seen the Cyberlink MPEG2 decoder do the same). With modern TVs with frame rate interpolation this does sound like a bad idea (even without these it is of no benefit). You might want to discuss it with them!

Note 4: You should also get the latest "resetrefresh" script from the other thread before using this.

 

[mkanet]

Thanks for the tip. Actually the sourceheight detection was only meant for American digital TV (1280x720p and 1920x1080i). This is because my TV plays back 1280x720p TV better at (60.000hz) and 1920x1080i at (59.940hz) for some reason. However, one thing I didn't think of was SD TV content; which is <=720 (480p/480i). Thanks for catching that.

I am using LAV video filter (CUVID decoding). I have noticed that it is sometimes inconsistent (for some 1080i mpeg2 television.... It will report as 29.97hz; and, sometimes as 59.940hz). I am not sure if there is a way for the LAV video decoder to try to use the framerate specified in the file properties description (which is almost always correct if its available) instead of real-time analysis of the file.

Thanks again. I will try this VB script when I get home tonight!

Here you go.

Note: the sourceheight is not always 720 for 720p video or 1080 for 1080i/p video. Other than in Blu-ray, black bars are not normally encoded, so a 2.35:1 video @720p will have a vertical height of 544. So I've set this to check for height <=720.

Note 2: this will also affect SD, so if you want a different rate for that you need to add a separate IF statement to catch it. Hopefully though it will now be obvious what to do.

Note 3: FYI, Reclock does not "want to use NTSC (2x) for both 1080i and 720p", it is merely reporting what it is given. It seems Sage is frame doubling the video to 2xNTSC (I've seen the Cyberlink MPEG2 decoder do the same). With modern TVs with frame rate interpolation this does sound like a bad idea (even without these it is of no benefit). You might want to discuss it with them!

Note 4: You should also get the latest "resetrefresh" script from the other thread before using this.

 

[Jong]

You might want to ask nevcairiel about this. I wonder why sometimes it chooses a frame rate doubling algorithm and sometimes not. If it is a logical choice I guess sometimes the difference between half resolution fields is so large it decides it is better to interpolate two different 60Hz frames. If it is doing this and Doing it well maybe it does make sense?

 

[mkanet]

I wonder if it's related to using the "adaptive" deinterlace setting. Interestingly, if I disable deinterlacing completely in the LAV video decoder, after playing the video for a while, the FPS changes to 24fps (from 29.97).

Edit: I will ask Nev. I will also include a sample video file for him to playback. I am guessing Reclock will just display the framerate that LAV filter gives it.

You might want to ask nevcairiel about this. I wonder why sometimes it chooses a frame rate doubling algorithm and sometimes not. If it is a logical choice I guess sometimes the difference between half resolution fields is so large it decides it is better to interpolate two different 60Hz frames. If it is doing this and Doing it well maybe it does make sense?

 

[Jong]

Yes, Reclock is just telling you what it is told.

It is interesting though. If these are actually 24p I'd normally expect the decoder to spot the cadence and give you 24p. Maybe the adaptive deinterlacer is trying to be too clever and give you something better suited to your 60hz display, not realising if it gave you unadulterated 24p, you would switch to that refresh rate for a result that is better still. Maybe there is already an option that will do this, or maybe there could be?

 

[mkanet]

I think it's something weird related to the TV recordings; which is definitely 29.97fps interlaced (1080i). I see very strange fps changes (sometimes media is reported at 29.97, sometimes 59.940; and if I force deinterlacing to Weave (none), Reclock shows 24.000fps ...and my display changes to 24hz as well

It has been many years since I have wondered why these particular TV channels stutter on some playback devices (especially PCs). I used to think its because they were incorrectly flagged. However, the file properties "details" tab, show 29 frames/second. Which is correct. There is something definitely weird about these recordings; but not sure what. I will upload a sample clip. Maybe someone either on LAV filter forum or here may know what is causing this strange framerate change (sometimes right in the middle of the recording).

 

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

 

[mkanet]

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

However, I have some bad news. I really didnt want to say this, but I thought you should know. The sourceheight code is not working correctly. Sometimes it will change the video card refresh rate to 60hz (incorrectly) for 1080i; and, sometimes it will change it to 59hz. I can't find any consistency. It looks like it's almost random. This is the behavior I was seeing yesterday with my code before asking for help. I thought I was doing something wrong.

The only way it is 100% consistent is if I take out the sourceheight code and use no extra conditions.






EDIT:

I just modified the sourceheight code to change to 24hz no matter what, but it gets completely ignored. The refresh rate just stays at 59.40hz.

Case "NTSC(2x)"

If sourceheight <= 720 Then
newTimings = "24"
Else
newTimings = "24"
End if

 

[Jong]

OK, so one of those is 59Hz and one 60Hz, but they are different videos. Are you saying it is random for the same video or it works for some and not others?

Let's turn on logging and see what the source height sent to the script is for each.

 

[mkanet]

They are two different videos. One is 720, the other is 1080. I just wanted to show you what refresh rate the script thought they each one should be at (which is the wrong for each one).

I honestly dont think its even looking at the conditions. I had changed them to 24hz. They wont even change now.

I will send you a log shortly.

OK, so one of those is 59Hz and one 60Hz, but they are different videos. Are you saying it is random for the same video or it works for some and not others?

Let's turn on logging and see what the source height sent to the script is for each.

 

[Jong]

Ah, yes, sorry.

I checked those code paths myself it is definitely evaluating the conditions. Send me clips of the two if you like. Once again though, is it some videos that work and some that don't or the same video is random each time you play.

 

[Jong]

I think I know what the problem is. It is dropping straight to GREEN - never going through YELLOW. if you want to differentiate between 59Hz and 60Hz you will need to untick "guess a better speed...."

 

[mkanet]

You are absolutely right. I didn't realize that it is GREEN. However, unchecking that option didn't make any difference. It starts immediately at GREEN and continues to stay at green.

I think I know what the problem is. It is dropping straight to GREEN - never going through YELLOW. if you want to differentiate between 59Hz and 60Hz you will need to untick "guess a better speed...."

 

[Jong]

Sorry, yes, wrong setting. Change it back.

I think you would have to turn off all allowable speedup/slowdown, which with reclock is not a good idea!

So I suppose you could add the whole "Select Case mediaType...... End Select" from YELLOW to GREEN. Can't see what harm it will do. As far as I can see (on ATI at least) requests to change refresh rates do nothing if that rate is already selected.

 

[mkanet]

Jong, I think I know what is best...

I can leave my desktop/default refresh rate to 59.940 (basically everything except for when I play 720p media...

Sorry, yes, wrong setting. Change it back.

I think you would have to turn off all allowable speedup/slowdown, which with reclock is not a good idea!

So I suppose you could add the whole "Select Case mediaType...... End Select" from YELLOW to GREEN. Can't see what harm it will do. As far as I can see (on ATI at least) requests to change refresh rates do nothing if that rate is already selected.

 

[Jong]

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