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 copy et -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 Christophe --- . En réponse au message x265 - vidéo sombre.. É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.