ffmpeg en ligne de commande pour la capture (et l'enregistrement) de l'audio et de la vidéo en 720p de carte decklink à l'aide de Windows 7

Je suis en train d'essayer de capturer l'audio et de la vidéo à partir d'une blackmagic decklink carte de capture à l'aide de Windows 7 @ 720p, mais je ne peux pas sembler obtenir le ffmpeg en ligne de commande paramètres de droit.

ffmpeg -list_devices vrai -f dshow -je factice

[dshow @ 02457a60] DirectShow video devices
[dshow @ 02457a60]  "Blackmagic WDM Capture"
[dshow @ 02457a60]  "Decklink Video Capture"
[dshow @ 02457a60] DirectShow audio devices
[dshow @ 02457a60]  "Decklink Audio Capture"

ffmpeg -list_options vrai -f dshow -je vidéo="Decklink Capture Vidéo"

[dshow @ 03c2ea20] DirectShow video device options
[dshow @ 03c2ea20]  Pin "Capture"
[dshow @ 03c2ea20]   pixel_format=uyvy422  min s=720x486 fps=29.97 max s=720x486 fps=29.97
[dshow @ 03c2ea20]   pixel_format=uyvy422  min s=720x486 fps=23.976 max s=720x486 fps=23.976
[dshow @ 03c2ea20]   pixel_format=uyvy422  min s=720x576 fps=25 max s=720x576 fps=25
[dshow @ 03c2ea20]   pixel_format=uyvy422  min s=720x486 fps=59.9402 max s=720x486 fps=59.9402
[dshow @ 03c2ea20]   pixel_format=uyvy422  min s=720x576 fps=50 max s=720x576 fps=50
[dshow @ 03c2ea20]   pixel_format=uyvy422  min s=1920x1080 fps=23.976 max s=1920x1080 fps=23.976
[dshow @ 03c2ea20]   pixel_format=uyvy422  min s=1920x1080 fps=24 max s=1920x1080 fps=24
[dshow @ 03c2ea20]   pixel_format=uyvy422  min s=1920x1080 fps=25 max s=1920x1080 fps=25
[dshow @ 03c2ea20]   pixel_format=uyvy422  min s=1920x1080 fps=29.97 max s=1920x1080 fps=29.97
[dshow @ 03c2ea20]   pixel_format=uyvy422  min s=1920x1080 fps=30 max s=1920x1080 fps=30
[dshow @ 03c2ea20]   pixel_format=uyvy422  min s=1280x720 fps=50 max s=1280x720fps=50
[dshow @ 03c2ea20]   pixel_format=uyvy422  min s=1280x720 fps=59.9402 max s=1280x720 fps=59.9402
[dshow @ 03c2ea20]   pixel_format=uyvy422  min s=1280x720 fps=60.0002 max s=1280x720 fps=60.0002

ffmpeg -list_options vrai -f dshow -je audio="Decklink de Capture Audio"

[dshow @ 047fea20] DirectShow audio device options
[dshow @ 047fea20]  Pin "Capture"
[dshow @ 047fea20]   min ch=1 bits=16 rate= 48000 max ch=1 bits=16 rate= 48000
[dshow @ 047fea20]   min ch=2 bits=16 rate= 48000 max ch=2 bits=16 rate= 48000
[dshow @ 047fea20]   min ch=4 bits=16 rate= 48000 max ch=4 bits=16 rate= 48000
[dshow @ 047fea20]   min ch=6 bits=16 rate= 48000 max ch=6 bits=16 rate= 48000
[dshow @ 047fea20]   min ch=8 bits=16 rate= 48000 max ch=8 bits=16 rate= 48000
[dshow @ 047fea20]   min ch=10 bits=16 rate= 48000 max ch=10 bits=16 rate= 48000
[dshow @ 047fea20]   min ch=12 bits=16 rate= 48000 max ch=12 bits=16 rate= 48000
[dshow @ 047fea20]   min ch=16 bits=16 rate= 48000 max ch=16 bits=16 rate= 48000

C'est le flux d'informations pour mon source vidéo/audio, connecté à la carte decklink port hdmi de

Stream #0:0: Video: rawvideo (UYVY /0x59565955), uyvy422(tv), 1280x720, 59.94 tbr, 10000k tbn, 59.94 tbc
Stream #0:1: Audio: pcm_s16le, 48000 Hz, stereo, s16, 1536 kb/s

En fin de compte, j'ai besoin d'afficher cette vidéo à l'écran. Et simultanément être en mesure de démarrer et d'arrêter l'enregistrement, tandis que l'aperçu continue à jouer.

Mon idée était d'utiliser ffmpeg pour capturer la vidéo et le signal audio et de le transmettre à un flux réseau (par exemple l'adresse 127.0.0.1:6666). Ensuite, utilisez VLC player pour afficher le flux (aperçu). Et, finalement, de démarrage ou d'arrêt d'un autre ffmpeg pour économiser la même flux sur le disque.

Dans mon esprit, cela fonctionne, mais je ne suis pas d'audio/vidéo expert donc si quelqu'un avec plus d'expérience peut aider, j'apprécierais.

Mise à jour:

J'ai été capable d'afficher de la vidéo à l'aide de ffplay, avec la commande suivante :

ffplay -f dshow -video_size 1280x720 -rtbufsize 702000k -framerate 60 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -threads 2

Prochaine étape est de streaming pour que je puisse voir le flux (aperçu) avec VLC.

Essayé d'utiliser cette commande :

ffmpeg -f dshow -video_size 1280x720 -rtbufsize 702000k -framerate 60 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -threads 2 -f mpegts rtp://127.0.0.1:6666?pkt_size=188?buffer_size=65535

Qui ne donne pas toutes les erreurs, il semble fonctionner. Mais quand j'essaie d'ouvrir le flux dans VLC j'obtiens l'erreur suivante :

SDP requis:
Une description SDP est le format requis pour recevoir le flux RTP. Notez que le protocole rtp://Uri ne peut pas travailler avec dynamique de la RTP payload format (65).

Après un peu de lecture, il semble que je ne devrais pas être en streaming rtp://, mais plutôt à udp://

Commande devient :

ffmpeg -f dshow -video_size 1280x720 -rtbufsize 702000k -framerate 60 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -threads 2 -f mpegts udp://127.0.0.1:6666?pkt_size=188?buffer_size=65535

Et quand j'essaie de l'ouvrir dans VLC je n'obtiens pas d'erreur, pas d'avertissement, mais pas de vidéo.

Temps pour un peu plus de lecture.

Mon vote ici serait que vous vous attendez trop de ffmpeg. Utiliser directshow et construire une application (Il ressemble à un enregistreur).
Je dois dire que c'était mon intention première. Donc, je suis allé de l'avant et a rapidement réalisé le défi que j'ai eu était avec la conversion de l'image de la source en temps opportun. Cela est dû au fait que la source est de 8 bits YUV422. Alors j'ai parlé à la prise en charge de développeur @ blackmagic pour voir ce qui pourrait être la meilleure option pour les utiliser. Ils m'a indiqué libav. Et vu qu'il est utilisé dans ffmpeg, j'ai pensé que je pourrais aussi bien essayer cette voie.
Il est récemment ajoutée "native" decklink périphériques d'entrée/sortie dans FFmpeg, ainsi, FWIW
J'ai eu une grande résolution avec ton post, j'ai ajouter une page à propos de blackmagic sur le ffmpeg site web. J'ai eu un 4k carte de sorte qu'il n'était pas la même ligne et je me devais de -vsync chute afin d'éviter les problèmes de timestamp

OriginalL'auteur Huron | 2013-10-06

30

A finalement obtenu ce travail. Mon installation a cette tous en cours d'exécution sur un seul ordinateur.

Pour prendre la vidéo et de le servir via UDP-je utiliser la commande suivante :
```
ffmpeg -f dshow -video_size 1280x720 -rtbufsize 702000k -framerate 60 -i video="Decklink Video Capture":audio="Decklink Audio Capture" -r 30 -threads 4 -vcodec libx264 -crf 0 -preset ultrafast -f mpegts "udp://239.255.12.42:6666"
```
- La -f dshow dit ffmpeg nous avons besoin d'utiliser direct show.
- -video_size 1280x720 définit la source de taille, étant donné que je suis en utilisant un 720p60 source, c'est ça.
- 702000k est très important car sans elle, le temps réel de la mémoire tampon soit plein dans une affaire de secondes.
- -framerate 60 dit ffmpeg de la source à l'aide de 60fps.
- L'option: video="Decklink Video Capture":audio="Decklink Audio Capture" dit ffmpeg à l'utilisation de ces périphériques en entrée, mais en les spécifiant dans ce mode, le décalage entre l'audio et la vidéo sera beaucoup moins (et/ou disparu).
- -r 30 forces de la sortie à 30fps au lieu de le 60fps dans la source.
- -threads 4 est-ce que vous pensez, 4 threads.
- -vcodec libx264 code de la source de flux h264 alors que la radiodiffusion.
- -crf 0 définit la "constante du taux de facteur" (quantification de l'échelle) à 0, sans perte de sens.
- -preset ultrafast signifie que nous n'avons pas le tout de la patience, afin de l'utiliser comme peu de compression possible. Cela provoque un débit élevé, mais c'est bien pour mon but.
- -f mpegts option indique ffmpeg pour utiliser MPEG-TS de paquets, ce sera la "force" de ffmpeg pour utiliser un débit constant format mpeg, depuis mpeg lui-même est généralement un débit variable.
- Enfin l'option udp://239.255.12.42:6666 spécifie que nous voulons diffuser ce flux à l'adresse de multidiffusion 239.255.12.42 en utilisant le port 6666 sur udp. La raison j'ai choisi d'utiliser une adresse de multidiffusion ici est tout simplement parce que j'ai besoin d'afficher le flux (preview) et d'enregistrer en même temps, avec le moins de traitement possible. Cela m'empêche d'avoir à copier les flux audio et vidéo à deux adresses réseau.
Pour capturer cette vidéo à l'aide du lecteur VLC, j'ouvre la suite de la diffusion en continu adresse :
```
udp://@239.255.12.42:6666
```
Enfin pour l'enregistrement du flux I frayer un nouveau processus et exécutez la commande suivante :
```
ffmpeg -y -threads 4 -i udp://239.255.12.42:6666 -map 0 -acodec copy -vcodec copy output.mkv
```
- La -y option est toujours d'écraser le fichier, s'il existe, sans poser de questions.
- La -threads 4 option ne ce que vous pensez, il utilise 4 fils.
- La -i udp://239.255.12.42:6666 se connecte au flux de nous avons de la diffusion.
- La -map 0 dit ffmpeg que nous avons besoin de tous les flux (vidéo et audio).
- La -acodec copy et -vcodec copy sont là pour veiller à ce que les flux sont pris comme est, au lieu de faire de la compression/transcodage.
La seule chose qui reste à faire (ce qui est un travail en cours atm) est la création d'un c# gui pour cela. Flux de production de base sera de lancer le flux de processus lors du chargement du formulaire. Utiliser le vlc com+ contrôle pour afficher la vidéo à la demande.

Puis lorsque le bouton d'enregistrement est poussé, de générer un autre processus d'enregistrement et d'arrêter ce processus à mettre fin à l'enregistrement.

Toutefois, j'ai arrêter le flux lorsque j'ai commencer à enregistrer, ce qui rend l'enregistrement/la détection d'aller beaucoup plus en douceur. Si le flux reste allumé et j'ai commencer l'enregistrement, il faudra un certain temps avant que le processus d'enregistrement peut "brancher" sur le flux. En arrêtant le flux, le début de l'enregistrement (qui ne fait rien jusqu'à ce que le flux est de retour sur) et le démarrage du flux de données, l'enregistrement de ramassage à partir de la première image sans aucun problème.

Ce petit retard/flicker est tout à fait acceptable pour mes fins.

Pourriez-vous mesurer le retard en ms? est-il plus de 100ms? ou secondes ?
C'est une question de mme pas secondes. Plus dans la gamme de 100ms-300ms
Oui, c'est là que j'ai atterri ainsi, n'est-ce pas 100ms mais > 200ms <300ms. Est ce que tu dis vlc ne pas utiliser de cache? Faire la même chose sur linux est un gâchis, il n'y a pas d'entrée d'un pilote pour linux pris en charge avec ffmpeg. Cependant, je vais tester votre configuration.
Pour mon but, je n'ai pas dis vlc perdre le cache, mais cela dépend de votre besoin, je suppose.
J'ai été en utilisant la dernière nouvelle Zeranoe FFmpeg Construire qui a été disponible à ce moment, vous pouvez les trouver ici : ffmpeg.zeranoe.com/builds Mais à chaque fois j'ai eu un écran noir, c'était en raison d'un décalage sur la vidéo source et les videosize/framerate options. Donc, assurez-vous de vérifier ces.

OriginalL'auteur Huron

Vous devez vous connecter pour publier un commentaire.