100Hz e algoritmi di motion compensation

[lorenzo82]

Ciao Mauro ,
Suggerisci, quindi, un sistema tipo quello utilizzato nella compressione mpeg2...se non ho capito male:
prendendo in analisi piccoli gruppi di frame contenenti almeno
1 frame di riferimento per l'analisi del gruppo preso in esame
1 frame contenente le sole differenze tra 2 frame adiacenti
1 o più frame derivati da interpolazione sulla base dei primi due
Lorenzo.

 

[Maxti]

Io non mi pronuncio:fiufiu: ... l'unica cosa che mi viene in mente che, magari, può/potrebbe (non credo) aiutarVI, io mi tiro fuori, è il funzionamento dei sistemi di compressione video MPEG con i frame I, B e P.
Ho in cartaceo un sacco di roba che studiai:fiufiu: ... ho trovato in rete qualcosa, di molto sintetico però.
http://www.occhiuzzitiming.it/eLearning/Corso_Video_Digitale/Sistemi Video Digitali.pdf

È esattamente quello che intendevo. Nel caso di mpeg2 vi sono i frame di tipo I che vengono codificati senza riferimenti ad altri frame (sono il riferimento), i frame di tipo P vengono codificati rispetto ai frame I utilizzando la stima e compensazione del moto, in questo modo se la stima è sufficientemente accurata si riesce a comprimere un bel pò. I frame di tipo B sono simili a quelli P ma possono essere stimati a partire da due frame I (precedente e succesivo). Tutte queste operazioni vengono fatte suddividendo il frame a blocchi e lavorando su quest'ultimi.

 

[Onslaught]

Per certo si sa che il moto viene ormai analizzato lungo tutti gli assi, in tempo reale ovviamente, in modo da capire come sarà il frame successivo, ed operare di conseguenza.

 

[mariorenz]

Però, se così fosse, gli errori sarebbero inevitabili in situazioni del tipo: un persona cammina e, all'improvviso inverte il senso di marcia tornando indietro a mo' di gambero. L'ultimo frame prime dell'inversione e il primo di quando torna indietro... hai voglia ad interpolare quel passaggio di frames! Non c'è scampo.
Le partite di pallone sarebbero un festival di errori con cambi di direzione improvvisi e finte di corpo (non che non ce ne siano nei sistemi di FI però secondo me renderebbero la partita inguardabile).

 

[Onslaught]

Infatti lo devo ancora vedere un frame interpolation senza artefatti.

 

[mariorenz]

Beh, però io mi riferisco ad un quantitativo assolutamente superiore a quello che rilevo io che è davvero trascurabile. L'unico modo sicuro, penso che sia quello di differire leggermente l'immagine (di un frame) al fine di fare un'interpolazione reale.

 

[Maxti]

ma il sistema è abbastanza intelligente da capire quando la stima del moto è abbastanza inaffidabile (differenza dei frame troppo grande) ed agire di conseguenza. Basti pensare ai cambi di scena, si passa da un frame ad un altro completamente diverso...
Comunque anche in caso di moto improvviso non dovrebbero esserci grossi problemi se si usano frame di tipo B (quindi stima del moto bidirezionale).

 

[mariorenz]

Ok, ma siamo sempre lì: non ho ancora letto bene ma mi pare di capire che per i frames di tipo B (bidirezionali) serva conoscere anche il frame N+1 mentre per quelli di tipo P (predicted) servano addirittura altri frames.. Mi pare che quel documento parli di altro (anche se serve molto a noi come spunto per la discussione) ossia di una compressione a partire dalla conoscenza di TUTTI i frames di una sequenza video.

 

[Onslaught]

E' impossibile che si generino errori così macroscopici, per quanto già detto.
Non si generavano quando l'analisi del moto non veniva effettuata lungo tutti gli assi, a maggior ragione è impossibile adesso.

 

[mariorenz]

Forse il senso del documento è che, nelle coppie di frames per le quali si rileva una differenza troppo ampia, si evita totalmente di interpolare. Però devo sempre conoscere il frame N+1...

 

[Maxti]

Si è così. Nel caso l'errore sia troppo elevato il frame viene codificato senza stima del moto (quindi è di tipo I). Questo è quello che succede nei cambi di scena. In questo caso però stiamo parlando di codifica video e quindi non è un problema lavorare sul frame N+1 o successivi. Nell'mpeg2 per esempio all'interno dei gop (group of picture) i frame vengono prima ordinati e poi codificati.
Nel caso di applicazioni real-time è molto più complesso anche se per ottenere il frame N+1 basta bufferizzarlo introducendo però del ritardo.
Naturalmente non sapendo bene come funzionino sti algoritmi si possono fare solo supposizioni.

 

[mariorenz]

Questo spiegherebbe forse il motivo per cui gli lcd sembrano non riuscire a scendere sotto i 16ms di lag?

 

[Maxti]

Effettivamente potrebbe essere. Però 16ms sono pochi considerato che con i 50Hz ogni field ha cadenza 20ms, il tempo che dovrei attendere per bufferizzare il frame N+1... considerando poi la stima del moto ecc...
sinceramente non so

 

[mariorenz]

sbaglio o non ci sono lcd con lag inferiore, diciamo, ai 20ms (non in game mode)? Mi sentirei di scommettere che nessun lcd scende sotto i 20ms con interpolazione attiva.

 

[Maxti]

In realtà, pensandoci, decodificando l'mpeg2 è necessario avere il gop completo, ovvero tutti i frame tra un I frame ed il successivo, di conseguenza sono già bufferizzati per la decodifica, quindi non sarebbe necessario fare ulteriori bufferizzazioni introducendo ritardi.
Questo non vale nel caso il segnale di ingresso non necessiti di decodifica (hdmi da una ps3).

 

[Onslaught]

E' così Mario, anzi, 20ms con interpolazione attiva è poco, in genere si va bene sopra a questi valori.

 

[lorenzo82]

L'hdmi da ps3 è comunque segnale compresso...magari cambia il codec ma andrà sempre decodificato...molti bd, specie i primi, sono proprio in mpeg2...
Lorenzo.

 

[mariorenz]

Beh, allora penso che sia palese come i vari algoritmi si tengano buono (bufferizzano) almeno il frame n+1 per il loro calcolo d'interpolazione. Probabilmente, poi, alcuni algoritmi hanno bisogno magari anche di quello n+2, n+3, ecc.. per il loro approccio al calcolo quindi si arriva a valori alti di lag tipo 100 e passa ms. E' solo una deduzione dettata dalla logica, direbbe Spock. Con un po' di intuito umano, però.

 

[lorenzo82]

Allora come ipotizzavo non sarebbe più in tempo reale ma con un buffer di appoggio per l'elaborazione e la successiva visualizzazione...che poi se uno ci pensa su un attimo, tolti i videogiochi, che problema ci sarebbe ad avere una visione in differita (lag) di anche qualche secondo...per dar tempo al processore video di avere, potenza permettendo, un risultato senza dubbio molto più vicino alla perfezione (artefatti prossimi a zero) di quanto si sia riusciti a fare fin'ora?
Alla fine tutto quello che serve è tempo e potenza di calcolo...la ricerca in fatto di algoritmi credo spinga molto per ottenere ottimi risultati in tempi di elaborazione molto contenuti...ma avendo tempo a sufficienza...
Lorenzo.

 

[mariorenz]

In effetti, si tratterebbe addirittura di qualche ms. Nel migliore dei casi 20-25ms ms ossia il minimo tempo di visualizzazione di un frame più qualcosina per bufferizzazione e calcolo interpolazione.
Penso che non possa che funzionare così, al di là di qualsiasi algoritmo predittivo iper complesso. Almeno nella maggior parte dei casi.