Un pipeline de GStreamer - en cours d'exécution sur cet environnement:étals uvch264src lors de la capture de Logitech C920 dans l'obscurité
- Raspberry Pi 3
- Classe 10 sdcard Sandisk 8 Go
- Raspbian Jessie, tous mis à jour
- Logitech C920 USB 2 webcam
- Gstreamer 1.8 compilé à partir de la source
- Aucun périphérique ou périphérique USB supplémentaire
- 2A d'Apple Alimentation USB (chargeur iPad)
- testé à la fois avec et sans concentrateur USB pour connecter le C920
Il capture des images H264 ([email protected]). Mon pipeline prend la sortie codée H264 du C920, et le té. Il capte également (alsa) l'audio du C920, le compresse en AAC, et le tee en est ainsi. Une jambe des deux tees va directement dans un muxer FLV, puis sur le disque pour la sauvegarde. La deuxième partie du tee est décodée (en utilisant OpenMax), puis recomprimée à un débit inférieur (encore une fois, OpenMax), et enfin, muxed FLV, et poussé à un serveur RTMP pour la visualisation en direct.
En fin de compte, le résultat ressemble fondamentalement ceci:
CPU se trouve à environ 50% de 400% (quad core :) souvenez-vous)
Maintenant pour la partie amusante ..
J'ai eu tout ce travail - parfaitement. Ensuite, j'ai fermé tout cela, et pris une pause de récompense. J'y suis revenu le soir, j'ai démarré le code ... et ça a duré environ 10 secondes, puis le pipeline a calé. Il n'arrêtait pas, ne faisait pas de pause, ou d'erreur - il a juste bloqué - les paquets ont cessé d'être écrits sur le disque et le flux.
Il y avait des avertissements et des erreurs, mais je l'avais vu ces derniers avant et ils n'a eu aucune incidence sur le flux résultant, mais maintenant, pour une raison - ils étaient terminaux à la santé du pipeline:
0:01:31.219560984 4075 0x1445400 WARN audiobasesrc gstaudiobasesrc.c:864:gst_audio_base_src_create:<alsasrc0> create DISCONT of 708160 samples at sample 2904320
0:01:31.219736087 4075 0x1445400 WARN audiobasesrc gstaudiobasesrc.c:869:gst_audio_base_src_create:<alsasrc0> warning: Can't record audio fast enough
0:01:31.219774941 4075 0x1445400 WARN audiobasesrc gstaudiobasesrc.c:869:gst_audio_base_src_create:<alsasrc0> warning: Dropped 708160 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
WARNING: from element /GstPipeline:pipeline0/GstAlsaSrc:alsasrc0: Can't record audio fast enough
Additional debug info:
gstaudiobasesrc.c(869): gst_audio_base_src_create(): /GstPipeline:pipeline0/GstAlsaSrc:alsasrc0:
Dropped 708160 samples. This is most likely because downstream can't keep up and is consuming samples too slowly.
Alors, après avoir sorti les petits poils qui me restaient, je l'ai emballé et l'ai appelé une nuit. Ce matin, je l'ai attrapé à nouveau, prêt à repartir à zéro. Je démarre le code, et ... ça marche encore ... pas de hoquet !! Que se passe t-il ici???
La seule chose qui a changé entre travailler, ne pas travailler, puis travailler à nouveau - était le moment de la journée!
Puis j'ai eu une idée. J'ai couru le code, pendant quelques minutes. Pas de hoquet, tout va bien ... alors, j'ai mis l'appareil photo dans mon sac d'ordinateur portable, donc il ne pouvait rien voir. Après 10 secondes, le pipeline a calé !!!
J'ai simplifié le pipeline vers le système de fichiers (en supprimant les tés, les éléments OMX et rtmpsink), et j'ai relancé les tests. Cette fois-ci, il ne s'est pas complètement arrêté, mais j'ai reçu les avertissements "Impossible d'enregistrer du son assez rapidement", et le fichier qui en résultait présentait des pertes audio significatives. Donc, il semble que le Logitech C920, lorsqu'il est dans un environnement sombre, semble s'étrangler d'une manière ou d'une autre.Quelque chose d'autre que j'ai remarqué, je ne sais pas si c'est lié ... mais j'ai toujours eu un bruit de haute fréquence oscillante (environ 16khz) dans mes enregistrements. Si je tiens l'appareil photo à la hauteur de mon oreille, je peux effectivement entendre le même son émis par l'appareil photo. Si je couvre l'objectif de l'appareil photo, la tonalité s'arrête. Si j'éteins la mise au point automatique sur l'appareil photo, ET que le niveau de mise au point absolu est réglé sur "0", le bruit presque disparaît également. Je sais que ce n'est pas une caméra ratée, car j'ai environ 6 d'entre eux, et ils se comportent tous de la même façon. Je sais aussi ce n'est pas une mauvaise Raspberry Pi, parce que je l'ai essayé cela sur tous ces
- 3 * Raspberry Pi 3
- 1 * Raspberry Pi 2 B +
- 2 * Raspberry Pi B +
Quelqu'un peut-il nous éclairer à ce sujet?
=====================================
Notes complémentaires:
- La capture de mjpeg (sans activer le codeur h264 sur l'appareil photo) empêche le bruit audible provenant de l'appareil photo. Indique que le bruit est causé par le DSP de l'appareil photo. Capturer mpjeg fait quelque chose d'intéressant ... le fichier vidéo résultant semble avoir laissé tomber beaucoup d'images pendant que l'appareil photo était dans l'obscurité ... donc une fois qu'il est à nouveau dans la lumière, la vidéo est en avance sur l'audio par plusieurs secondes.
Salut Mark - êtes-vous sûr de cela? Le rapport de problème concerne les flux H264, pas le flux mjpeg. Pouvez-vous fournir un lien vers le correctif? Je ne vois rien de pertinent ici: https://github.com/GStreamer/gst-plugins-bad/commits/1.12/sys/uvch264/gstuvch264_mjpgdemux.c – Adam
Certains sur le problème et l'emplacement - en dépit de cela dit mjpeg_demux.c il gère tous les flux de caméras. Besoin de vérifier si elle est arrivée. Va poster un patch ici sinon, mais mieux si ça passe par l'équipe de Gstreamer. – Markw63
https: // github.com/GStreamer/gst-plugins-bad/arbre/maître/sys/uvch264/gstuvch264_mjpgdemux.c a le patch - si vous regardez les lignes 662 pour environ 30 lignes, vous verrez l'effet sur h264. Je ne suis pas sûr que votre miroir soit à jour avec la branche principale (il y a 7 jours). – Markw63