Le problème est du, selon mes connaissances, à l’encodage. Ce problème est visible aussi avec des vidéo standard sans nécessairement en stream live.
Ce qui ce passe, est que quelques bits du stream ne sont pas la, corrompu ou mal formaté, et empêche une gestion de l’image correctement. Ceci peut être du à la source ou au lecteur destinataire.
Sans savoir ce qui cause exactement ce problème, il faut jouer avec les paramètre de l’encodage (si possible) et du décodeur.
L’idée serait de jouer avec les valeurs de « buffer », « frame skip » et de « frame sync ».
Ton lecteur HiCam doit avoir ce type de paramètre, qui permet d’éviter ce problème.
Ce problème arrive aussi si la lecture et trop proche du point de réception; je m’explique.
La plupart du temps, quand tu suis un Stream, tu a un décalage de 1 à 5 secondes, (pouvant être plus), ce délais permet a la source de streamer sans que le lecteur subisse d’arrêt.
EN principe, un serveur vidéo doit faire un « Tampon », d’un certain nombre de seconde, disont 5 secondes.
Quand le stream est reçu, théoriquement il doit attendre 5 secondes pour permettre l’écoute, comme sa si la source stop quelques instant (msec ou sec) sa permet au stream de continuer sans coupure en lecture (mais un saut d’image est possible). C’est le principe de « buffering » et « frame skip ».
Si ton serveur pousse le stream reçu sans tampon, il doit encoder à la volé et suivre le stream en limitant la perte, il ne veut pas « couper » le stream et envoie des images partiel pour « tenir le rythme ». ET plus le RPi va encoder direct, plus la chance d’erreur est grande.
Quand tu as du mouvement, l’encodeur doit recréer une map de couleur et d’autres information du « header » vidéo, quand l’image est fix ou que les mouvements sont minime, l’encodeur utilise l’image précédente et ajoute que les pixels bougé, mais plus il y a du mouvement dans l’image, plus il doit noter de modification au « header » vidéo, voir « flush » le frame précédente pour redéfinir l’ensemble.
C’est un peu dur a comprendre et à expliquer. Le meilleur moyen est de ne pas demander a MotionEye de réencoder mais de copier le stream, ce qui lui fera sauter l’encodage et fournir le stream dans sont état reçu. Mais il est difficile de changer ce type de paramètre avec MotionEye.
J’ai déja testé MotionEye et malgré le côté AiO qui est for intéressant, j’ai abandonné ce système pour opter de quoi de plus simple et maniable. Le problème de ma solution est que j’utilise une application qui n’est plus supporté.
J’ai créé un serveur FFServer pour mes Stream, j’ai 5 caméras sur ce serveur, chaque caméra est Stream depuis une commande par FFmpeg. Chaque caméra Stream donc en MJpeg directement sur le server, ce serveur ne fait que copier le format reçu vers le client, à la demande. Dans mes commandes, je demande aux caméras de faire du Frame Skip, de limiter le débit à 15 img/s sur ceux en Wifi et 25 img/sec ceux en filaire.
Résultat, j’ai aucun bug d’image. Mais ici je dois spécifier de quoi.
J’ai une caméra sur un RPi Zero 2, qui fait aussi office de Deskboard. Par moment le RPi commence à être surchargé, sont encodage ralenti, au point que j’ai un décalage avec la réalité et le visionnement pouvant atteindre, attention les yeux… 5 heures de décalage. Car le RPi, même en prenant le format MJpeg de la caméra et sans l’encoder, à de la misère à suivre le rythme, et j’ai aussi un problème de décalage de quelques secondes avec une autre caméra RPi (RPi Zero 1 WH), qui fait que ça.
Le RPi est vraiment pourri en encodage vidéo et Stream. Alors gérer plusieurs Stream via MotionEye est encore plus exigeant, pouvant causer à des pertes de qualité d’encodage pour être le plus « Real Time ». La solution la plus viable est de travailler soit même le serveur pour ajuster tout les paramètre à fin de limiter la charge de travail et la perte de qualité. De faire travailler chaque source dans l’encodage au lieu de demander à un seul appareil de le faire.
Je n’ai pas de solution pour toi, sauf de faire des tests et de comprendre ou le problème ce crée exactement. De hack/tweaker le MotionEye pour changer sa charge de travail et la manière qui travail le tout. Si je ne me trompe pas, le MotionEye sort en format MJpeg tout les stream, alors il doit réencoder la source. Lui fournir un stream directement en MJpeg peut grandement l’aider.
), et que l’accès API est très limité.
.
