[VotreAvis] concertir avchd en mpg

Bjr,

Je souhaite convertir mes rush avchd
(1920x1080 21Mbps) et les conserver dans un format mpg.

deux interrogations:

- Faut-il choisir un débit constant ou variable ?

- cela a-t-il du sens de choisir un débit supérieur à celui enregistré en AVCHD?

Beru

 

Réponses:

1- le débit variable permet simplement d'avoir un volume final plus petit, à qualité égale; on peut encore améliorer et réduire la taille en faisant 2 passes.

2 - Moins un format est compréssé, plus il faut augmenter le débit pour conserver la qualité.
Ceci est d'autant plus vrai s'il y a des mouvements dans la vidéo (zooms et panoramiques) que le Mpeg2 traite assez mal.

Pour de l'AVCHD en 21 Mbits/s, je conseillerai du Mpeg2 en VBR Cible 30 Mbits/s, Max 40 Mbits/s

faire des essais sur une séquence courte (20sec) pour trouver les meilleurs paramètres qualité/taille.

Edit : coiffé sur le poteau par JLH37

Olivier

 

Merci de vos réponses claires.

J'ai déjà commencé les test d'encodage en faisant varier les paramètres.

Beru

 

Pour te faciliter la tâche dans le choix des paramètres d'encodage, tu as Bitrate Viewer 2.3 très utile pour "optimiser" tes paramètres :

Bitrate Viewer - FAQ


"2 - Moins un format est compréssé, plus il faut augmenter le débit pour conserver la qualité.
Ceci est d'autant plus vrai s'il y a des mouvements dans la vidéo (zooms et panoramiques) que le Mpeg2 traite assez mal."

Après pour savoir qui du mouvement de la camera (zoom ou pano) ou de la complexité de l'image elle même (entre une image contenant des applats de couleurs et une image complexe : embruns, feuillage ou champ de blé dans le vent), sans parler du format lui même (entre 24p et le 50i ou p) a le plus d'influence sans avoir vu les rushs, je trouve que c'est beaucoup s'avancer
Bitrate Viewer a aussi le mérite d'identifier les parties les plus complexes à encoder.

 

J'ai constaté depuis longtemps que l'encodage Mpeg2 souffre beaucoup plus dans les mouvements (déplacements importants des pixels), que dans la complexité de l'image elle même.
Les mouvements on ne les voit pas avec Bitrateviewer.

Pour un encodage correct il faut jouer avec des paramètres fins de "Motion estimation" tels que :
- sub pixel mode
- search mode
- search range
- noise sensitivity

qui en général ne sont pas proposés par les encodeurs standards.

Olivier

 

On peut se poser la question de savoir pourquoi Sony, Canon, JVC continuent à utiliser le format XDCAM, XDCAMEX...sur des produits semi-pro et pros et d'autres si ce genre de problème était aussi génant.

Tu peux justement visualiser sur le graphique la compression de chaque image, de chaque GOP, cela permet d'identifier les parties où le bitrate est le plus élevé, sur les pics pour vérifier si la compression est visible et pose problème.

Je n'ai pas sous la main actuellement de séquence en mpeg2 HD, mais j'ai pris une séquence en mp4 pour monter l'intérêt de BitrateViewer et de vérifier s'il est plus compliqué de coder les images en mouvement ou des images complexes :
drive_through_snow_canyon_with_the_blackmagic_cinema_camera_1920x1080.mp4

téléchargeable ici dans la partie téléchargement -> HD .MP4 file (1920x1080 / 154MB) :



http://www.repaire.net/forums/cinem...c-cinema-camera-2k-raw-21.html/post1970109094

Mode opératoire :
A - Ouvrir BitrateViewer y glisser/déposer la séquence "drive_through_snow_canyon_with_the_blackmagic_cinema_camera_1920x1080.mp4"

B - Cliquer sur le petit carré en haut et à gauche du haut de la fenêtre ou utiliser :
- Ctrl+ S courbe bitrate par seconde ou
- Ctrl+ G courbe bitrate par Gop ou
- Ctrl+ X courbe bitrate par Gop Etendu ou
- Ctrl+ F courbe bitrate par image

C - pour utiliser le graphique qui te convient le mieux et vérifiant bien que l'echelle des valeurs s'adaptent automatiquement "Auto Scale Mode Ctrl + A"


D - Repérer les pics représentant les bitrates les plus élevés (valeurs approximatives) :

1- entre 1mn 07 et 1mn 16
2- entre 2mn04 et 2mn 25
3- entre 2mn40 et 2mn 52

E - Ouvrir un player MPC, VLC ou autre


F - Démarrer la vidéo plein écran en mettant en avant plan bitrate Viewer pour suivre les pics


Résultats :
1- entre 3 secondes et 5 secondes : passage devant des arbres -> pics à 7,5 Mbits
2- entre la 24 eme et la 31eme seconde passage devant des arbres -> pic à 7 Mbits
3- entre 1mn 07 et 1mn 16 : Passage dans le feuillage d'un arbre -> pic à 11 Mbits
4- en 1mn 28 et 1mn 34 : passage devant des buissons -> pic à 7 Mbits
5- entre 2mn04 et 2mn 25 : passage dans le feuillage de 2 arbres -> pic à 8,5 Mbits
6- entre 2mn40 et 2mn 52 : plan sur des buissons -> pic à 7,8 Mbits

Remarques :
1 - La camera est en mouvement pendant pratiquement toute la durée de la séquence (travelling et panos), avec un travelling très rapide sur le 30 premieres secondes
2 - D'après les informations fournies par BitrateViewer, les parties qui réclament les bitrates les plus élevés sont les images contenant du feuillage ou des buissons sur une partie plus ou moins importante de l'image.
3 - Malgré un déplacement un travelling très rapides des 30 premières secondes il apparait que sur la courbe l'encodage se situe en dessous des 5 Mbits/s et présente des pics lors de la présence d'arbres ou de buissons occupant une plus ou moins grande partie de l'image.
4 - Avant et après les 6 pics cités plus haut, le travelling ou le panos continuent et le bitrate chute rapidement en l'absence de feuillage ou de buisson présents sur une bonne partie de l'image.

J'imagine bien Beru investir dans des encodeurs de ce type et jouer avec les sous pixels et les autres paramètres pour convertir ses rushs !!!

Il est certainement plus rapide de choisir comme l'a préconisé JLH37 , dans un premier temps un bitrate en 35 Mbits VBR et si la compression est visible, ce qui est loin d'être évident -> voir les pics avec Bitrateviewer, et éventuellement passer en 50 Mbits (mais CBR uniquement).

 

C'est ce qui s'appelle une réponse fournie.


Merci Gaston

En effet, je ne vais pas mettre ces moyens là et me contenter de 35mbps..

 

"On peut se poser la question de savoir pourquoi Sony, Canon, JVC continuent à utiliser le format XDCAM, XDCAMEX...sur des produits semi-pro et pros et d'autres si ce genre de problème était aussi génant"

Parce que les professionnels n'utilisent pas l'encodeur de Mr tout le monde que l'on trouve dans les logiciels "grand public" et même les versions standard de PremierePro, Vega ou autres.

S'il n'y avait pas de problèmes dus à l'encodage des mouvements , personne ne se serait creusé la cervelle pour inventer les paramètres que j'ai cités (et il y en a d'autres) dans les encodeurs sophistiqués.

Moi j'ai mis en évidence ce problème dans l'encodage des DVD (donc en Mpeg2-SD) ou on est forcément limité en débit par la norme (max 10800 Kbits/sec vidéo + audio).

En utilisant l'encodeur Pro de Mainconcept, j'ai obtenu des images très stables dans les panoramiques, ce que je n'arrivais pas à faire avec les options standards même en prenant le maximum du débit autorisé.
Les paramètres standards des encodeurs ne permettent pas de faire une prédiction de mouvement suffisamment lointaine, et génèrent donc des saccades.

Le problème est certainement moins critique en HD, puisque l'on peut monter beaucoup plus le débit.

Mais c'est un défaut du Mpeg2 que je n'ai pas inventé, il faudra que je recherche sur Internet, les articles que j'avais lu sur le sujet.

Ce défaut a été largement corrigé avec le H264/Mpeg4.

Nota : Dans un montage AVCHD, Première encode les rendus en Mpeg2, mais en image I uniquement (donc intra-image) et à 50 Mbits/s, pour ne pas perdre en qualite.


Edit : pour le détail du codage en Mpeg2 voir là (en anglais)
MPEG-2 video compression

Olivier

 

euh, les pros et certains amateurs éclairés utilisent aussi PPro, Avid, Edius et Vegas avec des sources XDCAM (issues de sony PMW-100, 150, 200, EX1R, séries canon XF 100, XF300, C300, C500, JVC GY-HM600, GY-HM650, GY-HM750 ... ) et encodent parfois sans l'aide d'encodeurs tiers.

qui parle pas de mpeg2-DVD ?

Qu'il y ait des limitations sur les codecs dus aux Gops longs (mpeg, avchd vs intra), aux algorithmes de compression utilisés... c'est une chose, mais les utilisateurs vidéastes doivent paramétrer correctement (choix format d'enregistrement : i/s i ou p, de la vitesse d'obturation...) et filmer en conséquence en tenant compte des contraintes (en évitant les panos rapides..., en jouant sur la profondeur de champ...) ou en corrigeant en post prod (en ajoutant du flou de mouvement/motion blur...) pour contourner ou limiter les problèmes.

H264/Mpeg4 c'est aussi du gop long, le type et le taux de compression sauve en grande partie la mise par rappor au mpeg2 HD.
L'AVC intra de Panasonic est techniquement bien meilleur mais c'est 50 ou 100 Mbits/s uniquement en bitrate constant.

 

Bonsoir, Jean-Luc,
Mais toujours de façon très cordiale

Parfaitement d'accord avec toi, c'est le mouvement rapide du contenu de l'image qui met en difficulté l'encodeur, d'ailleurs c'est peut être ce qu'à voulu dire Ogt dans ces posts précédents,
ce qui peut se produire sur des séquences en plan fixe du type time lapse court ou diaporama.
Les travelling ou panoramiques sont potentiellement moins contraignants à cause du flou de mouvement et de la surface occupée par le sujet (partie nette) dans l'image, le bitrate peut varier en fonction de plusieurs facteurs (réglage de la vitesse d'obturation, de la profondeur de champ, du piqué de l'objectif utilisé, du type de format vidéo...).

Même à partir d'un boitier dslr et d'une optique identique, le 5D par exemple, un timeplase réalisé en mode photo et le même en mode vidéo, l'encodeur ne compressera pas de de la même manière.
Pareil entre la BMCC et le 5D en mode camera pour un même plan la compression sera plus compliquée pour l'image de la BMCC.

le test "comparing_the_BMC_5d_mk_iii_1920x1080_400Go.mp4" est intéressant pour cela et mes en évidence tes remarques


14mn16 14 mn35 -> image bruitée difficile à compresser.

C'est probablement pour un problème de configuration que Beru a choisi cette solution, il pourra toujours passer au 50 Mbits CBR au cas où.

 

Ca dépend ce que tu entends par configuration.
(j'imagine la puissance des ordis)

C'est plus pour un problème de poids final et d'archivage.
on passerait de 15Go/h à 21 Go/h minimum
Car il faut que je raisonne sur des temps longs.

Beru

 

La question qui reste:

Cela a-t-il du sens d'un point de vue qualitatif d'encoder en 50Mbps CBR ?

Si oui, alors ça vaut le coup de raisonner sur les capacités de stockage.

Beru

ps: 50Mbps en constant, on est plutôt à 30Go/h (quand même!)

 

Si c'est uniquement un problème de poids uniquement, il faut rester dans ton format natif en avchd ou en X.264 pour une compression un peu meilleure mais bien plus longue en durée !!!