Streaming video + audio to decklink causes duplicate frames and buffer underflows
|Reported by:||vschweitzer||Owned by:|
|Cc:||Marton Balint||Blocked By:|
|Blocking:||Reproduced by developer:||no|
|Analyzed by developer:||no|
I am trying to stream audio and video in an endless loop from a file to
a DeckLink Duo 2 on Windows 10. When streaming in this loop,
ffmpeg reports duplicated frames approximately at the time
the loop starts anew. The command I'm using is the following:
.\ffmpeg.exe -v 9 -loglevel 99 -report -re -stream_loop -1 -i trailer_stereo.mp4 -pix_fmt uyvy422 -f decklink "81:4108a8c0:00000000"
where trailer_stereo.mp4 is a file containing a h264 stream at 25fps
and a resolution of 1920x1080 and an aac stream at 48000Hz.
The test file was created by converting a mp4 with 5.1 audio to stereo
and re-encoding it with a lower bitrate to fit the 10 MB.
The original file is linked at .
The re-encoded sample file (~9MB, stereo audio) on the ftp server
(upload.ffmpeg.org, according to https://ffmpeg.org/bugreports.html)
should be named "duplicate_frames_in_decklink_stream.mp4".
The command to get this sample file from the original is:
.\ffmpeg.exe -i .\trailer_1080p.mov -b:v 2M -vcodec h264 -acodec aac -ac 2 trailer_stereo.mp4
After approximately every loop there seems to be a buffer underrun
for both video and audio and a few frames are duplicated.
When running this for a longer time period the decklink stream becomes
unusable, as audio and video drift apart.
What I tried already:
- Asking the mailing list. The thread can be found at .
- Streaming without audio "fixes" the issue, as no duplicates appear. Adding the -an option to the either the encoding or streaming command works. No duplicates are reported.
- The original video and audio tracks are not of equal length. When re-encoding with the -shortest option and starting the stream again, no buffer overrun is explicitly reported, but duplicate frames still appear.
- In the ffmpeg-user mailing list someone suggested dropping the -re option and trying with uncompressed audio. I tried re-encoding the audio track with -acodec pcm_s16le and streaming without -re. Sadly, neither of these options fixed the issue.
The original mp4 file before re-encoding:
The original ffmpeg-user thread: