Realtime software-based genlock now possible with PowerStrip API

[Mark Rejhon]

Hi,

Just trying to start a discussion about how software-based realtime genlock is now possible with an arbitrary DirectShow capture card, thanks to the existence of the PowerStrip API which can adjust a graphics card refresh rate.

See my post in the Reclock thread (http://forum.doom9.org/showthread.php?s=&postid=469897#post469897).

The existence of the PowerStrip API makes it possible to adjust a Radeon graphics card in 0.001 Hz refresh rate increments using an API method, or adding/removing scanlines to the VBI output (this latter method actually works on all Geforce cards going all the way back to the old TNT2 cards!).

By automatically using the PowerStrip API on a realtime basis, it is therefore possible to write a software DirectShow-style filter program that does a realtime genlock (synchronization) between an input (capture card) and the output (Radeon card). This must be done carefully during the VBI (Vertical Blanking Interval) -- in order to avoid disruption. Ideally, PowerStrip would be set as a higher-priority task and a thread waiting on the VBI would be done before doing a PowerStrip API to adjust if the synchronization was "falling behind" or "falling ahead" by microseconds. I did a crude test in a short C++ program, and all monitors I tried didn't show any disruption if I made the PowerStrip API to adjust the display frequencies during the VBI interval. (CRT monitors though). I found that the scanline addition/removal during the VBI produced the best results, and is actually compatible with Geforce. So basically, if you are using a 640x480 computer graphics mode, you usually have 525 scanlines (including VBI scanlines). Using the PowerStrip to alternately dynamically between 524, 525 and 526 scanlines on the Radeon graphics output (ie toggle between 39, 40, and 41 vertical retrace interval scanlines) in realtime, in order to keep the Radeon VGA output perfectly synchronized with the input framerate/fieldrate of a capture card. The existing buffering that DirectShow does, will give approximately a 1/60th of a second safety margin before a singe frame drop/add occurs, so the addition/removal of a few scanlines only adds/removes a few tens of microseconds of delay to a Radeon refresh. This minute delays can already be dynamically manipulated accurately enough to be much smaller than the existing safety margin of the existing DirectShow buffering, for 100% perfect 1:1 framerate synchronization between the capture card and graphics card.

(The existing Reclock DirectShow filter (http://ogo.nerim.net/reclockfilter/) does a similiar process already, but only on prerecorded material, not on live video material. In the past, it was impossible to do the same thing with live video material. Now that the PowerStrip API exists, this can now be achieved.

Genlock is very important for the broadcasting industry, especially if a PC is used as a realtime live video processing machine that is immediately used for broadcast in live video processing by a PC. (Example: www.dscaler.org or other realtime video processing like ffdshow for live display.)

An existing filter such as ReClock DirectShow filter (GNU open source) can be retrofitted to use the PowerStrip API, to make realtime software-based genlock possible on live video sources!

I made proprietary software for some earlier video processor products that has been able to genlock on a 5:4 basis, using a 60 Hz video source with 24fps material. First, a 3:2 pulldown deinterlace (reverse telecine) is done down to 24fps, then the framerate is tripled to 72 Hz by repeating each frame. So basically, a 5:4 genlock for a realtime 72 Hz output from a realtime 60 Hz video source that has embedded 24fps material in 3:2 pulldown.

I also invented the algorithm that is used behind JudderTerminator in dScaler -- with me being listed as one of the authors of the dScaler open-source realtime video processor software (http://www.dscaler.org/Authors.htm). Combine this with a realtime genlock, you get a judder-free dream.

Anyway, contact me by email if you'd like more details on the technical implementations... (I helped program the software behind some video processors in the industry such as TAW ROCK, Key Digital LEEZA, Immersive HOLO3D, and a few others).

Thanks,
Mark Rejhon
www.rejtech.com (http://www.rejtech.com)
www.marky.com/hometheater (http://www.marky.com/hometheater)

[Mark Rejhon]

I have a posted a much longer version of this paper here:
Programmers: Realtime 1:1 genlock now possible btwn live capture video and Radeon (http://www.avsforum.com/avs-vb/showthread.php?s=&postid=3624602)

[hartford]

Well, that's nice.

Are you trying to sell something?

If not, then provide url to your source.

Thanks.

[Mark Rejhon]

Come on. I'm not selling anything. Just trying to get this idea through to the author of Reclock, since this is an exciting new development in video synchronization technology now being possible on mainstream PC's without needing special hardware! A software program, called Reclock DirectShow Filter (http://ogo.nerim.net/reclockfilter/) could easily be modified to take advantage of PowerStrip API to provide synchronization on live DirectShow sources (ie capture cards) rather than from prerecorded media/files.

Here's the proof. Here's this Microsoft Research article [click] (http://www.microsoft.com/whdc/hwdev/tech/stream/vidcap/VidSynch.mspx) proves this science. See their article covering Video Synchronization. I'm not the original author. I just announced successful tests of genlock by using PowerStrip API as the method of controlling the genlock (video synchronization), and that it is now pratical enough to be added to computer applications now. I am using the VBI scanline add/remove method outlined in the Microsoft Research document, which is indicated as "Adjust the number of scan lines or horizontal pixels dynamically for speed up and slow down." (Microsoft, 12-04-2001 [link] (http://www.microsoft.com/whdc/hwdev/tech/stream/vidcap/VidSynch.mspx)). I did exactly this in my simple genlock test using the PowerStrip API, and succeeded (scanlines work better than horizontal pixels, though).

Considering most of you on this forum have heard of dScaler, I'm surprised you don't know my name. I've contributed lots to open source video projects. I am one of the earlier authors to dScaler: www.dscaler.org

I invented one of the world's first open source 3:2 deinterlace algorithms:
ttp://www.dscaler.org/32Spec.htm
Which is based on an old 1999 AVSFORUM post I made:
http://archive.avsforum.com/avs-vb/showthread.php?threadid=74510

My credentials:
Magazine articles with my name I've been mentioned in. (SGHT = Stereophile Guide To Home Theater):
- Fortune Magazine, July 24, 2000, Page 210 (HTPC)
- SGHT, May 2001, Page 55 (TAW Rock)
- SGHT, November 2001, Page 38 (free open-source dScaler)
- SGHT, December 2001, Page 32-33 (free Test Pattern I invented)
- SGHT, October 2002, Page 90 (JudderTerminator in a product, contributed to dScaler too)
Google highlighting my name within web version of Forbes article:
http://www.google.com/search?q=forbes.com+Rejhon
Google highlighting my name within web version of SGHT articles:
http://www.google.com/search?q=guidetohometheater.com+Rejhon
http://www.google.com/search?q=guidetohometheater.com+Rejohn
Also, my own various personal websites at:
www.marky.com
www.marky.com/hometheater
And of course, an easy check on my reputation via Googling me (my last name is relatively unique).
http://www.google.com/search?q=rejhon

I'm a computer programmer for 18 years out of my 30 years and well known in other forums such as AVSFORUM (I have a postcount of 7502 there, and was the moderator of the AVSFORUM Home Theater Computers forum from 1999 through 2001.)

[Mark Rejhon]

For more information for the programmer types. (A reasonable familiarity with "video timings" is required with concepts such as PowerStrip or Linux XFree86 modelines, Vertical Blanking Interval, horizontal scan frequency, etc.)


[Sent email to dScaler discussion, but this technical information is useful to other programmers such as the Reclock DirectShow filter author, the ffdshow author, other capture card software, etc.]

Updated & expanded version of original email I wrote as follows as of April 5th, 2004, various of which were first sent to the dScaler list, doom9 forum, the Reclock author, and to people like John Adcock. I actually came up with this idea more than a year ago, but I think it's time for me to let the cat out of the bag (this may cause some other people to make money off this idea in certain cases rather than me... but try not to forget about me! ;))

______________________________________________________

Hi,

Long time no talk! There are new developers on this list who don't even remember my involvement, so let me introduce myself first.

You may remember that I helped invent the original algorithmic paper for the 3:2 pulldown algorithm dScaler:
http://archive.avsforum.com/avs-vb/showthread.php?threadid=74510
Note, dScaler used to be called dTV. The old version of the algorithm is documented at:
http://www.dscaler.org/32Spec.htm
It was the first 3:2 pulldown algorithm to really work well in dScaler (formerly dTV). Many of you remember that I invented the JudderTerminator algorithm that John Adcock deployed in source code. These two algorithms arguably form the two-pillar dScaler foundation of a pleasant 72 Hz experience with using dScaler to watch NTSC film material. (3:2 deinterlacing combined with JudderTerminator, for watching at 72 Hz)

Now I am about to suggest a new revolutionary suggestion for dScaler. Do software-based realtime genlock (perfect sync between capture card and Radeon). Make dScaler take advantage of the PowerStrip API or something similiar. This could make dScaler broadcaster-quality!

The existence of the PowerStrip API makes it possible to adjust a Radeon graphics card in 0.001 Hz refresh rate increments using an API method, or adding/removing scanlines to the VBI output (this latter method actually works on all Geforce cards going all the way back to the old TNT2 cards!).

By automatically using the PowerStrip API on a realtime basis, it is therefore possible to write a software DirectShow-style filter program that does a realtime genlock (synchronization) between an input (capture card) and the output (Radeon card). This must be done carefully during the VBI (Vertical Blanking Interval) -- in order to avoid disruption. Ideally, PowerStrip would be set as a higher-priority task and a thread waiting on the VBI would be done before doing a PowerStrip API to adjust if the synchronization was "falling behind" or "falling ahead" by microseconds. I did a crude test in a short C++ program, and all monitors I tried didn't show any disruption if I made the PowerStrip API to adjust the display frequencies during the VBI interval. (CRT monitors though). I found that the scanline addition/removal during the VBI produced the best results, and is actually compatible with Geforce. So basically, if you are using a 640x480 computer graphics mode, you usually have 525 scanlines (including VBI scanlines). Using the PowerStrip to alternately dynamically between 524, 525 and 526 scanlines on the Radeon graphics output (ie toggle between 39, 40, and 41 vertical retrace interval scanlines) in realtime, in order to keep the Radeon VGA output perfectly synchronized with the input framerate/fieldrate of a capture card. The existing buffering that DirectShow does, will give approximately a 1/60th of a second safety margin before a singe frame drop/add occurs, so the addition/removal of a few scanlines only adds/removes a few tens of microseconds of delay to a Radeon refresh. This minute delays can already be dynamically manipulated accurately enough to be much smaller than the existing safety margin of the existing DirectShow buffering, for 100% perfect 1:1 framerate synchronization between the capture card and graphics card.

The existing Reclock DirectShow does a similiar process already, but only on prerecorded material for DirectShow based DVD players, and not on live video material. It adds/removes clocks from the audio clock, in order to keep prerecorded file/media/DVD playback in synchronization with the output refresh rate. In the past, it was impossible to do the same thing with live video material on a standard PC system because consumer AGP cards do not synchronize to the clock of a capture card. Now that the PowerStrip API exists, this can now be achieved.

Realtime dotclock synchronization between the capture card and the AGP graphic card!

Genlock is very important for the broadcasting industry, especially if a PC is used as a realtime live video processing machine that is immediately used for broadcast in live video processing by a PC.

An existing filter such as ReClock DirectShow filter (GNU open source) can be retrofitted to use the PowerStrip API, to make realtime software-based genlock possible on live video sources! Ideally, realtime genlock needs to be directly built into the video viewer.

I made proprietary software for some earlier video processor products that has been able to genlock on a 5:4 basis, using a 60 Hz video source with 24fps material. First, a 3:2 pulldown deinterlace (reverse telecine) is done down to 24fps, then the framerate is tripled to 72 Hz by repeating each frame. So basically, a 5:4 genlock for a realtime 72 Hz output from a realtime 60 Hz video source that has embedded 24fps material in 3:2 pulldown.

Even a Microsoft Research paper covered this topic of synchronization:
http://www.microsoft.com/whdc/hwdev/tech/stream/vidcap/VidSynch.mspx

FINALLY, by using the PowerStrip API makes this possible in a VERY easy manner for existing software such as Reclock or dScaler. Your software program is one of the other closest thing on the market that makes this achievable with realtime capture cards, because of dScaler's existing JudderTerminator algorithm. All this needs is a PowerStrip API calling algorithm to be piggybacked on top of this. The PowerStrip API only needs to be called approximately 15 to 30 times per second, all during the VBI interval. Make sure PowerStrip is running at a slightly higher priority than dScaler, to be safe (some adjustment may be needed). It is critical that all PowerStrip adjustments must be done instantaneously during the VBI interval in order to eliminate any visible computer monitor disruptions. (It works on 4 computer monitors I tried -- all of them CRT though) It also works on my DILA projector.

A wait port instruction on the VGA port 0x03DA is all that is needed to wait for the vertical blanking interval (or the appropriate DirectX API call), followed by an immediate PowerStrip API call (maybe wait a few scanlines into the VBI -- but making the call immediately at the beginning of the VBI seems to be fine in most cases). Here, it was possible for me to change the refresh rate in 0.001 Hz increments or add/remove a VBI scanline without ANY VISIBLE disruption to the computer graphics -- the monitor does not even notice the change. On some displays, there may be minor disruptions, and not all displays may be able to handle dynamic refresh rate changes. However, since 50 years ago, VCRs have had variable refresh rates and many displays have been designed to be tolerant of variability in refresh rate. Much of the "raster scanning" methodology for TV's also applies to most computer monitors. Therefore, the use of software-based very-slight varying of refresh or VBI scanlines, can work on most computer monitor displays properly.

The scanline add/remove trick, on a 1920x1080p (assuming 1125 vertical total, 72.0000 Hz) can achieve refresh rate adjustment granularity of 0.000012 Hz on both Radeon and Geforce cards! (1080p with 1125 line vertical total at 72 Hz equals a 81 kilohertz horizontal scanrate, which means 81000 Hz. This means adding and removing scanlines from VBI gives you a ultra precision of 1/81000ths of a single hertz. 1/81000th of a second equals approximately 0.000012 Hz. With this precision, this does not interfere with the display -- most displays are tolerant of such tiny variances. Simply modulating the refresh rate up and down in these tiny increments as needed to make the synchronization "catch up" or "fall behind", it is then subsequently possible to achieve 1:1 perfect genlock between a capture card and a Radeon card.

The PowerStrip API is documented at:
http://www.entechtaiwan.net/forums/viewtopic.php?t=6

By making realtime genlock possible, it should now be possible to have perfect 48 Hz or 72 Hz operation without a single dropped/added refresh during the entire course of a 2-hour DVD movie played through a capture card and then through dScaler out to a Radeon graphics card, on a properly setup computer system. Or perfectly correct 3:2 pulldown at 60 Hz with no stutter in the judder caused by lack of synchronization between the capture card and the output graphics board.

It is true that PowerStrip allows someone to get very very very close to a 1:1 synchronization between the capture card and the Radeon output. However, refresh rate will always differ by a tiny fraction, and this causes 'microstutters' occasionally that some sensitive people like me can notice!

There are certain technical issues regarding PowerStrip performance using the SendMessage API, and the PowerStrip automatic-scanning for clock frequency divisors take up some CPU time during "ultrafine" adjustments -- this may explain why I got better results with the vertical sync scanline addition/removal technique in my crude C++ internal testing of the viability of software-based genlock. The VBI scanline add/remove technique works fine on Geforce cards, so that's another advantage. (Actually incrementing/decrementing the Back Porch or Front Porch actually works too, although sometimes it caused the vertical image position to shift on some displays. So, a consensus should be made which VBI setting should be manipulated to achieve realtime genlock.

Another alternative is a direct Radeon register write to increment/decrement the number of scanlines in a refresh. This would be less portable than the PowerStrip API method, but would be higher performance.

While certain displays have absolutely no effect at all to the dynamic add/removes of scanlines in the VBI, certain types of CRT displays sometimes have a slight one-scanline shift or half-scanline shift if manipulating using the add/remove scanline method. This can be mitigated somewhat by rapidly alternating between two vertical totals that are off by 1 pixels alternatingly (i.e. 1125 versus 1126 for a 1080p graphics display, including VBI lines) to "balance"/"blur" the shifting out on such displays. That is, 1125 scanline vertical total half of the time, with 1126 scanline vertical total during the other half. Rapidly alternate between 1125 and 1126. During genlock synchronization, certain refreshes using 1125 would simply become 1126 instead whenever necessary to "catchup"/"fallback", while every other refresh would have 1126 scanline vertical total. This technique appears to compensate on some displays that has noticeable one-pixel-shift effects to the VBI scanline add/remove. Based on my testing with my DILA projector, it appears that the scanline add/remove has absolutely no perceptable deleterious effect on the DILA, which would mean that the displays that benefit the most from the scanline add/remove technique, would be certain digital displays that don't use a "native refresh rate". (Be noted, that my DILA is able to sync to 48 Hz refresh rate -- not all digital displays can do native refresh rates other than 60 Hz without internal framerate conversion.)

For attempting genlock to more variable-refresh-rate input material such as VCR-based material, this can become more tricky. It may be necessary to have a VBI add/remove scanline system that works automatically at greater amplitudes (i.e. dynamically modulate all the way between 1120 and 1140 vertical total for a 1080p output) or combine with dynamic refresh rate adjustment (if the PowerStrip people can make this faster or more efficient - i.e. precalculated lookup tables of divisors for every 0.001 Hz increments). It is observed that disruption is minimized on CRT displays if you increment 1 scanline at a time between refreshes. (You may be familiar with that some settop video processors that has genlock, sometimes causes CRT projectors to go out of sync when playing from a VCR -- because the refresh rate varies too much). So in essence, it may be necessary to buffer these variances somewhat to avoid display disruption. There is about 1/60th of a second safety margin, so one can keep incrementing/decrementing VBI scanlines every refresh, until fully caught up or fallen behind. Obviously, at the start, it's necessary to try to set the vertical refresh rate as accurately as possible, so that ideally, the VBI scanline add/remove technique of doing genlock, only requires an amplitude of 1 scanline (i.e. switching between 1124 or 1125 scanlines). Playback from external DVD players (and perhap piped through a theoretical genlock-capable dScaler) produce a refresh rate stable enough to be genlocked using only an amplitude of 1 scanline for the VBI add/remove scanline trick, but definitely not from analog VCR's.
[continued...]

[Mark Rejhon]

[...continued]
Optional extra step: Not necessary at the moment as we can use VBI scanline add/remove technique instead. But to also improve the viability of the other technique using the dynamic refreshrate modulation rather than just scanline add/remove, we may need Entechtaiwan's involvement in improving the performance of the PowerStrip API for the refresh rate changes since it seems to do a display-disruptive scanning process (at the moment, the VBI scanline add/remove trick works best - and works on Geforce cards) Reprogramming the vertical refresh rate without changing the vertical total/horizontal total is much more complicated programming for a graphics card. The refresh rate is calculated indirectly using a math formula containing a divisor, involving the dotclock setting. A computer running for a while might be able to pre-calculate a nice, large table of precomputed clock divisors to be used for direct register writes, for as many possible super-tiny fractional refresh rate increments as possible between say, 59.9 Hz and 60.1 Hz automatically. Then there is less display disruption during refresh rate changes. Certain resolutions at certain dotclocks on certain Radeons may be able to achieve 0.0001 Hz precisions, while other resolutions will not be able to do any better than approximately 0.1 Hz. Anyway, this part is a little too complex to contempate at the moment. The point is that the VBI scanline add/remove trick seems to work just fine for most purposes. Behaviour caused by VBI scanline add/remove is display dependant, but the vast majority of displays are not having noticeable effects with a 1-pixel add/remove scanline, especially with various workarounds possible. Unless refresh rate changes can be made at even tinier fractions, this is not as good as the VBI scanline add/remove technique of doing genlock.

Also, started a thread in the doom9 forum because I am trying to inform the Reclock author of this revolutionary technique that is now possible with the PowerStrip API in my limited testing;

http://forum.doom9.org/showthread.php?s=&postid=469899

I am letting this cat out of the bag to be attacked by all you professional programmers. I am announcing that software-based genlock (synchronization) is now actually pratical on current computer hardware!

[Update: It appears that on some graphics cards, it is not even necessary to wait for the vertical sync interval before doing the PowerStrip API to do a dynamic increment/decrement to the Vertical Total in order to add/remove VBI scanline in a PowerStrip API call. However, this is not guaranteed. More testing is needed. My Radeon 9600 Pro seems perfectly happy with a random Vertical Total increment/decrement with no display disruption. It may actually be automatically buffering that particular register write(s) from PowerStrip, or that certain versions PowerStrip is automatically waiting for VBI itself. This still needs to be as-of-yet determined. The good news is that this may eliminate a requirement, since not all CPU-hungry video capture applications have the luxury of waiting until VBI.]

[Update2: I have heard there are other non-PowerStrip-API's that might be possible for manipulating timings of a graphics card. Those can be used as well, assuming the API is clearly documented somewhere. Direct register writes can be done. One could research the existing Linux XFree86 video timings tweaking source code for such programming information, for example.]

Mark Rejhon

[Mark Rejhon]

As you can see, the only reason I came to visit this forum rather than my usual forum hangouts elsewhere on the Internet, is that I'm trying to get the message of this success through to the author of the Reclock software. (Though, a third party can just about easily modify Reclock to also work on live video sources with this new information, if one had the time)

[Mug Funky]

FWIW it seems you've achieved some very cool feats here, but unfortunately i've no immediate use for them (no capture card, useless TV out as my TV is in a different room).

hope you get through to the ReClock guy

[mf]

Bah, this would be pretty annoying. It'd mean I'd have to set geometry presets for every tenth variation in refresh rate, not to mention that (I don't know about your CRT, but mine does) the monitor actually shakes the image vertically when changing the vertical refresh rate. Also, cheaper-brand monitors perform bad on nonstandard refresh rates (anything that isn't 60, 75, 85, 100 or 120Hz).

(disclaimer: i haven't read all of the above posts so I might be uninformed about what I just posted)

[avih]

this feature would be the most needed addition to dscaler imho.
dscaler is very advanced in all other fields (well, except for time shifting, but i can live without it).

although i don't really like the fact that it counts so much on dshow (esp. with the 5.x versions in design). it just keeps locking us to ms platforms.

@Mark Rejhon:
i don't quite understand why u preach to incorporate this api into re-clock. i know it's the closest in concept, BUT dscaler has much more usage to it. afterall, reclock modifications of the playback rate don't harm the playback (esp. if your monitor refresh rate is set in advance to a multiple of the clip frame rate) so using this api instead of the current method won't have such a huge gain. dscaler, otho, IS the application to take advantage of this api. afterall, this api is most sutible to live video pc playback, and dscaler is the best app this this area on pc (win32 only unfortunately).

avih

[avih]

i will be looking forward to see this method incorporated into dscaler.

[Bitmonster]

First let me thank Mark Rejhon for his efforts.
This problematic actually made me sad till I started to use the PC as a media-player. I never thought there would be much chances of success to control this in software, but my first attemps with Powerstrip and the VBI add/remove scanlines idea are really promising.

Originally posted by avih
@Mark Rejhon:
i don't quite understand why u preach to incorporate this api into re-clock. i know it's the closest in concept, BUT dscaler has much more usage to it. afterall, reclock modifications of the playback rate don't harm the playback
Of course DScaler would benefit much from such a concept. Because you are completly at the mercy of the external clock of the source, a solution is highly needed if you want to make the PC competitive to external scalers.

BUT:
For DVD-playback this would also have great benefits. Most HTPC-users want to use an external AC3-decoder. Currently ReClock can only adjust the audio-sync by dropping/repeating complete AC3-frames and this results in an awful annoyance. By modifying the video-timing, ReClock could stick to the audio-timing and such problems would be a thing of the past.

[Bitmonster]

Originally posted by mf
(disclaimer: i haven't read all of the above posts so I might be uninformed about what I just posted)
Yes, you should have read the posting in more detail. :)

As Mark Rejhon accurately explained in his postings, such deviations will not result in any geometrical changes of the display. Or at least they could be overcome. In such problematic cases the user would have to set an option to use a slightly other algorithm, if he notices a minimal vertical jump. My experiments with a CRT-monitor show the same result. They are able to process a range of slightly different timings without starting to resynchronize. We are not talking about a jump in frequency like 75 to 85 Hz. What will be needed here is a deviations of not more than 0,01 Hz.

So the user will not have to make a bunch a presets ot things like that.

@Mark Rejhon
Actually ReClock isn't open source. Ogo has decided to use some open source code for the audio resampling, but the core of ReClock is unfortunately closed source.

[mf]

Originally posted by Bitmonster
What will be needed here is a deviations of not more than 0,01 Hz.
If it stays within that range, sure :). Like I said, you need a different preset for every tenth variation. You're talking about hundredth or thousandth, so that shouldn't be a problem if it stays within that range.

[vinetu]

Hi!
I cross my fingers so this method to be implemented !!!
Good Luck!

[Mark Rejhon]

To reply to various people bringing up questions:

(1) Less than 0.01 Hz granularity is definitely possible, provided you use VBI add/remove method. I succeeded in deviations of being within approximately 0.000012 Hz at 1920x1080/72 Hz using the VBI scanline add/remove method, from a stable source such as a DVD player. There is absolutely no disruption on about 50% displays that I tried this method on. Besides, it's much less disruption than the mechanical-error in a VCR-playback signal (a VCR signal can vary by 0.1 Hz or so)

(2) My posting explains some testing of which displays where there was no disruption at all. It is indeed display dependant. But some displays showed no response to a 0.000012 Hz refresh change using the dynamic VBI add/remove scanline method. Then out of this percentage of these displays, there are a percentage that can be "worked around" using various suggestions in my post from my testing.

(3) For people who do not want this feature, this can be an optional feature that can be turned off. Not everyone wants genlock, but some of us (me!) really want this feature.

(4) I'm not preaching Reclock instead ofdScaler. As a reminder, I am one of the earlier dScaler authors and I have contacted several dScaler people already, with a copy of this already. But I want this added to Reclock too, since it's a pretty natural extension to Reclock. Besides, the dScaler people are busy fixing some issues (especially with Conexant CX23882 based capture cards). In fact, I made a post on the dScaler forum, dScaler mailing, AND AVSFORUM too -- for maximum exposure. So I am not really preaching one or the other :) Just want to spread this word wide, there are some capable skilled synchronization programmers like the author of Reclock, who might find this information interesting and might add this feature!

(5) Thanks for the clarification about Reclock not being fully open source. Darn, it was only the audio portions of the code, then.

So essentially, I'm encouraging discussion. I've recycled this same paper in about 5 different places on the Net for other video related software, so I'm not preaching Reclock. As it stands now, assuming an appropriately skilled programer familiar with video timings (sync, concept of VBI, Powerstrip, XFree86 modelines, or similiar), it would probably be 10 quicker work adding to Reclock than adding to dScaler. Part of this reason is because of the present "between-releases" state of dScaler. That's one of the reasons why I seemed to make an impression that I am preaching Reclock -- it's just that I am familiar with the present in-between-releases state of dScaler, which means it'll be somewhat of a wait before this is added. There are more problems, with the CX2388X based capture cards than with the 848/878 based capture cards, that the dScaler people wants to work on first. genlock isn't particularly useful until synchronization is already good enough that the lack of genlock is the limiting factor (which is definitely now the case for 848/878 based capture cards with dScaler. Watching the CNBC stock ticker, one can notice see a single 1/60th of a second microstutter at exactly the beat frequency difference between the capture card input field rate, and the output refresh rate, once PowerStrip is fine-tuned to match the VGA output with the capture rate as closely as possible. So if capture card input is 59.947 Hz field rate and Radeon output is 59.937 Hz refresh rate, there is an 0.01 Hz microstutter in watching live video in a TV viewer such as dScaler, because of the lack of genlock. Even if one manage to match 59.94 Hz and 59.94 Hz, there are micro differences in the clock that makes it about a few 0.001 Hz's of difference between input and output. So computer technology has already reached the point where the lack of genlock is the limiting factor in eliminating the occasional microstutters that occurs during 60 Hz video, even after deinterlace overhead. Now, at the moment, this is still not always easy to get good synchronization performance with dScaler on a CX2388X card instad of a 848/878 card. So that, for example, improved and less buggy CX2388X support in dScaler is a higher priority before genlock can be added natively to dScaler. (Although perhaps Reclock as a DirectShow filter plugin for the latest dScaler -- that would be an interesting idea actually, as dScaler has a DirectShow infrastructure nowadays.)

Mark Rejhon

[Mark Rejhon]

>>If it stays within that range, sure . Like I said, you need a different preset for every tenth variation. You're talking about hundredth or thousandth, so that shouldn't be a problem if it stays within that range.

Yes, true -- unless you're using a VCR.

If you are using a VCR, this can be a bigger problem, because this can be a pretty big synchronization challenge.

One method is to simply program the clocking software to limit the genlocking to a 59.93 to 59.95 range, which should accomodate the vast majority of "stable frequency" sources such as DVD players. Many CRT's will not notice the difference between 59.93 and 59.95, so you would only need one memory. I have used CRT projectors before, as well as CRT displays that had customizable user memories that were very sensitive to changes in sync frequencies. But the vast majority will not notice a 0.02 Hz change.... usually you only need less than one-thousandths of a Hz deviation (0.001 Hz!) at most to genlock a DVD source. While I have seen CRT auto resync (go black) during 0.1 Hz changes, I've never seen a CRT monitor go black during a 0.001 Hz change -- it doesn't even change memories -- not even my old fussy NEC XG135 CRT projector (http://www.marky.com/hometheater/) when I used to have it.

________________

RELATED SUBJECT....

This brings up a new programming challenge. What IF there is a huge change, like switching inputs from a DVD player to a VCR? Or switching from 59.94 Hz to 60.00 Hz?

One method is to simply automatically turn off genlock if it goes out of the 59.93-59.95 Hz range, and automatically turn on genlock when it comes back in range.

However... if you are lucky enough to have a display that doesn't care about 0.1 Hz changes, this brings a new programming challenge, because VBI add/remove is not good enough for large 0.1 Hz changes.

Ideally, it should be intelligent so that it can automatically slew to a new synchronization range, if it is necessary to do a new range. This is technically possible. You just average the average field rate for the last 1 second, 5 seconds, or 10 seconds, to multimedia timer precision. (i.e. averaging produces pretty accurate fieldrate results - longer running averages with higher precision). Say, you got exactly 600 fields captured in about 10.0124 seconds, this results in an average of 59.9257 Hz for the last 600 fields. Just use the multimedia timers for achieving the precision (dScaler already uses a running average similiar to this, for calculating fieldrate for use with the JudderTerminator algorithm) With this running average capture fieldrate, if this number differs suddenly from the average a few seconds ago, you probably had a video input switch somewhere in the last few seconds, and therefore a PowerStrip API call should be made to change the vertical refresh rate to 59.9257 Hz and reset the number of VBI lines back to the middle range. So that the VBI add/remove can be used without the add/remove process going out of range. Different devices (DVD, cable boxes, PVRs, consoles, etc) sometimes have different fieldrates, like 59.94 Hz versus 60.00 Hz. For example, HDTV has a fieldrate of 60.00 Hz and downconverted HDTV->NTSC sometimes continues to have a fieldrate of 60.00 Hz, rather than the usual fieldrate of 59.94 Hz like that from a DVD player. This difference is big enough to be quickly detected using a running average only a couple seconds long at multimedia timer precision (at least on 8x8 based capture cards). This sudden 0.06 Hz change will require a vertical refresh rate change, in order to effectively continue to use the VBI add/remove scanlines because you don't have enough scanlines (~0.0001 Hz increments) to change refresh rates that much. Then again, you often get disruption and rolling picture anyway during a video input switch, so changing the output refresh rate suddenly isn't such a big deal, because most of the sudden changes in capture card refresh rate only occurs during input switches or cable swapping.

This timing to a very high precision would be the most challenging aspect, but it's already proven in pratice using the running average already built in dScaler, and the running average built into Reclock. Using this information can give you enough information. Automatically optimizing for small variances (DVD style) to huge variances (VCR style) is a very challenging programming task, but not impossible. One can keep realtime running statistics. Reclock already does dynamic synchronization.

Another way to put this, is that it may be necessary to change the master refresh rate in 0.1 or 0.01 Hz steps to the new average input fieldrate everytime you switch input sources (and causes the input fieldrate to change by 0.1 Hz -- as a TV box may even be 0.1 Hz different from a DVD player for example), so that the VBI add/remove scanlines don't end up adding/removing too many scanlines to try to move into a new range. This could be detected by scanning for an abrupt change in fieldrate, and doing an automatic refresh rate switch. If done during the VBI and quickly enough, many displays will not lose sync (CRT monitor will not black out for 1 second) and all that would appear is a minor disruption, which you usually get anyway with the video noisiness of switching video inputs, anyway... A resync can occur during every DMA buffer overrun event or something, or by capturing attempts to switch video inputs, or by detecting for a quick change in the running average field rate over the last 10 seconds.

So this is a programming challenge that can probably be solved without needing the user to do presets. (Presets could be useful, but why not just automatically scan, everytime the "Change Input" option in a video software is done?) Override the DirectShow interface to capture attempts to change inputs, so that a refresh rate resynchronization calculation can be done, etc. Or keep a 10 second (or last X seconds) running average fieldrate of the last while of viceo, so you know the fieldrate to a high precision (multimedia timer precision levels). Things like that.

Logic will also be needed to ignore bad splices in the fieldrate -- like during input switches, or new video material, etc. So if one field is interrupted halfway, or that there's a DMA buffer overrun (or skipped DirectShow frame), then the running timer obviously should be reset as to not contaminate the result. dScaler already automatically takes this into account in its own internal running internal fieldrate timer. A resync (refresh rate change, to get back into the ballpark necessary for VBI add/remove) should automatically be suppressed in this case, if the new running average is identical to the running average immediately before this interruption/framedrop.

Presets is okay, if a programmer wants to be lazy - to get the refresh rates into "the ballpark" of each other, so that VBI add/remove can be used properly. But I really think that granular refresh rate changes should be done automatically upon input switching, or upon detection of a sudden 0.1 Hz change in the input fieldrate (which probably indicates somebody swapped cables). Could also be done when fieldrate drops to 0 Hz then back up to 59.94 Hz (like an unplugged cable being plugged back in -- and also occurs momentarily with external video switcher). So essentially the vertical refresh rate will automatically be changed whenever this happens. Ideally, in tiny 0.01 Hz increments at a time or less, in order to avoid CRT monitors blacking out for a second. Many models of Radeon graphics cards, are capable of such tiny increments, but Geforce graphics cards are unfortunately not (at least the older Geforces and earlier -- haven't tried GeforceFX to see if the refresh rate adjustability is in tinier granularity levels yet, like a Radeon)

But for now, presets can be an OK starting point. DVD players output fieldrates so stable that you usually only need about 0.0001 Hz of range to do realtime genlock.

A very interesting programming challenge, for the one that takes upon this challenge. No doubt, some of these issues are already tackled in dScaler and Reclock (and in certain other software), it's an extension of the existing synchronization code in respective softwares to control the display refresh rate.

And of course, that option to limit genlock to a tiny range such as 59.93-59.95 so you always use only one memory on your CRT -- no blackscreens -- no resyncs.

[Mark Rejhon]

>>BUT:
For DVD-playback this would also have great benefits. Most HTPC-users want to use an external AC3-decoder. Currently ReClock can only adjust the audio-sync by dropping/repeating complete AC3-frames and this results in an awful annoyance. By modifying the video-timing, ReClock could stick to the audio-timing and such problems would be a thing of the past

Exactly. This is another benefit for Reclock for non-live sources. By using PowerStrip API to dynamically sync the display to the audio clock; Reclock can have perfect unmodified audio! And since the audio clock never realtime-deviates much, genlocking could in this case probably be done more directly to the audio clock (a more accurate frequency source) rather than directly to the incoming fieldrate (a less accurate frequency source). In this case, only one or two VBI scanlines could just be used. In fact, the audio disruptions are worse than the worse-case video disruption scenario (which only happens on certain CRT's as nearly imperceptible 1/2 pixel vertical shifts)

This is probably actually an easier step for the Reclock author to do as the first step, before adding support for live video.