module inscription newsletter haut de page forum mobile

Rejeter la notice

Nouvelle Formation Prise de son : les inscriptions sont ouvertes !
Maîtrisez la qualité de vos prises de son avec notre formation théorique et pratique de 3 jours ! Du 14 au 16 mai 2024 à Paris.

[VotreAvis] concertir avchd en mpg

Discussion dans 'Compression, conversion vidéo' créé par Beru, 4 Février 2013.

Tags:
  1. Beru

    Points Repaire:
    4 270
    Recos reçues:
    8
    Messages:
    1 154
    Appréciations:
    +12 / 22 / -1
    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
     
  2. JLH 37

    JLH 37 Super Modérateur
    Modérateur So

    Points Repaire:
    24 400
    Recos reçues:
    539
    Messages:
    11 117
    Appréciations:
    +398 / 1 300 / -13
    Si tu n'as pas besoin d'économiser de la place en optimisant le débit par rapport à l'image tout au long du film, prends un débit constant en une passe, tu gagneras du temps.

    Oui parce que l'AVCHD est plus performant que le mpeg pour le même débit. Je te conseille donc de choisir un débit de 35 Mbs pour l'export en mpeg2 HD. Si les scènes sont difficiles à encoder, tu peux monter à 45 Mbs.
     
  3. ogt

    ogtx Regretté conseiller technique
    So

    Points Repaire:
    17 700
    Recos reçues:
    546
    Messages:
    23 514
    Appréciations:
    +712 / 1 396 / -41
    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
     
  4. Beru

    Points Repaire:
    4 270
    Recos reçues:
    8
    Messages:
    1 154
    Appréciations:
    +12 / 22 / -1
    Merci de vos réponses claires.

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

    Beru
     
  5. GastonHD

    Points Repaire:
    4 580
    Recos reçues:
    85
    Messages:
    2 347
    Appréciations:
    +19 / 31 / -1
    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 :perplexe:
    Bitrate Viewer a aussi le mérite d'identifier les parties les plus complexes à encoder.


    ;)
     
  6. ogt

    ogtx Regretté conseiller technique
    So

    Points Repaire:
    17 700
    Recos reçues:
    546
    Messages:
    23 514
    Appréciations:
    +712 / 1 396 / -41
    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
     
  7. GastonHD

    Points Repaire:
    4 580
    Recos reçues:
    85
    Messages:
    2 347
    Appréciations:
    +19 / 31 / -1
    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. :suspicious:

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

    ;)
     
    #7 GastonHD, 7 Février 2013
    Dernière édition par un modérateur: 14 Octobre 2015
  8. Beru

    Points Repaire:
    4 270
    Recos reçues:
    8
    Messages:
    1 154
    Appréciations:
    +12 / 22 / -1
    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..
     
  9. ogt

    ogtx Regretté conseiller technique
    So

    Points Repaire:
    17 700
    Recos reçues:
    546
    Messages:
    23 514
    Appréciations:
    +712 / 1 396 / -41
    "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
     
    #9 ogt, 7 Février 2013
    Dernière édition: 8 Février 2013
  10. GastonHD

    Points Repaire:
    4 580
    Recos reçues:
    85
    Messages:
    2 347
    Appréciations:
    +19 / 31 / -1
    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 ? :perplexe:


    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.

    ;)
     
  11. JLH 37

    JLH 37 Super Modérateur
    Modérateur So

    Points Repaire:
    24 400
    Recos reçues:
    539
    Messages:
    11 117
    Appréciations:
    +398 / 1 300 / -13
    Hou là, ça discute dur sur les encodages !:laugh:

    Là comme ailleurs, il faut se garder de conclusions définitives. Si l'on veut attaquer le sujet de l'encodage, nous allons y consacrer quelques bonnes dizaines de pages. Mais nous l'avons déjà fait il y plusieurs années.

    Evidemment que le mouvement est un facteur de difficulté pour un encodeur qui fonctionne... sur un calcul prédictif du mouvement. Mais tout dépend de ce que l'on appelle "mouvement".

    Il serait beaucoup plus juste de parler de changement. Ainsi, un panoramique fait dans les règles de l'art, c'est à dire avec un mouvement régulier, un flou de bougé convenable et parfaitement horizontal, ne pose pas d'énormes problèmes à un encodeur. Là, comme le souligne Gaston HD, ce sont la profusion de micro détails qui vont en poser.

    Par contre, un brave fondu enchainé entre deux images fixes et d'aspect bien différents va affoler l'encodeur et générer des macro blocs. C'est un des premiers tests que je fais passer à un encodeur.

    Autre test absolument redoutable : des changements d'aspects continus et aléatoires au sein d'une image fixe. Le meilleur étant une prise de vues d'une surface aquatique avec vaguelettes. Là c'est très dur et permet de juger la qualité de l'encodage. C'est donc un test à avoir absolument.

    Le comportement sur des dégradés n'est pas mal non plus. Et enfin, pour faire court, une image bien bruitée ne dépareillerait pas dans la batterie de tests.

    L'ennui, c'est qu'aucun encodeur ne se ressemble et sur des tests sérieux entre différents encodeurs, on s'aperçoit que l'un gèrera mieux ceci et l'autre cela. Donc, ça se complique.

    Enfin, un film contient tout un tas de sortes d'images et, le réglage qui pourrait convenir à une sorte risque de ne pas être bon pour une autre sorte. Là, c'est presque insoluble.

    Ce ne sont pas "les professionnels", au sens large du terme, qui vont utiliser du matériel permettant de se sortir de ces chausse-trappes mais des laboratoires professionnels de traitement de l'image. Ils n'utilisent pas de simples logiciels sur un ordinateur mais des machines dédiées dont le prix va faire reculer 99,99 % des repairenautes ici présents.

    Que faire alors. Il faut trouver un compromis acceptable au milieu de tout ça.

    - Premier compromis: le temps d'encodage. Si, sans se préoccuper de réglages compliqués (dont on ne maîtrise pas toujours la finalité) on met l'encodeur en qualité maxi, celui-ci va mettre tous les paramètres d'analyse au maxi mais au détriment du temps car il va falloir qu'il se livre à des opérations complexes qui rallongent la durée.

    En mpeg ce n'est pas un gros problème et, en HD, un bon encodeur réglé au maxi devrait sortir le film en deux à trois fois le temps du film.

    Il en va tout autrement avec du X264 ou des réglages au maxi de la qualité peuvent monter à plus de dix fois le temps du film.

    - Deuxième compromis : le débit. Plus on va baisser le débit et plus il va falloir augmenter le temps de calcul. Ainsi, toujours avec du X264, j'arrive à un excellent résultat à 30 Mbs en quatre fois le temps du film. Pour retrouver le même résultat à 15 Mbs, c'est... onze fois le temps réel.

    Bon, mais comme le sujet c'est du mpeg2 HD, je préconise en CBR du 35 Mbs qualité maxi qui devrait donner de bons résultats sans trop se prendre la tête.
     
    • Je recommande ! Je recommande ! x 1
  12. GastonHD

    Points Repaire:
    4 580
    Recos reçues:
    85
    Messages:
    2 347
    Appréciations:
    +19 / 31 / -1
    Bonsoir, Jean-Luc, :hello:
    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ù.
    ;)
     
    #12 GastonHD, 11 Février 2013
    Dernière édition par un modérateur: 14 Octobre 2015
  13. Beru

    Points Repaire:
    4 270
    Recos reçues:
    8
    Messages:
    1 154
    Appréciations:
    +12 / 22 / -1
    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
     
  14. Beru

    Points Repaire:
    4 270
    Recos reçues:
    8
    Messages:
    1 154
    Appréciations:
    +12 / 22 / -1
    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!)
     
  15. GastonHD

    Points Repaire:
    4 580
    Recos reçues:
    85
    Messages:
    2 347
    Appréciations:
    +19 / 31 / -1
    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 !!!

    ;)
     
Chargement...
Discussions similaires - concertir avchd mpg
  1. Pierro787
    Réponses:
    13
    Nb. vues:
    939
  2. FredPonthus
    Réponses:
    12
    Nb. vues:
    950
  3. fplanglois
    Réponses:
    20
    Nb. vues:
    2 505
  4. Zoldo
    Réponses:
    14
    Nb. vues:
    1 843
  5. Borne
    Réponses:
    70
    Nb. vues:
    9 389

Partager cette page