r0lZ a écrit :Je propose également une nouvelle option -m, pour lancer le programme Minimisé dans la barre des tâches. En la combinant à -bv, cela permettrait de générer les fichiers VPRJ et log sans être embêté par une fenêtre qui s'ouvre au moment où on s'y attend le moins. (Je sais qu'il est possible de créer un raccourci qui lancerait le programme minimisé, mais ce n'est pas toujours possible si on utilise certains langages de scripting.)
Ok, on va y penser.
De toutes façons, il y a quelques autres trucs à finaliser éventuellement, en fait ça fait déjà un certain temps que j'avais ces applications à peu près fonctionnelles, je me suis finalement décidé à les publier, même si on peut encore y ajouter des choses, considérant qu'il valait mieux avoir des applications complètes à 90 % que pas d'applications du tout.
r0lZ a écrit :Maintenant, s'il était possible d'intégrer cet outil, d'une manière ou d'une autre, à PTVM, pour qu'il vérifie automatiquement le fichier enregistré à la fin de l'enregistrement, ce serait vraiment génial! (J'en profite pour rappeler mon idée d'ajouter une commande de post-processing aux options d'enregistrements.)
J'y pense aussi. Mais si je fais ça, la vérification se fera en temps réel
pendant l'enregistrement, et certainement pas après.
r0lZ a écrit :J'ai également quelques remarques mineures au sujet du log et du fichier VideoRedo.
Pour commencer, dans le log intégré au GUI, je préférerais ne pas voir apparaître les lignes "indicateur d'erreur placé". Je ne vois pas ce qu'elles apportent, puisque l'erreur est décrite, avec le même time code.
Les lignes « indicateur d'erreur placé » correspondent à une indication réelle. Elles indiquent que le tuner a mis un bit précis à 1 dans le paquet, pour indiquer qu'il y a vraisemblablement une erreur dans ce paquet. Même si ce n'est pas nécessairement un cas fréquent, ce type d'erreur peut très bien être la seule indication disponible de l'existence d'une erreur, et le message est ajouté pour
chaque paquet rencontré dans lequel ce bit d'erreur est placé.
r0lZ a écrit :Il y a systématiquement des erreurs au début du fichier (aux time codes 00:00:00.0 et 00:00:00.1), inhérentes au problème de la capture du premier paquet. Comme ces erreurs sont inévitables, je ne pense pas qu'il soit nécessaire de placer un marqueur de scène dans le projet VideoRedo. Cela donne à penser que jamais aucun fichier ne sera correct, et de toutes façons, le début de fichier est généralement coupé.
Systématiquement je ne sais pas, chez moi je rencontre ce cas de figure relativement peu souvent. Je suppose que c'est
votre tuner qui doit « hoqueter » quelque peu au démarrage et induire des défauts de ce genre.
r0lZ a écrit :Il y a d'ailleurs un petit problème avec le fichier VPRJ. En fait, VideoRedo supprime automatiquement le premier paquet (du moins s'il contient des erreurs, ou est incomplet). Peut-être supprime-t'il seulement les B frames qu'il ne peut décoder, je ne sais pas, mais il est certain qu'il supprime des frames (à la différence de Womble). Il n'y a donc PAS d'erreurs visibles au début du fichier, une fois qu'on l'a chargé dans VideoRedo, et ces erreurs ne sont pas non plus présentes si on sauve le fichier vidéo avec VideoRedo, même si on n'a rien changé. C'est donc une erreur d'inclure les erreurs du premier paquet dans le fichier VPRJ. De plus, VideoRedo considère que le fichier qu'il montre commence au time code 0:00:00.0. Or, comme il a supprimé quelques images, les time codes des marqueurs qui suivent sont décalés de ce nombre de frames. Par exemple, je peux voir une erreur au time code 1:03:27:10, mais le marqueur se trouve à 1:03:27:17. Résultat, il est nécessaire de revenir un peu en arrière pour visualiser l'erreur. C'est dommage, car par ailleurs, le checker est extrêmement précis, et trouve même certaines erreurs ignorées par PVAStrumento. Je ne sais pas s'il est possible de calculer le nombre de frames que VideoRedo va automatiquement retirer au début du fichier, en analysant le nombre de B frames ou la longueur du premier paquet, mais si c'était le cas, il serait bon de soustraire ce nombre aux time codes des marqueurs du fichier VPRJ. J'espère vraiment que c'est faisable, car ça faciliterait grandement l'utilisation de l'outil.
Oui, j'ai déjà constaté ce problème. L'ennui est qu'il est difficile à résoudre car il implique de décoder effectivement le contenu des flux audio et vidéo, ce que
PTvM Ts Checker ne fait pas et n'a pas vocation à faire.
Je pense que
VideoRedo (et les autres applications analogues) doivent supprimer tout le contenu jusqu'au premier I-Frame rencontré, ce qui amène un temps de décalage qui doit être, en gros, aléatoirement compris entre zéro et une seconde, puisque les I-Frames se présentent à un intervalle qui est à peu près de cet ordre.
PTvM Ts Checker ne vérifie que l'encapsulation TS et absolument pas les données incluses dans les paquets. Ceci présente l'avantage qu'il devrait fonctionner correctement avec n'importe quel type d'encodage audio et vidéo, puisque la nature de ce contenu ne le concerne pas.
Toute tentative de décodage, même très partiel, outre le fait qu'elle alourdirait considérablement l'application, induirait nécessairement le fait de devoir être programmée séparément pour chaque type de contenu, et ferait quand même en sorte que tous les contenus qui ne sont pas gérés ne pourraient pas être vérifiés.
En plus de cela, notez que tel quel le programme fonctionne aussi parfaitement avec des enregistrements de multiplex complet. Si le contenu devait être analysé, ce type de vérification poserait des problèmes énormes puisque le nombre de paquets à éliminer, nécessairement, ne saurait être le même pour toutes les chaînes du multiplex en même temps.
r0lZ a écrit :Dans le même ordre d'idée, quand plusieurs erreurs se suivent à intervalles très court, le checker pourrait ne placer qu'un seul marqueur de scène pour la série. Après tout, il s'agit d'une aide pour retrouver facilement les erreurs, et pouvoir tester visuellement si l'erreur est visible. On visionnera donc plusieurs secondes de vidéo pour se rendre compte du problème, et il n'est pas nécessaire d'avoir un marqueur à peu près à chaque frame. Cela oblige à cliquer plusieurs fois sur les flèches rouges de VideoRedo pour voyager à la prochaine partie abimée. Je propose donc de ne pas placer de marqueur pour les erreurs qui sont situées dans le même paquet qu'une erreur déjà marquée, ou à moins d'une seconde de l'erreur précédente.
PTvM Ts Checker procède déjà ainsi : du point de vue des marqueurs
VideoRedo, toute erreur distante de moins de
250 mS d'une autre erreur est automatiquement fusionnée avec celle-ci. Autrement, il y aurait beaucoup plus de marqueurs que cela qui seraient générés.
Maintenant, peut-être qu'on peut augmenter cette durée, mais la valeur de
250 mS m'avait jusqu'ici paru assez adéquate.
Ceci étant dit, si vous avez envie de recompiler à partir du code source
(celui-ci est inclus dans un sous-dossier de celui de Pouchin TV Mod dans le référentiel Subversion), pour changer cette valeur, il suffit de remplacer la valeur
250, dans le fichier
vredo_prj.h ligne
38 par la valeur souhaitée exprimée en millisecondes :
Code : Tout sélectionner
bool operator == (const TimeMark & sT2) const {
return _abs64(sT2.nTime - nTime) < 250 * 10000; }
Gingko