h264 codage sans perte
Est-il possible de le faire totalement sans perte de l'encodage en h264? Par lossless, je veux dire que si je lui donne une série de cadres et que je les encode, et puis si j'extrait tous les cadres de la vidéo encodée, j'obtiendrai exactement les mêmes cadres que dans l'entrée, pixel par pixel, image par image. Est-ce réellement possible? Prenez cet exemple:
je génère un tas de cadres, puis j'encode la séquence d'image en AVI non compressé( avec quelque chose comme virtualdub), j'applique ensuite le h264 sans perte (les fichiers d'aide prétendent que le fait de définir --qp 0 rend la compression sans perte, mais je ne suis pas sûr que cela signifie qu'il n'y a pas de perte à n'importe quel point du processus ou que juste la quantification est sans perte). Je peux ensuite extraire les images de la vidéo h264 résultante avec quelque chose comme mplayer.
j'ai essayé avec le frein à main en premier, mais il s'avère qu'il ne supporte pas l'encodage sans perte. J'ai essayé x264 mais il s'écrase. C'est peut-être parce que mon fichier AVI source est dans l'espace Coloré RGB au lieu de YV12. Je n'ai pas savoir comment alimenter une série de bitmaps YV12 et dans quel format à x264 de toute façon, donc je ne peux même pas essayer.
En résumé ce que je veux savoir si c'est là un moyen d'aller d'
série de bitmaps sans perte (dans n'importe quel colorspace) -> une certaine transformation -> h264 encodage -> h264 décodage -> une certaine transformation -> la série originale de bitmaps sans perte
S'il y a un moyen d'y parvenir?
EDIT: il y a un point très valable à propos de lossless H264 ne faisant pas trop beaucoup de sens. Je suis bien conscient qu'il n'y a aucun moyen que je puisse dire (avec juste mes yeux) la différence entre et clip non compressé et un autre comprimé à un taux élevé dans H264, mais je ne pense pas qu'il n'est pas sans utilisations. Par exemple, il peut être utile pour stocker la vidéo pour l'édition sans prendre d'énormes quantités d'espace et sans perdre la qualité et en dépensant trop de temps d'encodage chaque fois que le fichier est enregistré.
mise à jour 2: maintenant x264 ne crash pas. Je peux utiliser comme sources soit avisynth ou yv12 lagarith sans perte (pour éviter l'avertissement de compression de l'espace coloré). Cependant, même avec --qp 0 et une source RGB ou yv12, j'obtiens quand même quelques différences, minimes mais présentes. Cela est troublant, car toutes les informations que j'ai trouvées sur lossless predictive coding (--qp 0) affirment que l'encodage entier devrait être sans perte, mais je ne suis pas en mesure de le vérifier.
8 réponses
je vais ajouter une réponse tardive à celle-ci après avoir passé toute la journée à essayer de trouver comment obtenir YUV 4:4 pixels dans x264. Alors que x264 accepte les pixels raw 4:2:0 dans un fichier, il est très difficile d'obtenir des pixels 4:4:4 passés. Avec les versions récentes de ffmpeg, les travaux suivants pour l'encodage et l'extraction complètement sans perte pour vérifier l'encodage.
tout d'abord, écrivez votre yuv brut de 4:4:4 pixels à un fichier dans un format planaire. Les plans sont un ensemble D'octets Y, alors les octets U et V où u et V utilisent 128 comme valeur zéro. Maintenant, invoquer ffmpeg et passer dans la taille des cadres bruts de YUV comme utiliser le format de pixel" yuv444p " deux fois, comme ceci:
ffmpeg -y -s 480x480 -pix_fmt yuv444p -i Tree480.yuv \
-c:v libx264 -pix_fmt yuv444p -profile:v high444 -crf 0 \
-preset:v slow \
Tree480_lossless.m4v
une fois que l'encodage à h264 et l'empaquetage comme un fichier Quicktime est fait, on peut extraire les mêmes octets comme ceci:
ffmpeg -y -i Tree480_lossless.m4v -vcodec rawvideo -pix_fmt yuv444p \
Tree480_m4v_decoded.yuv
Enfin, vérifiez les deux fichiers binaires avec diff:
$ diff -s Tree480.yuv Tree480_m4v_decoded.yuv
Files Tree480.yuv and Tree480_m4v_decoded.yuv are identical
il suffit de garder à l'esprit que vous devez écrire les octets YUV à un fichier vous-même, ne pas laissez ffmpeg faire n'importe quelle conversion des valeurs YUV!
Si x264 ne l'encodage sans perte, mais n'aime pas votre format d'entrée, alors votre meilleur pari est d'utiliser ffmpeg pour traiter le fichier d'entrée. Essayez de commencer par quelque chose comme
ffmpeg -i input.avi -f yuv4mpegpipe -pix_fmt yuv420p -y /dev/stdout \
| x264 $OPTIONS -o output.264 /dev/stdin
et ajouter des options à partir de là. YUV4MPEG est un format sans perte non compressé adapté à la mise en réseau entre différents outils vidéo; ffmpeg sait l'écrire et x264 sait le lire.
Je ne connais pas vos besoins en compression et décompression, mais un archiveur polyvalent (comme 7-zip avec LZMA2) devrait pouvoir compresser aussi petit ou, dans certains cas, même beaucoup plus petit qu'un codec vidéo sans perte. Et c'est beaucoup plus simple et plus sûr qu'une chaîne de traitement vidéo. L'inconvénient est la vitesse beaucoup plus lente, et que vous devez extraire avant de le voir. Mais pour les images, je pense que vous devriez essayer.
il y a aussi l'image sans perte formats, comme .png.
pour encoder lossless RGB avec x264, vous devriez utiliser la version en ligne de commande de x264 (vous ne pouvez pas faire confiance à GUIs dans ce cas, ils vont probablement faire des erreurs) r2020 ou plus récent, avec quelque chose comme ça:
x264 --qp 0 --preset fast --input-csp rgb --output-csp rgb --colormatrix GBR --output "the_lossless_output.mkv" "someinput.avs"
toute perte/différence entre l'entrée et la sortie doit provenir d'une conversion d'espace couleur (soit avant l'encodage, soit lors de la lecture), de mauvais réglages ou de certaines en-têtes/méta-données qui ont été perdues. x264 ne supporte pas RGBA, mais RGB est ok. YUV La compression 4:4: 4 est plus efficace, mais vous perdrez quelques données dans la conversion de l'espace couleur car votre entrée est RGB. YV12 / i420 est beaucoup plus petit, et de loin l'espace de couleur le plus commun en vidéo, mais vous avez moins de résolution chromatique.
Plus d'informations sur les paramètres x264: http://mewiki.project357.com/wiki/X264_Settings
évitez aussi lagarith. Il utilise x87 en virgule flottante... et il y a de mieux alternative. http://codecs.multimedia.cx/?p=303 http://mod16.org/hurfdurf/?p=142
modifier: Je ne sais pas pourquoi j'ai été donwvoted. Laissez un commentaire lorsque vous faites cela.
FFmpeg a un mode "sans perte" pour x264, voir FFmpeg et x264 Guide d'Encodage
essence -qp 0
pour générer un H. 264 sans perte avec GUI Frein À Main, définir le Codec vidéo: H. 264, qualité constante, RF: 0, h. 264 Profil: auto. Bien que ce fichier ne soit pas supporté nativement par Apple, il peut être ré-encodé comme presque sans perte pour la lecture.
fenêtre D'activité de HandBrake GUI:
H. 264 Profile: auto; encodage à RF constant 0.000000... profil haut 4: 4:4 prédictive, niveau 3.0, 4: 2: 0 8-bit
H. 264 profil: élevé; encodage à constante RF 0.000000...lossless nécessite high444 profil, la désactivation...profil, niveau 3.0
si vous ne pouvez pas obtenir la compression sans perte en utilisant un h. 264 encodeur et décodeur, vous pourriez peut-être regarder dans deux solutions:
(1) plutôt que de transmettre toutes les données en H. 264, certaines personnes expérimentent la transmission de certaines données avec un résiduel "côté canal":
- (h.264 fichier) -> décoder le h264 -> transformation -> une perte de rapprochement de la série originale de bitmaps
- (fichier résiduel compressé) --> décodeur - > une série de bitmaps résiduels sans perte
- Pour chaque pixel de chaque image, approximate_pixel + residual_pixel = un pixel bit égal au pixel d'origine.
(2) Utilisez le format de compression vidéo Dirac en mode "sans perte".
je suis d'accord que parfois, la perte de données est acceptable, mais ce n'est pas simplement une question de la façon dont il regarde immédiatement après la compression.
même une perte visuellement imperceptible de données de couleur peut dégrader la séquence de telle sorte que la correction de la couleur, le clavier vert, le suivi, et d'autres tâches de post deviennent plus difficiles ou impossibles, ce qui ajoute des dépenses à une production.
cela dépend vraiment quand et comment vous compressez dans le pipeline, mais en fin de compte, il est logique d'archiver la qualité d'origine, comme le stockage est généralement beaucoup moins cher que reshooting.
ce n'est pas exactement une réponse à votre question, mais plutôt une raison pour laquelle être avec une perte peut être mieux que sans perte.
Voici une comparaison de la même image mais encodée différemment avec un format avec perte et sans perte.
PNG (lossless) 148 kB:
JPEG-8 (lossy) 36 kB:
JPEG-10 (avec perte) 65 kB:
JPEG-12 (lossy) 122 kB:
ouvrez maintenant l'image PNG (sans perte) et L'image JPEG-10 (avec perte) dans deux nouveaux onglets de votre navigateur web. On peut voir une légère différence, mais à peine. Ce que je veux dire, c'est qu'on ne ferait jamais la différence dans la qualité sans les regarder tous les deux en même temps et les examiner de près. Compression sans perte de données n'est pas la peine dans la plupart des cas parce que les formats de perte peuvent vous donner la qualité exacte à un coût moindre (taille du fichier).