Capture video en FFV1 artefacts

Capture video en FFV1 artefacts - Traitement Vidéo - Video & Son

Marsh Posté le 21-05-2014 à 16:46:15    

Salut.
Je voulais faire de la capture video en lossless avec Dxtory pour l'instant je capture avec le codec Lagarith je trouve qu'il a des performances excellentes et je peux enregistrer en 1080@60fps sans problèmes.
Je voulais donc essayer le codec FFV1 réputé plus lent mais avec un ration de compression supérieur. Mais même quand j'essais d'enregistrer à 15 fps il y a des artefacts partout et la video est illisible je ne comprends pas d'où ça vient. Je sais que le codec Lagarith est plus rapide mais capturer en FFV1 à 30 fps ça devrait pourtant être possible non ?
Dans Dxtory je choisi "ffdshow video codec" en suite je choisi FFV1, espace de couleur YV12 coder type VLC (je sais pas la différence entre VLC et AC si on pouvait m'expliquer au passage), context model small (là aussi je sais pas ce que ça change entre small et large).
Merci de votre aide.
 
Edit: je crois que le codec n'est en faite pas assez performant pour de la capture en temps réel mais j'aimerais avoir une confirmation.


Message édité par aresias le 21-05-2014 à 17:28:54
Reply

Marsh Posté le 21-05-2014 à 16:46:15   

Reply

Marsh Posté le 21-05-2014 à 21:12:18    

Je ne sais pas d'où vient ton problème mais tu peux tenter de convertir ta capture Lagarith en FFV1, ça évitera les éventuels problèmes liés à la capture en temps réel et tu gagneras de la place. Mais ça fait une opération en plus par rapport à une capture faite directement en FFV1.
Sinon je vois une alternative au FFV1, le x264 en mode intra-frame : il faut encoder en ajoutant ce paramètre : --keyint 1. Ça définit la taille des GOP, donc 1 = uniquement des keyframes.
Mais il faut aussi spécifier le débit ou la qualité (paramètre crf), ce n'est pas comme le DV (codec intra-frame) qui a un débit fixe.

Message cité 1 fois
Message édité par arnuche le 21-05-2014 à 21:26:22
Reply

Marsh Posté le 21-05-2014 à 21:26:06    

hum, donc si j'ai que des keyframe je vais pas avoir de problèmes quand je vais vouloir éditer la video ?
Par contre je crois pas que ce soit possible d'avoir du "vrai" lossless comme avec le Lagarith et le FFV1 si ? (même si je change d'espace de couleur je perds juste en précision des couleurs mais ça c'est pas grave).
Edit: ah ben tu as édité ton message il y a donc un CRF à mettre et je vais perdre pas mal en qualité je pense.


Message édité par aresias le 21-05-2014 à 21:27:03
Reply

Marsh Posté le 21-05-2014 à 21:35:23    

J'ai édité mon message précédent pour apporter une précision.
Et pour ta dernière question, j'ai un doute ; apparemment il y a moyen de faire du x264 lossless en mettant --qp 0 ;
https://trac.ffmpeg.org/wiki/x264En [...] slessH.264
Mais je ne sais pas si dans ce cas il faut tout de même mettre --keyint 1.
Faut voir aussi s'il supporte autre chose que le yv12.

Reply

Marsh Posté le 21-05-2014 à 21:39:09    

OK merci j'essayerai ça à l'occasion. Pour le YV12 c'est bon j'ai pas besoin d'avoir du RGB, même les Blu-ray sont "seulement" en YV12.

Reply

Marsh Posté le 21-05-2014 à 23:21:21    

Apparemment il existe une astuce avec Avisynth pour encoder du RGB (ou du yuy2) en x264 (qui ne supporte que le yv12) ; ça consiste à séparer l'image en 3 couleurs primaires et à les mettre les unes à côté des autres, donc on obtient une image 3 fois plus large (ou plus haute, on a le choix) qui n'est pas regardable, mais c'est juste une solution transitoire si on veut absolument stocker en x264 lossless sans faire de conversion en yv12.
Au final, si on veut retrouver l'image d'origine, il faut ouvrir le fichier x264 avec Avisynth et ré-assembler les 3 couleurs.
 
Autre astuce du même genre à laquelle j'ai pensé pour encoder cette fois de l'entrelacé en x264 lossless (mode qui apparemment ne supporte pas l'entrelacé) ; utiliser la fonction JDL_UnfoldFieldsVertical(flip=true) pour séparer les 2 champs et les assembler dans la même image l'un au dessus de l'autre (donc bien mieux qu'un simple separatefields qui alterne les champs, ce qui pose problème aux filtres temporels qui travaillent dans ce cas sur une image qui vibre). L'image devient donc progressive sans qu'il n'y ait eu désentrelacement. :)  
Ce script très simple et très astucieux a été inventé pour utiliser des filtres avisynth non compatibles avec l'entrelacé.
Mais rien n'empêche d'utiliser cet état transitoire (puisque l'image n'est pas regardable) et de l'encoder en x264 lossless.
Pour que l'image retrouve son état normal, il faut utiliser la fonction JDL_FoldFieldsVertical(flip=true) qui ré-entrelacera les champs.
Voir ce site ;
http://www.avisynth.nl/users/stickboy/
Il faut mettre les fichiers jdl-interlace.avsi et jdl-util.avsi dans le répertoire plugin d'avisynth.

Message cité 1 fois
Message édité par arnuche le 21-05-2014 à 23:22:43
Reply

Marsh Posté le 30-05-2014 à 12:35:42    

arnuche a écrit :

J'ai édité mon message précédent pour apporter une précision.
Et pour ta dernière question, j'ai un doute ; apparemment il y a moyen de faire du x264 lossless en mettant --qp 0 ;
https://trac.ffmpeg.org/wiki/x264En [...] slessH.264
Mais je ne sais pas si dans ce cas il faut tout de même mettre --keyint 1.
Faut voir aussi s'il supporte autre chose que le yv12.


Avec un quantizer à 0, la vidéo encodée risque de prendre une place monstrueuse (je sais, c'est du lossless, mais quand même, il faut le préciser).

Reply

Marsh Posté le 30-05-2014 à 12:40:33    

Oui, mais ceux qui veulent du lossless savent à quoi s'en tenir. Faut voir si c'est plus ou moins qu'en Lagarith. Je suppose que c'est moins sinon je ne vois pas l'intérêt, surtout que le Lagarith est plus facile à éditer (avi oblige).

Reply

Marsh Posté le 30-05-2014 à 12:42:38    

arnuche a écrit :

Apparemment il existe une astuce avec Avisynth pour encoder du RGB (ou du yuy2) en x264 (qui ne supporte que le yv12) ; ça consiste à séparer l'image en 3 couleurs primaires et à les mettre les unes à côté des autres, donc on obtient une image 3 fois plus large (ou plus haute, on a le choix) qui n'est pas regardable, mais c'est juste une solution transitoire si on veut absolument stocker en x264 lossless sans faire de conversion en yv12.
Au final, si on veut retrouver l'image d'origine, il faut ouvrir le fichier x264 avec Avisynth et ré-assembler les 3 couleurs.

 

Autre astuce du même genre à laquelle j'ai pensé pour encoder cette fois de l'entrelacé en x264 lossless (mode qui apparemment ne supporte pas l'entrelacé) ; utiliser la fonction JDL_UnfoldFieldsVertical(flip=true) pour séparer les 2 champs et les assembler dans la même image l'un au dessus de l'autre (donc bien mieux qu'un simple separatefields qui alterne les champs, ce qui pose problème aux filtres temporels qui travaillent dans ce cas sur une image qui vibre). L'image devient donc progressive sans qu'il n'y ait eu désentrelacement. :)
Ce script très simple et très astucieux a été inventé pour utiliser des filtres avisynth non compatibles avec l'entrelacé.
Mais rien n'empêche d'utiliser cet état transitoire (puisque l'image n'est pas regardable) et de l'encoder en x264 lossless.
Pour que l'image retrouve son état normal, il faut utiliser la fonction JDL_FoldFieldsVertical(flip=true) qui ré-entrelacera les champs.
Voir ce site ;
http://www.avisynth.nl/users/stickboy/
Il faut mettre les fichiers jdl-interlace.avsi et jdl-util.avsi dans le répertoire plugin d'avisynth.


Pour encoder l'entrelacé, c'est pas plus simple d'utiliser --no-interlaced dans la ligne de commande x264 ?


Message édité par sebnutt le 30-05-2014 à 12:42:53
Reply

Marsh Posté le 30-05-2014 à 13:59:00    

Faut voir si c'est compatible avec le mode lossless. Mais même si c'est le cas, il y a quand-même un problème : l'encodeur va travailler sur une image qu'il croit progressive alors qu'elle contient 2 champs différents, alors que le mode entrelacé en x264 sert justement à s'adapter à une vidéo entrelacée.
 
A propos de la première partie de mon message (encodage en yuy2 ou rgb), il semblerait que ce soit maintenant possible, donc plus besoin de diviser l'image en 3.
Voilà les 4 espaces de couleur possibles en sortie (il y en a beaucoup plus en entrée), d'après l'aide de x264 ;
i420, i422, i444, rgb
Par défaut c'est i420 (réglage --output-csp).

Reply

Marsh Posté le 30-05-2014 à 13:59:00   

Reply

Marsh Posté le 31-05-2014 à 10:21:56    

mhouais, je sais pas trop si le x264 peut être utilisé pour faire l'editing sans avoir de problèmes.
Par contre personne a répondu à ma question initiale. Est-ce que j'arrive pas à capturer en FFV1 parce que le codec est trop lent pour du temps réel ?


Message édité par aresias le 31-05-2014 à 10:22:20
Reply

Marsh Posté le 31-05-2014 à 11:52:57    

Ma première réponse reste valable ;

arnuche a écrit :

Je ne sais pas d'où vient ton problème mais tu peux tenter de convertir ta capture Lagarith en FFV1


Difficile de savoir pourquoi tu as ce problème.

Reply

Marsh Posté le 03-06-2014 à 13:40:28    

je peux utiliser quel logiciel gratuit pour convertir. Un qui accepte tous les codecs installé sur le PC ?
Si j'essais avec "AVIMux" présent dans DXtory j'ai une erreur "Builder.init error 4000FFFF Problème réglé ça vient de codecs audio manquants j'ai plus l'erreur mais ça n'encode pas quand même :S
et AVS video converter me dis que le codec est manquant il arrive pas à lire le Lagarith pourtant bien installé >.<


Message édité par aresias le 03-06-2014 à 15:05:46
Reply

Marsh Posté le 03-06-2014 à 15:59:01    

Vu qu'on peut visiblement mettre du FFV1 dans le conteneur AVI*, tu peux tenter le coup avec Virtual Dub, il reconnaît bien le Lagarith.
 
* marqué là ;
http://en.wikipedia.org/wiki/FFV1
 
Et pour ouvrir du FFV1 (et plein d'autres formats) avec Virtual Dub, il peut être utile d'installer le plugin FFMpeg Input ;
http://fr.sourceforge.jp/projects/ [...] putplugin/
Il faut mettre le fichier .vdplugin et le répertoire ffdlls (contenant des dll) dans le dossier plugins32 de Virtual Dub.
Pour ouvrir le fichier, il faut aller dans File, Open video file, Files of type (fichiers de type) et choisir FFmpeg supported files.

Reply

Marsh Posté le 03-06-2014 à 18:00:43    

Il me dit qu'il peut pas décompresser le format d'entrée et que je dois cocher "forcer YUY2" dans les propriétés du codec.
Je trouve pas où c'est.
Ou de sélectionner un format video d'entrée différent dans video > color depht.
Pourtant je peut me déplacer dans la video en cliquant sur la time line ça marche nickel je vois les images partout mais je peux pas faire lecture :/
 
Edit: Je vois bien tous les codecs quand je choisis mon codec de sortie donc ça détecte bien tous les codecs.

Message cité 1 fois
Message édité par aresias le 03-06-2014 à 18:15:29
Reply

Marsh Posté le 03-06-2014 à 18:42:21    

Bon j'arrive à encoder quand même la video.
Par contre je viens de tester un encodage FFV1 VLC et contexte Large. La video prend un peu moins de place que le Lagarith par contre j'arrive même pas à la lire en temps réel ! 1080p 60fps.
Mais je viens de lire sur le net que le mode AC serait plus rapide en plus de mieux compresser donc là je vais faire un 2ème encodage pour comparer.
 
Edit: OK avec le mode AC je gagne encore en compression par contre mon i5 4670k@4.2Gz n'arrive pas à lire la video en temps réel T.T
les videos sont en 1080p 60 images/s YV12 et durée de 2 minutes 42 secondes
Lagarith: 9.43Go
réencodage du Lagarith vers FFV1 contexte Large encoder VLC: 9.11Go
réencodage du Lagarith vers FFV1 contexte Large encoder AC: 8.74Go

Message cité 1 fois
Message édité par aresias le 03-06-2014 à 19:00:50
Reply

Marsh Posté le 03-06-2014 à 19:00:50    

aresias a écrit :

Il me dit qu'il peut pas décompresser le format d'entrée et que je dois cocher "forcer YUY2" dans les propriétés du codec.
Je trouve pas où c'est.
Ou de sélectionner un format video d'entrée différent dans video > color depht.


Je n'ai jamais eu ça, normalement on ne touche au codec que pour l'export, pas pour la lecture.

Reply

Marsh Posté le 03-06-2014 à 19:02:40    

aresias a écrit :

Edit: OK avec le mode AC je gagne encore en compression par contre mon i5 4670k@4.2Gz n'arrive pas à lire la video en temps réel T.T
les videos sont en 1080p 60 images/s YV12 et durée de 2 minutes 42 secondes
Lagarith: 9.43Go
réencodage du Lagarith vers FFV1 contexte Large encoder VLC: 9.11Go
réencodage du Lagarith vers FFV1 contexte Large encoder AC: 8.74Go


Dans ce cas, si tu lis sans problème le Lagarith, autant rester dans ce format vu que tu ne gagnes pas beaucoup de place en FFV1.

Reply

Marsh Posté le 03-06-2014 à 19:06:39    

Ouais je suis déçu. Je savais que le FFV1 demandait plus à la fois en encodage et en décodage mais là la différence est tellement énorme niveau performances...
Le Lagarith est vraiment le meilleur codec lossless.

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed