100Hz e algoritmi di motion compensation

[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.