distance des images clés ?

Je suis d'accord avec Ogt. Et c'est ce que dit JLH au-dessus.

Une image I est une image clé (keyframe). Il n'y en a qu'une par GOP. C'est forcément une image de référence : d'autres images dans le GOP vont s'y référencer pour se construire (évidemment, je parle d'un GOP > 1 !)

Une image P n'est pas une image clé, mais elle est une image de référence puisque d'autres images dans le GOP vont également l'utiliser pour se constituer. Et pire encore : dans le cas d'un Open GOP, des images en dehors de son GOP peuvent également l'utiliser !

Beaucoup plus rares, les images B peuvent également servir de référence (les b-pyramid) mais je n'en ai jamais vu en utilisation pro. On peut d'ailleurs le voir dans le fichier texte qu'a posté Ogt.

Donc dans le cas d'un GOP "classique" de 12 :

I-B-B-P-B-B-P-B-B-P-B-B

Il y a une image clé et au minimum 4 images de référence si on suppose que les images B ne sont pas des b-pyramid.

 

Alcoriza...
Comment peut on être d'accord avec Olivier et dire le contraire ...et pourquoi surligner des chose que personne ne conteste?
Oui I c'est l'image clef. Oui P ce n'est pas I et ce n'est pas B non plus, c'est écrit partout ...autre chose ? Ah oui B ( bidirectionnel) peu s'appuyer aussi bien sur une image I qu'une image P (c'est donc une images très longues à encoder)... P peut s'appuyer sur I et une image P précédente...etc...encore ?
Arroeux. "...quand on rencontre une nouvelle image I, c'est qu'on change de GOP..." L'article de Jean Charles F sur ce forum ou d'autres ailleurs me paraissaient pourtant bien clair.


Je rajouterais pour rester pratique et revenir dans le sujet du topic, l'important à priori, c'est d'être raccord avec le fichier natif car en effet re-créer des I-frames à partir d'images prédictives !?! A moins de prouver que l'on soulage ainsi un lecteur ..c'est comme faire du 10 bits avec du 8 bits...on s’éloigne du signal d'origine..non ? C'est vous qui voyez ...

C'est le chiffre lié à N qui détermine la longueur d'un Gop (nombre d'image dans le Gop)
C'est celui lié à M qui détermine le nombre d' images B ( que l'on ne souhaite pas trop nombreuses à priori)...après on peut discuter de la distance des images clefs.

 

L’ambiguïté reposait donc apparemment que sur le terme Image de Référence confondu avec Image clef I-Frame la seule qui permet d’identifier la longueur d'un Gop...
Pour ceux qui suivent on le voit, ce n'est pas exactement pareil...P peut être la référence d'une image P qui la suit ou d'autres images B et n' est pas l' image clef du Gop...je n'avais pas penser que l'erreur pouvais se nicher ici...encore un bête problème de sémantique.

Tout cela est juste si et seulement si le mot image clef dans l'univers du Gop et chez Adobe est réservé à l'image I-frame ...il est possible que des articles n'aient pas respecté cette sémantique (à tord ou à raison, il faudrait des ingénieurs pointus fondamentalistes pour en parler )...

Bref c'est tout bon Jean Luc....

 

J'ajouterai que c'est pareil à la lecture : le décodage doit se faire de la même manière non linéaire...

Pour clore le débat, on peut peut-être dire que les images I(ntra) sont les seules du troupeau a être compressées sans références à d'autres images et remettent donc les "compteurs" à 0.

Pour revenir sur les (très) longs GOP (250 images ça fait quand même 10 ou 5 secondes), j'ai lu que le codec H264 était capable de faire varier la longueur du GOP en fonction de la complexité des mouvements de la scène qu'il traite.

Si c'est vrai, la stratégie proposée par JLH 37 est la bonne : il faut utiliser un GOP maxi et laisser le codec se débrouiller quand il rencontre une scène avec beaucoup de mouvements. Mais si ça ne pose pas de problème à l'encodage, le codec pouvant prendre tout son temps, ça en poserait peut-être à la lecture : elle doit se faire en temps réel et les images B et P sont plus difficiles à traiter que les images I.

Qu'en pensez vous ? Quelqu'un a-t-il expérimenté cela sur des images complexes (je reviens au coup de la flaque d'eau filmée par temps de pluie)

Sinon, je suis bien d'accord avec AQW333 : moins on touche aux caractéristiques du fichier initial lors d'un réencodage, mieux on se porte...

 

Voir si ça bloque peut-être pas mais voir si on constate une dégradation progressive de l'image sur les 5 ou 10 sec du GOP, un retour à une image normale avec l'image I, une nouvelle dégradation progressive... etc...

Merci pour le fichier, je vais le télécharger (avec ma ligne ADSL pourrie, ça va me prendre 2 h ) Mais j'aimerai bien que tu fasses le test : tu as sûrement de meilleurs écrans et plus l'habitude que moi...

 

Discussion très intéressante.

Mais pour reproduire à l'export les caractéristiques du fichier natif, comment interpréter alors l'analyse de MediaInfo (Mac) comme ici par exemple d'un 50p à 28 Mbps Sony :

Profil du format : High@L4.2
Paramètres du format, CABAC : Oui
Paramètres du format, RefFrames : 2 images
Paramètres du format, GOP : M=1, N=12

Peut-être MediaInfo Windows donne-t-il plus de détails ?

 

N=12 soit la longueur du GOP : OK
Pour M : pas évident. Je pencherai plutôt pour IPPPPPPPPPPP. La structure IBPBPBPBPBPB correspondrait plutôt à M=2, si je comprend bien la logique.

Extrait Wikipedia :
"La structure GOP est souvent définie par deux nombres, par exemple M = 3, N = 12. Le premier nombre M indique la distance entre deux images d'ancrage (de type I ou P). Le second nombre N indique la distance entre deux images complètes (images I) : c'est la longueur du GOP. Pour l'exemple M = 3 N = 12, la structure du GOP est IBBPBBPBBPBBI. Au lieu du paramètre M, on peut utiliser le nombre maximal d’images B entre deux images d'ancrage consécutives."