Nouvelle application : PTvM Ts Checker.

Section consacrée aux produits dérivés publiés en association avec Pouchin TV Mod

Nouvelle application : PTvM Ts Checker.

Messagepar Gingko » 04 Aoû 2011, 23:26

Bonjour,

J'ai l'honneur de vous soumettre, ici, la première version d'une nouvelle application nommée PTvM Ts Checker.

Le rôle de cette application est de vérifier l'intégrité des fichiers Mpeg2 Transport Stream (« TS ») générés par Pouchin TV Mod (ou bien par n'importe quelle autre application capable de générer des fichiers au même format), et de repérer les endroits précis du fichier où des erreurs existent.
L'application est également capable de générer un fichier projet VideoRedo avec les emplacement des erreurs repérés.

Une documentation plus complète existe dans l'application elle-même, en utilisant la commande d'« Aide ».

PTvM-Ts-Checker-(Fr).png
Image de l'interface de l'application
PTvM-Ts-Checker-(Fr).png (14.6 Kio) Vu 5211 fois

Une version en langue anglaise de cette application est également disponible.

TsChecker_fr_1.0.0.300.zip
PTvM Ts Checker version 1.0.0.300, en français, dans un fichier .zip.
(147.38 Kio) Téléchargé 277 fois

Gingko
Gingko
․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․
Tuners utilisés, sur 3 ordis : • USB : AverMedia HDTV DVB-T Volar (2×) • PCI : Hauppauge Nova-DT Dual DVB-T • Express Card : AverMedia Digi Express 54
Avatar de l’utilisateur
Gingko
Administrateur du site et développeur
 
Messages: 1950
Enregistré le: 05 Aoû 2007, 12:57
Localisation: Pantin (IDF, 93)

Re: Nouvelle application : PTvM Ts Checker.

Messagepar r0lZ » 05 Aoû 2011, 08:40

Très intéressant! Merci!

J'apprécie particulièrement les options "-bv" de la ligne de commande. C'est exactement ce qu'il manquait à PVAStrumento! Un tout grand merci!

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.)

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'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.

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é.

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.

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.

Ce sont des problèmes vraiment mineurs, et ne sont pas des critiques, mais des suggestions pour simplifier la lecture du log et l'utilisation du projet VideoRedo.

Je suis en tous cas extrêmement satisfait d'avoir la possibilité de tester facilement un fichier TS en mode batch! Plus besoin de bricoler avec PVAStrumento!
Merci encore!
r0lZ
Win7 x64 SP1, Asus My Cinema PS3-100 (PCI) et Genius TVGo DVB-T03 (USB), émetteur TNT de Wavre (Belgique)
r0lZ
 
Messages: 110
Enregistré le: 03 Fév 2011, 15:15

Re: Nouvelle application : PTvM Ts Checker.

Messagepar Gingko » 05 Aoû 2011, 10:17

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
Gingko
․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․ ․
Tuners utilisés, sur 3 ordis : • USB : AverMedia HDTV DVB-T Volar (2×) • PCI : Hauppauge Nova-DT Dual DVB-T • Express Card : AverMedia Digi Express 54
Avatar de l’utilisateur
Gingko
Administrateur du site et développeur
 
Messages: 1950
Enregistré le: 05 Aoû 2007, 12:57
Localisation: Pantin (IDF, 93)

Re: Nouvelle application : PTvM Ts Checker.

Messagepar r0lZ » 05 Aoû 2011, 11:28

Merci pour cette très complète réponse.
Gingko a écrit:... 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. :)

Absolument d'accord avec vous. Ça fonctionne déjà très bien.

Gingko a écrit:
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.

Excellent! Cela dit, ça ne supprime pas pour autant l'intérêt d'avoir une option de post-processing. Par exemple, j'ai écrit un script qui utilise ComSkip pour détecter les pubs et les ajouter au fichier VPRJ (sous forme de zones à retirer, et non pas de marqueurs de scènes). Pour le moment, je suis obligé d'utiliser l'option de PTVM Quitter l'application à la fin de l'enregistrement, et mon script vérifie toutes les 10 secondes si la fenêtre de PTVM est toujours ouverte. Quand ce n'est plus le cas, il recherche les nouveaux fichiers dans le dossier d'enregistrement, et s'il y en a, il lance le processing. Ce serait tellement plus facile (et plus fiable) de pouvoir lancer ce script depuis PTVM, en lui passant le nom de fichier enregistré en argument!

Gingko a écrit: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é.
OK, j'ignorais ça. Je retire ce que j'ai dit! C'est parfait comme ça!

Gingko a écrit:
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.
Well, l'enregistrement commence largement après que le tuner soit initialisé et que la chaîne soit sélectionnée (car en général, je lance les enregistrements via le guide, après avoir sélectionné la chaîne que je désire enregistrer). Je supposais donc que PTVM n'avait plus qu'a sauvegarder le fichier à partir de l'heure de début d'enregistrement, sans avoir besoin de réinitialiser quoi que ce soit. Quoi qu'il en soit, ces erreurs sont bien réelles chez moi, mais ma suggestion de virer les marqueurs n'est pas des plus importantes!

Gingko a écrit: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.

Je comprends. OK, mais alors, dans ce cas, peut-être serait-il bon d'ajouter une option "Mettre les marqueurs 1 seconde plus tôt". Ce serait très pratique, et on aurait la garantie que l'erreur serait de toutes façons peu après le marqueur.

Gingko a écrit:Ceci étant dit, si vous avez envie de recompiler à partir du code source...

Ne serait-il pas plus facile pour tout le monde d'ajouter un petit fichier INI avec la valeur à utiliser? Même si j'avais un compilateur sous la main (ce qui n'est pas le cas), il me semble compliqué de recompiler chaque fois qu'on veut changer la valeur, et ça risque d'arriver souvent lors des tests.
Et vous pourriez inclure dans l'INI l'option "Mettre les marqueurs 1 seconde plus tôt", et même permettre facilement de régler ce "temps d'avance". Peut-être y a t'il d'autres options "avancées" qu'il pourrait être intéressant d'y ajouter également.
Comme l'INI pourrait très bien se trouver dans le même directory que l'app, puisque elle ne ferait que le lire, ce devrait être facile, non?
r0lZ
Win7 x64 SP1, Asus My Cinema PS3-100 (PCI) et Genius TVGo DVB-T03 (USB), émetteur TNT de Wavre (Belgique)
r0lZ
 
Messages: 110
Enregistré le: 03 Fév 2011, 15:15


Retourner vers Produits dérivés

Qui est en ligne

Utilisateurs parcourant ce forum : Aucun utilisateur enregistré et 1 invité

cron