Streaming, replay et téléchargement (tout ça)

Bonjour,

Pour le contexte, il ne s’agit pas de superproduction hollywoodienne (ni de streaming/partage douteux d’œuvres protégées) mais de faire de la surveillance de manipulations en sciences.

J’aimerai :

  • filmer et diffuser en continu (qualité médiocre acceptée) le flux vidéo de la caméra du RPi. Pour cela j’imagine un serveur web sur le RPi.

  • pouvoir enregistrer la vidéo (de préférence en qualité plus correcte mais on peut favoriser la vitesse à 60 images par seconde au détriment de la résolution si besoin)

  • permettre le visionnage après coup depuis la page web ou le téléchargement du fichier vidéo (pas de contrainte majeure sur le format)

J’ai vu qu’il existait plein de tutos pour faire du streaming, captures etc mais j’ai surtout vu qu’il existait différentes méthodes pour cela.

Quelle serait, au vu de mes souhaits s’ils ne sont pas loufoques, la technique à privilégier ?

Merci de vos conseils.

(j’ai pour le moment un raspberry pi 3 (2015 ??) et une caméra vers. 2.1. Si ça suffit, tant mieux, sinon achat possible dès que les disponibilités reprendront :frowning:

Une solution est MotionEye OS, qui est une système de vidéo surveillance avec des options d’enregistrement.

Sinon, je crois que c’est le projet à faire par toi-même.

Je relance le sujet, désolé pour @levelKro que j’ai laissé en plan, souci de santé oblige :frowning:

Depuis janvier, j’ai pu acheter un zero W et j’ai relancé les tests…
Pas encore essayé MotionEyes OS parceque j’ai vu que le projet semblait abandonné. A défaut, j’essayerai quand même mais pour le moment je suis parti sur une bulleyes lite classique.

Donc j’ai fait :

  • installation de l’OS version lite 32b avec ssh activé et wifi configuré → tout OK
  • activation de la cam par raspiconfig (j’ai lu qui ça ne sert plus à rien ?)
  • activation de I2C (j’en aurai besoin plus tard) → pas testé
  • installation de motion et des dépendances

J’ai en fait fait deux installations de motion : celle des dépôts et celle du GIT. Dans les deux cas le problème est le même !

L’installation par défaut de motion semble fonctionner : si mouvement devant la cam, il y a enregistrement d’un fichier vidéo.

J’ai modifié motion.conf pour mettre threshold à 0 et filmer en continu. J’ai prévu (plus tard) de faire le déclenchement/arrêt par un interrupteur et de toutes façons c’est pour 10-15 s de vidéo pas plus.
Sauf que le RPi semble planter : ssh ne répond plus, l’image en live se fige après queleques secondes. Reboot brutal indispensable et aucun fichier n’est enregistré. Aps trouvé de log non plus pour essayer de comprendre.

Est-ce que quelqu’un a une idée ??
MErci

MotionEye OS est affreux, lent et très lourd, il ne marche pas très bien sur un RPi 0/1. Alors l’option que d’utiliser Motion est viable, je le fais actuellement et c’est très performant, mieux que FFMpeg.

Avec RPi0 v1 tu peux utiliser la dernières version (ou non), mais dans mes tests, j’utilise Motion fourni via le APT. De mon avis c’est plus stable, le GIT peux contenir des bugs fix, mais aussi des ajouts plus lourd pour prendre en compte le RPi4 par exemple. Alors je fais confiance a une version précompilé fournis par le OS.

Newer is not necessary better (oldversion.com)

Avant d’ajuster les paramètres de Motion, vaut mieux tester en mode simple, soi seulement capturer et streamer en RTSP/HTTP selon ton choix.

Après tests la capture d’image et fini par la capture vidéo

Fait a noter, si tu opte pour la capture d’image, configure bien ton dossier ou il seront stocké, j’ai pas mégarde ativé cette option sans configurer le dossier, et j’ai rempli ma carte SD en quelques heures, ce qui a bloqué le OS bien dur. De plus les images était dans le dossier système de Motion, ce qui a compliqué la suppression. Le trop grand nombre de fichier a fait en sorte que sudo rm *.jpg ne pouvait traiter la demande (dans le dossier), il a fallu faire une quantité limité par le « sting match » pour supprimer l’ensemble.
Le système de Motion ne vérifie pas l’espace disponible avant d’écrire.


Ceci me dit que ton problème est au niveau de ta carte SD, il semble ne pas être en mesure d’écrire. Test sans sauvegarde (stream seulement) et en théorie tu n’auras pas ce problème. Après coup, si le problème est toujours la, tu as un problème très précis. Quand tu as un problème de ce genre c’est 3 choses qui sont impliqué; le CPU, la RAM et la carte SD.

En stream, seul le CPU et la RAM sont sollicité, alors si tu n’as pas de plantage, le CPU et la RAM ne sont pas en cause (et encore moins le logiciel, qui réside dans les deux). Si tu as quand même ce problème, alors c’est que ton CPU est surchargé, soit la RAM a un problème. Mais un problème en RAM n’est pas « permanent » car le système devrait être en mesure d’isoler les secteur problématique et continuer.

Sur la carte SD, si le problème a lieu, c’est que tu as atteint la limite lecture/écriture, soit des secteurs sont défectueux ou que la carte SD est de mauvaise qualité. Le plus simple est de faire une analyse de la carte, avec HWtest ou une analyse de surface avec Gparted (qui est moins profond, mais qui peut aider).


Petite histoire…

J’ai un serveur sous Debian qui est pour mes services réseau (torrents, partage de fichiers réseau, ASF, etc…) et j’ai eu le disque principal qui est mort.

Cependant je m’en suis rendu compte vraiment très tard après. Vu que l’ensemble du OS est chargé dans la RAM et utilise le CPU, peut d’interactions avec le disque dur ont lieux. Mes services utilisant ce disque dur sont tombé « planté »’ comme les torrents, car des problèmes d’écriture. Le système était lent vu le nombre d’erreur qui générais avec un disque dur principal « monté » mais « n’est plus présent ». Alors j’avais des erreurs de I/O a la volé. Le SSH ne marhait pas, vu son incapacité de charger le dossier à la connexion et de valider le user/pass. Le système était partiellement opérationnel, vu que j’ai Webmin de chargé. J’ai été en mesure de faire une ou deux actions avant que tout plante. Sur l’écran connecté, des erreurs en série apparaissait.

Si je relancais le système (reboot), j’avais des erreurs mais le système chargeait. J’ai eu un avertissement SMART (qui est absent du RPi), sur la fin du disque dur. Certains secteur pouvait être utiliser, mais clairement le système était instable.

J’ai du reconfigurer sur un nouveau HDD, et après quelques démarrage sur l’ancien disque dur, il nous a quitté pour de bon.

Ce qui est différent est que le serveur a plus de RAM, plus de puissance CPU, ce qui fait qu’une grande partie des applications sont donc chargé en mémoire et la lecture sur disque est minime. La lecture des torrents a fait en sorte que c’est le premier service qui a planté, vu qui doit lire les packet sur le HDD, après les autres services ont planté un après l’autre dès qu’il était sollicité, car justement ils ont besoin du disque dur pour certains éléments (identification, affichage de dossier, scripts…)

Vu que Webmin charge plusieurs modules en mémoire, j’ai été en mesure de l’utiliser, mais dès que je suis entré dans des sections ou l’usage du HDD était nécessaire, des erreurs sont survenu.

J’explique cette histoire car un unité de stockage quand il meurt, ne meurt pas d’un coup, il va commencer par avoir des secteurs défectueux et le tout grandi assez vite. Il peu avoir aucun problème a lire, mais écrire lui causera problème. Et tout dépend ou il va écrire. Alors par exemple le log du boot s’enregistre sur une section et la capture vidéo sur une autre e comble de (mal)chance, c’est sur un secteur défectueux.

Par exemple les carte chinoise SD peuvent être de faible qualité, il existe des clones Kingston et Sandisk, et par exemple, j’avais acheté 2 cartes SD Kingston 32GB de Chine, après des tests, seul les 8GB en début de carte existait vraiment, le resterait n’était que du « fake », pour visualiser la chose; ils ont surement changé le « header ID » de la carte pour ce faire passer pour une 32GB quand c’était une 8GB. Je ne dis pas que ta carte est un clone. Mais une carte avec une (grande) section morte peut quand même donner l’impression de marcher.

Il faut savoir que l’écriture de données ne suit pas une logique « humaine », le OS peut selon la demande aller porter les donner sur un espace vide ou l’entasser dans les premiers secteurs. Si il tombe sur un secteur défectueux, il va tenter de déplacer les données sur un autre secteur. Mais si il accumule les mauvais secteur, sont usage d’écriture monopolisera le système. C’est un peu comme si je te demande de rentrer un livre dans une bibliothèque, si tu prend le livre et arrive a le placer « sans trop y penser » dans un espace libre sans problème, ttu serais en mesure de continuer de me parler, mais si après 3-4 tentatives tu n’arriverais pas à entrer le livre sur la tablette de la bibliothèque, tu me demanderais surement de me la fermer pour tenter de résoudre ce problème, résultat; le SSH et autres services ne répondent plus parce que tu tente de compléter la demande de placement du livre qui te génère des problèmes.


Sarieux, faudrait je résume mieux mes idées, je sort toujours des romans, désolé :stuck_out_tongue:

Merci pour cette (longue ¹) réponse. Je vais essayer de cibler le problème.
Carrouf ouvre à 8h demain matin… j’ai plus de SDcard dispo :wink:

¹ : non non surtout ne résume rien !

Je suis reparti sur une installation fraiche et minimale : OS lite mis à jour, motion et ses dépendances.
J’ai réglé un premier problème : out of the box, motion ne démarre pas : erreur relative au foichier de log qui ne dispose pas des droits nécesaires. J’ai réglé ça par un chown motion:motion mais il reste un autre pb : l’image est grise avec une autre erreur de droits probablement.

Est-ce que cela parle à qq’un ? j’ai un peu googlé sur ce problème mais pas de solution qui semble fonctionner pour moi…

Regarde en haut a gauche…

Unable to open video device

Soit que le chemin vers la caméra n’est pas le bon, soit ta caméra n’est pas accessible/connecté.

Commence par vérifier le chemin, si c’est la seul caméra présente, ce sera « /dev/video0 ». Si le chemin est bon, assure toi de donner des paramètre compatible avec la caméra; résolution, images/seconde, etc… c’est une configuration « avancé ».
Pour ton log, bizarre, car je vien justement d’installer a neuf des Raspberry et PC Debian avec motion e je n’ai pas eux ce problème. As tu passé par le « apt » pour le motion ou a tu utilisé le « git » ? Moi j’ai pris le « apt ». Et sans modification, sauf pour activer l’interface web, et j’ai eu aucun problème.

Pour t’aider, voici les parties modifié de mes fichiers de configurations

Dans motion.conf

# Rename this distribution example file to motion.conf
#
# This config file was generated by motion 4.1.1
# Documentation:  /usr/share/doc/motion/motion_guide.html

############################################################
# Daemon
############################################################

# Start in daemon (background) mode and release terminal (default: off)
daemon on

# File to store the process ID, also called pid file. (default: not defined)
process_id_file /var/run/motion/motion.pid

############################################################
# Basic Setup Mode
############################################################

# Start in Setup-Mode, daemon disabled. (default: off)
setup_mode off


# Use a file to save logs messages, if not defined stderr and syslog is used. ($
logfile /var/log/motion/motion.log

# Level of log messages [1..9] (EMG, ALR, CRT, ERR, WRN, NTC, INF, DBG, ALL). ($
log_level 6

# Filter to log messages by type (COR, STR, ENC, NET, DBL, EVT, TRK, VID, ALL).$
log_type all

###########################################################
# Capture device options
############################################################

# Videodevice to be used for capturing  (default /dev/video0)
# for FreeBSD default is /dev/bktr0
;videodevice /dev/video0# Rotate image this number of degrees. The rotation affects all saved images as
# well as movies. Valid values: 0 (default = no rotation), 90, 180 and 270.
rotate 0

# Flip image over a given axis (vertical or horizontal), vertical means from le$
# horizontal means top to bottom. Valid values: none, v and h.
flip_axis none

# Image width (pixels). Valid range: Camera dependent, default: 320
width 720

# Image height (pixels). Valid range: Camera dependent, default: 240
height 480

# Maximum number of frames to be captured per second.
# Valid range: 2-100. Default: 100 (almost no limit).
framerate 30

# Minimum time in seconds between capturing picture frames from the camera.
# Default: 0 = disabled - the capture rate is given by the camera framerate.
# This option is used when you want to capture images at a rate lower than 2 pe$
minimum_frame_time 0

############################################################
# Image File Output
############################################################

# Output 'normal' pictures when motion is detected (default: off)
# Valid values: on, off, first, best, center
# When set to 'first', only the first picture of an event is saved.
# Picture with most motion of an event is saved when set to 'best'.
# Picture with motion nearest center of picture is saved when set to 'center'.
# Can be used as preview shot for the corresponding movie.
output_pictures off

############################################################
# HTTP Based Control
############################################################

# TCP/IP port for the http server to listen on (default: 0 = disabled)
webcontrol_port 8080

# Restrict control connections to localhost only (default: on)
webcontrol_localhost off

# Output for http server, select off to choose raw text plain (default: on)
webcontrol_html_output on

# Authentication for the http based control. Syntax username:password
# Default: not defined (Disabled)
; webcontrol_authentication username:password

# Parameters to include on webcontrol.  0=none, 1=limited, 2=advanced, 3=restri$
# Default: 0 (none)
webcontrol_parms 2

camera /etc/motion/camera1.conf
camera /etc/motion/camera2.conf

Pour camera1.conf

# /etc/motion/camera1.conf
#
# This config file was generated by motion 4.1.1

###########################################################
# Capture device options
############################################################

# Camera Id
# Consistent identification number to assign to each camera across multiple
# invocations of Motion.
# Default: The order when the camera file was read
# camera_id = 1

# Videodevice to be used for capturing  (default /dev/video0)
# for FreeBSD default is /dev/bktr0
videodevice /dev/video0

# The video input to be used (default: -1)
# Should normally be set to 1 for video/TV cards, and -1 for USB cameras
input 2
norm 0
# Draw a user defined text on the images using same options as C function strft$
# Default: Not defined = no text
# Text is placed in lower left corner
text_left CUISINE


# Let motion regulate the brightness of a video device (default: off).
# The auto_brightness feature uses the brightness option as its target value.
# If brightness is zero auto_brightness will adjust to average brightness value$
# Only recommended for cameras without auto brightness
auto_brightness off

# Set the initial brightness of a video device.
# If auto_brightness is enabled, this value defines the average brightness level
# which Motion will try and adjust to.
# Valid range 0-255, default 0 = disabled
brightness 0

# Set the contrast of a video device.
# Valid range 0-255, default 0 = disabled
contrast 0

# Set the saturation of a video device.
# Valid range 0-255, default 0 = disabled
saturation 0

# Set the hue of a video device (NTSC feature).
# Valid range 0-255, default 0 = disabled
hue 0

############################################################
# Target Directories and filenames For Images And Films
# For the options snapshot_, picture_, mpeg_ and timelapse_filename
# you can use conversion specifiers
# %Y = year, %m = month, %d = date,
# %H = hour, %M = minute, %S = second,
# %v = event, %q = frame number, %t = camera id number,
# %D = changed pixels, %N = noise level,
# %i and %J = width and height of motion area,
# %K and %L = X and Y coordinates of motion center
# %C = value defined by text_event
# Quotation marks round string are allowed.
############################################################

# Target base directory for pictures and films
# Recommended to use absolute patch. (Default: current working directory)
#target_dir /tmp/motion/cam1
# File path for motion triggered images (jpeg, ppm or webp) relative to target_$
# Default: %v-%Y%m%d%H%M%S-%q
# Default value is equivalent to legacy oldlayout option
# For Motion 3.0 compatible mode choose: %Y/%m/%d/%H/%M/%S-%q
# File extension .jpg, .ppm or .webp is automatically added so do not include t$
# Set to 'preview' together with best-preview feature enables special naming
# convention for preview shots. See motion guide for details
picture_filename CAM1_%v-%Y%m%d%H%M%S-%q


############################################################
# Live Stream Server
############################################################

# The mini-http server listens to this port for requests (default: 0 = disabled)
stream_port 8081

# Quality of the jpeg (in percent) images produced (default: 50)
stream_quality 90

# Output frames at 1 fps when no motion is detected and increase to the
# rate given by stream_maxrate when motion is detected (default: off)
stream_motion off

# Maximum framerate for stream streams (default: 1)
stream_maxrate 25

# Restrict stream connections to localhost only (default: on)
stream_localhost off


# Limits the number of images per connection (default: 0 = unlimited)
# Number can be defined by multiplying actual stream rate by desired number of $
# Actual stream rate is the smallest of the numbers framerate and stream_maxrate
stream_limit 0

# Command to be executed when a picture (.ppm|.jpg|.webp) is saved (default: no$
# The filename of the picture is appended as an argument for the command.
#on_picture_save /usr/local/motion-extras/camparse2.pl

# Command to be executed when a movie file (.mpg|.avi) is closed. (default: non$
# Filename of movie is appended as an argument for the command.
#on_movie_end /usr/local/motion-extras/mpegparse2.pl

J’ai laissé les commentaires etc pour t’aider a comprendre et repérer les options.

Salut,

c’est motion du dépot apt : j’ai suivi tes conseils en jouant la stabilité…
La caméra est une picam v2.1 est elle est seule, branchée apparemment correctement.

iss@iss:~ $ ls -l /dev/video*
crw-rw---- 1 root video 81, 13 Mar 28 21:40 /dev/video0
crw-rw---- 1 root video 81, 14 Mar 28 21:40 /dev/video1
crw-rw---- 1 root video 81,  8 Mar 28 21:40 /dev/video10
crw-rw---- 1 root video 81,  9 Mar 28 21:40 /dev/video11
crw-rw---- 1 root video 81, 10 Mar 28 21:40 /dev/video12
crw-rw---- 1 root video 81,  0 Mar 28 21:40 /dev/video13
crw-rw---- 1 root video 81,  1 Mar 28 21:40 /dev/video14
crw-rw---- 1 root video 81,  2 Mar 28 21:40 /dev/video15
crw-rw---- 1 root video 81,  3 Mar 28 21:40 /dev/video16
crw-rw---- 1 root video 81, 11 Mar 28 21:40 /dev/video18
crw-rw---- 1 root video 81,  4 Mar 28 21:40 /dev/video20
crw-rw---- 1 root video 81,  5 Mar 28 21:40 /dev/video21
crw-rw---- 1 root video 81,  6 Mar 28 21:40 /dev/video22
crw-rw---- 1 root video 81,  7 Mar 28 21:40 /dev/video23
crw-rw---- 1 root video 81, 12 Mar 28 21:40 /dev/video31

la fin du ficheir de motion.log :

[1:ml1] [NTC] [VID] [Mar 28 21:47:11] v4l2_pixfmt_set: Testing palette Y12  (640x480)
[1:ml1] [ERR] [VID] [Mar 28 21:47:11] v4l2_pixfmt_set: Error setting pixel format.
VIDIOC_S_FMT: : Device or resource busy
[1:ml1] [ERR] [VID] [Mar 28 21:47:11] v4l2_pixfmt_select: Palette selection failed for format Y12
[1:ml1] [ERR] [VID] [Mar 28 21:47:11] v4l2_pixfmt_select: Unable to find a compatible palette format.
[1:ml1] [ERR] [VID] [Mar 28 21:47:11] vid_start: V4L2 device failed to open
[1:ml1] [WRN] [ALL] [Mar 28 21:47:11] motion_init: Could not fetch initial image from camera
[1:ml1] [WRN] [ALL] [Mar 28 21:47:11] motion_init: Motion continues using width and height from config file(s)
[1:ml1] [NTC] [ALL] [Mar 28 21:47:11] image_ring_resize: Resizing pre_capture buffer to 1 items
[1:ml1] [NTC] [ALL] [Mar 28 21:47:11] image_ring_resize: Resizing pre_capture buffer to 4 items

je nage…

Sous Raspberry les /dev/video sont tous pré-inscrit, mais pas nécessairement utilisé.

Dans ton second log, tu as des début de réponse…

Le format de palette n’est pas le bon, faudra voir les capacité de la caméra. tente le 720x480 (standard 480p) ou le 1280x720 (standard 720p).

Ici il te l’explique justement que la palette choisi et le format ne sont pas bon, alors il ne peut pas l’utiliser.

Ici motion t’avise qu’il ne peut pas capturer l’image (vu l’erreur précédente) et continue a créer le stream avec les valeurs de la configuration. Il crée le stream avec espérance que la situation ce règle.

Pour savoir les formats que la caméra rapporte utilisable, réfère toi à cette commande;

v4l2-ctl --list-formats -d /dev/video0

et

v4l2-ctl --get-fmt-video -d /dev/video0

Avec cette commande, tu obtiens des détails sur la caméra (et te permet de voir si c’est bien reconnu);

v4l2-ctl --info -d /dev/video0

Avec celle si, tu vois toutes les caméras actuellement pris en charge et leur point de montage disponible;

v4l2-ctl --list-devices

J’ai enté de figurer avec Google ton problème.

Voici mes résultats (non testé)

#1
Il faut retirer du fichier « /boot/config.txt » cette ligne;

  • camera_auto_detect=1

Et ajouter;

  • start_x=1
  • gpu_mem=128

#2
Dans un charabia et de long texte j’ai extrait cette information…

Les caméra doivent marquer « supporté » et « détecté » dans les modules, si ce n’est pas le cas, quelques raisons existe:

  • Ce n’est pas une caméra compatible avec Raspberry Pi
  • La mémoire est trop petite pour permettre le chargement de la caméra
  • Une configuration du Kernel/Config empêche l’activation de la caméra
  • La caméra est défectueuse

Tu obtiens cette information avec

vcgencmd get_camera

E le résultat doit être ;

supported=1 detected=1

(avec d’autres informations)

j’ai modifié le motion.conf pour mettre les formats 480p ou 720p, mais rien ne change : l’écran gris prend juste la taille demandé mais pas d’image…

v4l2-ctl --list-devices
unicam (platform:20801000.csi):
	/dev/video0
	/dev/video1
	/dev/media3

bcm2835-codec-decode (platform:bcm2835-codec):
	/dev/video10
	/dev/video11
	/dev/video12
	/dev/video18
	/dev/video31
	/dev/media2

bcm2835-isp (platform:bcm2835-isp):
	/dev/video13
	/dev/video14
	/dev/video15
	/dev/video16
	/dev/video20
	/dev/video21
	/dev/video22
	/dev/video23
	/dev/media0
	/dev/media1

la caméra semble OK :

v4l2-ctl --info -d /dev/video0
Driver Info:
	Driver name      : unicam
	Card type        : unicam
	Bus info         : platform:20801000.csi
	Driver version   : 6.1.19
	Capabilities     : 0xa5a00001
		Video Capture
		Metadata Capture
		Read/Write
		Streaming
		Extended Pix Format
		Device Capabilities
	Device Caps      : 0x25200001
		Video Capture
		Read/Write
		Streaming
		Extended Pix Format
Media Driver Info:
	Driver name      : unicam
	Model            : unicam
	Serial           : 
	Bus info         : platform:20801000.csi
	Media version    : 6.1.19
	Hardware revision: 0x00000000 (0)
	Driver version   : 6.1.19
Interface Info:
	ID               : 0x03000006
	Type             : V4L Video
Entity Info:
	ID               : 0x00000004 (4)
	Name             : unicam-image
	Function         : V4L2 I/O
	Flags         : default
	Pad 0x01000005   : 0: Sink
	  Link 0x02000008: from remote pad 0x1000002 of entity 'imx219 10-0010': Data, Enabled, Immutable

Par contre la liste des formats me parait bien plus obscure que tout le reste :

v4l2-ctl --list-formats -d /dev/video0
ioctl: VIDIOC_ENUM_FMT
	Type: Video Capture

	[0]: 'YUYV' (YUYV 4:2:2)
	[1]: 'UYVY' (UYVY 4:2:2)
	[2]: 'YVYU' (YVYU 4:2:2)
	[3]: 'VYUY' (VYUY 4:2:2)
	[4]: 'RGBP' (16-bit RGB 5-6-5)
	[5]: 'RGBR' (16-bit RGB 5-6-5 BE)
	[6]: 'RGBO' (16-bit A/XRGB 1-5-5-5)
	[7]: 'RGBQ' (16-bit A/XRGB 1-5-5-5 BE)
	[8]: 'RGB3' (24-bit RGB 8-8-8)
	[9]: 'BGR3' (24-bit BGR 8-8-8)
	[10]: 'RGB4' (32-bit A/XRGB 8-8-8-8)
	[11]: 'BA81' (8-bit Bayer BGBG/GRGR)
	[12]: 'GBRG' (8-bit Bayer GBGB/RGRG)
	[13]: 'GRBG' (8-bit Bayer GRGR/BGBG)
	[14]: 'RGGB' (8-bit Bayer RGRG/GBGB)
	[15]: 'pBAA' (10-bit Bayer BGBG/GRGR Packed)
	[16]: 'BG10' (10-bit Bayer BGBG/GRGR)
	[17]: 'pGAA' (10-bit Bayer GBGB/RGRG Packed)
	[18]: 'GB10' (10-bit Bayer GBGB/RGRG)
	[19]: 'pgAA' (10-bit Bayer GRGR/BGBG Packed)
	[20]: 'BA10' (10-bit Bayer GRGR/BGBG)
	[21]: 'pRAA' (10-bit Bayer RGRG/GBGB Packed)
	[22]: 'RG10' (10-bit Bayer RGRG/GBGB)
	[23]: 'pBCC' (12-bit Bayer BGBG/GRGR Packed)
	[24]: 'BG12' (12-bit Bayer BGBG/GRGR)
	[25]: 'pGCC' (12-bit Bayer GBGB/RGRG Packed)
	[26]: 'GB12' (12-bit Bayer GBGB/RGRG)
	[27]: 'pgCC' (12-bit Bayer GRGR/BGBG Packed)
	[28]: 'BA12' (12-bit Bayer GRGR/BGBG)
	[29]: 'pRCC' (12-bit Bayer RGRG/GBGB Packed)
	[30]: 'RG12' (12-bit Bayer RGRG/GBGB)
	[31]: 'pBEE' (14-bit Bayer BGBG/GRGR Packed)
	[32]: 'BG14' (14-bit Bayer BGBG/GRGR)
	[33]: 'pGEE' (14-bit Bayer GBGB/RGRG Packed)
	[34]: 'GB14' (14-bit Bayer GBGB/RGRG)
	[35]: 'pgEE' (14-bit Bayer GRGR/BGBG Packed)
	[36]: 'GR14' (14-bit Bayer GRGR/BGBG)
	[37]: 'pREE' (14-bit Bayer RGRG/GBGB Packed)
	[38]: 'RG14' (14-bit Bayer RGRG/GBGB)
	[39]: 'GREY' (8-bit Greyscale)
	[40]: 'Y10P' (10-bit Greyscale (MIPI Packed))
	[41]: 'Y10 ' (10-bit Greyscale)
	[42]: 'Y12P' (12-bit Greyscale (MIPI Packed))
	[43]: 'Y12 ' (12-bit Greyscale)
	[44]: 'Y14P' (14-bit Greyscale (MIPI Packed))
	[45]: 'Y14 ' (14-bit Greyscale)

EN tout cas, merci du temps que tu prends pour m’aider !

Ok, je me suis décidé a me connecter sur ma caméra géré par Raspberry Pi…

pi@rpi0:~ $ v4l2-ctl --list-devices
bcm2835-codec-decode (platform:bcm2835-codec):
        /dev/video10
        /dev/video11
        /dev/video12
        /dev/video18

bcm2835-isp (platform:bcm2835-isp):
        /dev/video13
        /dev/video14
        /dev/video15
        /dev/video16

mmal service 16.1 (platform:bcm2835-v4l2-0):
        /dev/video0

Moi c’est le troisième, « mmal service 16.1 », alors j’ai une vraie caméra compatible RPi, vu que c’est le chipset du RPi qui le prend en charge.

Avec plus d’information, je confirme que la configuration est similaire a toi.

pi@rpi0:~ $ v4l2-ctl --get-fmt-video -d /dev/video0
Format Video Capture:
        Width/Height      : 720/480
        Pixel Format      : 'YU12' (Planar YUV 4:2:0)
        Field             : None
        Bytes per Line    : 720
        Size Image        : 529920
        Colorspace        : SMPTE 170M
        Transfer Function : Default (maps to Rec. 709)
        YCbCr/HSV Encoding: Default (maps to ITU-R 601)
        Quantization      : Default (maps to Limited Range)
        Flags             :

→ YUV12 (UYVY 4:2:2)
→ 720x480

Avec d’autres informations, je confirme les formats;

pi@rpi0:~ $ v4l2-ctl --list-formats -d /dev/video0
ioctl: VIDIOC_ENUM_FMT
        Type: Video Capture

        [0]: 'YU12' (Planar YUV 4:2:0)
        [1]: 'YUYV' (YUYV 4:2:2)
        [2]: 'RGB3' (24-bit RGB 8-8-8)
        [3]: 'JPEG' (JFIF JPEG, compressed)
        [4]: 'H264' (H.264, compressed)
        [5]: 'MJPG' (Motion-JPEG, compressed)
        [6]: 'YVYU' (YVYU 4:2:2)
        [7]: 'VYUY' (VYUY 4:2:2)
        [8]: 'UYVY' (UYVY 4:2:2)
        [9]: 'NV12' (Y/CbCr 4:2:0)
        [10]: 'BGR3' (24-bit BGR 8-8-8)
        [11]: 'YV12' (Planar YVU 4:2:0)
        [12]: 'NV21' (Y/CrCb 4:2:0)
        [13]: 'RX24' (32-bit XBGR 8-8-8-8)

Ici le 0 est celui utilisé par ma caméra par défaut.

SI je me compare a toi sur cette partie, tu n’est pas en YU12 et c’est un format YUYV 4:2:2, et non le UYVY 4:2:2.

Si tu regarde ta liste, le format YU12 n’est pas compatible avec cette caméra, ce qui e ramette à ce message de motion dans le log;

Alors le problème n’es pas la résolution, mais bien le format de l’image.

Selon le guide de motion, l’option par défaut est le « 17 ».

Tu trouvera cette option dans le config de motion (motion.conf)

# v4l2_palette allows one to choose preferable palette to be use by motion
# See motion_guide.html for the valid options and values.  (default: 17)
v4l2_palette 17

Alors dans ton cas c’est 14, 15 qui serait les plus proche et compatible.

Et pour aller plus loin, les palette 2,4,5,10,14 et 15 sont compatible.


Le « unicam » est le pilote universel des caméras USB, alors tu aurais une caméra « clone » utilisant le pilote USB. Tes détails sur la compatibilité me donne impression que j’ai raison, mais je ne suis pas expert du décode des pilotes.

Et après l’analyse de tes formats, tu semble être tombé sur une caméra avec des caprices, pour ça que ce n’est pas « Plug’n Play » comme les autres.

v4l2-ctl --get-fmt-video -d /dev/video0
Format Video Capture:
	Width/Height      : 1280/720
	Pixel Format      : 'Y12 ' (12-bit Greyscale)
	Field             : None
	Bytes per Line    : 2560
	Size Image        : 1843200
	Colorspace        : Raw
	Transfer Function : None
	YCbCr/HSV Encoding: ITU-R 601
	Quantization      : Limited Range
	Flags             : 

format Y12 donc chez moi et option 19 ?

C’est une caméra que j’ai déjà utilisé il y a 2 - 3 ans et elle fonctionnait OK avec un RPi 1… et en couleur, avec motion je crois. J’avais fait du timelapse sans pb, quasiment « out of the box » mais je n’ai pas gardé mes notes d’installation…

pas de v4l2_palette dans mon motion.conf !

Explications des formats et leur présence d’après mon expérience.

J’ai travaillé sur mon système de caméra et d’autres projets comme Dash Cam et j’ai tenté de trouver des format rapide et qui génère un minimum de bug en cas de rupture (fin) non planifié.

Premièrement j’ai remarqué que toutes mes caméras et TV Tuner support le format MJpeg. C’est un format simple et qui demande peut de travail vu qu’elle est compressé par la caméra et non logiciel. Dans le cas des autres format, l’encodage pour lecture est souvent décodé/converti et requière une décodeur spécifique. Le cas pour les H.26x.

Voulant minimiser les configuration spécifique à chaque caméra, car dans mon contexte j’ai;

  • Un serveur caméra avec deux (2) TV Tuner (l’un en NTSC et l’autre en PAL) pour des caméra analogique (CCTV traditionnel). C’est motion qui s’en charge sans problème (et mieux que FFMpeg). J’utilise un FFMpeg pour copier les stream des caméras vers le serveur sur ce PC, qui est un serveur FFServer (vieux mais fonctionnel). Il est sous Debian.
  • Une caméra Wifi IP traditionnel avec un stream RTSP
  • Une caméra USB C270 sur mon serveur de fichiers, géré par motion
  • Une caméra sur un RPi 0 W v1 avec une caméra pour RPi (clone à 5$) avec gestion par motion

Tous ont la même configuration de FFMpeg pour streamer. Il copie vers le server simplement, sans support audio.

Le signal RTSP peu varier les formats (selon le modèle de caméra etc…) et dans mon cas je peux avoir en sortie MJpeg. Alors pas de problème pour la caméra Wifi. Pour la C270 tout comme la clone camera RPi, et bien j’ai les format similaire à ce que le log j’ai posté. Dans la liste il y a MJpeg et même que la C270 et une Microsoft VX-700 utilise le MJpeg comme format par défaut.

Les TV Tuner c’est un peu plus complexe vu qu’il fau choisir l’entré sur la « caméra », et le format du signal (PAL/NSC) qui est aussi un caprice de la caméra physique. Après c’est options, ont peu voir que le YUV/RGB/MJpeg est supportés.

Bref, j’ai jamais vu de caméra de ma vie sans le support de MJpeg, ce qui me dit que ta caméra est soit destiné a un public précis ou une configuration précise.

Et bien ajoute le! :slight_smile:

Non… le détails ici est important…

C’est la version « Noir et blanc » et le Y12 n’est pas YU12, qui lui est un Y12 avec couleur, en simplifié. ET les deux formats sont pas pareil, il faut exactement le même format dans tout les détails.

Ici je n’ai jamais nommé 19 du à ce détails, alors tu le set idéalemen sur « 14 » ou le « 15 ».

bon, là je n’ai même plus le rectangle gris :frowning:

Dodo quand même pour le moment… je reprend les recherches demain

En tout cas un grand merci à toi !!

Je ne l’ai peut-être pas précisé mais c’est une caméra raspberry basique, la très classique v2.1
camera_v2_250px