Ghidul Autostopistului prin Galaxia Procesarii Video

[goodolddog]

Ghidul Autostopistului prin Galaxia Procesarii Video
sau Ce E Procesoarele Video Si Ce Vrea Ele ...

Citeva discutii purtate pe ici pe colo precum si o mai veche contributie a unor pitici care nu au avut alta treba decit sa-si construiasca o resedita (care deocamdata pare permanenta) la mine pe creier m-au determinat in cele din urma sa deschid acest thread.

E relativ usor sa pari mare specialist folosind o groaza de acronime si chinezarii specifice unui domeniu ingust si sa te bucuri dupa aia de o aura discreta de ... cuvintul parca era guru ?
Pentru ca sint departe de a fi un expert in domeniul asta, fiind mai degraba un hoby-ist oarecum norocos, o sa incerc sa folosesc aceasta ocazie si pentru a pune p-aci citeva link-uri, unele poate cunoscute, altele poate mai putin, catre scrieri facute de scriitori mai destepti decit subsemnatul pe aceasta tema minunata si plina de fiori, in care vom intilni noi motive de a ne mihni existenta si asa destul de efemera, ingropate sub acronime abstracte ca ICP si CUE sau sub metafore tehnice prost deghizate ca pull-down, macroblocking si motion-adaptive-deinterlacing.

Cum zicea Marvin atunci cind, in plina prabusire catre un soare destul de fierbinte in momentul apoteotic al concertului vestitei trupe de rock intergalactic "Zona de Dezastru", a fost intrebat "ce mai faci" ?:
"Pai presupun ca nu prea bine, nu ?"

Sau altfel spus:
Ce bine ca am scapat de problemele analogicului pentru a da de cu totul alte probleme noi si minunate specifice digitalului!

Orice asemanare cu situatia din domeniul audio nu este de loc intimplatoare

* * *

Capitolu' 1
(Invatati, Invatati, Invatati - a zis Marvin!)

Unde citim cite ceva pentru amatori ca noi ca sa vedem despre ce e vorba ?

Desigur, internetu' poate fi prietenul celei de-a treia fiinte ca inteligenta pe planeta aia mica si albastra din sectoru' spatial ZZ9 PLural Z Alpha ...

Pentru un primer destul de serios insotit de teste pentru partea de aparatura video digitala as incepe prin a recomanda celor care nu au facut-o inca sa sacrifica putin timp pentru a accesa link-ul de mai jos:

http://www.hometheaterhifi.com/volume_7_3/dvd-benchmark-introduction-9-2000.html

La sfirsitul articolului se afla un numar de link-uri (oripilante) care, in masura timpului disponibil pot fi parcurse pentru ca acele articole spun multe lucruri despre diverse tipuri de erori si artefacte video, despre masurarea performantei video dar si despre modul cum este stocata si procesata informatia video.

Warning: identificarea pe propriul sistem a artefactelor digitale produce efecte nedorite printre care cel mai nociv este acela ca acestea vor fi percepute mai apoi obsesiv, fiind foarte greu sa te desprinzi de ideea ca sint acolo. Este exact ca la audio, cind ai prins o anumita nuanta neplacuta pe care sistemul tau o introduce sistematic, cel mai adesea vei sfarsi prin a-l schimba.

Un prim plonjon in apa inghetzata a minunatei lumi a DVD-urilor si a MPEG-ului ar fi articolul despre Chroma Upsampling Error, din care aflam cu ilustratii si exemple clare despre prietenii nostri CUE si ICP, dar si despre stocarea informatiei Chroma si Luma pe media, precum si cite ceva despre procesarile care intervin (hint: cind si daca va fi sa discutam despre color-space conversion si output-ul prin HDMI si SDI comparativ cu DVI, informatia asta se va dovedi utila).

Desi este multa lectura, poate fi interesant sa fie parcursa si partea de testare (6 articole explicative pentru conditiile de testare si o sectiune de teste foarte comprehensiva). Persoanele care scriu acolo sint considerate somitati in domeniu, si pot fi regasite sub nume propriu si pe forumuri de specialitate. As mentiona si ca Stacey Spears, printre altele, are si o contributie voarte practica la realizarea specificatiilor software-ului pentru o famile de scalere/deinterlacere cu o excelenta pozitionare pe piata la nivelul zile de astazi.

Un alt loc bun pentru o informare la zi asupra realitatilor (uneori nu foarte vesele, dar - OH! - atit de interesante ...) din lumea procesarii di display-urilor digitale video este binecunoscutul AVSforum, care are si o sectiune specializata dedicata acestui subiect (pe linga numeroasele trimiteri dispersate iremediabil in zonele dedicate display-urilor si playerelor):

http://www.avsforum.com/avs-vb/forumdisplay.php?f=37

Si sa nu uitam ca exista producatori specializati in domeniu, catre care ne putem arunca privirea pentru informatii insotite de doza inevitabila de marketing.

In ordine oarecare:
http://www.pixelmagicsystems.com/
http://www.lumagen.com/
http://www.dvdo.com/
http://www.meridian-audio.com/faroudja/
si probabil altele.

Pe siturile de mai sus si forumurile asociate e mult mai multa informatie decit se poate ingurgita intr-o sedinta de studiu, dar se si pot afla multe lucruri folositoare incercind in masura posibilitatilor sa dezbracam informatia de mantia de marketing care o invaluie.

In masura in care subiectul este cu adevarat interesant si permite dialog, eu unul as fi mai mult decit bucuros sa imi imbunatatesc cunostintele discutindu-l. Este evident ca orice experienta personala a cuiva care nu este profesionist in domeniu este limitata, dar atita cit eventual este, poate fi impartasita si poate creste in contextul unui schimb de idei.

Sa inchei aceasta introducere in propunerea de subiect cu ideea ca aceleasi elemente se pot intilni si in discursul pasionatilor de HT bazat pe calculatorul din dotare, fie el Mac sau PC sau ce-o mai fi , acolo devenind o problema de software si minunatele setari si upgrade-uri necesare (sau altfel spus: mama, I need a faster processor ...). Asta pentru ca tot vor navali peste noi placile grafice cu iesire HDMI ...

* * *

Subiecte posibile de discutie in continuare (la care putem cere ajutorul nepretuit - pe bune- al utilizatorilor de PhotoShop sau similare):

Scalarea imaginilor sau Da mama cu biciu-n mine ca n-am rezolutia nativa ... (aici ne vom lupta cu intrebarea obsesiva: Da' cu scalingu' din display-uri sau din player ce-avetzi mama ? dar si cu moralizatorul indemn: Nu scala decit odata! - sau de ce strica mai multe scalari succesive)

Conversia spatiului de culoare (Chroma) - cum se face si de ce ne e frica de ea, sau cum ne-am furat-o daca o aplicam de 2 ori. YCbCr vs RGB sau eterna intrebare: si ce daca?

Deintreteserea. Cum n-am avut noi treaba si ne-am apucat sa deintretesem imagini in miscare, de ce acest lucru nu e chiar atit de simplu pe cit ni s-ar parea la prima vedere si in ce masura apetitul editorului de media in a face munca de mintuiala ne complica infinit existenta. Si bineinteles vesnicul: da' de ce ne ferim dom'le de deinterlacingu' din display-uri/playere ?

Cum ar arata un pipeline grafic ideal in domeniul digital pentru procesarea video?

Care playere/procesoare/display-uri si la ce pret.

Si eventual altele ...

[Mitica]

[Bogdan]

[greierasul2006]

[goodolddog]

Bag aici o micutza divagatie de amateur, scrisa destul de pe fuga, lucru pentru care imi cer scuze, dar ca sa fie totusi un inceput de discutie pe tema asta, sper sa ma mai si fac inteles pe ici pe colo:

Hai sa luam o sursa digitala, de exemplu un DVD pe care avem material NTSC full 16:9 ( FAR 16:9, AAR 1.78 ).
Ma limitez in continuare la acest exemplu si nici nu stiu daca il discut chiar complet.

>> Citire info de pe suport

Pe linga informatia privind imaginea si sunetul, mai exista multe alte informatii scrise care ne spun ce si cum e intregistrat acolo din punct de vedere tehnic (de ex, ca materialul provine dintr-un original film, ca un cadru inregistrat e progresiv sau nu, etc.). Din pacate, aceste chestiuni au fost respectate cu atita strictete in procesul de editare a tonelor de DVD-uri de pe piata, incit astazi mai toate jucariile serioasa incearca sa-si dea seama singure din analiza informatiei despre ce ar fi vorba, sau alternativ, roaga frumos userul sa aleaga un anumit mod de procesare dupa cum "da mai bine" pe ecran - astea ar fi acele moduri "film" "video" "Auto1" "Auto2" "2:2 Odd" "2:2 Even" si asa mai departe cu care ne imbie playerele - si la care de regula noi, utilizatori consumeri nici nu prea umblam decit poate din curiozitate, chit ca selectia modului corect este destul de importanta pentru calitatea imaginii obtinute, ca sa zic asa ...

Pe acest material DVD avem (in exemplul NTSC i) inregistrata pe disc in domeniul digital pentru fiecare field (field= cimp=semicadru= o jumatate de cadru intretesut formata din liniile pare sau liniile impare ale acelui cadru), informatia corespunzatoare la 240 linii a 852 pixeli (pentru luma = Y = R+G+B) si 120 linii a 426 pixeli pentru chroma (2 canale de chroma - unul pentru B-Y=Cb, unul pentru R-Y=Cr). Toata aceasta mustarie este codata MPEG2. Acest mod de codare, un canal luma pe field care contine info digital pentru toti pixelii si doua canale chroma care contin fiecare informatii din 2 in 2 pixeli - atit vertical cit si orizontal, se numeste 4:2:0 si este economic saracu', dar si sursa a numeroase neplaceri. Esantioanele din canalele chroma sint obtinute practic inainte de codarea MPEG2 ca si medie intre esantioanele din 2 linii succesive, asta ca sa fie lucrurile complicate, dar sa ocupe spatiu putin ( - aici e un clinci: trebuie tinut cont ca doua linii succesive pe ecran se afla in field-uri diferite!!!).
Compresia e lossy, asa ca stim de la inceput ca "pixelii" care vor iesi din decoder nu sint chiar aia care au fost codati initial (ca si valori digitale pentru Y, Cb si Cr), doar ca sint la fel de multi. Asta e, din pacate vorbim numai dupa decodare in pixeli si linii din alea - sa zicem - cu corespondent geometric. Asa ca dupa citire de pe suport, materialul trebuie decodat MPEG.

>> Decodare

Enter decodoru' prietenu' omului, (ESS, Mediatek, Zoran, alte alea, de multe ori jucariile astea controleaza si unitatea de citire desi n-ar fi obligatoriu ...). Decoderul citeste MPEG2, decodifica si produce esantioane YCbCr 4:2:2 din codificarea initiala 4:2:0. Asta presupune ca face atit decodare MPEG2 cit si reconstruire a esantionelor chroma in fiecare linie (dar in continuare din 2 in 2 pixeli pe orizontala). Decodarea incorecta produce "pretenari" te tipul CUE sau macroblocking (perfect vizibili pe ecrane mari si progresive). Aceste erori pot fi eliminate prin mascare/procesare. Decodarea incorecta (4:2:0 la 4:2:2) produce ICP care poate fi mascat dar prin mascare produce jaggies minunati. Chestiile astea sint descrise in detaliu pentru cei rabdatori sa citeasca link-urile date intr-un post mai sus.
Decoderul scoate semnal digital YCbCr 4:2:2 (luma pentru fiecare linie + doua canale de chroma pentru fiecare linie dar din 2 in 2 pixeli in interiorul liniei). Outputul este serializat in pixeli in ordinea scanarii, esantioanlea fiind generate in paralel pe 10 biti.

[Aici se poate povesti pe scurt despre modarea SDI - din decodor, semnalul digital iese BT601 sau BT565 (aceeasi informatie, formatata idferit), semnal pe care-l poate prelua ca atare un adaptor SDI SD out (cu conditia sa-l poti cupla ... mecanic, pardon electric). Citirea din decodor se face de pe 10 pini de date, informatia se serializeaza apoi pentru transmisie prin SDI. Aceasta este cea mai bruta si neprocesata forma de semnal digital care se poate scoate din player, adica imediat dupa decodare]

* * *
E, cam de aici incolo incepe ceea ce se cheama pipeline de procesare video in domeniul digital
* * *

>> Reducere zgomot tipic MPEG2

Acum si aici (dupa decodare) am putea eventual aplica algoritmi de reducere a tipurilor de zgomot specifice MPEG2

>> Determinare tip si cadenta sursa, deintretesere adaptiva cu pull-down

Dupa decodare si eventuala eliminare diverse zgomote si artefacte, rezulta 3 "masti digitale" pentru fiecare field, si anume o matrice 852x240 pentru luma si doua matrici 426x240 pentru chroma (chestie pe care o mai intilnim -daca e serializata dupa scan- si sub pseudonimul YCbCr 4:2:2 care inseamna ca avem informatie de luma pentru toti pixelii iar pentru chroma numai din 2 in 2 pe orizontala). [Valorile digitale sint reprezentate pe un anumit numar de biti - de aici si latimea de procesare a culorii - cind citim "atitia biti de culoare". In aplicatiile consumer, desi sint prevazuti conform BT.601 10 biti, se folosesc numai 8 semnificativi- vezi si ce am povestit la iesirea din decodor. Catre display se trimit 8, 10 sau 12 (de ex prin HDMI) - evident informatia e serializata pe linii, liniile pe pixeli iar pixelii pe componente, relativ la aceasta serializare se poate vorbi de frecventa de linie si frecventa de pixel].
Doua semicadre (field-uri) succesive (incepind evident cu primul inregistrat) formeaza un cadru= o imagine completa. Bun. Ca sa obtinem informatia completa pentru o imagine venim si facem deintreteserea = aplicam unui numar de field-uri (minim 2, maximul pe care il stiu este de 7 la raster processing si 10 la vector processing) un algoritm care reconstituie imaginea din semicadre, tinind insa cont si de cadrele dinainte / de dupa pentru a putea reda fluent miscarea si a detecta corect muchiile (de exemplu), dar si pentru a asigura coerenta temporala - de exemplu la material video sau mixed mode (in captura video intretesuta, de exemplu in PAL, intre doua field-uri sint 20msec, timp in care un obiect aflat in miscare si-a schimbat pozitia, la film asta nu e valabil, intreteserea fiind doar un artificiu de compatibilitate rezultat in procesul telecine). In procesul de deintretesere trebuie sa se mai tina cont si de faptul ca de exemplu sursa este la 60HZ si display-ul functioneaza la 50/100Hz, sau de exemplu in original chestiunea a provenit de pe un film la 24 cadre pe secunda si a ajuns pe DVD la 60 semicadre pe secunda, chestie care se trateaza prin ceea ce se cheama pull-down 3:2 (de fapt 2:3 - la codificare se iau 24 de cadre si se impart in 2 grupe de 12, si anume din 2 in 2 - prima grupa de cadre se dubleaza, a doua se tripleaza - daca aveam cadrele c1 c2 c3 c4 etc. vor rezulta c1 c1 c2 c2 c2 c3 c3 c4 c4 c4 etc. - astfel din 24 de cadre se obtin (12x2=24) + (12x3=36) = 60 de cadre. Acestea se convertesc in 60 de semicadre daca vrem sa punem pe suport un format intretesut tinind cont ca fiecare cadru original are coerenta temporala=corespunde unui moment fix in timp; cu oarecare grija, algoritmul e reversibil). Chestia asta intra la conversie de cadenta si nu e chiar neglijabila. De lucrurile astea se ocupa in diverse echipamente, macar partial, chestii ca SIL03/04, FLI22xx/23xx, alte ginganii.

>> Transformari in spatiul Chroma si determinare pixeli sursa

Asa - dupa deintretesere (care e o chestie mult mai complicata decit pare) am obtinut o imagine intreaga. Putem sa privim aceasta imagine ca avind rezolutia de 852x480 in luma si 426x480 in cele 2 canale de chroma (calculate de la 426x240 stocat pe DVD, si asta cu mari sanse de decodare eronata ... nasol intr-adevar, imi pare rau daca v-am stricat ziua, dar se zice totusi ca ochiul e mai putin sensibil la variatii de chroma decit de luma ...). In acest moment se poate face o conversie de chroma - de exemplu, display-urile sint nativ RGB (ca astea sint primarele aditive), asa ca putem trece din YCbCr in RGB, ocazie cu care daca ne punem mintea putem si interpola informatia de chroma la fiecare pixel, rezultind trei matrici R, G si B a cite 852 x 480 elemente fiecare (RGB 4:4:4). Evident, deja v-ati prins, 4:4:4 inseamna cite un esantion in fiecare din canalele R G si B pentru fiecare pixel (nu se sare nimic).

[daca am trecut in RGB digital si nu prea ne mai intereseaza chestii anexe cum ar fi sunetul, negocierea parametrilor sau chestii futuriste cum ar fi deep color, putem la fel de bine sa calatorim in continuare si pe HDMI si pe DVI-D]

Putem deja privi imaginea ca o singura matrice de pixeli RGB 852x480 care reprezinta cea mai buna reconstituire a semnalului codat original de care a fost in stare sistemul pina aici (si a cam avut ceva de lucru, nu ?).

[Aici cred ca e locul sa amintesc faptul ca 480p@60 inseamna 60 de cadre progresive = imagini complete pe secunda, iar 480i@60 inseamna 60 de field-uri (semicadre) pe secunda adica 30 imagini pe secunda, adica o rata de afisare de doua ori mai mica in imagini complete si un bandwith la jumatate fata de 480p@60. In consecinta, vom tine probabil minte ca 1080i@50 inseamna ca si bandwith 540 (!!!) de linii transmise de cite 50 de ori pe secunda (adica 25 de imagini complete). Evident, nu discutam in toate situatiile de informatie distincta - multa din ea se repeta, ci de rata cu care imaginile complete ajung efectiv la ecran. Dara daca am film digitizat la 1080fp24 si video capturat la 1080i@60, atunci si bandwith-ul materialului original e diferit, si coerenta temporala a informatiei din linii e diferita ]

>> Eliminarea zgomotului de imagine

Acum si aici am putea folosi Noise Reduction pe imagine pentru eliminarea diverselor tipuri de zgomot. Aici intervin diverse filtre de zgomot adaptate la banding, mosquito, etc.

>> Transformari geometrice in spatiul imaginii sursa

Zoom si pan in spatiul imaginii reconstruite se cheama aici overscan si shift ...
In aceasta pozitie intervine facilitatea pe care am tot numit-o overscan (si anume inainte de scalare - adica in spatiul imaginii sursa) - cu alte cuvinte, putem alege sa eliminam o parte din marginile imaginii determinate anterior, fie pentru ca acestea contin artefacte cu aspect neplacut (si de prea multe ori chiar contin - de exemplu una sau doua linii din partea de jos sau de sus a imaginii pot contine zgomot aiurea, sau un front al imaginii cel da atac sau cel de fuga poate fi neregulat, etc.) fie pentru ca nu contin informatie utila si nu ne place sa folosim real estate de ecran ca sa afisam un negru comunicativ ...

>> Scalare (eventual cu procesare in domeniul frecventa)

Apoi intervine scalarea. Care se face cu algoritmi care tin cont de pozitia fiecarui pixel in aria activa, de raportul de scalare, dar si de informatia din vecinatati, pentru fiecare pixel destinatie valoarea fiind calculata dintr-o arie de pixeli vecini din zona sursa si anume ca medie ponderata prin interpolare polinomiala cu coeficienti (FIR, ca in analiza in frecventa a semnalelor digitale) care determina si comportammentul in frecventa al operatiei de scalare (cu alte cuvinte, o scalare permite si controlul sharpness-ului de exemplu). Astfel de algoritmi functioneaza oarecum simetric si pentru downscaling si pentru upscaling.

>> Corectii de imagine, inclusiv geometrice

In sfirsit acum putem procesa imaginea pentru adaptare la gustul privitorului sau (ca sa ne dam stricti) pentru calibrare (luminozitate, contrast, gamma, etc.). Tot aici se pot aplica Zoom si Pan, care datorita faptului ca se aplica deja in spatiul display-ului au alte efecte. Pan-ul poate fi util pentru time-alignment la pixelmapping, insa zoom-ul (cel fin, nu selectiile de gen 2x, 4x) trebuie atent corelat cu timing-urile din pipeline pentru a nu afecta relatia dintre pixelul din semnal si cel fizic al display-ului.

... si tot mai e nu mult ci probabil foarte mult de discutat pe tema asta

In functie de implementari, etapele de mai sus se pot regasi oarecum in alta ordine, dar ideea cam pe aici este. Adica ce e mai sus ar descrie aproximativ un pipeline de procesare video in digital. Cu mentiunea ca in prezent consensul pare a fi ca locul tuturor decodarilor este in sursa si procesarea pr-zisa incepe dupa decodare.

Aceste procesari pot fi facute partial in sursa, partial in display (cam toate sursele si display-urile digitale includ astazi ceva procesare, macar minimala). In principiu este de dorit ca un anumit tip de procesare sa se faca intr-un singur loc pentru a evita artefactele inerente procesarii multiple in domeniul digital.

Procesoarele video se utilizeaza atunci cind vrei sa renunti la procesarea din sursa SI din display, concentrind totul intr-o cutie dedicata despre care cel putin se zice/se banuieste ca ar trebui sa faca procesarile respective mai bine decit solutiile integrate din echipamente care au totusi limitari fie si numai din motive economice/de spatiu/de pret/ de costuri de implementare, etc.

Boala utilizatorului de procesor video este sa poata alege din materialul preinregistrat exact aria pe care doreste sa o vada (de obicei aria utila maxima in care nu sint prezente balbe din inregistrare) si sa genereze pornind de la aceasta un semnal de calitate cit mai buna, ba in plus informatia digitala corespunzatoare unui pixel din acest semnal tre' sa ajunga exact - valoric si "la timp" - intr-un pixel fizic al display-ului intr-o logica 1:1 (chestie zisa si pixelmapping). Normal ca atunci cind are un material intregistrat 480/576i omu' are buza de jos tremurinda ... Iar cind are 1080p24 ar vrea daca s-ar putea, dom' doctor, de maine, sa puna fiecare dintre aia 1920x1080 pixeli (da, da, stiu full 16:9 AAR FAR etc. tralala) in pixelu corespondent al display-ului nativ 1080 pe care il viseaza ... adica exact si la timp, ma'ntzelegi ?

Mmmh ...

Sper ca nu mi-au scapat prea multe balbe ... si multumesc lui gurux pentru sprijin in editarea balbelor pe care le-am descoperit pina in acest moment ...

[goodolddog]

Desigur, la capitolul balbe, putem adauga si faptul ca de facto rezolutia utila (asa zisele "esantioane active") a cadrului din semnalele 480i/p este 720x480 !!! ... cu modificarile ce rezulta in consecinta in exemplul de mai sus.