[FFmpeg-trac] #8374(ffmpeg:new): Streaming video + audio to decklink causes duplicate frames and buffer underflows

FFmpeg trac at avcodec.org
Mon Nov 11 11:33:55 EET 2019

#8374: Streaming video + audio to decklink causes duplicate frames and buffer
             Reporter:  vschweitzer  |                     Type:  defect
               Status:  new          |                 Priority:  normal
            Component:  ffmpeg       |                  Version:  git-
                                     |  master
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
 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 [1].
 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

 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 [2].
 * 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
 * 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:

Ticket URL: <https://trac.ffmpeg.org/ticket/8374>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list