J'essaie d'encoder une vidéo .mp4 à partir d'un ensemble d'images en utilisant FFMPEG en utilisant le codec libx264.

Voici la commande que j'exécute:

/usr/local/bin/ffmpeg -r 24 -i frame_%05d.jpg -vcodec libx264 -y -an video.mp4

J'obtiens parfois l'erreur suivante:

[libx264 @ 0xa3b85a0] height not divisible by 2 (520x369)

Après quelques recherches, il semble que le problème ait quelque chose à voir avec l'algorithme de mise à l'échelle et peut être résolu en ajoutant un argument -vf.

Cependant, dans mon cas, je ne veux pas faire de mise à l'échelle. Idéalement, je veux garder les dimensions exactement les mêmes que les cadres. Aucun conseil? Existe-t-il une sorte de rapport hauteur / largeur que h264 applique?

La réponse à la question d'origine qui ne souhaite pas mettre à l'échelle la vidéo est:

-vf "pad=ceil(iw/2)*2:ceil(ih/2)*2"

Commander:

ffmpeg -r 24 -i frame_%05d.jpg -vcodec libx264 -y -an video.mp4 -vf "pad=ceil(iw/2)*2:ceil(ih/2)*2"

Fondamentalement, .h264 a besoin de dimensions égales, donc ce filtre:

1. Divisez la hauteur et la largeur d'origine par 2
2. Arrondissez-le au pixel le plus proche
3. Multipliez-le par 2 à nouveau, ce qui en fait un nombre pair
4. Ajouter des pixels de remplissage noirs jusqu'à ce nombre

Vous pouvez changer la couleur du remplissage en ajoutant un paramètre de filtre :color=white. Voir la documentation de pad .

Juste utiliser -2

À partir de la documentation du filtre de balance :

Si l'une des valeurs est -navec n > 1, le filtre d'échelle utilisera également une valeur qui conserve le rapport hauteur / largeur de l'image d'entrée, calculé à partir de l'autre dimension spécifiée. Après cela, il s'assurera cependant que la dimension calculée est divisible par net ajuste la valeur si nécessaire.

Exemples

Définissez la largeur sur 1280, et la hauteur sera automatiquement calculée pour conserver le rapport hauteur / largeur, et la hauteur sera divisible par 2:

-vf scale=1280:-2

Identique à ci-dessus, mais avec une hauteur déclarée à la place; laissant la largeur à traiter par le filtre:

-vf scale=-2:720

"divisible par 2"

Comme requis par x264, le "divisible par 2 pour la largeur et la hauteur" est nécessaire pour les sorties sous-échantillonnées de chrominance YUV 4: 2: 0. 4: 2: 2 aurait besoin de "divisible par 2 pour la largeur", et 4: 4: 4 n'a pas ces restrictions. Cependant, la plupart des lecteurs non basés sur FFmpeg ne peuvent décoder correctement que 4: 2: 0, c'est pourquoi vous voyez souvent des ffmpegcommandes avec l' -pix_fmt yuv420poption lors de la sortie de vidéo H.264.

Caveat

Malheureusement, vous ne pouvez pas utiliser -2à la fois la largeur et la hauteur, mais si vous avez déjà spécifié une dimension, l'utilisation -2est une solution simple.

Si vous souhaitez définir une largeur de sortie et obtenir une sortie avec le même rapport que l'original

scale=720:-1 

et pour ne pas tomber avec ce problème, vous pouvez utiliser

scale="720:trunc(ow/a/2)*2"

(Juste pour les personnes qui cherchent comment faire cela avec la mise à l'échelle)

Le problème avec les scalesolutions ici est qu'elles déforment l'image / la vidéo source, ce qui n'est presque jamais ce que vous voulez.

Au lieu de cela, j'ai trouvé que la meilleure solution consiste à ajouter un tampon de 1 pixel à la dimension impaire. (Par défaut, le rembourrage est noir et difficile à remarquer.)

Le problème avec les autres padsolutions est qu'elles ne se généralisent pas sur des dimensions arbitraires car elles bourrent toujours.

Cette solution n'ajoute un pad de 1 pixel à la hauteur et / ou à la largeur que s'ils sont impairs:

-vf pad="width=ceil(iw/2)*2:height=ceil(ih/2)*2"

C'est idéal car il fait toujours ce qu'il faut, même si aucun rembourrage n'est nécessaire.

Cela est probablement dû au fait que la vidéo H264 est généralement convertie de l'espace RVB en espace YUV au format 4: 2: 0 avant d'appliquer la compression (bien que la conversion de format elle-même soit un algorithme de compression avec perte entraînant une économie d'espace de 50%).

Le YUV-420 commence par une image RVB (rouge vert bleu) et la convertit en YUV (essentiellement un canal d'intensité et deux canaux "teinte"). Les canaux Hue sont ensuite sous-échantillonnés en créant un échantillon de teinte pour chaque carré 2X2 de cette teinte.

Si vous avez un nombre impair de pixels RVB horizontalement ou verticalement, vous aurez des données incomplètes pour la dernière colonne ou ligne de pixels dans l'espace de teinte sous-échantillonné du cadre YUV.

LordNeckbeard a la bonne réponse, très vite

-vf scale=1280:-2

Pour Android, n'oubliez pas d'ajouter

"-preset ultrafast" and|or "-threads n"

Vous pouvez également utiliser la bitandfonction au lieu de trunc:

bitand (x, 65534)

fera la même chose trunc(x/2)*2et il est plus transparent à mon avis.
(Considérez 65534 comme un nombre magique ici;))

Ma tâche consistait à mettre automatiquement à l'échelle un grand nombre de fichiers vidéo en demi-résolution .

scale=-2,ih/2conduisent à des images légèrement floues

raison:

• les vidéos d'entrée avaient leur format d'affichage (DAR) défini
• scale met à l'échelle les dimensions réelles du cadre
• pendant l'aperçu, les tailles des nouvelles vidéos doivent être corrigées à l'aide du DAR, ce qui peut entraîner un flou dans le cas d'une vidéo à faible résolution (360x288, DAR 16: 9)

Solution:

-vf "scale='bitand(oh*dar, 65534)':'bitand(ih/2, 65534)', setsar=1"

explication:

• output_height = hauteur_entrée / 2
• largeur_sortie = hauteur_sortie * rapport_aspect_affichage_original
• à la fois output_width et output_height sont maintenant arrondies à divisible plus petit nombre le plus proche de 2
• setsar=1signifie que output_dimensions est désormais définitif, aucune correction de rapport hauteur / largeur ne doit être appliquée

Quelqu'un pourrait trouver cela utile.