ffmpeg command line for capturing (and recording) audio and video in 720p from decklink card using Windows 7

后端 未结 1 1778
予麋鹿
予麋鹿 2021-01-30 02:44

I am trying to capture audio and video from a blackmagic decklink capture card using Windows 7 @ 720p, but I cant seem to get the ffmpeg command line settings right.

ff

相关标签:
1条回答
  • 2021-01-30 03:17

    Finally got it working. My setup has this all running on a single machine.

    For taking the video and serving it via UDP I use the following command :

    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"
    
    • The -f dshow tells ffmpeg we need to use direct show.
    • -video_size 1280x720 sets the source size, since I am using a 720p60 source, this is it.
    • 702000k is really important since without it the realtime buffer would be full in a matter of seconds.
    • -framerate 60 tells ffmpeg the source is using 60fps.
    • The option: video="Decklink Video Capture":audio="Decklink Audio Capture" tells ffmpeg to use those device as input, but by specifying them in this fashion, the lag between audio and video will be substantially less (and/or gone).
    • -r 30 forces the output to be 30fps instead of the 60fps in source.
    • -threads 4 does what you think, use 4 threads.
    • -vcodec libx264 encodes the source stream to h264 while broadcasting.
    • -crf 0 sets the "constant rate factor" (quantizer scale) to 0, meaning lossless.
    • -preset ultrafast means we dont have any patience, so use as little compression as possible. This causes a high bitrate, but that's fine for my purpose.
    • -f mpegts option tells ffmpeg to use MPEG-TS packets, this will "force" ffmpeg to use a constant bitrate mpeg format, since mpeg itself is normally variable bitrate.
    • Finally the option udp://239.255.12.42:6666 specifies that we want to broadcast this stream to the multicast address 239.255.12.42 using port 6666 over udp. The reason I chose to use a multicast address here is simply because I need to display the stream (preview) and record at the same time, with as least processing as possible. This prevents me from having to copy the audio and video stream to two different network addresses.

    For capturing this video using VLC player, I open the following network streaming address :

    udp://@239.255.12.42:6666
    

    Finally for recording the stream I spawn a new process and issue the following command :

    ffmpeg -y -threads 4 -i udp://239.255.12.42:6666 -map 0 -acodec copy -vcodec copy output.mkv
    
    • The -y option is for always overwriting the file if it exists without questions.
    • The -threads 4 option does what you think, it uses 4 threads.
    • The -i udp://239.255.12.42:6666 connects to the stream we are broadcasting.
    • The -map 0 tells ffmpeg that we need all streams (both video and audio).
    • The -acodec copy and -vcodec copy are there to ensure that the streams are taken as is, instead of doing any compression/transcoding.

    The only thing left to do (which is a work in progress atm) is creating a c# gui for this. Basic workflow will be to spawn the stream process when the form loads. Use the vlc com+ control to display the video in the application.

    Then when the record button is pushed, spawn another process to record and stop that process to end the recording.

    I do however stop the stream when I start to record, this makes the recording/detection go much more smoothly. If the stream stays on and I start recording it will take some time before the recording process can "tune in" to the stream. By stopping the stream, starting the recording (which will do nothing until the stream is back on) and starting the stream again, the recording will pickup from the first frame without any problems.

    This small delay/flicker is totally acceptable for my purposes.

    0 讨论(0)
提交回复
热议问题