Comment les vecteurs de mouvement fonctionnent-ils dans le codage prédictif pour MPEG?

16

En MPEG, il existe un processus où une image est divisée en macroblocs et un vecteur de mouvement est calculé pour chacun de ces macroblocs. Vous transmettez ensuite ces vecteurs, ainsi que les erreurs de prédiction, pour reconstruire l'image suivante dans la séquence vidéo.

J'essaie de bien comprendre comment cela fonctionne. Chaque macrobloc a un vecteur de mouvement qui lui est associé, qui (si le vecteur est [1,0]), dit all the pixels in this block move 1 in the x direction and 0 in the y direction for the next frame. Si tous les vecteurs de mouvement ne s'alignent pas correctement, cela ne laissera-t-il pas les zones de l'image disparues (comme la zone où ce macrobloc était en premier lieu)?

Par exemple, j'ai la question suivante que j'ai trouvée.

Considérons l'image suivante au temps t:

7   7   7   7           
7   7   5   5        
7   5   5   8         
8   8   8   8           
9   9   9   9       
9   9   9   9

Cette image a été divisée en macroblocs 2x2 et les vecteurs de mouvement suivants ont été envoyés pour la recréer:

(0,0)  (0,0)  (0,1)  (-1,1)  (0,0)  (0,0)

L'image au pas de temps précédent, t - 1, ressemblait à ceci:

7   7   7   7           
7   7   5   4        
7   7   7   7         
7   5   8   8           
8   9   8   9       
9   9   9   9

Quelles ont été les erreurs transmises?

Comment résoudriez-vous cela?

— Portefeuille
source

5

Pour simplifier votre confusion - il existe deux processus:

1. Estimation du
mouvement 2. Compensation du mouvement

Avant de parler d'estimation, nous devrions parler de la compensation de mouvement.

Disons que l' est divisée en bloc . $Image_{t}(x,y)$ $Blocks_{t}[k](x',y')$

La tâche de compensation de mouvement est de produire des partir de n'importe quelle région de l' . $Blocks_{t}[k](x',y')$ $Image_{t-1}(x,y)$

Par conséquent, un autre bloc qui n'est pas nécessairement aligné à la limite 16x16 est la meilleure correspondance possible $Blocks_{t-1}[k](x'+mx,y'+my)$

Ici, est appelé vecteurs de mouvement. $mx, my$

Nous pouvons calculer l'erreur entre la cible et la référence comme

E r r_{t} [k] (x, y) = B l o c k s_{t} [k] (x^{'}, y^{'}) - B l o c k s_{t - 1} [k] (x^{'} + m x, y^{'} + m y)

$Err_{t}[k](x,y) = Blocks_{t}[k](x',y') - Blocks_{t-1}[k](x'+mx,y'+my)$

Alors maintenant, le codeur transmet essentiellement (avec DCT et quantification) et pour chaque bloc. $Err_{t}[k](x,y)$ ${( mx, my) }[k]$

L'encodeur a donc 2 tâches à faire:

1. Estimation de mouvement
Le processus ou estimation pour chaque tel que est minimisé est appelé estimation de mouvement. ${ mx, my }[k]$ $k$ $Err_{t}[k](x,y)$

2. Génération d'une image d'erreur après compensation de mouvement
Le processus de construction de partir de pixels d'image et est appelé compensation de mouvement. L'image d'erreur est ce qui est transmis. $Blocks_{t}[k](x',y')$ $I_{t}$ ${ (mx, my) }[k]$

Enfin, le décodeur peut refaire la compensation de mouvement par lui-même en utilisant des vecteurs moiton et l'image d'erreur pour effectuer la reconstruction finale de l'image.

Nous réalisons maintenant quelques points:

La meilleure estimation de mouvement permet de minimiser l'énergie qui doit être transmise et donc d'optimiser les bits pour une qualité donnée.
Cependant, même si n'est pas idéal ou si la scène a un changement significatif par rapport à la dernière image, le est toujours transmis au récepteur - d'où la reconstruction est toujours parfait (modulo la perte créée par la quantification). Par conséquent, même si vous avez un vecteur de mouvement sous-optimal ou la redondance n'est pas beaucoup, la reconstruction est toujours parfaite, bien qu'avec plus de bits! ${ (mx, my) }[k]$ $Err_{t}[k](x,y)$
Chaque bloc est compensé en mouvement par lui-même - donc même si les vecteurs de mouvement réels des blocs voisins n'ont aucun effet dans la construction. Par conséquent, il n'est pas nécessaire d'avoir des vecteurs de mouvement parfaitement alignés pour qu'une reconstruction parfaite soit possible. $Blocks_{t}[k](x',y')$
Bien qu'il existe un algorithme suffisamment intelligent pour deviner que si a un vecteur de mouvement la supposition pour pourrait être plus proche de cela seulement. $Blocks_{t}[k]$ $( mx ,my )[k]$ $Blocks_{t}[k+1]$
Supposons enfin que l'image suivante soit complètement différente, il est possible que l'énergie pour l' .
$E n e r g y (E r r_{t} [k] (x, y)) > E n e r g y (B l o c k s_{t} [k] (x^{'}, y^{'}))$ $Energy (Err_{t}[k](x,y)) > Energy ( Blocks_{t}[k](x',y') )$

Dans de tels cas, il pourrait être plus judicieux de transmettre un bloc directement sans prédiction que d'envoyer la différence. Ceci est également possible dans le codeur par une disposition appelée bloc INTRA.

— Dipan Mehta
source

3

Non, il ne laissera pas de trous, car le vecteur va d'une trame inconnue (P ou B) à une trame connue (I-frame). Il rappelle un peu comment calculer une transformation d'image - vous utilisez une transformation en arrière pour éviter les trous /

— Andrey Rubshtein
source

3

Comme c'est le cas avec de nombreuses routines de traitement de signal standard, c'est assez simple sur papier et un peu délicat en pratique. Vous avez séparé votre image en six blocs avec et . chacun de ces blocs a des coordonnées à (nous considérons le coin supérieur gauche de chacun pour identifier son emplacement). Nous avons donc maintenant six blocs à $B(i,j)$ $i = \{0,1,2\}$ $j = \{0,1\}$ $(2i, 2j)$

(0,0) (0,2)
(2,0) (2,2)
(4,0) (4,2)

Vos vecteurs de mouvement calculés pour chaque bloc sont $M(i,j)$

(0,0) (0,0)
(0,1) (-1,1)
(0,0) (0,0)

Maintenant, pour calculer l'image résultante, nous devons d'abord savoir où chaque bloc s'est déplacé. Pour ce faire, nous ajoutons simplement la matrice de coordonnées ci-dessus à sa matrice de mouvement: . On a $B'(i,j)=B(i,j)+M(i,j)$

(0,0) (0,2)
(2,1) (1,3)
(4,0) (4,2)

Afin d'éviter les "trous" comme vous l'avez dit, nous ne déplaçons pas simplement les blocs du cadre d'origine pour obtenir le nouveau, nous prenons celui d' origine comme référence et injectons les blocs nouvellement calculés. Pour ce faire, nous faisons d'abord une copie du cadre d'origine. Nous prenons ensuite chaque et le remplaçons par des pixels de . $B'(i,j)$ $B(i,j)$

Remarque: Nous ne sommes pas protégés contre tout type de chevauchement de bloc "en mouvement" (deux blocs sont déplacés vers des emplacements qui se chevauchent). Il existe des moyens de gérer cela, mais cela dépasse le cadre de cette réponse. Pour l'instant, nous allons simplement réécrire tous les pixels avec un bloc que nous déplaçons à leur emplacement, de sorte que même s'il y avait des blocs déplacés précédemment, ils seront écrasés.

Maintenant, en procédant bloc par bloc dans l'ordre que vous aviez dans votre question, nous remplaçons chaque par son . On obtient la trame estimée suivante $B'(i,j)$ $B(i,j)$ $F_e$

L'erreur est trouvée entre la trame estimée et celle que nous essayons de prédire est trouvée par que nous calculons être $E$ $F_e$ $F$ $E=F-F_e$

— Phonon
source

Bien que je pense que la communauté du traitement du signal est de loin le meilleur endroit pour poser cette question, cependant, des sujets comme celui-ci et des technologies profondément impliquées dans ce domaine ont besoin d'un espace propre. Il y a une nouvelle proposition de site Q&R Technologies de diffusion et de médias Veuillez vous joindre et contribuer.

— Dipan Mehta

@DipanMehta Très cool! =)

— Phonon