Je reprends les investigations… et j’ai testé la commande
$ libcamera-hello
Preview window unavailable
[0:01:25.293263000] [598] INFO Camera camera_manager.cpp:299 libcamera v0.0.4+22-923f5d70
[0:01:25.475761000] [599] WARN RPI raspberrypi.cpp:1357 Mismatch between Unicam and CamHelper for embedded data usage!
[0:01:25.482016000] [599] INFO RPI raspberrypi.cpp:1476 Registered camera /base/soc/i2c0mux/i2c@1/imx219@10 to Unicam device /dev/media3 and ISP device /dev/media0
[0:01:25.486541000] [598] INFO Camera camera.cpp:1028 configuring streams: (0) 1640x1232-YUV420
[0:01:25.488943000] [599] INFO RPI raspberrypi.cpp:851 Sensor: /base/soc/i2c0mux/i2c@1/imx219@10 - Selected sensor format: 1640x1232-SBGGR10_1X10 - Selected unicam format: 1640x1232-pBAA
#0 (0.00 fps) exp 33251.00 ag 8.00 dg 1.00
#1 (30.01 fps) exp 33251.00 ag 8.00 dg 1.00
(suit plein de lignes du genre des deux dernières)
libcamera-jpeg renvoie bien une image 3280 x 2464. Donc la caméra marche et est reconnue par le système.
Une chose m’étonne, c’est la ligne qui fait référence à /dev/media3 et /dev/media0
Le périphérique ne serait pas /dev/video0 ? Pourtant en essayant dans motion.conf rien de plus : écran gris !
Heureusement, il me reste des cheveux, je tiens ça plus de mon grand-père que de mon père.
As tu mis la palette en en valeur « 14 » ou « 15 » ?
Oui la caméra marche avec une résolution ~4K. Avec le format YUV420, qui utilisera les formats de SBGGR10 et pBAA pour une résolution de 1640x1232 dans les deux cas.
Alors le YUV420 semble marcher et serait la valeur … 17 ? Bah eeee non si je me fit a la liste de format fournis et le log de motion.
Alors pour SBGGR10 … ce serait aucun de ces choix, les plus proche serait 1 et 2 mais le format n’est pas identique. Pour le PBAA alors ont a rien qui s’y rapproche.
Voici ce qui est sur selon tes logs de motion…
La caméra en /dev/video0 est valide
Le format « 17 » n’est pas bon pour cette caméra selon le log, alors faut vraiment tester avec « 14 » et sinon « 15 ».
Si après le test de « 14 » et « 15 » ça ne marche toujours pas et que le message dans le log est toujours le même, alors ont continuera pas a lancer des théories, ont va simplement teste un à un chaque valeur pour trouver celle que le motion va arriver à prendre en charge.
Si tu active l’interface Web sur le port 8080 avec le mode avancé, tu peux changer des valeur sans redémarrer motion, je ne sais pas si il peut ajuster la palette sans redémarrer, mais tente le coup, ça éviterais de relancer motion a chaque essai. Je me suis servi de ça pour ajuster la « luminosité » de mes caméras.
SI le message d’erreur est identique à celui posté hier, alors faudra tester toutes les palettes.
Au passage, tu configura tout depuis motion.conf sans charger de fichier autres pour « chaque caméra », car si tu en as plus qu’une c’est conseillé. Sinon assure toi bien que aucun autre paramètre vient changer ceux que tu configure, bref, assure toi que une fois chargé c’est bien les paramètres que tu as mis qui sont en charge. Je te conseille aussi de passer en revu tout les paramètres qui sont affiché et de contre vérifier avec la documentation.
Car…
Ta caméra fonctionne
Le Motion fonctionne
Mais les deux ensemble ça ne marche pas, alors c’est que des ajustements à faire, car il y a aucune autre raison qui empêche de l’utiliser.
ET j’espère que tu ne teste pas en mode « sudo » ou « root », car la, c’est sur que rien va marcher.
Bon, ça marche (enfin j’ai de nouveau une image, je vais pouvoir peaufiner les réglages…
Et c’est très con !
J’ai juste repassé raspi-config et réactivé la cam (alors qu’il explique que le réglage est obsolète) et que la caméra fonctionnait malgré tout partiellement (libcamera-jpeg par exemple !)
Les déboires de hier soir sont alors probablement liés à des config bancales… Mais en tout cas un grand merci pour l’aide !
je continue mes longues recherches sur la vidéo embarquée par RPi… maintenant que j’arrive à avoir une image, je suis confronté à deux (en attendant les autres) problèmes supplémentaires :
le fréquence de rafraichissement reste très lente (env. 2 image/s, indépendamment du réflage ) et il y a un délai de trois à quatre secondes entre ce qui se passe devant la caméra. Pour le rafraichissement, le paramètre framerate semble n’avoir aucun effet !
des plantages complets à très cours terme : après deux trois minutes de fonctionnement, ssh ne répond plus et le reboot sauvage est indispensable. Aucune trace du plantage dans les logs de motion (sui n’ont probablement pas pu s’écrire), où puis-je commencer mes recherches pour identifier l’origine du plantage de l’ensemble de l’OS ??
edit : j’ai vu passer un « kernel oops : 2f #1 ARM » si ça parle à quelqu’un…
edit2 : ce n’est pas la même carte SD que lors des premiers tests mais les symptômes sont semblables et j’ai le même plantage sur RPi zero comme sur RPi 3…
Ton problème de vitesse a surement la même source que le plantage, et tout indique la carte SD.
Perso, les SanDisk Ultra 32GB SDHC marche très bien et sont très solide. (SanDisk Ultra microSDHC UHS-I A1 32GB en simple ou kit double).
Les Kingston sont a éviter, tout comme certaines Lexar. Les « Generic » et clone chinois sont à éviter a tout prix. Les Verbatin sont pas bon. Bref, le SanDisk es le meilleur.
Je ne sort pas le SanDisk de nulle part, il existe des listes de compatibilité pour le RPi et les SanDisk ont le meilleur taux de succès et de performance. J’ai même fait des réserves de carte SD de ce type pour ne plus avoir de problème à ce niveau dans mes projets après avoir confirmé a plus d’une reprise leur bonne qualité.
Je vais essayer une autre… les deux qui déconnent (de la même manière, ce qui est quand même étonnant) sont deux SanDisk. Une ultra de 8G, donc pas très récente mais peu utilisée et une SanDisk (pas ultra) de 32. Celle-là est neuve.
