Aller au contenu


Photo

Meilleur format d'édition pour du Hi8 capturé en DV...


  • Veuillez vous connecter pour répondre
18 réponses à ce sujet

#1 Mikélé

Mikélé

    Maître

  • Membres
  • PipPipPipPipPip
  • 786 messages
  • Gender:Male
  • Location:92° sud
  • Mac : iMac Pro 2017 10© 64Gio 2To V64
  • Version OS X : 10.13

Posté 23 janvier 2016 - 15:36

Bonjour,

 

je me pose la question suivante : quel est le meilleur format d'édition pour archiver mes rushes (± 50 heures) issus de caméscopes Hi8 PAL et capturés en DV ?

 

La réponse peut sembler évidente (format DV) mais elle ne l'est pas vraiment. En effet :

 

1• la numérisation Hi8 vers DV est faite via un caméscope Digital8, qui produit une image d'excellente qualité...

    mais bordée de bandes à recadrer / "cropper" (qui ne sont normalement pas affichées avec l'overscan des téléviseurs)

    ( et accessoirement perte des informations de timecode RC stocké en analogique )

 

2• je ne souhaite pas avoir à recadrer chaque montage FCPX issu de ces clips

 

3• l'emploi du codec DV pour une image de dimensions inférieures à 768 x 576 engendre un zoom indésirable de l'image croppée

    car apparemment, seul ce format de 720 x 576 anamorphosé est possible avec le codec DV PAL (MPEG Streamclip)

 

Typiquement, l'image numérisée par le caméscope Digital8 a une dimension de 768 x 576 pixels (anamorphose des 720 x 576 pixels enregistrés)

Les bandes à cropper du pourtour ont pour dimension : haut = 2 pixels, gauche = 2 pixels, bas = 8 pixels, droite = 11 pixels soit une dimension de 755 x 566 croppée.

La bande du bas contient en effet des informations - sous forme analogique - de timecode pas très esthétiques

et celle de droite souffre d'une décoloration en plus de la bande noire assez prononcée.

 

Sur mon clip de test (18s+4/25e, 65,2 Mo), la conversion de l'image croppée (755 x 566 mais encore entrelacée 50i) en :

• Prores 422 pèse 121,3 Mo

• Prores LT   pèse   86,0 Mo

 

Visuellement, je ne vois pas de différence entre les 2 versions Prores.

Et le surcoût en poids est assez modeste (+32%) entre la version DV d'origine et la prores LT, compte-tenu notamment des pixels supplémentaires provenant de l'anamorphose (+7%).

 

Je m'achemine donc vers le choix du Prores LT mais j'aurais aimé avoir votre avis.

 

Bien sûr, je ne me suis pas posé la question pour mes clips DV issus de caméscopes mini-DV car le recadrage n'est pas nécessaire. Le DV natif s'est bien sûr imposé naturellement dans ce cas.

 
Merci par avance pour vos conseils !
Mikélé
 
PS : pour donner le contexte : 13 Go/h * 50 = 650 Go pour l'ensemble des rushes Hi8 en format DV
        650 +32% = ± 860 Go pour tous les clips en Prores LT et recadrés... très acceptable en fait

Modifié par Mikélé, 23 janvier 2016 - 15:50.


#2 JLB21

JLB21

    Maître

  • Membres
  • PipPipPipPipPip
  • 1 468 messages
  • Gender:Male
  • Location:78
  • Mac : iMac i7 5K 4 GHz 24 Go CG 4 Go
  • Version OS X : 10.13

Posté 23 janvier 2016 - 18:11

Bonjour Mikélé  ;),

 

 

A ta place, je n'aurais aucune hésitation, j'encoderais en H.264/AAC.

 

Tes originaux ont un débit de l'ordre de 28/29 Mbps. Ton ProRes 422 a un débit de 54 Mbps. Ton ProRes 422 LT a un débit de 36/37 Mbps.

 

D'après un petit essai que j'ai fait avec MPEG Streamclip, si je choisis le codec H.264, en mettant le curseur Qualité à 100 % (et donc sans limitation du débit), pour une vidéo de même définition que la tienne, j'arrive à 22/23 Mbps, c'est à dire un poids de vidéo inférieur de 20 % environ de tes originaux.

 

Et 22/23 Mbps, c'est presque le débit de l'AVCHD 1080 25p issu de camescope grand public. Donc, un débit extrêmement élevé pour du 755 x 566 (11,5 Go de l'heure)…

 

En second lieu, ni le ProRes ni le dv ne sont des formats de diffusion.

 

Alors, à ta place, je vérifierais s'il existe une différence de qualité entre H.264 à 22/23 Mbps et ProRes 422 LT (puisque le ProRes 422 n'est pas meilleur que le LT).

 

Je fais le pari que tu ne decèleras aucune différence. Et même si tu limites le débit du H.264 à 15 Mbps (auquel cas, tu diminuerais ton poids de 60 %, à 7,7 Go de l'heure)…

 

Enfin, ce qui précède est d'autant plus valable si tu envisages ultérieurement de faire des montages dans FCP X.


Modifié par JLB21, 23 janvier 2016 - 18:12.


#3 adesir

adesir

    Administrateur

  • Admin
  • PipPipPipPipPip
  • 4 335 messages
  • Gender:Male
  • Location:Jouy en Josas
  • Interests:Sobriété, efficacité, renouvelable !
  • Mac : iMac 5K 2017
  • Version OS X : 10.12.6

Posté 23 janvier 2016 - 19:00

Bonjour,

 

Le ProRes LT étant moins compressé que le DV, il me parait bien suffisant. En fait, il "gonfle" du 420 (le DV) en 422 (le ProRes). Pas forcement utile. L'idée du H.264 intra (sans GoP) est séduisante.

 

Antoine



#4 Mikélé

Mikélé

    Maître

  • Membres
  • PipPipPipPipPip
  • 786 messages
  • Gender:Male
  • Location:92° sud
  • Mac : iMac Pro 2017 10© 64Gio 2To V64
  • Version OS X : 10.13

Posté 23 janvier 2016 - 19:34

Merci JL et Antoine !

Intéressante cette suggestion du H.264... et même un peu iconoclaste pour du format d'édition !

Mais bon, les progrès techniques font bouger les idées préconçues ! ^_^ Je vais faire des essais.

Avec de belles économies de stockage à la clé.

 

Mais 2 petites questions :

1• comment spécifier l'intra au lieu du GoP lors du transcodage H.264 avec MPSC ?

    j'étais persuadé que le H.264 était systématiquement GoP, avec des groupes plus ou moins longs... mais pas de 1 image par groupe.

2• la contrainte des dimensions multiples de 8 (ou 16) pixels pour le H.264 peut-elle / doit-elle être contournée ?

    ou s'agit-il seulement d'une "moindre efficacité" de l'encodage ?

 

Et une autre grosse question :

3• Si le format d'édition se rapproche de celui de diffusion, que faire de l'entrelacement ?

 

Dois-je désentrelacer mes 3500 clips directement dans MPSC ?

Car ce serait assez pratique de pouvoir diffuser beaucoup de ces clips à mes proches sans montage, ou en tout cas avant montage...

Et donc pas question de laisser l'entrelacement ! ( visu sur ordi )


Modifié par Mikélé, 24 janvier 2016 - 10:56.


#5 adesir

adesir

    Administrateur

  • Admin
  • PipPipPipPipPip
  • 4 335 messages
  • Gender:Male
  • Location:Jouy en Josas
  • Interests:Sobriété, efficacité, renouvelable !
  • Mac : iMac 5K 2017
  • Version OS X : 10.12.6

Posté 24 janvier 2016 - 16:33

Bonjour,

 

1. D'après mes essais, on ne peut pas avec MPSC. En export MPEG-4, il ne permet pas de régler les groupes d'image comme QuickTime. Et en export QuickTime, codec H.264, le bouton Options ne fonctionne pas...

 

2. J'arrive à encoder par multiple de 4, pas moins.

 

3. Si c'est pour faire de la diffusion ordi, autant désentrelacer tout de suite. Le traitement par lot va chauffer !

 

Antoine



#6 Mikélé

Mikélé

    Maître

  • Membres
  • PipPipPipPipPip
  • 786 messages
  • Gender:Male
  • Location:92° sud
  • Mac : iMac Pro 2017 10© 64Gio 2To V64
  • Version OS X : 10.13

Posté 24 janvier 2016 - 17:46

Merci Antoine !

 

Je comprends que MPSC - qui m'a été d'une immense utilité pour la découpe de mes captures de bandes Hi8 en clips individuels propres - doit être remplacé pour :

      • la conversion en H.264 "intra" (GoPs de longueur un)

      • le recadrage idoine

      • accompagné du désentrelacement

 

Je pense donc utiliser soit iFFmpeg soit Compressor - d'Apple - qui remplissent probablement tous les deux ce cahier des charges... je vais faire des tests.

En résumé :

 

                                  iFFmpeg        Compressor         MPSC

H.264 intra                     oui                 probable              non

Recadrage                     oui                     oui                    oui

Désentrelacement         oui                     oui                    oui

 

Et donc effectivement, le traitement par lot va chauffer, mais mon iMac a l'habitude avec DxO et son mode PRIME incroyable !   ;)

 

Au fait, petit aparté, je viens de recevoir ce matin un email concernant iFFmpeg m'annonçant la sortie imminente (début février) de la version 6 !

 

Donc un grand merci à vous deux, Antoine et JL, pour vos conseils plus qu'éclairés !   ^_^

Car j'ai en effet aussi parlé à JL ce matin et il m'a bien aidé avec ses propres tests.



#7 JLB21

JLB21

    Maître

  • Membres
  • PipPipPipPipPip
  • 1 468 messages
  • Gender:Male
  • Location:78
  • Mac : iMac i7 5K 4 GHz 24 Go CG 4 Go
  • Version OS X : 10.13

Posté 24 janvier 2016 - 20:11

A propos de chauffage, le dernier iMac 27"ne chauffe 'physiquement' pas du tout. En pleine charge d'encodage, le ventilo se met à fonctionner, avec un bruit plutôt doux, et un courant d'air chaud s'échappe de la grille située dans le dos, derrière la fixation du pied.

Le ventilateur s'arrête quelques secondes après la fin de l'encodage, et le métal du dos comme de la façade reste rigoureusement froid. ;)



#8 houdini

houdini

    Professionnel

  • Développeurs
  • PipPipPipPip
  • 222 messages
  • Gender:Male
  • Location:Lyon
  • Interests:Vidéo ; arbres
  • Mac : Mac Mini 2012
  • Version OS X : 10.9.5

Posté 24 janvier 2016 - 22:04

Bonsoir à tous :) ,

 

J'ai moi-même 223 Go d'Hi8 PAL numérisé en DV (sans compter 230 Go de DV natif !) ) et votre discussion est vraiment à conserver quand je projetterai de les éditer.

 

Il y a un autre outil, Hybrid, qui est aussi très flexible car utilisant ffmpeg et toutes les manips nécessaires présentées par Mikélé sont faisables par ce logiciel. Il n'a surement pas l'ergonomie des logiciels cités mais avec un peu d'effort il est complètement fonctionnel et très flexible. Son développeur est de plus très réactif.

 

houdini ;)


Vous désirez analyser vos vidéos ? et plus ! VideoSpec

#9 Mikélé

Mikélé

    Maître

  • Membres
  • PipPipPipPipPip
  • 786 messages
  • Gender:Male
  • Location:92° sud
  • Mac : iMac Pro 2017 10© 64Gio 2To V64
  • Version OS X : 10.13

Posté 24 janvier 2016 - 23:15

Salut Houdini !

 

Il y a un autre outil, Hybrid, qui est aussi très flexible car utilisant ffmpeg et toutes les manips nécessaires présentées par Mikélé sont faisables par ce logiciel. Il n'a surement pas l'ergonomie des logiciels cités mais avec un peu d'effort il est complètement fonctionnel et très flexible. Son développeur est de plus très réactif.

 

Ach ! (lu sur http://www.selur.de)

 

Hybrid is a multi platform (Linux/Mac OS X/Windows) Qt based frontend...

 

( lire avec l'accent allemand / finnois / norvégien... car Karl L. est trop cher )

 

Encore un logiciel utilisant cette horreur de Qt !

Et dire qu'il faudrait lire "Qt"... "cute" ("mignon" en anglais) !  :wacko:

 

Car honnêtement, ce sont les pires interfaces utilisateur que l'on puisse trouver sur Mac !

Et pas seulement pour des logiciels gratuits (par ex. TsMuxer), mais même pour certains payants (MakeMKV) voire très onéreux comme SilverFast Archive Suite ( > 500 € ) ou AutoPano Giga ( > 200 € ).

Même DxO Optics Pro a eu sa période Qt... Heureusement, ils en sont revenus !  Et dire que je les ai tous achetés !  :unsure:

 

Franchement, le jour où le gars de chez Nokia a eu l'idée en 2008 de créer racheter à Trolltech - rien que le nom m'amuse - ce framework à la c*n, il aurait dû se casser une jambe !

 

( fin de l'aparté )


Modifié par Mikélé, 26 janvier 2016 - 00:33.


#10 houdini

houdini

    Professionnel

  • Développeurs
  • PipPipPipPip
  • 222 messages
  • Gender:Male
  • Location:Lyon
  • Interests:Vidéo ; arbres
  • Mac : Mac Mini 2012
  • Version OS X : 10.9.5

Posté 25 janvier 2016 - 08:31

Salut Mikélé !

 

Je comprends pour l'interface Qt mais l'outil (gratuit) fonctionne correctement (encodage ProRes amélioré à ma demande ; encodage par lots ; encodage audio AAC nickel ; rapport qualité/poids de fichier meilleur qu'avec HandBrake... ; encodage h265 et j'en passe :P ). je préfère un logiciel "rustique" mais permettant d'encoder de manière optimisée qu'un logiciel avec un GUI design souvent payant et inefficace.

 

houdini ;)


Vous désirez analyser vos vidéos ? et plus ! VideoSpec

#11 Mikélé

Mikélé

    Maître

  • Membres
  • PipPipPipPipPip
  • 786 messages
  • Gender:Male
  • Location:92° sud
  • Mac : iMac Pro 2017 10© 64Gio 2To V64
  • Version OS X : 10.13

Posté 26 janvier 2016 - 00:03

OK Houdini, chacun fait comme il veut / peut...

Mais pas de problème entre nous !  ;)

 

Et pour ton info, j'utilise régulièrement exiftool* en mode ligne de commande (commandes générées par formules Excel), mais ffmpeg, non merci !

Et donc, j'ai acheté iFFmpeg, qui lui est bien fichu question interface utilisateur (pas un logiciel Qt, tout comme VideoSpec, tu l'as compris).

 

Mais alors Qt... je préfère encore la ligne de commande ou payer une alternative !

C'est d'ailleurs cette dernière option que je retiens le plus souvent.

Il faudra que j'appelle les gars de Kolor (autopano) un de ces jours. C'est déjà fait pour Lasersoft (SilverFast), avec quelque espoir !  :o

 

Ayant donc acheté Compressor (d'Apple) - il y a quelques années en même temps que FCPX - et après l'avoir longtemps négligé...

sur les conseils éclairés de JLB21, je trouve cette outil TRÈS puissant... et malgré tout vraiment bien fichu ! Comme quoi, l'un n'empêche pas l'autre.

Surtout que je peux utiliser ma version AppStore en mode coopératif sur 5 machines chez moi... et ça blinde ! Enfin, cela devrait, lorsque j'aurai passé l'étape des tests.

( ok, tout le monde n'a pas 5 macs chez lui, mais moi... oui avec ceux de mes enfants ! :P )

 

Je suis assez embêté pour poster des copies d'écran sur le forum actuel ( Antoine, de l'espoir en vue ? ) mais je peux simplement dire que les conseils de JLB et d'Antoine sont excellents :

j'arrive à des taux de compression impressionnants sans aucune perte de qualité visible (et même amélioration du fait du désentrelacement et des filtres de netteté et d'anticrénelage).

 

Mes derniers essais, notamment avec le mode H.264 / "entropie CAVLC" (normal en sorte), sont tout bonnement identiques au mode ProRes...

pour moins de la moitié du DV d'origine en stockage et cela malgré le surcoût en pixels lié à l'anamorphose !

( pour une raison que j'ignore, Compressor ne sait / veut pas générer des pixels rectangulaires en h.264 alors que iFFmpeg le fait sans souci )

 

Je teste, je teste, mais - comme prédit par JLB21 - je suis ravi des résultats jusqu'à présent.   :D

 

 

 

(*) par exemple pour connaître les coordonnées GPS tout au long d'un film à vitesse rapide


Modifié par Mikélé, 26 janvier 2016 - 08:44.


#12 Mikélé

Mikélé

    Maître

  • Membres
  • PipPipPipPipPip
  • 786 messages
  • Gender:Male
  • Location:92° sud
  • Mac : iMac Pro 2017 10© 64Gio 2To V64
  • Version OS X : 10.13

Posté 27 janvier 2016 - 17:13

Petite question subsidiaire : comment dois-je traiter l'audio DV (4 x 32KHz) pour faciliter sa lecture directe et son édition ?

En "pass-thru" ? ou AAC 128 Kbps (32 ou 44.1ou 48 KHz) ? ou PCM (32 KHz ou réechantillonné) ?

 

Sinon, même si les résultats sont excellents, les temps de traitement depuis Compressor ont l'air un peu trop dissuasifs...  :(

Et donc mes essais avec iFFmpeg d'autant plus encourageants, une fois que j'ai pu identifier le bon filtre de désentrelacement !

Au fait, vous utiliseriez lequel ?

   • Kernel deinterlacing

   • Motion-compensation deinterlacing

   • W3F deinterlacing filter

   • Yadif

 

Quel binz !

Pour l'instant Yadif semble donner les résultats les plus fiables.

 

Je pense quand même attendre quelques jours la sortie de la v6 de iFFmpeg pour me lancer dans "le grand transcodage".   ;)


Modifié par Mikélé, 28 janvier 2016 - 01:05.


#13 JLB21

JLB21

    Maître

  • Membres
  • PipPipPipPipPip
  • 1 468 messages
  • Gender:Male
  • Location:78
  • Mac : iMac i7 5K 4 GHz 24 Go CG 4 Go
  • Version OS X : 10.13

Posté 28 janvier 2016 - 16:42

Bonjour Mikélé,

 

En me basant sur le clip de 18" que tu m'as envoyé, j'aurais tendance à dire ceci :

 

Audio : le clip en ma possession ne comporte pas beaucoup d'audio comme en témoigne l'ouverture audio dans Audacity :

 

Capture d'écran 2016-01-28 à 16.07.45.gif

 

En conséquence, je choisirais l'AAC en 128 Mbps.

 

Vidéo : les filtres de iFFmpeg ne sont pas faciles à régler. Et dans plusieurs essais effectués avec pas mal de réglages, je ne suis pas parvenu à améliorer l'original.

J'obtiens du plus net en arrêt sur image, mais plutôt inférieur en qualité d'image.

Car l'original est excellent.

 

Je suis donc revenu sur Compressor et je trouve que les réglages suivants, toujours compte tenu de l'original dont je dispose, donnent un résultat au moins aussi bon que l'original en visionnage avec des arrêts sur images sans les artéfacts de l'entrelacé :

- fréquence d'images : 25

- Ordre de trame : progressif

- Encodage : Qualité optimale (passes multiples)

- Débit personnalisé : 6000 kbps

- Profil H.264 : Principal

- Mode d'entropie : CABAC

- Effet Accentuer contours : 5 (peut-être un peu fort)

- Effet Correction gamma : 1,10

 

Durée d'encodage pour 18" : 8", soit près de 60 ips.

 

Il faut quand même se poser la question de l'intérêt ou non de desentrelacer ?

 

Mais, je connais tes exigences et je doute que cela soit susceptible de te satisfaire… :D

 

 



#14 houdini

houdini

    Professionnel

  • Développeurs
  • PipPipPipPip
  • 222 messages
  • Gender:Male
  • Location:Lyon
  • Interests:Vidéo ; arbres
  • Mac : Mac Mini 2012
  • Version OS X : 10.9.5

Posté 28 janvier 2016 - 20:12


Au fait, vous utiliseriez lequel ?

   • Kernel deinterlacing

   • Motion-compensation deinterlacing

   • W3F deinterlacing filter

   • Yadif

 

Quel binz !

Pour l'instant Yadif semble donner les résultats les plus fiables.

 

Je pense quand même attendre quelques jours la sortie de la v6 de iFFmpeg pour me lancer dans "le grand transcodage".   ;)

J'utilise Yadif pour ma part avec de bons résultats.

 

houdini ;)


Vous désirez analyser vos vidéos ? et plus ! VideoSpec

#15 Mikélé

Mikélé

    Maître

  • Membres
  • PipPipPipPipPip
  • 786 messages
  • Gender:Male
  • Location:92° sud
  • Mac : iMac Pro 2017 10© 64Gio 2To V64
  • Version OS X : 10.13

Posté 30 janvier 2018 - 11:30

Je déterre ce sujet - que j'avais moi-même lancé il y a 2 ans déjà - pour demander si quelqu'un est intéressé par un sujet sur la capture vidéo analogique (les souvenirs de famille) et la finalisation des clips individuels.

J'ai depuis, en effet, acquis une certaine expérience sur le procédé (environ 120 heures de vidéo Hi8, VHS et aussi DV) et j'ai découvert, un peu par hasard, le moyen de capturer du SD 50i (PAL, SECAM) en 50p avec une qualité tout à fait remarquable.

 

Je me propose donc de partager tout cela dans un nouveau sujet dont je mettrai à jour régulièrement le premier "post" et qui j'espère sera complété et enrichi par vos contributions.

Au programme

• dispositifs de capture

• découpe des clips

• recadrage

• encodage (édition et distribution)

• annotation

 

Antoine, une idée où commencer ce sujet ? si cela intéresse quelqu'un bien sûr ! 

 

À vous lire

Mikélé


Modifié par Mikélé, 30 janvier 2018 - 14:27.


#16 uzboxberg

uzboxberg

    Maître

  • Membres
  • PipPipPipPipPip
  • 3 162 messages
  • Gender:Male
  • Location:Paris
  • Mac : iMac alu 27" Core i5 24 Go
  • Version OS X : 10.11

Posté 30 janvier 2018 - 14:01

mais bien sûr c'est intéressant, cher Mikélé ! :)

Surtout la façon dont tu transcode du 50i en 50p. :huh:

 

Pour le recadrage lors de l'encodage (en H.264), pour moi la solution la plus facile est Handbrake (qui fait ça souvent correctement même en automatique, sinon on configure).

Sinon, je suis passé au H.265, encodage par ffWorks (ex-ffMPEG).



#17 JLB21

JLB21

    Maître

  • Membres
  • PipPipPipPipPip
  • 1 468 messages
  • Gender:Male
  • Location:78
  • Mac : iMac i7 5K 4 GHz 24 Go CG 4 Go
  • Version OS X : 10.13

Posté 30 janvier 2018 - 15:35

Sinon, je suis passé au H.265, encodage par ffWorks (ex-ffMPEG).

 

Salut uzboxberg  ;) 

 

Il te faut passer à Compressor (A partir de High Sierra)…

 

D'après mes derniers essais (rapides) d'encodage en H.265 d'un même fichier H.264 en 1080 50p 28 Mbps, débit cible à 6 Mbps :

 

- iFFmpeg dernière version (je n'ai pas acquis ffWorks) encode en hvc1, ventilos de l'iMac à fond, à 16,30 images/seconde (20,7 images/seconde en le laissant libre pour le débit qui tombe alors à 2,4 Mbps),

 

- Handbrake (hev1 non lisible QT) : 24,44 images/s, ventilos à fond,

 

- Compressor (impossible de descendre en dessous de 11,3 Mbps) : 29,5 images/s, pas de ventilateur

 

Dans d'autres essais, Compressor, sans jamais faire tourner les ventilos, encode 40 % plus vite que Handbrake.

 

Concernant le débit mini incompressible de Compressor (mais je n'ai pas fait un inventaire exhaustif des possibilités du logiciel), je pense que ce n'est pas anormal.

Quand on encode à 28 Mbps de la HD en H.264, il n'est pas idiot de ne pas descendre en dessous de 11 Mbps en H.265 (poids divisé par 2,5 à qualité égale) !



#18 uzboxberg

uzboxberg

    Maître

  • Membres
  • PipPipPipPipPip
  • 3 162 messages
  • Gender:Male
  • Location:Paris
  • Mac : iMac alu 27" Core i5 24 Go
  • Version OS X : 10.11

Posté 30 janvier 2018 - 17:32

c'est curieux, mais je n'ai pas eu des ventilos qui s'emballent lors de l'encodage en H.265 (fait avec iFFfMpeg, je n'avais pas encore acquis ffWorks [que je n'ai pas encore eu le temps de comparer, les changements ne sont pas évidents à première vue]). Or, je n'ai pas transcodé du H.264 en 265 (??), mais encodé des fichiers .mts en mpeg-2 (caméra HDV), ce qui donnait à peu près le même poids pour un fichier 1080p25 en H.265 que pour un fichier 576p25 en H.264, avec une qualité nickel. (Handbrake, c'était surtout pour recadrer lors de l'encodage).

Mais je veux bien essayer avec Compressor !  Et je reverrai pour les temps d'encodage à ce moment-là aussi. ;)

 

(iMac 2017 SSD i5 3,4 4Go VRAM)



#19 adesir

adesir

    Administrateur

  • Admin
  • PipPipPipPipPip
  • 4 335 messages
  • Gender:Male
  • Location:Jouy en Josas
  • Interests:Sobriété, efficacité, renouvelable !
  • Mac : iMac 5K 2017
  • Version OS X : 10.12.6

Posté 30 janvier 2018 - 20:51

Salut,

 

Antoine, une idée où commencer ce sujet ? si cela intéresse quelqu'un bien sûr ! 

 

 

Je mettrais bien un sujet comme ça ici : http://forum.mac-vid...hp?showforum=26

 

Antoine




0 utilisateur(s) li(sen)t ce sujet

0 membre(s), 0 invité(s), 0 utilisateur(s) anonyme(s)