Format vidéo universel sans perte

J'essaie de trouver le format vidéo sans perte le plus approprié pour la vidéo 1280x720 25fps. La vidéo a 4 minutes. Le son sera de 320 kbps mp3, ce n'est pas un gros problème. Conditions idéales:

Sans perte (peut être sans perte de perception)
Container + codec peut être joué sur la plupart des plateformes
Container + codec peut être lu sur des lecteurs DVD modernes (prenant en charge d'autres formats que les DVD)
La taille est inférieure à 700 Mo

Est-ce que c'est possible? Ont déjà eu du mal trois jours, sans aucun résultat satisfaisant, même en obtenant des fichiers de 12 Go (semble beaucoup - 3 Go / minute).

video ffmpeg video-editing

— mrkva
source

Pour une comparaison, voir en.wikipedia.org/wiki/List_of_codecs#Lossless_compression

— artistoex

Je suis désolé, mais vous ne pouvez pratiquement pas obtenir une vidéo 720p (visuellement) sans perte de 4 minutes compressée à moins de 700 Mo (je suppose que mégaoctet ici, pas "mb" qui signifierait "bit"). Pourquoi avez-vous une telle contrainte? La vidéo ne peut-elle pas être encodée en H.264?

— slhck

oui, MB, désolé de la confusion. Je dois insérer des vidéos cca 5 x 4 minutes dans 4 Go (limitations moyennes).

— mrkva

Puisque vous obtenez des fichiers 12 Go, je suppose que vous utilisez une profondeur de couleur de 24 bits. Le flux de données vidéo non compressé est d'environ 4 Gio par minute. C'est une énorme quantité de données. Ce que vous voulez, c'est environ 170 Mo par minute. Quel que soit le codec que vous choisissez, vous ne pouvez y parvenir qu'avec une scène statique sans beaucoup de mouvement. Je crains que vous ne deviez assouplir la contrainte pour ne pas perdre, réduire la fréquence d'images ou tolérer une taille de fichier plus importante.

— Marco

Pouvez-vous préciser: "Le conteneur + codec peut être lu sur des lecteurs DVD modernes (prenant en charge d'autres formats que les DVD)"?

— llogan

Réponses:

Le meilleur format réel, mathématiquement sans perte que je connaisse, est huffyuv, mais qui produira des fichiers énormément énormes et ne serait pas compatible avec beaucoup. Pour mémoire, ffmpeg peut le faire avec:

ffmpeg -i input -c:v huffyuv -c:a libmp3lame -b:a 320k output.avi

X264, l'encodeur open source h.264, dispose d'un mode sans perte. Cela peut aller à l'intérieur d'un conteneur MP4 et devrait être compatible avec la plupart des matériels fabriqués ces dernières années. La première commande donnera une vitesse d'encodage rapide, mais un fichier volumineux; la deuxième commande prendra beaucoup plus de temps, mais le fichier devrait être environ la moitié de la taille de celui à encodage rapide (il sera quand même assez gros):

ffmpeg -i input -c:v libx264 -crf 0 -preset ultrafast -c:a libmp3lame -b:a 320k output.mp4

ffmpeg -i input -c:v libx264 -crf 0 -preset veryslow -c:a libmp3lame -b:a 320k output.mp4

Si cela ne vous donne pas un fichier suffisamment petit, un crf de 18 est généralement considéré comme 'sans perte visuelle':

ffmpeg -i input -c:v libx264 -crf 18 -preset veryfast -c:a libmp3lame -b:a 320k output.mp4

Je recommande généralement le préréglage très rapide pour l'encodage avec x264, selon mon expérience, il offre le meilleur compromis vitesse / taille (il y a une grande baisse de la taille du fichier entre super rapide et très rapide, plus lente que cela et c'est plus incrémentielle). Le conseil général est d'utiliser le préréglage le plus lent que vous pouvez gérer, les préréglages sont: ultra-rapide, ultra-rapide, très rapide, plus rapide, rapide, moyen, lent, plus lent, très lent.

Voir ici pour un guide plus approfondi de l'encodage x264.

— evilsoup
source

Ne pas suggérer veryfastcomme bon défaut pour le x264 avec perte. mediumest un bon compromis, mais j'utilise habituellement veryslowpour l'encodage final de tout. Ce huffyuvn'est même pas très rapide, je ne le recommanderais pas pour autre chose que la compatibilité.

— Peter Cordes

ffmpeg propose également quelques autres codecs sans perte qui méritent d'être essayés [FFv1 me vient à l'esprit]. GL!

— rogerdpack

Libx264 ne sous-échantillonne pas les deux canaux de couleur (dans YUV les UV) de moitié dans les deux sens, même si vous utilisez un CRF de 0, ce n'est donc pas vraiment sans perte. De plus, avec des erreurs d'arrondi, il n'est pas garanti que les données soient identiques pour chaque bit après un cycle de compression x264.

— Adisak

Dans mes expériences avec ffmpeg 3.4.1, libx264 a utilisé le format de pixel yuv444, où "444" signifie "ne pas sous-échantillonner la partie U, V". Et, l'OP ne dérange pas explicitement les erreurs d'arrondi: "peut être perçu sans perte". Donc, @Adisak, vos préoccupations sont raisonnables, mais ne s'appliquent pas à cette réponse.

— Jim DeLaHunt

ffmpeg et libx264 en mode YUV négocieront un format de pixel YUV basé sur l'entrée. Donc, si l'entrée est YUV 4: 2: 0, le format de pixel de sortie l'est également. Si l'entrée est YUV 4: 4: 4 ou RVB, la sortie est YUV 4: 4: 4.

— Gyan

Ces jours-ci, j'aime webm :

ffmpeg -i input.avi -c:v libvpx-vp9 -lossless 1 output.webm

Pour convertir plus rapidement, avec des processeurs multicœurs, j'ai lu qu'il est recommandé d'utiliser un thread de moins que vous n'en avez de vrais cœurs. Donc, avec un noyau 8, vous pouvez spécifier 7 threads comme ceci:

ffmpeg -i input.avi -c:v libvpx-vp9 -threads 7 -lossless 1 output.webm

— LonnieBest
source

J'aime utiliser la variable d'environnement% NUMBER_OF_PROCESSORS% pour déterminer le nombre de threads à utiliser. Si le nombre est de 1 ou 2, j'ai utilisé tous les processeurs. Si le nombre est de 3 ou 4, j'utilise tout sauf un processeur. Et si le nombre est plus élevé, j'utilise tous les processeurs sauf deux pour le nombre de threads.

— Adisak

En tant qu'expressions DOS, cela ressemble à ceci: si "% ADJUSTED_CPUCOUNT%" EQU "" (si% NUMBER_OF_PROCESSORS% EQU 1 (set ADJUSTED_CPUCOUNT = 1) sinon si% NUMBER_OF_PROCESSORS% EQU 2 (set ADJUSTED_CPUCOUNT = 2) sinon si% NUMBER_OF EQU 3 (set ADJUSTED_CPUCOUNT = 2) else if% NUMBER_OF_PROCESSORS% EQU 4 (set ADJUSTED_CPUCOUNT = 3) else (set / A ADJUSTED_CPUCOUNT =% NUMBER_OF_PROCESSORS% -2))

— Adisak

superuser.com/questions/155305/… dit que ffmpeg choisit déjà le nombre optimal de threads

— Boris

Un meilleur choix que webm (de nos jours) est peut-être le format av1 .

— LonnieBest

-1

# RÉCIPIENT

pour avoir une compatibilité totale avec les lecteurs DVD, vous devrez utiliser le format MPEG-2, le conteneur, les restrictions, les codecs. Je suppose que «lecteurs modernes» signifie compatibilité «mp4», qui est essentiellement et principalement un lecteur de fichiers mp4 - H.264, MPEG-4, AVC => libx264 en
savoir plus: https://de.wikipedia.org/wiki /H.264

# VIDÉO

Jetez un œil à https://trac.ffmpeg.org/wiki/Encode/H.264 , en particulier la partie où il est question de "profil" et de "niveau", pour la compatibilité, l'
utilisation -profile:v high -level 4.0devrait le faire

# L'AUDIO

Évitez de ré-encoder les pistes audio avec des codecs avec perte - tout format mp3 est avec perte, même 320 kbps.
Utilisez -c:a copyplutôt.

Jusqu'à présent, cela a fait du très bon travail pour moi. aucun problème de synchronisation.
Les flux audio ne sont pas liés aux images clés. Des coupes précises sont possibles.
Si votre piste audio est enregistrée à un taux d'échantillonnage de 44 kHz, utilisez max. 256 kbps

Utilisez des codecs avec perte uniquement pour le codage final de votre vidéo, si vous avez besoin de remplir certaines conditions préalables.

J'ai entendu parler de certains problèmes de synchronisation audio, mais il semble que le problème principal était le matériel protégé (!).

# Finalement

Je préfère quelque chose comme ça:
ffmpeg -i input -c:v libx264 -crf 5 -preset faster -profile:v high -level 4.0 -c:a copy output.mp4

— d'oh
source

L'option "-level 4.0" n'est pas nécessaire. Le niveau en x264 est déterminé en fonction de la résolution et du FPS, donc généralement il est inutile de le régler manuellement, cela n'améliorera rien. Pour autant que je sache, ffmpeg peut définir automatiquement le niveau correct, donc à moins que vous n'ayez de très bonnes raisons de le forcer et que vous compreniez parfaitement comment choisir le niveau en fonction du FPS et de la résolution, vous ne devez pas utiliser l'option "-level". Si vous vous souciez de la compatibilité la plus élevée, utilisez le profil "baseline" au lieu de "high".

— Lissanro Rayen