Flux rtsp et Portier Konx 02C

Bonjour
Je possede un portier video Konx 02C et je desire integre le flux dans Gladys, mais si je suis là, c’est que ça ne fonctionne pas. Pourtant apres maintes recherches pour trouver le flux, j’ai reussi à l’afficher dans VLC.
Voila l’adresse du flux :
rtsp://admin:Motdepasse@192.168.1.165:554/onvif1
Est ce que vous auriez une idée , de pourquoi ça ne fonctionne pas avec Gladys?
Merci d’avance

Tu as une erreur particulière ? Quelle est l’erreur ?

Est-ce que tu as plusieurs sources qui consomment le flux ? Certaines caméras ne sont pas capable d’être consommée par plusieurs clients

Bonsoir @pierre-gilles
Non je n’ai que Gladys, quand je le parametre. Parcontre en testant le flux fonctionne sur l’appli Yoosee et sur VLC en meme temps donc le portier gere plusieurs sources apparement.
L’erreur

Non , c’est l’erreur qu’il affiche normalement :
image
Par contre dans les logs j’ai ça :

2024-12-16T22:06:49+0100 <warn> getImage.js:77 () Error: Command failed: ffmpeg -rtsp_transport tcp -i rtsp://admin:#######@192.168.1.165:554/onvif1 -f image2 -vframes 1 -qscale:v 15 -vf scale=640:-1 /tmp/gladysassistant/camera-9f552bf5-683a-4265-8f96-caef4bfe08d0-324-49-6-22.jpg
ffmpeg version 5.1.6-0+deb12u1 Copyright (c) 2000-2024 the FFmpeg developers
  built with gcc 12 (Debian 12.2.0-14)
  configuration: --prefix=/usr --extra-version=0+deb12u1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-gnutls --enable-ladspa --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libdav1d --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libglslang --enable-libgme --enable-libgsm --enable-libjack --enable-libmp3lame --enable-libmysofa --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librabbitmq --enable-librist --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libsrt --enable-libssh --enable-libsvtav1 --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzimg --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx --enable-openal --enable-opencl --enable-opengl --enable-sdl2 --disable-sndio --enable-libjxl --enable-pocketsphinx --enable-librsvg --enable-libmfx --enable-libdc1394 --enable-libdrm --enable-libiec61883 --enable-chromaprint --enable-frei0r --enable-libx264 --enable-libplacebo --enable-librav1e --enable-shared
  libavutil      57. 28.100 / 57. 28.100
  libavcodec     59. 37.100 / 59. 37.100
  libavformat    59. 27.100 / 59. 27.100
  libavdevice    59.  7.100 / 59.  7.100
  libavfilter     8. 44.100 /  8. 44.100
  libswscale      6.  7.100 /  6.  7.100
  libswresample   4.  7.100 /  4.  7.100
  libpostproc    56.  6.100 / 56.  6.100
[rtsp @ 0x565b139cfe80] Nonmatching transport in server reply
rtsp://admin:########@192.168.1.165:554/onvif1: Invalid data found when processing input

L’erreur que tu vois est parce que Gladys demande du « transport tcp » pour avoir une image de caméra sans bavure, et que ta caméra ne semble pas adhérer au standard RTSP parfaitement en omettant de retourner le transport dans la réponse, et donc ffmpeg rejète la réponse de la caméra.

Apparement, c’est courant avec les caméras implémentées de manière « cheap » par le constructeur :grimacing:

Quand on voit la note Amazon de cet appareil, les commentaires ont l’air d’aller dans le même sens ^^

Je lis ce genre d’infos sur ce post :

Une solution serait de proposer un mode transport UDP dans Gladys, configurable depuis l’interface des caméras, après j’ai peur que dans ton cas tu finisse par avoir du coup des images corrompues comme c’est souvent le cas en UDP / en plus avec une caméra de mauvaise qualité…

bonjour @pierre-gilles
Donc je ne m’acharne pas alors?, c’est dommage pour moi.
Merci pour le temps que tu passes à nous depanner.

Je suis pas spécialiste mais si cela arrive jusqu’à vlc on peut peut être refaire partir de vlc le flux pour l’envoyer à gladys ???

En l’état, ça ne peut pas fonctionner en direct car le flux RTSP développé par Konx renvoie une réponse RTSP non-conforme au standard lorsque le flux est demandé en TCP (c’est un bug de Konx).

Je vois 2 options pour toi :

  • Court terme: Soit tu trouves un logiciel qui peut faire le pont entre ton Konx et Gladys, qui permettrait de lire le flux en UDP depuis ton Konx, et de le re-émettre en TCP pour Gladys. Un NVR en gros ! ça peut-être Frigate par exemple ( https://frigate.video/ ), ou ZoneMinder ( https://zoneminder.com/ ). Après, rien ne dit que ce NVR ne va pas être dans le même cas que Gladys, mais ça vaut le coup d’essayer, ils sont peut-être plus « ouvert » aux implémentations non-standard.
  • Moyen terme: Attendre qu’on développe un mode UDP forcé dans Gladys. Dans ce cas, je veux bien que tu créé une demande de fonctionnalité :slight_smile:

Dans tous les cas, ne t’attend pas à de la magie avec ce portail. Il est extrêmement mal noté… ça ne m’étonnerait pas que même en UDP ça nous fasse une image saccadée voir corrompue

Merci pour ton aide, je vais tenter de me debrouiller avec ce que tu m’indiques.
Je vais faire la demande de fonctionnalité meme si ça ne fonctionne pas avec mon appareil, ça ouvrir des options pour d’autres cameras peut etre?

1 « J'aime »