Partager selon Final Cut Pro X

icone_partagerUn petit tour de la fonction Partager qui permet les différentes sorties possible de Final Cut Pro X.
icone_partager_10.3Tous les utilisateurs de FCP avant la 10.0.6 peuvent se vanter d’avoir connu le menu « Partager » (toujours présent dans Motion) dans la barre des menus. Il se retrouve en tant que sous-menu du menu fichier. Cela semble plus logique car la fonction de partage sert à créer/sortir un fichier informatique du montage. En plus il vient de faire entièrement peau neuve. Regardons ça d’un peu plus près.  Continuer la lecture de « Partager selon Final Cut Pro X »
 

Youtube fait le ménage

En plus de fournir un hébergement gratuit, parfois conséquent, Youtube permettait une compatibilité totale avec le parc d’ordinateur et de tablette/smartphone toutes marques confondues.

Depuis le 20 avril 2015 ce n’est plus le cas. Voici une page évoquant les OS et appareils devenus obsolètes. C’est bien le lecteur ou l’application qui rend impossible la lecture. Pour l’éco-système Apple voici les appareils obsolètes :

  • Anciens appareils iOS (iOS 5 et versions précédentes)
  • Anciennes Apple TV (première et deuxième générations)

Il va être donc plus compliqué d’être compatible avec tous le parc de Tablette et SmartPhone. Bienvenu dans un monde d’obsolescence programmée !!

Export_idevice_iphone4_ou _plusFinal Cut Pro X (<10.1) n’est d’ailleurs plus capable de « partager » des vidéos pour les premiers iphones !!!!

 

Proxy avec Timecode [MàJ]

Dans Final Cut Pro X, il n’existe toujours pas option d’affichage du timecode du plan dans les visualiseurs ni de filtre « Lecteur de Timecode », A l’inverse ce dernier se trouve dans Compressor. Donc aujourd’hui, Compressor est un passage obligé pour avoir le Timecode dans l’image.

L’astuce est de générer avec Compressor des simili-proxys Final Cut Pro X avec le TimeCode à l’image.

[MàJ] Le tutoriel a été amélioré Continuer la lecture de « Proxy avec Timecode [MàJ] »

 

Les bases de la compression

debit_passes_miniDepuis que la vidéo numérique existe, il y a de la compression. La quantité de données (information visuelles) est tellement importante, que d’abord pour des raisons de stockage puis de puissance de post production et enfin de diffusion, il faut la réduire de manière la moins « visible ».

Présentation

Analysons ce graphique de la qualité d’un fichier (Full HD en H264) en fonction du débit moyen demandé à la compression. Sont représentés les 3 principaux profils de ce codec.

BitRate_vs_Quality

 

Bien évidement les choses ne vont pas dans le bon/même sens .. un petit débit avec une bonne qualité n’existe pas. Tout est affaire de compromis et de respect de certaine contrainte.

  • Une SSIM proche de 1 est exigée pour les codec de post-production, c’est le cas des Apple Prores 4444 & 422 (HQ)
  • Une SSIM > 0.9 est une très bonne qualité pour la diffusion
  • Une SSIM comprise entre 0.85 et 0.9 est acceptable pour de la diffusion internet. C’est ici que c’est le plus compliqué !! Car il peut y avoir un rapport de 1 (500Kbps) à 3 (1500 Kbps) du débit, ce qui est loin d’être négligeable : stockage, bande passante, rapidité de téléchargement. C’est le Cœur du problème!!

Comparons ce qui est comparable

Comme je ne connais aucun logiciel donnant le SSIM suite à une compression, le seul garant de la qualité est notre œil. Plus il est entrainé et plus il voit les défauts engendrés par une trop forte compression.
Comparer deux vidéo compressées permet d’avancer vers ce que l’on veut et pourtant tout n’est pas comparable. Voici des exemples.

  • Comparer les qualités de la compression d’une même vidéo a des tailles et fréquences d’image différentes.
  • Comparer les qualités de la compression d’une même vidéo avec des codec différents.
  • Comparer les qualités de la compression avec les mêmes réglages pour des vidéos différentes.

Que faut-il régler ?

La compression a beaucoup de paramètres dont l’importance de chacun d’eux peut varier en fonction du but de chaque compression :

  • Taille et la fréquence
  • Codec (utilisation CPU & compatibilité iBidules ou DVD/Bluray)
  • Débit (Complexité et mouvement de l’image)
  • Temps de la compression

Généralement certains de ces paramètres sont contraints en fonction de la compression à réaliser
– Ipad : Image en 720p et codec Mpeg 4 ou H264 (profile de base)
– Bluray : codec en H264 (Profil Haut) ou Mpeg 2 HD et débit inférieur à 40 Mbit/s, taille inférieur à celle du disque 25 Go.
Proxy FCP X : taille réduite de moitié, faible débit, et faible utilisation CPU, codec en APR 422 proxy

Dans la pratique

Le menu « Partager » de Motion / FCP permet de nous simplifier la vie (je vous invite à lire le paragraphe dédié). Les commandes d’export sont toutes simples, plutôt rapides et très bonnes en terme de qualité (à l’exception du DVD peut-être).

Envoyer_a_compressor_2

Dans chaque boite de dialogue d’export le bouton « envoyer à Compressor » dans l’onglet « Avancé » permet d’aller plus loin dans les réglages de compression en se retrouvant basculer dans Compressor. Fort pratique! Ce n’est plus le cas pour FCP X depuis la version 10.0.6 car il y a une commande dédiée dans le menu Partager.

Pour aller encore plus loin il faut utiliser d’autre logiciel tel que Media Encoder, Squeeze ou Episode. Il y en a pour tous les tarifs et tous les raffinements de réglage de compression! (Apple fait office de mauvais élève)

profilsepisode

Les illustrations sont faites à partir d’encodage en Mpeg 2 ou H264.

profilsetniveauxmediaencoder

Voici ma manière de faire, je choisis :

debit_passesdebit_passes2

Pour le régler le débit et le nombre de passes

  • Avec une contrainte de temps d’encodage, je choisis un débit très élevé et je décoche « Passe multiple » ou choisi « CBR une passe »
  • Avec une contrainte de débit, je commence par un premier encodage basé sur un débit de référence en 2 passes/Passes multiple. Pour le H264 j’utilise un débit max deux fois plus élevé que le débit moyen, des « images I » toutes les 10 secondes et réglage « d’image B » de 3. Puis j’encode à nouveau avec un débit diminué, autant de fois que je juge la qualité du fichier encodé suffisante. Ou à l’inverse j’encode à nouveau avec un débit augmenté, autant de fois que je juge la qualité du fichier encodé insuffisante. Utiliser la dichotomie peut diminuer le nombre d’essai.
  • Avec une contrainte de débit et de temps …. ça demande de l’expérience, un certain doigté 🙂

Débit de référence

Un bon indice de travail est le « bit / pixel ». Une fois la vidéo compressée, c’est le nombre de bit moyen qu’il faut pour codé la couleur d’un pixel d’une image de la vidéo.
Débit = Bit/pixel X ( hauteur X largeur) X fréquence
Voici un tableau pour du H264 High Profile :

bit_par_pixel

il faut retenir que :
– plus l’image est grande plus l’indice de bit/pixel chute
– plus il y’a de mouvement plus l’indice de bit/pixel augmente
– plus le codec est récent plus il a de chance d’être très efficace et avoir un indice de bit/pixel très bas.

Le poids en bit de la couleur compressé d’un pixel