Configuration de ffserver pour gérer un gros flux webm

2

Je suis en train de configurer un ffserver pour les flux de vidéosurveillance avec 16 caméras - tous les canaux individuels diffusent bien avec une config comme:

<Feed 0.ffm>
File /tmp/0.ffm
FileMaxSize 5M
ACL allow 10.1.2.2
</Feed>

<Feed 0_webm.ffm>
File /tmp/0_webm.ffm
FileMaxSize 5M
ACL allow localhost
</Feed>

<Stream 0.mpg>
Feed 0.ffm
Format mpeg1video
NoAudio
VideoFrameRate 24
VideoBitRate 256
VideoSize 320x240
VideoBufferSize 40
VideoGopSize 12
</Stream>

<Stream 0.webm>
Feed 0_webm.ffm
Format webm
NoAudio
VideoCodec libvpx
VideoSize 320x240
VideoFrameRate 24
AVOptionVideo flags +global_header
AVOptionVideo cpu-used 0
AVOptionVideo qmin 1
AVOptionVideo qmax 31
AVOptionVideo quality good
PreRoll 0
StartSendOnKey
VideoBitRate 500K
</Stream>

Et les appels ffmpeg associés transformés en processus imminents:

ffmpeg -f video4linux2 -standard ntsc -i /dev/video0 http://10.1.2.1:8090/0.ffm

et

ffmpeg -f mpegvideo -i http://localhost:8090/0.mpg -vcodec libvpx http://localhost:8090/0_webm.ffm

Cependant, en ce qui concerne la vue d'ensemble de la grande grille 4x4 de tous les canaux, j'ai quelques problèmes avec la configuration de ffserver.conf. En utilisant cet appel ffmpeg transformé en un démon, je peux gérer de façon fiable environ 24-25 FPS (et j'ai vérifié que cela fonctionne en enregistrant dans un fichier local et en le lisant via ffplay):

ffmpeg -i http://localhost:8090/0.webm -i http://localhost:8090/1.webm -i http://localhost:8090/2.webm -i http://localhost:8090/3.webm -i http://localhost:8090/4.webm -i http://localhost:8090/5.webm -i http://localhost:8090/6.webm -i http://localhost:8090/7.webm -i http://localhost:8090/8.webm -i http://localhost:8090/9.webm -i http://localhost:8090/10.webm -i http://localhost:8090/11.webm -i http://localhost:8090/12.webm -i http://localhost:8090/13.webm -i http://localhost:8090/14.webm -i http://localhost:8090/15.webm -filter_complex "
nullsrc=size=1280x960 [bg];
[0:v] setpts=PTS-STARTPTS [v0];
[1:v] setpts=PTS-STARTPTS [v1];
[2:v] setpts=PTS-STARTPTS [v2];
[3:v] setpts=PTS-STARTPTS [v3];
[4:v] setpts=PTS-STARTPTS [v4];
[5:v] setpts=PTS-STARTPTS [v5];
[6:v] setpts=PTS-STARTPTS [v6];
[7:v] setpts=PTS-STARTPTS [v7];
[8:v] setpts=PTS-STARTPTS [v8];
[9:v] setpts=PTS-STARTPTS [v9];
[10:v] setpts=PTS-STARTPTS [v10];
[11:v] setpts=PTS-STARTPTS [v11];
[12:v] setpts=PTS-STARTPTS [v12];
[13:v] setpts=PTS-STARTPTS [v13];
[14:v] setpts=PTS-STARTPTS [v14];
[15:v] setpts=PTS-STARTPTS [v15];
[bg][v0] overlay=shortest=1 [bg];
[bg][v1] overlay=shortest=1:x=320 [bg];
[bg][v2] overlay=shortest=1:x=640 [bg];
[bg][v3] overlay=shortest=1:x=960 [bg];
[bg][v4] overlay=shortest=1:y=240 [bg];
[bg][v5] overlay=shortest=1:x=320:y=240 [bg];
[bg][v6] overlay=shortest=1:x=640:y=240 [bg];
[bg][v7] overlay=shortest=1:x=960:y=240 [bg];
[bg][v8] overlay=shortest=1:y=480 [bg];[bg]
[v9] overlay=shortest=1:x=320:y=480 [bg];
[bg][v10] overlay=shortest=1:x=640:y=480 [bg];
[bg][v11] overlay=shortest=1:x=960:y=480 [bg];
[bg][v12] overlay=shortest=1:y=720 [bg];
[bg][v13] overlay=shortest=1:x=320:y=720 [bg];
[bg][v14] overlay=shortest=1:x=640:y=720 [bg];
[bg][v15] overlay=shortest=1:x=960:y=720" http://localhost:8090/all_webm.ffm

le problème survient lors de la liaison au serveur ffserver - ni le processus ffmpeg ni le processus ffserver ne se bloquent, mais le flux est inaccessible (le travail du canal unique .webm est correct). J'ai essayé la même configuration que le plus petit .webm avec la résolution changée avec ceci:

<Feed all_webm.ffm>
File /tmp/all_webm.ffm
FileMaxSize 20M
ACL allow localhost
</Feed>

<Stream all.webm>
Feed all_webm.ffm
Format webm
NoAudio
VideoCodec libvpx
VideoSize 1280x960
VideoFrameRate 24
AVOptionVideo flags +global_header
AVOptionVideo cpu-used 0
AVOptionVideo qmin [1|10]
AVOptionVideo qmax [31|42]
AVOptionVideo quality good
PreRoll 0
StartSendOnKey
VideoBitRate [512|700|800|1024|3M|3686400]
</Stream>

Avec chaque combinaison des paramètres montrés entre parenthèses et quelques-uns, je ne me souviens plus. Quelqu'un at-il une configuration de travail pour diffuser des fichiers Webm volumineux avec ffserver?

Edit: Ajout des flux que j'utilise (pas de modification réelle, le flux all.webm est toujours interrompu de manière non spécifiée). J'aurais aussi dû l'inclure au départ, mais la sortie de ffplay est la suivante (elle se bloque indéfiniment):

ffplay http://10.1.1.15:8090/all.webm
ffplay version git-2013-03-17-ef3c888 Copyright (c) 2003-2013 the FFmpeg developers
  built on Mar 17 2013 19:21:22 with gcc 4.6 (Ubuntu/Linaro 4.6.3-1ubuntu5)
  configuration: --enable-gpl --enable-libass --enable-libfaac --enable-libfdk-aac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libspeex --enable-librtmp --enable-libtheora --enable-libvorbis --enable-libvpx --enable-x11grab --enable-libx264 --enable-nonfree --enable-version3
  libavutil      52. 19.101 / 52. 19.101
  libavcodec     55.  1.100 / 55.  1.100
  libavformat    55.  0.100 / 55.  0.100
  libavdevice    55.  0.100 / 55.  0.100
  libavfilter     3. 47.102 /  3. 47.102
  libswscale      2.  2.100 /  2.  2.100
  libswresample   0. 17.102 /  0. 17.102
  libpostproc    52.  2.100 / 52.  2.100
    nan A-V:  0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0

Une autre édition:

Testé avec les éléments suivants:

ffmpeg -r 29.97 -f lavfi -i testsrc -s 1280x960 -r 29.97 http://localhost:8090/all_webm.ffm

Ce qui fonctionne pour diffuser le flux de test (bien que lentement, il doit s’arrêter toutes les deux secondes pour rattraper son retard en chrome, échoue après la même période dans firefox) - n’a que 13 FPS. J'ai donc essayé de décomposer les parties de test et de conversion Webm comme suit:

ffmpeg -f lavfi -i testsrc -s 1280x960 -r 29.97 http://localhost:8090/all.ffm
ffmpeg -r 29.97 -f mpegvideo -i http://localhost:8090/all.mpg -r 29.97 -vcodec libvpx http://localhost:8090/all_webm.ffm

La première commande obtient plus de 29,97 FPS, la seconde à 13 FPS.

Je ne suis pas si inquiet à propos du FPS (13 FPS conviendrait pour la grille 4x4), mais cela me laisse penser que le problème peut exister entre la commande longue ffmpeg (avec l'option -format_complex) et l'importation dans ffserver malgré du fait qu’il enregistre un fichier .webm parfaitement valide lorsqu’il est envoyé dans un fichier local au lieu de ffserver - toujours besoin d’aide.

Une autre édition:

En ajoutant la queue de la grande sortie ffmpeg envoyée à http: // localhost: 8090 / all_webm.ffm ci-dessous, j'ai vu une sortie similaire dans les plus petits processus mpeg -> webm convertissant ffmpeg qui fonctionnent, mais la vitesse à laquelle elle diffère donc je ne pensais pas que cela importait (en enregistrant dans un fichier .webm local et en comptant la durée enregistrée en marchant devant l'une des caméras et en retournant au moment où j'ai arrêté le processus, les temps synchronisés et les la lecture a montré un mouvement fluide de 25 images par seconde), mais je ne connais pas suffisamment le processus pour l'exclure complètement (ce qui suit est la fin de la sortie de la console après avoir appuyé sur "q" pour arrêter ffmpeg):

[Parsed_overlay_26 @ 0x37464e0] Buffer queue overflow, dropping.
    Last message repeated 19 times
Buffer queue overflow, dropping. size=       4kB time=00:36:21.64 bitrate=   0.0kbits/s
[Parsed_overlay_25 @ 0x374db20] Buffer queue overflow, dropping.
    Last message repeated 28 times
[Parsed_overlay_17 @ 0x374ba40] Buffer queue overflow, dropping.
    Last message repeated 11 times
[Parsed_overlay_20 @ 0x374e3c0] Buffer queue overflow, dropping.
    Last message repeated 30 times
[Parsed_overlay_19 @ 0x374e4a0] Buffer queue overflow, dropping.
    Last message repeated 28 times
[Parsed_overlay_32 @ 0x3749b20] Buffer queue overflow, dropping.
    Last message repeated 17 times
[Parsed_overlay_24 @ 0x3745fc0] Buffer queue overflow, dropping.
    Last message repeated 2 times
[Parsed_overlay_23 @ 0x3751060] Buffer queue overflow, dropping.
Buffer queue overflow, dropping. size=       4kB time=00:36:22.28 bitrate=   0.0kbits/s
[Parsed_overlay_17 @ 0x374ba40] Buffer queue overflow, dropping.
    Last message repeated 6 times
Buffer queue overflow, dropping. size=       4kB time=00:36:23.04 bitrate=   0.0kbits/s
[Parsed_overlay_17 @ 0x374ba40] Buffer queue overflow, dropping.
    Last message repeated 22 times
Buffer queue overflow, dropping. size=       4kB time=00:36:23.68 bitrate=   0.0kbits/s
[Parsed_overlay_17 @ 0x374ba40] Buffer queue overflow, dropping.
    Last message repeated 10 times
Buffer queue overflow, dropping. size=       4kB time=00:36:24.12 bitrate=   0.0kbits/s
[Parsed_overlay_17 @ 0x374ba40] Buffer queue overflow, dropping.
    Last message repeated 9 times
Buffer queue overflow, dropping. size=       4kB time=00:36:24.84 bitrate=   0.0kbits/s
[Parsed_overlay_17 @ 0x374ba40] Buffer queue overflow, dropping.
    Last message repeated 1 times
Buffer queue overflow, dropping. size=       4kB time=00:36:25.32 bitrate=   0.0kbits/s
frame=54637 fps= 25 q=24.8 Lq=0.0 size=      48kB time=00:36:25.44 bitrate=   0.2kbits/s
video:172039kB audio:0kB subtitle:0 global headers:0kB muxing overhead -99.972099%
CoryG
la source

Réponses:

0

Avez-vous fourni un <feed all_webm.ffm> ... </feed>avant votre <Stream all.webm>? Je pense que cela devrait faire l'affaire, car FFserver ne sait probablement pas où se procurer le flux.

Si cela ne fonctionne pas, vous pouvez également tester votre flux depuis FFmpeg en utilisant ffplay http://localhost:8090/all_webm.ffm

Nick van Tilborg
la source
Je l'ai omis pour économiser de l'espace car les flux sont à peu près tous identiques, je vais modifier mon post pour afficher le flux que j'utilise.
CoryG
Ajout de la sortie ffplay aussi (il se bloque).
CoryG
Pourquoi as-tu essayé ffplay http://10.1.1.15:8090/all.webm? Je pensais qu'il était sur votre localhost: ffplay http://localhost:8090/all_webm.ffm?
Nick van Tilborg
L'adresse IP externe de l'hôte local est 10.1.1.15 - il s'agit d'un serveur Ubuntu et j'ai donc dû exécuter ffplay à partir d'un ordinateur externe (bureau Ubuntu). Le traitement vidéo a tous lieu le 10.1.1.15 (à l’exception de la lecture initiale, qui est celle du 10.1.2.2. 10.1.1.15 a une interface réseau distincte réglée sur 10.1.2.1, en particulier parce que les deux cartes de capture vidéo à 16 canaux sortent. d' un certain coup de chance de l' ingénierie, la gestion à la vie les colonnes montantes de serveur pci-x de leurs prises chaque fois insérés, malgré le fait qu'ils travaillent avec toutes les autres cartes PCI je dans le magasin et le travail de la vidéo pci dans d' autres machines).
CoryG
10.1.2.1 et 10.1.2.2 sont connectés via un câble croisé, 10.1.2.2 est une consommation d'énergie plutôt faible, il diffuse simplement des cartes pci vers 10.1.2.1/10.1.1.15 (j'ai essayé de le faire gérer également la conversion .webm, mais était trop lent pour cela alors je devais tout mettre après la première ligne ffmpeg de mon message sur le serveur vidéo principal [10.1.1.15/10.1.2.1]).
CoryG