Convertir 50i en 50p

Bonjour,

J'ai filmé un concert avec mon panasonic hc v700 en 50i (pour bouffer moins de batterie) et maintenant j'aimerais une fois monté, rendre mon projet en 50p, comme quand on mets le filtre bob ou yadif x2 dans VLC.

Je vais monter avec première pro et j'aimerais savoir s'il suffit de spécifier 50p en sortie ou s'il y a d'autres réglages à faire.

Merci d'avance.

 

Bonjour,
Si tu n'as pas encore commencé ton montage, tu crées un projet en 50p dans lequel tu incorpores tes rushes 50i puis tu exportes en 50p. Je ferais comme ça avec Edius.
Sinon, export 50i avec peu de compression puis encodage en 50p dans le format final de ton choix avec TMPGenc.

 

Avec Premiere pro (CS6), c'est au moment de l'export de ta séquence que tu demanderas une sortie en 1920x1080p 50.

Une fois ton montage terminé, tu sélectionnes ta séquence, et dans le menu Fichier tu passes sur "Exportation" et cliques "Media".

S'ouvre alors la fenêtre "Réglages d' exportation" où
le premier choix est celui du Format... si tu restes dans l' "environnement" AVCHD, tu peux choisir H264...
Ensuite tu devras... ne rien faire pour "Préconfiguration" - ça viendra "seul" plus tard...
Tu peux cependant déjà choisir à la fois un nom pour "Nom de la sortie" et ce faisant une localisation sur un disque dur... mais, ça peut aussi se faire plus tard...
Evidemment Exporter Vidéo et ... audio doivent être encochés,

Tu vas sur "Réglages vidéo de base"
là, en principe tu as L...1920 et H ...1080, si ce n'est tu rectifies;
sans toucher ni à Fréquence d' images (qui peut être 25) ni à "Ordre des trames", tu déroules pour contrôler "Pixels carrés" / "PAL"
puis c'est ce qui est important tu règles "Niveau" sur 4.2 , 5 ou 5.1 ( avec une valeur inférieure 1920x1080p descend à 1280x720p ...50)
maintenant (et seulement apès cette modif) tu peux revenir à Fréquence d'images et la passer à 50...
Alors, automatiquement "Ordre des trames" passera à "Progressif" (grisé)et "Préconfiguration" affichera "Personnalisé"...

Contrôle aussi les "Réglages du débit"
moi, pour ça, je mets VBR, 2 passages / cible 28Mbits/s / max 32 Mbits/s ... et, 50 comme distance entre les images clé.

Si tu n'as pas, au passage, donné un nom et l'adresse de la sortie c'est le moment, ça ouvre une fenêtre Windows et quand tu confirmes ça retourne à la fenêtre Premiere où tu cliques "Exporter".

Voilà, c'est plus long à exposer qu'à faire !

 

Merci pour les réponses, je vais voir si ça fonctionne

 

Il n'y a aucun problème sur Premiere à mélanger du 50i et 50p et tout ressortir en 50p; dans ce cas il faut définir une séquence en 50p.

Si par contre il n'y a en entrée que du 50i, il vaut mieux, comme l'a expliqué Guy-Jacques, définir une séquence en 50i, et au moment de l'export choisir 50p. Cela permet de conserver la fluidité sur la timeline pendant le montage (pas de convertion de format pour l'affichage).

Olivier

 

Oui c'est ce que je fais avec EDIUS ..Comme l'écrit Olivier avec CS6 ça doit pas poser problème.
Savoir que certains softs, certains encodeurs, sont meilleurs que d'autres dans leur méthode de désentrelacement ..Et qu'on peut gagner un petit plus en qualité.

Le mieux:
Tu essayes sur un export de 1 mn et tu regarde le résultat ...Pas très long et fatiguant à faire

Et comme l'écrit Guy

Perso je mets 33 de distance entre images clés
Heu... je ne fais qu'un passage et c'est trés bon quand même

 

Effectivement, sur un court essai (déjà "multiplié" pour une autre discussion - titrage), j'ai mis VBR 1 seule passe et choisi les bitrates analogues à ceux des clips "MTS" de mon camescope ( 24 / 26 selon mediainfo).

Pour la "distance...", j'avais, arbitrairement, choisi 50... est-ce judicieux, j'en doute
Pourquoi 33 ?
Il me vient quand même une idée: "normalement", les GOP décrivent 12 images dont 1 seule, bien que compressée "intra" est complètement décrite, alors je "décideé que cette distance devrait être un multiple de 12 ... J'ai donc choisi 36, mais .

Au visionnage vidéo, le rendu apparait tout aussi bon que celui de la séquence enregistrée selon les valeurs précédentes (VBR 2passes; bitrate 28 / 32; dist 50)

 

1 - le multipass dans l'encodage ne sert uniquement qu'a réduire le volume du fichier de sortie : en aucun cas il améliore la qualité à débit égal.
Donc tout a fait inutile si on n'est pas contraint pas la taille.
(et ça double le temps pour rien)

2 - la distance correspond justement à l'intervalle entre 2 images I (images pleines). C'est tout à fait pareil que le Mpeg2 un Gop = 12 images la premiere étant pleine, en AVCHD on travaille avec des gops plus longs, moi je prend 25.
On améliore la qualité dans les mouvements si l'intervalle diminue.

Olivier

 

Salut Olivier & Guy

Pourquoi j'ai pris 33 je l'ignore, c'était ans doute pas défaut la valeur de CS5.5
Si on diminue la distance entre les images clés on augmente pourcentage, si je puis parler ainsi, d'images complètes.
la qualité devrait s'en ressentir dans les mouvements ..mais ne devrait-on pas augmenter alors le débit???
Un spécialiste de l'encodage (un sacré truc de matheux ça) pourrait nous répondre
André

 

Disons plutôt que si on s'impose une taille de fichier (et donc un débit moyen imposé) il faut absolument faire deux passes.
C'est la seule façon de s'assurer que le débit instantané sera bien réparti.
Un bon encodeur ne devrait proposer que 3 choix :
- débit moyen en deux passes
- débit constant
- qualité constante

Malheureusement la plupart ne propose qu'une passe pour le débit moyen.
C'est encore pire avec les accélérations genre cuda ou quicksync dont le seul credo est la vitesse.

En fait, plus le GOP est long, meilleure sera la qualité à débit moyen égal.
Le meilleur encodeur h264 (x264) propose, par défaut, des GOPs de 250 images.
Dit autrement un GOP long permet de faire des économies sans sacrifier la qualité.
En raisonnant à l'envers, si on fait des GOPs de 1 image (AVCHD intra) il faut, à chaque image, coder l'intégralité de celle-ci donc un débit très élevé si on veut de la qualité.

L'inconvénient des GOPs long est la difficulté de les "prendre en cours". Le décodeur doit commencer par une image intra pour faire un travail propre. Idem pour un soft de montage : si on veut voir la 202ème image d'un GOP de 250 le soft devra remonter à l'image intra précédente la plus proche et reconstituer les 202 images avant de pouvoir afficher celle voulue.

En simple lecture (et tant que l'on ne demande pas une lecture en marche arrière !) les longs gops ne posent pas de problème.

Surtout ne pas croire qu'avec un gop de 250 images les 249 images qui suivent l'image intra tirent toutes les infos de cette image. Les images P ou B peuvent parfaitement contenir des macroblocs de type I.

Edit :
André, je n'avais pas vu ta question, je ne sais pas si ça y répond. (je me suis pas mal intéressé au sujet mais je ne suis pas du tout "spécialiste" et quand je vois les algorithmes mathématiques de certaines docs, ça me prend la tête )

 

Salut Baloub

Oui ça y répond
Avec quelques surprises : Pour la qualité j'aurais plutôt misé sur un GOP court
Plus d'image complètes.

Un GOP court demande un débit plus fort ça parait normal ...Je pense qu'il faut trouver le bon compromis.
Je prends 33 mais au fond je ne sais pas pourquoi

André

 

Ça peut être vrai ou faux La longueur d'un GOP, seule, ne peut permettre d'avoir une idée de la qualité.

En fait c'est assez simple :
- Si tu veux que le fichier puisse être éventuellement édité par la suite : gops courts.
- Pour le mettre sur une clé usb et simplement le lire : gops longs.
(la norme bluray n'aime pas les gops longs, mais d'un autre coté on n'est pas limité en débit)

La force de l'habitude, peut être. C'est aussi la valeur que j'ai mis par défaut comme longueur de gop dans cam2x264 (quand on veut un gop court).
Et honnêtement je ne me rappel plus du tout les origines de ce choix.

 

Re Baloub

Sur Première il est à 33 par défaut aussi ...Je vérifierais mais je crois bien

 

En ce qui concerne la longueur des GOP ... j'ai retrouvé une étude qui date de 2004 et qui fut effectuée à la fois dans les cadres de la reproduction et de la transmission de différents flux vidéo (9 plus ou moins "animés" ... l'un concernait un parisien bavard et plus gesticulateur qu'un ...italien), étude faite par 3 chercheurs d'un institut du Masachusset mais pas le MIT).
Leur conclusion était:

La structure du GOP devrait être:
IBBPBBP... BB , avec un maximum de 5 images P;
On pourrait alors avoir un flux
1 ) IIIIIII...I ( INTRA)
6 ) IBBPBBIBBPBBIBBPBB... IBBPBB type 3;6
9 ) IBBPBBPBBIBBPBBPBB... IBBPBBPBB type 3;9
12) IBBPBBPBBPBBIBBPBBPBBPBB... IBBPBBPBBPBB type 3;12
15) IBBPBBPBBPBBPBBIBBPBBPBBPBBPBB... IBBPBBPBBPBBPBB type 3;15
Le premier nombre du "type" est la longueur du GOP et le second la distance I -P ou P-I ou P-P.
Mais,
-- Si pour le MPEG2, en principe, les GOP sont du type 3;12 (Premiere CS6 le propose par défaut),
-- pour le MPEG4, en principe encore, une certaine "souplesse" devrait exister et, peut-être encore (???) autoriser plusieurs images "I" dans le mêm GOP (c'est permis) ou pour un flux très animé ... raccoucir les GOP concernés...
En fait, je n'en sais rien, sauf que:
- Premiere CS6, pour le H264 (non Blu-ray) par défaut inscrit 75 ... par défaut ???
ça conforte le (très) "LOG GOP" de Baloub... Et, contredit l' "étude" que je cite..
-Les "images" I sont, individuellement, compressées Intra ... les autres d'un même GOP ne recensent que les différences (elles sont nommées aussi "images delta") par vecteurs-mouvement.
Un vecteur-mouvement "suit" le déplacement de chaque pixel (qui bouge),
pour les "images P" ça concerne le mouvemnt depuis la "I" ou la "P" précédente,
pour les "B" c'est par rapport aux deux qui l' encadrent (bidirectionnelles).
Ce n'est pas, en soi, un gros problème mathématique... mais, il contraint le codeur / décodeur à travailler d' abord les images "I", puis les "P" en enfin les "B" - ce qui n'est pas l'ordre dans lequel elles se présentent ou devront se présenter.

André, le problème matheux est en amont, pour la compression "INTRA",
résolu depuis le XIXème siècle (DCT = Discrete Cosine Transformee) et exploité par le JPEG et le MPEG2,
plus récent et complexe (DWT = Discrete Wavelet ransformee) pour le MPEG4 (possible en photo avec le JPEG2000).
Les deux reposent sur le "découpage" de l'image en blocs carrés (de pixels) : taille des blocs constante en DCT (MPEG2), plus "souple" variable selon difficulté avec DWT (MPEG4), ça transforme des variations spatiales en variation de fréquence...
Et, ça, c'est un problème mathématique dont le traitement par algorithmes informatiques est plus lourd en calculs "élémentaires" pour le DWT (le terme "ondelettes" est significatif des "reprises itératives" de résultats intermédiaires).

nb: j'ai écrit "image"... car dès l'origine, c'est évidemment une description numérisée de l'image optique formée à la surface du capteur et que celui-ci a déjà traduite en "signaux électriques"...

 

Hello Guy

Bien par défaut, la case n'est pas cochée chez moi, et si je coche j'obtiens 33

75 c'est une valeur que tu as mesurée sur un export ??
C'est pas capital 33 ça le fait bien je trouve ...Mais simple curiosité

André