MPC-HC GothSync tryouts

[ADude]

Using Sync Renderer with the 'Present at nearest vsync' synchronization option with build 1.3.1486:

Ok sorry, I'm definitely not nuts. If I change the renderer to EVR CP, then untick all the vsync options under Renderer settings, and then change the renderer back to Sync Renderer and then look at the vsync options again, 'Vsync' is ticked but all 3 are greyed out ('Vsync', 'Accurate Vsync' and 'Alternative Vsync'). I then proceed to play a movie - terrible tearing and stuttering.

I then change the renderer back to EVR CP, tick 'Accurate Vsync' and 'Alternative Vsync' (along with 'Vsync') and then change the renderer back to Sync Renderer and look at the vsync options again, all 3 remain ticked but greyed out. I play a movie - play back is perfect ( I tested this over and over and the results are the same every time). So even though the vsync options are greyed out they still have an effect on playback.

Could someone please explain if this is to be expected or not - I had assumed that the vsync options were greyed out because they are not meant to be user selectable with Sync Renderer (i.e Sync Renderer had it's own vsync method and the options were greyed out simply because the render does not use them).

I have found something similar.

I found that if I used EVR CP with 1453 (shortly prior to Sync Renderer) and then used 1465 with Sync Renderer and then went back to 1453 with EVR CP, there were different results the second time with 1453 than the first time.

Similar things occurred with different versions and different orders.

When I rebooted the PC in between each version change, then I could tell each version's performance (as would be predicted by the code changes).

So there is either a memory leak, or else some other way in which different versions affect each other, such as options not being cleared properly.

[mark0077]

When you guys switch back to the standard mpc-hc (without syncrenderer included), you will have to manually select a renderer. mpc-hc will open with no renderer selected in this situation so you need to go in and select your desired renderer again when going to older versions.

[ar-jar]

When you guys switch back to the standard mpc-hc (without syncrenderer included), you will have to manually select a renderer. mpc-hc will open with no renderer selected in this situation so you need to go in and select your desired renderer again when going to older versions.

Good point. Thanks! -A

[ADude]

When you guys switch back to the standard mpc-hc (without syncrenderer included), you will have to manually select a renderer. mpc-hc will open with no renderer selected in this situation so you need to go in and select your desired renderer again when going to older versions.

It uses the default renderer, and nothing is checked in the list of renderers.

If you then go to 1465, Sync Renderer is checked again.

This is a different issue from the one mentioned above (although it could be related).

[mark0077]

Well I'm back again with some questions, and maybe some ideas to improve some of the three different sync options.

I am not trying to annoy, just picking out things I think could be improved as work continues, and some questions that I can't answer from reading your blog. I know the GUI will be improved at a later date, hopefully along with automation of best selection of options, but heres a few comments anyways.

I am using a GTX 295, Windows 7 64bit, with Samsung Series 9 display, and analog Xonar HDAV Deluxe. These Series 9 displays have a 60hz PC mode that doesn't do any funny modification of the image and although I have tried going back to 24hz from time to time, I can't stand the horrible effects that can be seen (another days story). So I decide to stick with 60hz and have used Reclock to get my 23.976 material to 24hz, and mpc-hc to sync this 24hz to my display as best as possible.

-- Sync video to display --
1) Out Of Sync Question.
So with 23.976 material being played on 60hz screen, this would speed the video up to 24fps right like ffdshow would do?
If so excellent!!, but I understand it is noted on your web page that this is with the disadvantage being that audio will get out of sync? If so, without you wasting your time explaining why this happens, could you also do whatever ffdshow does as it doesn't get out of sync in this scenario.
I guess ffdshow uses the open source audio resampler I linked you to, to resample the audio as an alternative to going out of sync over time. This of course would mean tiny pitch changes.
If this can be implemented in a future version, the only disadvantage people might have to be aware of here would be that almost inaudible pitch changes could occur, and that would be only noticible when going into the larger percent speed changes.

2) Frequency adjustment option
Is it in % as I see no percentage sign in the GUI currently? I see 0.00012 represents 0.12% in your documentation. Is this just another way to set a limit of how much things are changed by, just like the "Control limits" option sets a limit of how ms control can be changed?

3) What happens if my display / refresh are off by more than the frequency adjustment, and control limits. Does the renderer revert to some basic mode like mode 3, Present at nearest vsync?

Problem Noticed: Testing a 25fps music DVD that I want to play at 25fps, gives massive audio pops and glitches, and seems to play at a slow deep sounding rate in sync renderer using this option. It must be suffering badly from audio being out of sync and why I hear the audible blip as sound catches up? I didn't think 0.12% would allow this speed change at all, I thought it would revert to another mode.

-- Sync display to video --

I havn't been able to change front porch number in reclock so I guess this isn't support on Samsung Series 9 or my GTX 295. I don't see any newish Nvidia cards listed in supported list.... Maybe some custom resolution might allow changing of this but will need to look into it to see it in action.

1) Only comment is, that ffdshow refers to horizontal front porch in pixels, so I got a bit confused with SyncRender refering to it as columns.
As an improvement, can adjustment of lines / pixels default to 1 for the most fine grained control, and increase number to 2, 3 automatically if previous attempt at finer grain control didn't work? This if it works, could remove the frequency adjustment options from the renderer options?

2) What happens if sync renderer detects that porch control isn't possible on my display / graphics card. Does the renderer revert to some basic mode like mode 3, Present at nearest vsync, or just continue trying adjustments.

-- Present at nearest vsync --
I imagine this will always work for any combination of display / video so no comments here.

Problem Noticed: Playing my Queen 25fps interlaced Video again, as I enabled de-interlacing in ffdshow a few minutes into this clip, making the frame rate change to 50fps, the renderer starts to show frame rate switching from ~41fps to 50fps (In "Actual Frame Cycle" output), as if its going up and down, so the graph goes a bit mad when it starts go back down from 50.000. I can't hear or see this speed change and my machine has no problem with speed in this situation (cpu usage below 3% on 4ghz core i7). I will test some DVD menu's also as a benchmark of the renderer, to see how it can handle speed changes as time goes on. They have caused problems for some renderers in the past.

Other Questions
1) Do all three syncing work better with reclock loaded, ie does it somehow give more accurate details to your renderer in certain scenarios, other than just giving extra control for "Sync display to video".
2) Target Sync Offset: Forgive me on this one. I just imagine the target sync offset for anyone would be 0ms, why is it recommended to have a target of 8 – 14 ms for a 60 Hz display?

Again, I can test any builds you might have that might benefit from testing using the configuration I use. Just let me know.

[ar-jar]

Thanks for your input!


So with 23.976 material being played on 60hz screen, this would speed the video up to 24fps right like ffdshow would do?


Speeding up 23... to 24 is technically possible as long as you let the computer decode audio. Experiments show that the audio renderer "matches rate" at least up to about 0.5% speed difference. Unfortunately too little for 23... -> 25. What's the advantage of shifting from 23... to 24?


Is it in % as I see no percentage sign in the GUI currently? I see 0.00012 represents 0.12% in your documentation. Is this just another way to set a limit of how much things are changed by, just like the "Control limits" option sets a limit of how ms control can be changed?


0.0012 is means 0.12%. To use the actual number instead of a percentage saves one division op :-) This is how much speed is shifted to either slow down or speed up the video when needed. It's a rather crude control algorithm but it seems to suffice.


What happens if my display / refresh are off by more than the frequency adjustment, and control limits. Does the renderer revert to some basic mode like mode 3, Present at nearest vsync?


Today it just bangs its head against the wall, i.e. it tries to adjust but fails and then it tries again. There is today no fallback. It could be more intelligent admittedly.


Problem Noticed: Testing a 25fps music DVD that I want to play at 25fps, gives massive audio pops and glitches, and seems to play at a slow deep sounding rate in sync renderer using this option. It must be suffering badly from audio being out of sync and why I hear the audible blip as sound catches up? I didn't think 0.12% would allow this speed change at all, I thought it would revert to another mode.


Is there a typo above? 25 fps @ 25 fps should work just fine. It would do very few adjustments. Are you using analog audio out? SPDIF will give funny results.


I havn't been able to change front porch number in reclock so I guess this isn't support on Samsung Series 9 or my GTX 295. I don't see any newish Nvidia cards listed in supported list.... Maybe some custom resolution might allow changing of this but will need to look into it to see it in action.


I unfortunately doubt that the 9-series will be supported. ATI seems to be more leaky wrt docs (Rik at Entech once wrote that they depend on leaked docs from NVidia and AMD).


1) Only comment is, that ffdshow refers to horizontal front porch in pixels, so I got a bit confused with SyncRender refering to it as columns.


The columns are one pixel wide :-) When programming we think in rows and columns, that's why.


As an improvement, can adjustment of lines / pixels default to 1 for the most fine grained control, and increase number to 2, 3 automatically if previous attempt at finer grain control didn't work? This if it works, could remove the frequency adjustment options.


Yeah, one could do all kinds of magic with Powerstrip. Too bad it seems to be going out of fashion. It's such an amazing piece of s/w.


2) What happens if sync renderer detects that porch control isn't possible on my display / graphics card. Does the renderer revert to some basic mode like mode 3, Present at nearest vsync, or just continue trying adjustments.


No, it's stupid as of now.


Problem Noticed: Playing my Queen 25fps interlaced Video again, as I enabled de-interlacing in ffdshow a few minutes into this clip, making the frame rate change to 50fps, the renderer starts to show frame rate switching from ~41fps to 50fps (In "Actual Frame Cycle" output), as if its going up and down, so the graph goes a bit mad when it starts go back down from 50.000. I can't hear or see this speed change and my machine has no problem with speed in this situation (cpu usage below 3% on 4ghz core i7). I will test some DVD menu's also as a benchmark of the renderer, to see how it can handle speed changes as time goes on. They have caused problems for some renderers in the past.


I need to look into the code to see what happens at a rate shift. I might only get the rate at start of streaming which should explain your problem.


1) Do all three syncing work better with reclock loaded, ie does it somehow give more accurate details to your renderer in certain scenarios, other than just giving extra control for "Sync display to video".


You mean Powerstrip I presume? It gives a better estimate of the pixel clock but it's not a big deal.


2) Target Sync Offset: Forgive me on this one. I just imagine the target sync offset for anyone would be 0ms, why is it recommended to have a target of 8 – 14 ms for a 60 Hz display?


See this post (http://www.ostrogothia.com/?p=866). Sync offset is the same as "present margin" in the post.


Again, I can test any builds you might have that might benefit from testing using the configuration I use. Just let me know.

I will hold you to that promise :-)

-Arto

[mark0077]

Thanks for your replies. The advantage of speeding 23.976 upto 24 is that 24 fits into 60 exactly 2.5 times giving less jerkyness than 23.976 hz. ReClock does this when its rate is set to "Auto", and like yours, does it with configurable limits. I assumed option 1 was going to sync the 23.976 to my display better by making my video run at 24hz but I know gather it only changes the rate to get the playback rate to an almost exact multiple of the display, not to make a bad situation like mine a little better. Possible improvement! :D

I guess this ability of reclock's would be a mix of option 1, and then option 3 in your sync settings. Maybe if you can perfect your individual renderer modes, maybe get around to including the open source audio resampler, then advanced combinations like this can be suggested or maybe an algorithm can be thought of to make it naturally be used when a scenario could benefit from it (anyone using 60hz display's with 23.976 content).

Regarding the Queen DVD at 25fps, it wasn't a typo. These music DVD's are the only 25fps content that I don't ever want to slow down from 25 to 24hz as the audio was obviously remastered to sound at the correct pitch at 25fps. Obviously at the moment this drives the old option 1 crazy. :D

In any case a toolkit / improvement of two things should make this renderer perfect for myself at least would be

1) Ability to resample audio from one rate to another, along with options and an algorithm to control it.
This would allow
a) 25 -> 24fps speed down which I think alot of users can't go without (although reclock can be used for the time being).
b) Rate changes of say 23.976 to 24 fps without loss of audio sync, even well beyond 0.5% which I assume is the limit when audio isn't resampled to match video rate changes.

2) Options based around these abilities to enable / disable features like PAL SpeedDown.

3) Options to favour certain algorithms in certain situations perhaps, and more importantly the smart algorithm to choose the best of the three synchronization options so every scenario is catered for automatically.

Any input I can give or testing of particular things, as I say, let me know. More than happy to help.

[ar-jar]

Regarding the Queen DVD at 25fps, it wasn't a typo. These music DVD's are the only 25fps content that I don't ever want to slow down from 25 to 24hz as the audio was obviously remastered to sound at the correct pitch at 25fps. Obviously at the moment this drives the old option 1 crazy. :D


Ok, now I see past my prejudices. Your display is running @ 25 fps huh? I haven't tested exactly that scenario to be honest. What happens if you run your the display @ 50 Hz? That's a scenario I test over and over again.
-A

[mark0077]

No, my display is at 60hz, I mean playing 25fps video content at 25fps speed (ie its original speed, no pal speed down as its not required for most music content). So this was 25fps at 60hz. I'm trying to come up with the basics of a smart algorithm, Ill stick it in here and see if you agree with any of my thinkings on it.

[ar-jar]

No, my display is at 60hz, I mean playing 25fps video content at 25fps speed (ie its original speed, no pal speed down as its not required for most music content). So this was 25fps at 60hz. I'm trying to come up with the basics of a smart algorithm, Ill stick it in here and see if you agree with any of my thinkings on it.

Ok. That's unexpected then. I don't have any sound problems with that combination except that the sync adjustment stays at "-1" all the time trying but failing. Are you using analog audio out? And no Reclock? -A

[mark0077]

I had reclock enabled, apologies!!

So here is what I imagine being a high levelish algorithm and options list. This is what I personally would start working with, hope some of it might be of use to yourself when you get around to thinking about it. To test the logic of a possible algorithm I think you could have a simple gui, that would also let the user input a display resolution - refresh rate, and video rate, and click "calculate" to see what the renderer would decide to do. This could be refined before / while it was actually put into actual action in the final renderer. At least the "calculate" option would allow myself and others to go and say, hey in this scenario, with refresh rate x, and video rate y, with option z enabled and option w disabled, the renderer would have decided to do "abc", but the algorithm should be refined so that it does def in this case because "def" would give a better result.

A textual output of the renderers decisions would be great to see what its "thinking" when the algorithm is put in place.

Anyways..

----

--- Options Screen ---

List of resolutions / refresh rates available, with ability to choose which ones can be switched to or not, and possibly which ones to allow frequency adjustment with, with a lines and columns setting for each.


Enabled /Disabled | Resolution | Display Frequency Adjustments
[enabled] 1920 x 1080 @ 60hz | 0 lines | 2 columns
[enabled] 1920 x 1080 @ 24hz | 0 lines | 0 columns
[disabled] 1920 x 1080 @ 1hz | 0 lines | 0 columns
[add] [edit] [remove] [enable][disable][etc]

[enabled] Resolution Switching
[enabled] Display Frequency Adjustments

[enabled] Pal Speed Down

[enabled] Playback Rate Change Allowed
[0.12%] Max Frequency Adjustment
[enabled] Audio Frequency Adjustment Allowed (Would need secret rabbit resampler to be integrated) (Note that when disabled can cause audio going out of sync, but causes pitch change)

[very high] Audio Resampling Quality

[10ms] Target Sync Offset
[2ms] Control Limits +-

----------------------------------------

When Renderer detects rate change
do

# Record the current video rate.

# Generate some basic variables based around high level speed changes requested in options, like pal speed down.
1) If frame rate is 25fps, and if PAL SpeedDown is enabled
Mark video rate as being possibly 23.976 or 24.

# Generate list of possible frequencies, from resolutions and lines / columns figures given in options.
2) If "Resolution Switching" or "Display Frequency Adjustments"
Calculate "Display Frequencies Possible", from various combinations of resolutions, and from what X lines and Y columns changes will mean in terms of display frequency changes.

# Basically figure out what our strategy will be in terms of a one off display resolution / frequency change
3) For each of the possible display frequencies calculated, calculate which "Display Frequency Possible" (from step 2) + "Playback rates possible" (calculated from "Playback Rate Change Allowed" and "Max Frequency Adjustment" options) would give best results, or basically give "Sync video to display" the least to do ;) (how do we define best, making display refresh changes as less of an impact over video rate changes, and then prioritizing whatever combination gives the least skips / glitches).
Make that resolution change (if any).
Wait until resolution change is done?
Make display frequency change using powerstrip (if any).
Wait until frequency change is done?
Make that video rate change to the video and audio (if any).
If "Audio Frequency Adjustment Allowed" then resample audio.

# Now loop using "Sync video to display" knowing the strategy we are using to get in sync from work done above. We perform audio resampling in loop if needed.
4) Perform "Sync video to display" given current playback rate, and display frequency until another rate change occurs where we start again, and possibly pick a new strategy.

----------------------------------------

Oh and one more possible improvement. The graph still seems to refresh / calculate frame rate etc, when video is paused. Maybe this can be disabled when in pause mode.

[BatKnight]

I've been following mark00777 and ar-jar discussion and I would like to add that playing 23.976fps content on a 60Hz has always been a nightmare for me, no matter what render I use.
Ar-jar's render seem to help, and this is what I get: 23.976fps played at 60Hz (http://image-shed.com/show.php/1658_23.976fpsplayedat60hz-1.jpg.html). Notice the change in pattern in the red graph. This happens once in a while and it translates to a glitch or jerkiness in the motion of the Tearing Test Bar. in the quest of getting that CTRL-T test bar to travel across the screen fluidly and smoothly I would like to ask what am I missing? Is there really a way of doing it?

Messing around with the Target Sync Offset should help? If so, how? What differences should I look for when changing the values?

My LCD allows 24Hz and when at it the video is very smooth and the Tearing bar test travels quite smoothly too. But it glitches every once in a while. 2 Examples here: 23.976fps played at 24Hz - example 1 (http://image-shed.com/show.php/1659_23.976fpsplayedat24hz-1.jpg.html) and 23.976fps at 60Hz - example 2 (http://image-shed.com/show.php/1660_23.976fpsplayedat24hz-2.jpg.html)
Can this be minimized or eliminated?

INFO: Specs below, and during video play CPU never got higher than 40% and no other softwares loaded interfere because I've tested without them and get same results.

Bat

[mark0077]

BatKnight, from reading on the reclock forums, the reason 24fps is so desirable over 23.976 in this scenario, is that the final product will be a known number of glitches per second. With 23.976, as there is no number that divides into both it, and 60 evenly, there will be occasions where you have a certain number of glitches per second, and then suddenly you will have an unexpected one in the middle of all of that.

Have you ever tried reclock (without its sync option turned on), and its speed setting set to "Auto (best)". This type of auto mode is what I am hoping ar-jar can build into his code, maybe in step 3 of my attempt at an algorithm above, where its selecting the best combination of display refresh rate and video refresh rate.

In my case, for 60hz, with 23.976 fps video, that turns out to be 60hz display (no change), with 24fps video. 23.976 will give more glitches over time than 24 will. You can minimize this with sync offset, but as I say it will never be as "good" as 24fps on 60hz.

[BatKnight]

Have you ever tried reclock (without its sync option turned on), and its speed setting set to "Auto (best)". This type of auto mode is what I am hoping ar-jar can build into his code, maybe in step 3 of my attempt at an algorithm above, where its selecting the best combination of display refresh rate and video refresh rate.
I haven't used Reclock for a long time, not since version 1.6. Looks like it is very different now.
I've tried it using 60Hz and with 11ms of Target Sync Offset I get no changes in the pattern of the red lines in the stats but It's noticeable (specially in moving pans from down to up [vertically]) that it is not fluid and smooth, it doesn't stutter although it's not fluid.

But when I changed to 24Hz I was in awe! Perfect, smooth, fluid playback of a 23.976fps video. No glitches, no hiccups, nothing!

I left all Reclock settings at default. In your opinion should I had changed anything to help 60Hz playback?
I won't give up from 60Hz because it's somewhat annoying to have to change from 60Hz to 24Hz all the time because of two things. First I use the same computer for games and browsing and the mouse moves slow at 24Hz and I also notice some kind of flicker like in the old CRTs.

Any more suggestions?

Bat

[mark0077]

Well of course if some sort of gui like I suggest was put in place, a renderer could decide to switch to your 24hz display mode to get the best results, and then maybe speed up your 23.976 content slightly, or of course if your display was setup in the gui to allow slight rate adjustments, it could be possible to configure that, and leave speed at original 23.976. It will be great when an algorithm is put in place that people can agree gives best intelligence for a whole range of scenarios, and allows enough flexibility for peoples preferences during the calculations.

I think reclock can even do automatic resolution changing depending on input as is, I am sure you can find out how on the forums. I imagine this would be your best option, followed by 23.976 speed change to 24fps with reclock, followed by 23.976 with some playing with target sync offset to minimize extra judder.

I just hope I'm not going overboard with all of these thoughts on what I think the renderer could become, I suppose I am imagining what I would get if I had the perfect player / renderer for me :D

[ADude]

Restructured and encapsulated everything in the SyncRenderer files.
Is that any actual change in the video processing code, or is it just changes in the structure of the source code without any change in the video processing ?

[ar-jar]

Is that any actual change in the video processing code, or is it just changes in the structure of the source code without any change in the video processing ?

No change in functionality (hopefully) but a better basis for future changes with less risk for unintended side-effects. -A

[Jong]

I haven't used Reclock for a long time, not since version 1.6. Looks like it is very different now.
I've tried it using 60Hz and with 11ms of Target Sync Offset I get no changes in the pattern of the red lines in the stats but It's noticeable (specially in moving pans from down to up [vertically]) that it is not fluid and smooth, it doesn't stutter although it's not fluid.

But when I changed to 24Hz I was in awe! Perfect, smooth, fluid playback of a 23.976fps video. No glitches, no hiccups, nothing!

I left all Reclock settings at default. In your opinion should I had changed anything to help 60Hz playback?23.976fps @60Hz will never be as fluid as @24Hz. You will always have 3:2 Pulldown judder. What Reclock can do is eliminate the additional periodic "jerk" that you get playing 23.976 @60hz.

[Jong]

I think reclock can even do automatic resolution changing depending on input as is, I am sure you can find out how on the forums. I imagine this would be your best option, followed by 23.976 speed change to 24fps with reclock, followed by 23.976 with some playing with target sync offset to minimize extra judder.I used this with XP and Pstrip, but I have not managed to get it working reliably with W7 and my 5xxx series ATI card. PStrip advanced timing is not supported on the latest GPUs and Entech seem to be withdrawing support (claim the product does not sell much any more). Other ways of changing refresh rates in the middle of playback tend to cause problems for many players.

[Pr3d]

Its nice to see GothSync merged into MPCHC.
I'm already using it because it uses less CPU than EVR with DXVA enabled.
Keep up the good work ar-jar, hope to see it merged in the existing renderer asap.

[hdboy]

I have it working pretty well for 23.976fps material on my 24hz/60hz TV. Now the stumbling block is 25fps video (usually UK shows). I get stutters. ctrl+j shows a red sawtooth line with big spikes at regular intervals. Any tip on how to deal with this? thanks.

[Jong]

The only real answer is to change the display to 50Hz. If it is 25p material it might be worth trying slowing down to 24fps, but then it comes down to which is the lesser evil.

[mark0077]

Chances are the 25fps material was recorded at, and should be played at 24fps anyways. 99% of my 25fps PAL content, I choose to play at 24fps, to get the correct audio pitch and frame rate. The only 25fps that should be left at 25fps is mostly music DVD's that have had their pitch corrected to sound correct at 25fps.

[BatKnight]

Chances are the 25fps material was recorded at, and should be played at 24fps anyways. 99% of my 25fps PAL content, I choose to play at 24fps, to get the correct audio pitch and frame rate. The only 25fps that should be left at 25fps is mostly music DVD's that have had their pitch corrected to sound correct at 25fps.
When watching PAL content that was original filmed at 24fps, like US movies, and to get the correct pitch, which PAL Speedown should I tick at Reclock? Media Adaptation, Sound Adaptation or both?

Bat

[mark0077]

Yeah I think the GUI surround this isn't very intuitive. You only select PAL Speed down in media adaptation. If also selected in sound adaption, you get a double whammy and the audio sounds extremely deep.

In reclocks config properties screen, I always set Resampling quality to be "Excellent".

Make sure timestretching "When slowing down media" is disabled in the config properties screen also. Otherwise, you won't get the PAL Speed Down pitch change, as timestretching tries to keep the pitch the same, which is not whats intended during pal speed down. You actually want the pitch change, as you usually get closer to the original content that way.

[iSeries]

After reading this thread I had thought that the Target Sync Offset should be set to around 3/4 of a display refresh cycle - so for a 24hz screen this should be set to around 31? For some reason setting this to 31 gives me tearing. So instead would it be a good idea to change this to the highest value that does not give me tearing? 28 seems to be the highest I can go for tear-free playback.

Or should I just keep it at the default 12?

[Remicade]

In yours opinion what is the best way to play 23,796 content on a 60 Hz LCD 1360x768 ?

[BatKnight]

In yours opinion what is the best way to play 23,796 content on a 60 Hz LCD 1360x768 ?

In my experience I got to know that if your display can't do 24Hz then use Reclock to speedup to 24fps. This way won't give you smooth playback as when on 24Hz, just the classic 3:2 pulldown judder without further stuttering.

If your LCD does 24Hz, then use it. It's quite a difference in smoothness.

Bat

[Leak]

PStrip advanced timing is not supported on the latest GPUs and Entech seem to be withdrawing support (claim the product does not sell much any more).
Reading their forums it sounds more like they don't have the hardware documentation they'd need to support ATI's Evergreen (5xxx) line - yet.

Seeing as ATI released the full shader hardware documentation for it just before christmas, and one of their coders (John Bridgeman) said on the Phoronix forums that they were working on scrubbing the docs and code for modesetting (which is what PowerStrip does) so they can also released that in the near future...

Of course, with those docs it should also be possible to write a stand-alone driver for ATI cards to tweak the timings, taking PowerStrip out of the picture completely as far as twiddling the front and back porch values through the GothSync renderer is concerned...

(NB: that doesn't mean someone is going to do it, of course - it just means it should be possible...)

[madshi]

Of course, with those docs it should also be possible to write a stand-alone driver for ATI cards to tweak the timings, taking PowerStrip out of the picture completely as far as twiddling the front and back porch values through the GothSync renderer is concerned...

(NB: that doesn't mean someone is going to do it, of course - it just means it should be possible...)
Having an open source HTPC optimized Windows driver is one of my wet dreams.

(NB: I definitely have no plans to work on such a thing)

[Leak]

Having an open source HTPC optimized Windows driver is one of my wet dreams.

(NB: I definitely have no plans to work on such a thing)
I guess I should clarify - by "driver" I meant some small piece of kernel-level code that twiddles the card's timing values, not a full blown graphics driver; AFAIK that's what PowerStrip does.

[Jong]

Reading their forums it sounds more like they don't have the hardware documentation they'd need to support ATI's Evergreen (5xxx) line - yet.

Seeing as ATI released the full shader hardware documentation for it just before christmas, and one of their coders (John Bridgeman) said on the Phoronix forums that they were working on scrubbing the docs and code for modesetting (which is what PowerStrip does) so they can also released that in the near future...Let's hope! For sure they currently lack documentation, but they have also said in the last few months that the market and revenue stream for pstrip is drying up so they are not putting much time into it.

It's true that the infinite flexibility of pstrip is less and less useful now with LCDs, fixed refresh rates and synced HDMI audio. But a simplified tool targetted at HTPCs would I think be very popular.

[madshi]

I guess I should clarify - by "driver" I meant some small piece of kernel-level code that twiddles the card's timing values, not a full blown graphics driver; AFAIK that's what PowerStrip does.
Well, I meant a full blown graphics driver. Let me dream... :)

[ar-jar]

Having an open source HTPC optimized Windows driver is one of my wet dreams.

(NB: I definitely have no plans to work on such a thing)

I'd like to subscribe to that wet dream! I once tried to get some open source driver folks interested but I don't think I got any answer actually. One could forget about all the 3D-stuff and just focus on shuffling pixels and doing some 2D-filtering. And adjusting the timings of course in a delicate manner. A question that I still haven't found any answer to is how the digital set-top boxes do this. With dirt-cheap hardware and Linux. Do they have sync or aren't we just noticing the occasional judder because we are not looking for it? -A

[ADude]

I have it working pretty well for 23.976fps material on my 24hz/60hz TV. Now the stumbling block is 25fps video (usually UK shows). I get stutters. ctrl+j shows a red sawtooth line with big spikes at regular intervals. Any tip on how to deal with this? thanks.

The two answers you received were wrong.

(Sorry, nothing personal.)

I have a 60hz TV, and since it is not purchased from Europe, then it does not have a 50hz refresh setting, and probably neither does yours.

And, the UK shows we are watching are not based on films, so slowing them down to 24fps is also wrong. When we say "UK shows" that means "UK TV shows" that were captured from 25fps or 50fps broadcasts.

In my experience, what you need to do is to:

- Choose "Sync Renderer" and EVR Buffers = 10
- Check the "Present at Nearest sync" setting
- Set Target Sync Offset to 10

[Jong]

What is your definition of "wrong"?

The only way to smoothly play 25p content is @50Hz. Even slowing to 24fps still leads to 3:2 pulldown judder. Your answer leads to, even worse, one repeated frame for every five. You are trading smoothness for accurate pitch. Which, as I said, comes down to the lesser of two evils.

I fully respect your preference for judder over inaccurate pitch, but neither is right or wrong and it is a fact (like it or not) that all PAL DVDs of US films preferred 4% inaccurate pitch over judder.

[madshi]

I'd like to subscribe to that wet dream! I once tried to get some open source driver folks interested but I don't think I got any answer actually. One could forget about all the 3D-stuff and just focus on shuffling pixels and doing some 2D-filtering. And adjusting the timings of course in a delicate manner.
Well, my renderer makes a lot of use of pixel shaders, so I'd need access to 3D hardware, too... :(

A question that I still haven't found any answer to is how the digital set-top boxes do this. With dirt-cheap hardware and Linux. Do they have sync or aren't we just noticing the occasional judder because we are not looking for it?
I don't know about dirt cheap hardware. But I have feedback from higher quality companies. One answer from a set-top box designer (ReelBox), one answer from a receiver designer (Arcam), one answer from a Blu-Ray player designer (Ayre):

ReelBox: http://reelbox-forum.com/showthread.php?t=6839
Arcam: http://www.avsforum.com/avs-vb/showthread.php?p=11079529#post11079529
Ayre: http://www.avsforum.com/avs-vb/showthread.php?p=17402589#post17402589

Very interesting posts, I think.

[ar-jar]

Well, my renderer makes a lot of use of pixel shaders, so I'd need access to 3D hardware, too... :(


Yes, we would need to rewrite code but using a full-blown 3D engine to create a texture on two triangles (or something along those lines) is really overkill. I could do with a fast blt function, support for fast convolutions, some LUT functions and some simple arithmetics on color vectors.

I didn't quite understand how the posts that you referred to relate to judder (e.g. pan judder). They seemed to be more about jitter which sounds like something else. What I would like to know is whether simple satellite boxes actually synchronize their video output circuitry to the incoming video and how they in that case tweak the HDMI output to the display to reflect this sync. My take after reading about the standard is that there is actually a "digital sync pulse" in the DVI signal from which the display can extract a clock. I would be great to understand exactly how and how much and when this sync pulse can be tweaked. Or maybe I have misunderstood the standard? -A

[buzzqw]

@ar-jar

i am experimenting with your render, and it's very good so far !
but i have a problem, powerstrip don't support my card (gt240) so i am using reclock with displaychanger (http://www.12noon.com/displaychanger.htm)

will be possibile to implement displaychanger support in mpc-hc GothSync ?

thanks

BHH

[madshi]

using a full-blown 3D engine to create a texture on two triangles (or something along those lines) is really overkill.
The point is that I'm not happy with any of the GPU's built in video processing algorithms. So I'm doing everything myself, and for that I can use all the computational power I can get. The more, the better.

I didn't quite understand how the posts that you referred to relate to judder (e.g. pan judder). They seemed to be more about jitter which sounds like something else. What I would like to know is whether simple satellite boxes actually synchronize their video output circuitry to the incoming video and how they in that case tweak the HDMI output to the display to reflect this sync.
The posts I linked to are talking about adjusting audio / video clocks by using a VCXO. Which you can think of as a clock generator which can be adjusted very accurately. So if video is too fast, they simply lower the clock ever so slightly in real time.

Really cheap devices don't seem to do this. Instead they probably drop video/audio frames every once in a while...

My take after reading about the standard is that there is actually a "digital sync pulse" in the DVI signal from which the display can extract a clock. I would be great to understand exactly how and how much and when this sync pulse can be tweaked. Or maybe I have misunderstood the standard?
My understanding is that this "sync pulse" is simply the speed in which frames are sent by the source device. So it's controlled by the source device's clock generator. I don't think we can really tweak the HTPC audio/video clocks in a useful way. You can use PowerStrip to change the (pixel) clock, but the minimum pixel clock changes you can do are so big that changing them during playback would probably too much of a change and might confuse the display. What we'd really need is a way to change the pixel clock in *MUCH* smaller steps. I don't think the GPU hardware can do this. The GPU's clock generator is probably not flexible enough for such small pixel clock changes...

[ar-jar]

The point is that I'm not happy with any of the GPU's built in video processing algorithms. So I'm doing everything myself, and for that I can use all the computational power I can get. The more, the better.

I understand. But today I guess you are using that raw processing power through DirectX interfaces, the methods of which aren't necessarily optimal for 2D video processing. Or are you using Cuda or OpenCL or something like that for your algorithms?


My understanding is that this "sync pulse" is simply the speed in which frames are sent by the source device. So it's controlled by the source device's clock generator. I don't think we can really tweak the HTPC audio/video clocks in a useful way. You can use PowerStrip to change the (pixel) clock, but the minimum pixel clock changes you can do are so big that changing them during playback would probably too much of a change and might confuse the display. What we'd really need is a way to change the pixel clock in *MUCH* smaller steps. I don't think the GPU hardware can do this. The GPU's clock generator is probably not flexible enough for such small pixel clock changes...

The DVI specs define requirements on the clock and how the receiver must lock to the clock. But is also defines a horizontal and vertical sync. The question is to what extent and how these sync signals are used by the display unit. My Powerstrip-based "genlock" in fact shifts these sync signals one line or one column (or so) when needed and it seems that at least 720 displays immediately adapt to the new sync interval. I do not change the pixel clock. I also read somewhere that LCDs display one line at the time and I would guess that the timing for this is determined by the h-sync pulse, not the pixel clock. But I would be interested to read any articles or specs thay you may have and that explain how for instance an LCD displays the incoming digital signal, i.e what in the signal triggers what actions in the display unit. -A

[madshi]

I understand. But today I guess you are using that raw processing power through DirectX interfaces, the methods of which aren't necessarily optimal for 2D video processing. Or are you using Cuda or OpenCL or something like that for your algorithms?
The whole 3D pipeline is rather complicated and not optimized for video processing, of course. However, you set that up once and then forget it. I'm doing the real work by using Pixel Shaders and they work great for 2D video processing IMHO.

The DVI specs define requirements on the clock and how the receiver must lock to the clock. But is also defines a horizontal and vertical sync. The question is to what extent and how these sync signals are used by the display unit. My Powerstrip-based "genlock" in fact shifts these sync signals one line or one column (or so) when needed and it seems that at least 720 displays immediately adapt to the new sync interval. I do not change the pixel clock. I also read somewhere that LCDs display one line at the time and I would guess that the timing for this is determined by the h-sync pulse, not the pixel clock. But I would be interested to read any articles or specs thay you may have and that explain how for instance an LCD displays the incoming digital signal, i.e what in the signal triggers what actions in the display unit. -A
I know that you are modifying the sync signals, but that's not what high-end Blu-Ray players and satellite boxes do. They're changing the clock, not the sync signals. I can't say that your method is better or worse, I don't know that, but I do know that when I played with the sync settings on my old plasma, it sometimes "resynced" (image went black, then came back after a second or so). I think doing extremely small adjustments to the pixel clock would be a safer way to solve the problem, but the PC hardware doesn't allow us to do that.

[somy]

Hi ar-jar, thanks for your great work, now I can see it's integrated to MPC-HC with auto display refresh rate changing feature, amazing.
I have a question, what is the advised value of target sync offset and control for 24P playback on 23.976HZ display? The default value is 12ms, and I assume it only works for 25P playback on 50HZ device right?
Thanks!

[DigitalLF]

i have a question for Ar-Jar i think... (Leak later told me this is a question for Aleksoid)

are you the maker of the "autochange fullscreen monitor mode"? if so would it be possible to add a option for a delay before opening the file? it would help me to use this feature with MadVR.

its my just my very own personal way of thinking how it could be used with MadVR i don't know if its the solution ...


but I'm just guessing now but to find out the framerate you use mediainfo?

[somy]

i have a question for Ar-Jar i think...

are you the maker of the "autochange fullscreen monitor mode"? if so would it be possible to add a option for a delay before opening the file? it would help me to use this feature with MadVR.

its my just my very own personal way of thinking how it could be used with MadVR i don't know if its the solution ...


but I'm just guessing now but to find out the framerate you use mediainfo?

This could be nice. MadVR need some seconds to warm up, otherwise it will use the wrong refresh rate. I now use CCC to change refresh rate before I start to play movie ::devil::devil::devil:

[DigitalLF]

somy i for now use a hotkeys on my keyboard to run a .bat file to change the refreshrate. but that delay would be perfect =)

[Leak]

i have a question for Ar-Jar i think...

are you the maker of the "autochange fullscreen monitor mode"?
If you read the change log (http://mpc-hc.svn.sourceforge.net/viewvc/mpc-hc?view=rev&revision=1517) you'll find it actually was added by Aleksoid, so you might have more success asking in the "regular" MPC HC thread...

[THX-UltraII]

Hi Ar-Jar,

I just bought a new ATI 5670 card and have some tearing issues when selecting sync output as renderer. The problem is at the bottom of the screen. So no problems with 2:35:1 movies but you can see tearing at very bottom of the screen with 1:85 (full 16:9) content. It can also be seen when doing a tearing test (ctrl+t) because the two red bars are broken at the bottom of the screen. I also have this problem with EVR custom but found out that I can solve it by CHECKING 'alternative v-sync' (that s NOT the 'accurate v-sync option which is ENABLED by default in EVR custom).

I hope you can do something with this information because I m not using your output now because of this rendering issue. If you need more info let me know!

[somy]

Hi Ar-Jar,

I just bought a new ATI 5670 card and have some tearing issues when selecting sync output as renderer. The problem is at the bottom of the screen. So no problems with 2:35:1 movies but you can see tearing at very bottom of the screen with 1:85 (full 16:9) content. It can also be seen when doing a tearing test (ctrl+t) because the two red bars are broken at the bottom of the screen. I also have this problem with EVR custom but found out that I can solve it by CHECKING 'alternative v-sync' (that s NOT the 'accurate v-sync option which is ENABLED by default in EVR custom).

I hope you can do something with this information because I m not using your output now because of this rendering issue. If you need more info let me know!

The same result I had yesterday when I tried Sync renderer, I thought it was my projector problem:mad::mad::mad:

[DigitalLF]

Leak thank you i did not know where to find the changelog. =)