Lainaus, alkuperäisen viestin kirjoitti Betrayed:

---

Kyllä mun PALlit :) toistuu ihan kristallinkirkkaasti vaikka näytön virkistystaajuus onkin 60 Hz (LG L1730B 17" littu). Tiedä sitten mistä PeteTK on tuon keksinyt. Suuressa osassa (vähän vanhempia) littuja kun tuo virkistystaajuus on juuri tuon 60 Hz, tiedä sitten mitä se nykyisin on - en jaksa ottaa selvää.

---

Lainaus, alkuperäisen viestin kirjoitti hyyry:

---

Tekniikka mennyt eteenpäin eikä lituskoissa virkistystaajuudella enää merkitystä ole...

---

Lainaus, alkuperäisen viestin kirjoitti eräs asian harrastaja i:

---

Ja syystä vielä lyhyesti: hertsimäärän pitää olla 100% täydellisesti sama sekä kuvaa lähettävässä että vastaanottavassa laitteessa. Pienikin ero taajuuksissa aiheuttaa nykäyksiä/repeilyä/freimien katoilua.

Ilman ReClockin tapaista menetelmää taajuuksia ei ole mahdollista saada samoiksi, vaikka olisi atomikelloon lukitut kiteet kummassakin laitteessa. Syy on siinä, että näyttölaite ei osaa lukittua saamansa kuvan ominaistaajuuteen, vaan tottelee sisäistä kelloaan, joka ryömii eri tahtia kuin videokuvaa lähettäneen laitteen kello.

JOS, ja vain jos ottava laite osaa lukittautua lukemansa videokuvan taajuuteen, silloin on teoreettinen mahdollisuus esittää jokainen saatu freimi oikea-aikaisesti.

Mutta tämä teoreettinen idea taas kaatuu siihen käytännön pulmaan, että (nestekiteet ainakin) pitää ohjata tietyllä kiinteällä kellotuksella, ei voi antaa virkistystapahtumien taajuuksien huojua piiruakaan, se pilaisi värien sävyt. Eli jos näytön on muutettava pikselinsä tila 8 millisekunnin aikana, se ei saa kuluttaa siihen 8,0001 tai 7,999542 millisekuntia, koska silloin värisävy olisi väärä. Paneelin ohjauselektroniikka eli pikselin sävymuutoksen kiihdytysmetodit on ohjelmoitu vain parille hassulle taajuudelle, vaikkapa 59,9xxx Hz, tarkemmin en omaani muista, mutta se siis EI ole 60,0000000 Hz kuten maallikko kuvittelisi.

Ja kun siis näytön tekninen päivitys tottelee oma tarkkaa kelloaan, silloin vastaanotettu kuvavirta joko sattumalta osuu samaan taajuuteen, tai käytännössä ei todellakaan osu, eli sitten tippuu freimejä kadoksiin (kuvia tulee liian nopeasti sisään) tai sama freimi esitetään useampaan kertaan (kuvia tulee liian hitaasti sisään).

KUVAPUTKINÄYTÖISSÄ kyetään lukittumaan hieman huojuvaankin videokuvaan, eli kaikki lähteneet freimit osataan näyttää.

Jos ne ylipäänsä osataan lähettää oikein. Tämä lähetyspään ongelmatiíkka on kokonaan oma murheensa. Tietokone nimittäin seuraa play-tilanteessa audiokelloa, ja jos videovirta kulkee eri vaiheessa, kuva lähtee ulos valmiiksi pilalla eli freimejä uupuvana tai tuplaantuneena. Audio ja video kun omaavat eri kellonsa tietokoneessa, ja atomikelloja niistä ei kumpikaan ole.

Videofreimit ovat "yksittäisiä valokuvia", niiden lähetysnopeutta ei voi "hieman" nopeuttaa tai hidastaa. Videodatan standardit eivät tunne muuttuvanopeuksista videokuvaa. Kuva siis pitää lähettää kiinteästi samalla taajuudella, ja toivoa kädet ristissä, että lähtevä ja ottava pää ymmärtää lukittua keskenään tähän taajuuteen.

Ainoa sallittu "hieman" muuttuva vaihtoehto on täten audion muuttaminen. Juuri sen ReClock tekee, se venyttää ja hidastaa ääntä sen mukaan mitä tarve kulloinkin vaatii, jotta kuva ja ääni pysyisivät lukittuna ja oikeassa vaiheessa. Toki ääni lähtee sekin "kiinteällä tavalla digitoituna" esim. 48000 Hz tahdilla, mutta äänitteen tempoa muutetaan laskennallisesti, ääntä hidastetaan bassomaisemmaksi tai nopeutetaan pikkuoravamaiseksi, vaikka digitointitaajuus pysyy edelleen samana.

Audiolle tämä operointi on paljon helpompi tehdä kuin videolle. Korva ei ota pulttia vaikka äänessä olisi hieman huojuntaa, mutta silmä huomaisi heti jos jokainen freimi olisi teennäinen keskiarvo kahdesta peräkkäisestä, kuvanlaatu sumenisi liikaa. Siksi annetaan kuvan mennä koskemattimana ja "pilataan" vain ääni.

---