Bonjour,
Je shoote des vidéos en MTS. Quand je filme la nuit/dans des ambiances sombres, j'obtiens un peu de bruit, mais rien de très gênant.
Seulement, dès que j'encode la vidéo en mp4 avec h264 ou h265, ça devient très moche, avec pas mal de gros carrés, etc.
Alors, par exemple, pour une vidéo de 150Mo en MTS, j'obtiens une vidéo de 17Mo avec x264 et 3,5Mo avec x265…
C'est assez impressionnant, quoique très long à encoder (7 minutes pour 55 secondes de vidéo avec mon processeur, un G3320 d'Intel), mais je trouve ça même "trop impressionnant".
J'ai fait plusieurs tests, mais je n'ai rien trouvé de concluant me permettant d'obtenir une qualité proche du MTS tout en encodant (et pouvoir travailler avec les vidéos plus facilement). Dès qu'il fait sombre, ça perd vraiment en qualité.
Quelqu'un a des astuces ? :)
# Petite solution :
Posté par Stinouff . Évalué à 0.
Utiliser un bitrate constant avec l'option CRF.
Le fichier produit peut être très gros (sans perte, jusqu'à 10 fois mon fichier MTS).
[^] # Re: Petite solution :
Posté par xcomcmdr . Évalué à 2.
Ce n'est pas un bitrate constant (mauvais pour la qualité, mauvais pour la taille du fichier), mais un facteur de compression constant.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Petite solution :
Posté par Stinouff . Évalué à 1.
Ok, merci pour la précision ! :)
# Quel est la compression du fichier d'origine?
Posté par Christophe --- . Évalué à 1.
Bonjour,
Si j'en crois notre amis Wikipedia, le MTS c'est du MPEG2 qui peut contenir soit du h.262, du h.264 ou du VC-1;
Ce serait une bonne idée de commencer par savoir ce que tu as dans ta vidéo d'origine: format et bitrate.
Ceci connu, il faut savoir que le bruit est en général un gros problème à compresser, donc si tu connais un programme avec un bon algo de réduction du bruit ça devrait aider si tu veux vraiment de petits fichiers à la fin (non, je n'en connais pas, sinon je n'aurais pas manqué de les partager ici).
Pour ce qui est du choix de la compression, il y a plusieurs possibilités:
- viser un bitrate (constant ou variable), donc connaitre celui d'origine et par une règle de 3 tu peux estimer la taille du fichier d'origine, et seuls des essais te permettrons ensuite de trouver un bitrate correct pour ton cas;
- fixer une "qualité" (le terme n'est pas correct, mais reflète l'idée, c'est le CRF proposé ci-dessus), ce qui est moins bien mais une fois trouvé la valeur qui va bien pour ton cas ça peut fonctionner (il te faudra donc aussi faire des essais);
La doc de ffmpeg suggère pour le CRF des valeurs entre 18 et 28, mais dans ton cas (vidéo sombre + bruit), faudra peut-être descendre plus bas?
Vu les temps de compression que tu annonce, je te suggère de limiter la compression à ~10 secondes de vidéo tant que tu n'a pas trouvé la config qui va bien…
[^] # Re: Quel est la compression du fichier d'origine?
Posté par xcomcmdr . Évalué à 2.
Euh non justement, c'est viser une qualité qui est meilleure que de viser un bitrate constant.
La qualité vidéo sera meilleure si l'encodeur peut s'adapter.
Par ailleurs, le bitrate constant est en désuétude depuis deux décennies parmi les encodeurs vidéos. A part de vieux encodeurs, plus personne ne le propose (et à raison).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Quel est la compression du fichier d'origine?
Posté par Christophe --- . Évalué à 1.
Ah, il va falloir choisir: tu veux que l'encodeur s'adapte ou tu veux lui fixer un setting?
Si j'avais pris la peine de mettre «qualité» entre guillemets, c'est parce que la notion de qualité est subjective et que les algo de compressions n'ont pas encore de self-learning neural networks pour en juger (ça fait des points au business loto).
Ce que l'on appelle «qualité» dans les algorithmes actuels, cela correspond surtout au «quantifier» à utiliser. C'est lui qui détermine la quantité d'information que l'on va accepter de jeter pour réduire le besoin en bande passante.
Fixer le quantifier, en théorie ça n'est pas terrible car tu assume qu'un seul quantifier est valable pour toute la vidéo, ce qui n'est pas optimal: tu veux probablement un quantifier plus précis sur les détails et un moins précis sur les zones homogènes.
C'est pourquoi les compresseurs modernes proposent en pratique de viser un quantifier moyen et de les laisser s'adapter. Ce qui nous ramène au point de départ: quel est le bon quantifier à choisir? car cela dépend beaucoup de la vidéo en entrée, avec l'exemple flagrant de Stinouff: les settings par défaut sont très bien… sauf dans le cas de sa vidéo bruité!
Enfin pour les bitrate, s'il est vrai que le constant (CBR) a disparu c'est parce que le coût de compression pour bien le respecter est faramineux, et le VBR permet d'arriver au même résultat pour bien moins cher.
Il y a 2 cas pour lesquels un bitrate est tout de même plus important: pour les DVD/BD, car il y a le débit max du lecteur à respecter, et descendre en dessous veut dire une sous utilisation de l'espace disponible, donc pas la meilleur qualité auquel le cinéphile s'attend; et le streaming (internet, mais aussi TNT, satellite, …), pour lequel un débit est disponible, il n'est aussi pas possible de le dépasser, et hors internet remplir la bande passante inutilisée n'est pas souhaitable à cause de son coût à rentabiliser.
Deux applis certes mineures mais qui font que les normes prévoient en premier un bitrate et pas une qualité, et qui font que tous les codecs proposent un réglage par bitrate.
Mais je crois que je viens de faire un TL qui va finir en DR.
[^] # Re: Quel est la compression du fichier d'origine?
Posté par xcomcmdr . Évalué à 1.
On parle d'archivage.
Tu confonds les cas d'usage. Ça n'avance en rien le schmilblick.
Mais si ça t'amuse…
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Quel est la compression du fichier d'origine?
Posté par xcomcmdr . Évalué à 2.
Mais je suis sûr que tu vas encore prendre un malin plaisir à me faire dire ce que je n'ai pas dit.
Soupir, linuxfr… C'était mieux avant
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Quel est la compression du fichier d'origine?
Posté par Christophe --- . Évalué à 1.
Apparemment tu as pris mon message pour un attaque, et je te prie de m'en excuser car ce n'était pas mon but, seulement de faire avancer la discussion.
Maintenant, je vais quand même rajouter un peu de réflexion car le sujet m'intéresse, mais dans le cas d'archivage choisir une «qualité» ne me semble pas non plus la meilleure option: soit tu dispose d'un espace infini et dans ce cas mieux vaux partir sur du «lossless», soit tu as un espace fini et dans ce cas il vaux mieux contrôler la taille de tes fichiers, donc… choisir un bitrate et laisser le compresseur faire au mieux pour tenir la spec de taille.
Et comme je ne peux pas m'empêcher de taquiner, je te ferais remarquer que dans le sujet de Stinouff il n'est pas question d'archivage mais de travailler les vidéos, ce qui suggère donc plutôt en théorie du lossless.
Mais pragmatiquement tu as raison, dans ce cas un choix de «qualité» sera probablement la meilleure option.
[^] # Re: Quel est la compression du fichier d'origine?
Posté par Stinouff . Évalué à 2.
Merci pour ces éclairages intéressants.
Voici les éléments que me donne le logiciel mediainfo :
J'ai filmé avec un appareil A5000 avec un bitrate maximum de 24.0 Mb/s (d'où l'appellation Blu-ray Video, je pense).
Le Format est donc AVC, qui correspond à du H264 si j'ai bien compris. Autrement dit et seulement si j'ai bien compris, je n'ai pas besoin de réencoder chaque fichier ? Je le faisais (via un script).
J'avais l'habitude de filmer en 30 FPS, mais j'ai l'impression que la qualité supérieure (24 MB contre 17 MB d'ordinaire, selon mes réglages), fait sauter quelques images par seconde. Rien de gênant, mais je suis un peu surpris, j'espère ne pas regretter mon choix.
General
ID : 0 (0x0)
Complete name : 00333.MTS
Format : BDAV
Format/Info : Blu-ray Video
File size : 16.6 MiB
Duration : 6 s 210 ms
Overall bit rate mode : Variable
Overall bit rate : 22.3 Mb/s
Maximum Overall bit rate : 24.0 Mb/s
Video
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Format settings, GOP : M=2, N=13
Codec ID : 27
Duration : 6 s 160 ms
Bit rate mode : Variable
Bit rate : 21.1 Mb/s
Maximum bit rate : 22.0 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Interlaced
Scan type, store method : Separated fields
Scan order : Top Field First
Bits/(Pixel*Frame) : 0.408
Stream size : 15.5 MiB (94%)
Audio
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : 129
Duration : 6 s 240 ms
Bit rate mode : Constant
Bit rate : 256 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 spf)
Bit depth : 16 bits
Compression mode : Lossy
Delay relative to video : -80 ms
Stream size : 195 KiB (1%)
Text
ID : 4608 (0x1200)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144
Duration : 5 s 655 ms
Delay relative to video : -80 ms
[^] # Re: Quel est la compression du fichier d'origine?
Posté par Christophe --- . Évalué à 2.
Je peux me tromper, mais quand je voie les débits en jeu, je soupçonnerais que tu as une carte SD de classe C4, ce qui fait qu'a 24Mb/s elle à le temps d'écrire, mais si tu passes de 25 à 30 fps, en supposant que ton appareil soit réglé sur une qualité constante plutôt qu'un bitrate, alors le surcout en bande passante nécessaire (x1.2 théorique, x1.4 d'après tes chiffres) fait que la carte n'a pas le temps de suivre, et ton appareille jette quelques images pour compenser. Mais ça n'est pas la seule raison possible.
Effectivement, vu que tu fait cela pour travailler les fichier, j'aurais tendance à abonder dans ton sens en disant que ça n'est pas la peine de ré-encoder les fichiers, surtout si ton logiciel les accepte.
Si tu a envie de continuer tout de même quelques essais, ce serait de viser déjà un bitrate/2 en restant en x264 (le gain en x265 n'en vaut pas la peine tant que ça n'est pas du final, à cause des surcouts de compression et décompression) et voir ce que cela donne sur les images les plus bruitées, donc ici un VBR=11Mb/s en restant en h264 pour comparer; et selon le résultat essayer 11/2 (si ok) ou (11+22)/2 (si pas ok).
[^] # Re: Quel est la compression du fichier d'origine?
Posté par Stinouff . Évalué à 1. Dernière modification le 27 août 2017 à 22:48.
A priori, la carte est une class 10 (Une Sandisk 40 MB/s).
Je pense plutôt à une limite de mon appareil que de la carte SD, pour être franc ! C'est un peu gênant car j'utilise deux appareils, dont l'un produit des images en 30 FPS, mais bon, je verrai.
Pour le MTS, j'ai surtout de mauvais souvenirs avec KDENLIVE (plantages récurrents, lectures tronquées, lourdeur…)…En gérant plus de 500 vidéos dans un projet, ça fait beaucoup pour mon "petit PC".
Au final, ce sera de toute façon du H264 avec assez peu de réglages permis dans KDENLIVE, mais j'avoue que c'est aussi ma curiosité qui m'a fait poser la question. J'aime bien savoir ce que je fais et les conseils des gens sont toujours les bienvenus. De leur façon de penser à leurs connaissances. Par ailleurs, non, c'était plutôt un "NTLR". ;)
Ok, je vais tester en 11, puis en 16/17 MB/s. D'où te viennent ces "protocoles de test" ? Simple suggestion ?
[^] # Re: Quel est la compression du fichier d'origine?
Posté par Christophe --- . Évalué à 1.
Je suis d'accord avec toi, avec ta carte ça devrait passer à l'aise. La deuxième piste que j'avais en tête serait du côté de l'utilisation mémoire dans ton appareil avec cause du débit; si tu as moyen de régler cela ce serait intéressant de voir si en baissant le bitrate (par ex 22->18) tu obtiens moins de framedrop?
Si ce qui gène kdenlive c'est le MTS mais pas le h246, une solution possible serait de faire une conversion du conteneur mais sans recoder les flux audio et vidéo (par ex. avec ffmpeg:
-c:v copyet-c:a copy), ça devrait être rapide et ça évite de dégrader les flux.Pour les 500 vidéos, je comprend que ce soit un peu lourd, même si je doute que ce soit une limite volontaire de l'outil; la solution que j'aurais pris dans ce cas c'est de faire le boulot en plusieurs fois, en rassemblant par exemple déjà les vidéos par paquet de 20, mais cela suppose que ce soit compatible avec ton utilisation…
Enfin, pour le protocole de test, cela vient d'une habitude (déformation professionnelle?) qui consiste à avancer par dichotomie: si le bitrate de départ est à X, on se met à mi-chemin entre X et 0, donc X/2. On regarde le résultat, et on continue à mi-chemin: si le résultat était bon, on prend la plage basse (0-X/2 donc X/4), sinon la plage haute (X/2-X donc X/2+X/4), et ainsi de suite jusqu'à trouver la limite. C'est un algo assez classique pour arriver le plus rapidement possible à la solution dans ce genre de cas.
[^] # Re: Quel est la compression du fichier d'origine?
Posté par Stinouff . Évalué à 2.
De source sûre, je suis à 30 images par seconde en 17 MB/s ; en-dehors du bitrate maximal, je n'ai rien changé sur l'appareil.
Cela ne me surprend qu'à moitié. J'aurais aimé être prévenu par l'appareil de manière claire car quelques vidéos, en 25 FPS, sont légèrement indigestes, notamment lors de travellings.
Je te remercie pour les suggestions très pertinentes et je suis ravi d'avoir eu les mêmes. La conversion du conteneur s'est passée rapidement. Restent quelques fichiers très lourds passablement gênants mais que je trierai au cas par cas.
Ta progression par dichotomie est très intéressante ; le pifomètre se révèle parfois heureux, mais la technique s'est révélée, à l'usage, plutôt précise et peu chronophage. J'ai pu, au cas par cas, tester quelques vidéos et le bitrate moyen est à 11Mb/s, avec quelques vidéos descendant à 8Mb/s quand d'autres réclamaient jusqu'à 16 Mb/s.
En tout cas, j'ai appris à faire varier le bitrate plutôt proprement selon mon propre et humble avis.
Merci pour l'aide apportée.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.