Enregistrements corrompus

[Gingko]

Bonjour,

Il y a une autre requête, en ce moment, qui pourrait recouper au moins partiellement celle-ci.

Voir ici.

C'est pourquoi j'aimerais poser une question :

Est-ce que ça fait pareil si on effectue l'enregistrement en mode minimisé (autrement dit, sans affichage, avec l'application réduite dans la barre des tâches) ?

Gingko

[Piteur]

Peux-tu me rappeler quelle version de PTVM tu utilises pour enregistrer ?

0.4~svn-r2:130

Est-ce que le résultat est correct si tu enregistres en TS ?

Pas essayé, n'y voyant pas d'intérêt (je cherche à créer des fichiers gravables pour lecture sur platine de salon).

Est-ce que, pendant ces enregistrements corrompus, l'affichage vidéo reste néanmoins correct ?

Affirmatif : à l'écran, l'image affichée pendant l'enregistrement est impeccable.

Est-ce que ça fait une différence si tu enregistres sans regarder (autrement dit, en minimisant le logiciel dans la barre des tâches, ce qui, accessoirement, a aussi pour effet de désactiver le décodage vidéo, qui n'est alors pas nécessaire ?)

... si du moins est cochée l'option de configuration : "suspendre si minimalisée", non ?

Pas noté de changement.

Par contre, il m'a semblé (je dis bien "semblé", car je n'ai pas fait assez d'essais) que le changement de priorité (en passant de "supérieur à la normale" à "normale" rendait plus rare le problème...

Souhaites-tu que je fasse des tests rigoureux avec minimalisation de la fenêtre (en programmation Windows, ça démarre de toute façon sous la forme minimalisée, non ? Et j'ai constaté les mêmes problèmes !) ?

Question que je me suis posé (en néophyte) : lorsqu'on change de chaîne avec le clavier, il y a toujours un court moment où on voit une pixellisation tout à fait analogue à celle des films mal enregistrés : ne serait-ce pas comme si l'enregistrement démarrait "trop tôt", c'est à dire avant que l'image ne soit stabilisée, et qu'elle n'arrivait pas à se stabiliser ensuite ? -- Bon c'est du n'importe quoi, sans doute, mais pourquoi pas, hein ?

[lolo_32]

C'est vraiment utile de mettre une restriction comme ça sur le serveur FTP ?

Pardon, c'est mon serveur FTP qui met cette restriction, je m'en occupe dès que j'ai une seconde

[Gingko]

Peux-tu me rappeler quelle version de PTVM tu utilises pour enregistrer ?

0.4~svn-r2:130

Est-ce que tu as essayé avec la version expérimentale HD que j'ai mise en ligne ?

Cette version est, en plus de la HD, basée sur le développement le plus récent, qui inclut la correction d'un certain nombre de bugs.

Est-ce que le résultat est correct si tu enregistres en TS ?

Pas essayé, n'y voyant pas d'intérêt (je cherche à créer des fichiers gravables pour lecture sur platine de salon).

Ce serait sympa que tu essaies.
Parce que personnellement, j'y vois au moins l'intérêt de déterminer la cause du problème (ou plus précisément, ici, d'éliminer certaines causes).
Le mieux serait de comparer quelques secondes d'enregistrements du même flux, successivement en TS et en PS.

Les flux TS peuvent être lus par VLC et par Media Player Classic, au minimum. VLC est aussi capable de convertir des flux TS en flux PS. Je connais même au moins un logiciel commercial qui peut prendre des flux TS et produire des fichiers gravables pour lecture sur platine de salon à partir de ceux-ci.

Est-ce que ça fait une différence si tu enregistres sans regarder (autrement dit, en minimisant le logiciel dans la barre des tâches, ce qui, accessoirement, a aussi pour effet de désactiver le décodage vidéo, qui n'est alors pas nécessaire ?)

... si du moins est cochée l'option de configuration : "suspendre si minimalisée", non ?

Effectivement, ça peut aider.

Souhaites-tu que je fasse des tests rigoureux avec minimalisation de la fenêtre (en programmation Windows, ça démarre de toute façon sous la forme minimalisée, non ? Et j'ai constaté les mêmes problèmes !) ?

Au plus on a d'informations, au plus on a de chances de trouver l'origine du problème, alors tous les tests supplémentaires seront bienvenus.

Question que je me suis posé (en néophyte) : lorsqu'on change de chaîne avec le clavier, il y a toujours un court moment où on voit une pixellisation tout à fait analogue à celle des films mal enregistrés : ne serait-ce pas comme si l'enregistrement démarrait "trop tôt", c'est à dire avant que l'image ne soit stabilisée, et qu'elle n'arrivait pas à se stabiliser ensuite ? -- Bon c'est du n'importe quoi, sans doute, mais pourquoi pas, hein ?

Au changement de chaîne, ça fait ça en principe parce que le codec a du mal à se mettre en route. Le choix d'un codec de plus ou moins bonne qualité peut éventuellement augmenter ou réduire ce phénomène.

Le problème dans tes enregistrements tient vraisemblablement au fait que, pour une raison inconnue, certains paquets TS ne sont pas reçus par la fonction de transcodage.

La seule raison que je peux imaginer pour le moment est l'existence de micro-blocages système lors de l'appel de certaines fonctions, qui feraient que le traitement d'un paquet serait trop long pour pouvoir être terminé avant l'arrivée du suivant. Mais ce ne sont que des supputations.

Gingko

[Piteur]

Merci, Gingko, pour tes infos, conseils et suggestions.

Dans l'immédiat :

Codec utilisé : FFDSHOW Video Decoder

Pas une bonne idée ? Réglages ?

[virtualblue]

Bonjour,

je rencontre le même problème, à savoir une très bonne réception en live et une pixelisation à outrance en enregistrement ts ou ps, incompréhensible..

Clé USB intuix S800

[Gingko]

Je n'ai pas vraiment d'explication à ça, pour le moment.

Je ne peux que supputer une situation liée au système, dans laquelle l'écriture dans le fichier prendrait trop de temps, et serait sujette à des blocages ou des délais d'attente tels que des paquets seraient perdus pendant ce temps-là.

Éventuellement, essayez avec cette version-ci, que je vous mets en pièce jointe.

C'est la dernière version du SVN avant l'introduction de la HD, elle corrige quelques bugs de la 130, et elle me semble relativement stable.

Sinon, si par hasard vous en avez la possibilité, je serais curieux de savoir si vous reproduisez ce problème en faisant la même installation sur un autre ordinateur.

Gingko

[virtualblue]

Bonjour et merci pour votre réponse rapide

Je viens d'essayer cette version mais c'est toujours la même chose

J'ai également essayé sur mon portable (core 2 duo T7100 1,8Ghz) et c'est la même chose
Je ne comprends pas...

Cordialement

[Gingko]

Bonjour et merci pour votre réponse rapide

Je viens d'essayer cette version mais c'est toujours la même chose

J'ai également essayé sur mon portable (core 2 duo T7100 1,8Ghz) et c'est la même chose
Je ne comprends pas...

Cordialement

Je suppose que vous avez essayé d'augmenter la priorité de l'application ?

Sur quoi est-ce que vous effectuez l'enregistrement ?
(quel genre de disque dur ... et formaté en NTFS ou FAT32 ?)

Quelle version de Windows utilisez-vous ?

Qu'y a-t-il de commun entre les machines que vous utilisez, qui pourrait différer de ce que d'autres ont habituellement ?

Gingko

[Miguel]

J'ai un petit problème avec l'enregistrement, que ça soit en TS ou PS, en MPEG2 ou H264, l'image est pleine d'artefacts et le son saute parfois.

Ça se produit depuis la version 173 je crois, je ne l'ai jamais remarqué avant.

J'ai essayé divers codec de lecture, différents lecteurs, et ce sont bien les fichiers eux-mêmes qui sont dans cet état.
J'ai aussi essayé divers codecs dans PTVMod, et les trois modes d'affichage, mais c'est toujours pareil.
J'ai essayé sur deux disques dur différents (mon SSD principal et un externe en eSATA), et c'est pareil.

Aussi, j'ai remarqué que si je change de chaîne, le premier enregistrement se fait bien, mais si je change le mode d'affichage (plein écran ou fenêtré sans bord), les enregistrements sont "corrompus" jusqu'à ce que je change de chaîne.

[Miguel]

J'ai un petit problème avec l'enregistrement, que ça soit en TS ou PS, en MPEG2 ou H264, l'image est pleine d'artefacts et le son saute.

Ça se produit depuis la version 173 je crois, je ne l'ai jamais remarqué avant.

J'ai essayé divers codecs de lecture, différents lecteurs, et ce sont bien les fichiers eux-mêmes qui sont dans cet état.
J'ai aussi essayé divers codecs dans PTVMod, et les trois modes d'affichage, mais c'est toujours pareil.
J'ai essayé sur deux disques dur différents (mon SSD principal et un externe en eSATA), et c'est pareil.

Aussi, j'ai remarqué que si je change de chaîne, le premier enregistrement se fait bien, mais si je change le mode d'affichage (plein écran ou fenêtré sans bord), les enregistrements sont "corrompus" jusqu'à ce que je change de chaîne.

Je remonte mon post, car ça concerne cette version encore en développement, et c'est un réel problème, ça se produit seulement sur mon PC portable avec mes deux cartes tuner : une intégrée et l'autre en USB qui sert généralement sur le fixe.

J'ajoute que contrairement à ce que j'ai dit avant, le changement de chaîne ne résoud pas le problème à chaque fois sur le premier enregistrement finalement.
Et aussi que parfois le conteneur TS ou PS est corrompu, je suis obligé de passer par VLC pour réécrire le fichier via une ligne de commande pour que le fichier soit lisible avec d'autres lecteurs.

Ou alors dois-je créer un nouveau topic ?
Si oui, dans la partie développement (vu que c'est apparu avec la version 173 chez moi), ou dans la partie bugs ?

[Gingko]

[Edit : paragraphe concernant un déplacement de messages vers cette section, supprimé car obsolète en raison d'une fusion réalisée ensuite]

Je n'ai pas de solution pour l'instant, car je ne peux pas reproduire ce problème.

Les enregistrements TS ne sont qu'une extraction d'éléments du flux TS sans aucune transformation du contenu, si cet enregistrement est corrompu, je ne peux que présumer que des paquets doivent être perdus, peut-être parce que l'écriture sur fichier prend trop de temps à s'exécuter sur certains ordinateurs, pour une raison inconnue.

En plus je n'ai pas travaillé sur cette partie du programme récemment.

GIngko

[Miguel]

Les enregistrements TS ne sont qu'une extraction d'éléments du flux TS sans aucune transformation du contenu, si cet enregistrement est corrompu, je ne peux que présumer que des paquets doivent être perdus, peut-être parce que l'écriture sur fichier prend trop de temps à s'exécuter sur certains ordinateurs, pour une raison inconnue.

Je ne crois pas que ça soit ça, car c'est aléatoire et l'activité de mon disque dur est très faible lors de l'enregistrement, et sur mes deux disques dur c'est la même chose, que ça soit sous Windows Vista ou Windows Seven, et seulement depuis la version 173.

Je pense que c'est juste le conteneur quiest mal créé, car le son saute régulièrement : il est joué à bonne vitesse, mais fait de temps en temps un saut en avant de quelques milisecondes. De même pour l'image, d'où l'apparition des artefacts sur l'image, des images sont sautées donc les informations ne sont pas complètes.

Y-a-t'il un programme qui me permettrai d'extraire de façon brute les données des .ts, sans prendre en compte les informations du .ts ?
De façon à voir si ce sont les données ou le conteneur qui est corrompu.

[Gingko]

Bonjour,

Les enregistrements TS ne sont qu'une extraction d'éléments du flux TS sans aucune transformation du contenu, si cet enregistrement est corrompu, je ne peux que présumer que des paquets doivent être perdus, peut-être parce que l'écriture sur fichier prend trop de temps à s'exécuter sur certains ordinateurs, pour une raison inconnue.

Je ne crois pas que ça soit ça, car c'est aléatoire et l'activité de mon disque dur est très faible lors de l'enregistrement, et sur mes deux disques dur c'est la même chose, que ça soit sous Windows Vista ou Windows Seven, et seulement depuis la version 173.

Le fait que l'activité du disque dur soit très faible n'est absolument pas significatif.

L'écriture de fragments de fichiers sur le disque dur se fait à l'aide de la fonction WriteFile, qui est partie intégrante du noyau de Windows.

Le temps qui nous préoccupe, pendant lequel des paquets pourraient être perdus, est le temps qui s'écoule entre le moment où on entre dans cette fonction et le moment où on en sort.

Il peut se passer des tas de choses pendant ce temps-là, des choses qui n'ont pas nécessairement grand chose à voir avec une écriture sur le disque.

Par exemple, un antivirus un peu trop intrusif qui intercepterait l'appel en vue de vérifier si du code malicieux n'est pas en train d'être écrit sur le disque.

Ou bien à l'opposé, un virus qui essaierait de la même manière de capturer des données sensibles.

Je pense que c'est juste le conteneur quiest mal créé, car le son saute régulièrement : il est joué à bonne vitesse, mais fait de temps en temps un saut en avant de quelques milisecondes. De même pour l'image, d'où l'apparition des artefacts sur l'image, des images sont sautées donc les informations ne sont pas complètes.

Y-a-t'il un programme qui me permettrai d'extraire de façon brute les données des .ts, sans prendre en compte les informations du .ts ?
De façon à voir si ce sont les données ou le conteneur qui est corrompu.

Oui, il en existe un, il s'appelle Pouchin TV Mod.

L'enregistrement TS de Pouchin TV Mod est tout ce qu'il y a de plus trivial. Il prend les paquets TS, il en fait le tri (pour séparer ceux qui concernent la chaîne enregistrée et ceux qui ne la concernent pas), et il enregistre ceux qu'il retient tel qu'il les reçoit.

On ne peut pas faire plus brut.

Un flux TS ("Transport Stream") est constitué d'une suite de paquets qui sont tous de taille absolument identique, à savoir 188 octets.

Ces paquets sont une suite entrelacée de fragments des différents flux audio et vidéo de l'ensemble des chaînes du multiplex, toutes chaînes confondues.

Le cœur de la fonction d'enregistrement TS de Pouchin TV Mod se résume à ceci (extrait du fichier capture.cpp) :

Code : Tout sélectionner

void CCapture_TS::traite_paquet(const TS_packet & p)	// virtual
{
	// une chaîne en TS
	UINT16 pid = p.hdr.pid();

	if (
		pid == p_pid_PAT ||
		pid == pmt_pid ||
		pid == video_pid ||
		sons.cherche_pid(pid) ||
		autr.cherche_pid(pid)
	)
		ecrit_fichier(p.bytes, TS_SIZE);
}

... avec ceci comme définitions :

Code : Tout sélectionner

#define TS_SIZE 188			// Taille (fixée) des paquets TS

// [...]

struct TS_packet
{
	union {
		TS_hdr	hdr;
		UINT8	bytes[TS_SIZE];
	};

	// [...]
};

En résumé, la fonction reçoit les paquets en séquence, teste s'ils appartiennent à la chaîne à enregistrer, et les enregistre immédiatement tels quels. Et quand je dis tels quels, ça veut dire tels quels :

Code : Tout sélectionner

// Sortie d'un bloc de données vers le fichier
BOOL CCapture::ecrit_fichier(LPCVOID pBuf, DWORD sizBuf) const
{
	DWORD written;

	return WriteFile(hFile, pBuf, sizBuf, &written, NULL);
}

C'est même précis au point que vous pouvez prendre la longueur en octets d'un enregistrement au format TS et diviser cette valeur par 188, vous obtiendrez alors un nombre entier (si le fichier n'est pas endommagé, bien sûr).

Et même si le fichier est endommagé, mais que le dommage se résume à des paquets manquants, vous aurez encore une division qui tombe juste.

Pour résumer, le seul endroit où des paquets pourraient être perdus résulterait d'un appel à WriteFile qui prendrait plus de temps que l'intervalle entre deux paquets.

À la rigueur on pourrait imaginer un problème en amont, dans lequel la fonction traite_paquet ne serait même pas appelée. Un tel problème prendrait son alors son origine dans le graphe DirectShow lui-même.

... mais j'aurais tendance à croire, dans ce cas, que le problème existerait aussi dans la vidéo affichée par Pouchin TV Mod.

J'utilise personnellement Pouchin TV Mod pour effectuer facilement une douzaine d'heures d'enregistrements par semaine, sur deux ordinateurs différents (tournant sous Windows XP (SP3), mais j'en ai quelques uns faits sous Windows Vista également), avec n'importe quelle version, et qu'aucun de ces enregistrements n'a jamais été affecté de problèmes de cet ordre ....

Gingko

[Gingko]

Re ...

Éventuellement, pouvez-vous me copier un court d'enregistrement .TS à l'adresse suivante ? :

ftp://gingko.homeip.net/pub/incoming/

Je viens de réexaminer les fichiers .TS qui avaient été mis en ligne dans un des deux autres "topics" sur un problème similaire, et je constate que dans le "ptv130.ts", certains paquets de 188 octets, bien que présents, sont en réalité remplis de zéros.

J'aimerais bien savoir si avec les vôtres ça fait pareil.

Gingko