Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#8374 closed defect (invalid)

Streaming video + audio to decklink causes duplicate frames and buffer underflows

Reported by: vschweitzer Owned by:
Priority: normal Component: ffmpeg
Version: git-master Keywords: decklink
Cc: Marton Balint Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

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 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 [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 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.

[1]
The original mp4 file before re-encoding:
https://s3.amazonaws.com/senkorasic.com/test-media/video/big-buck-bunny/trailer/trailer_1080p.mov

[2]
The original ffmpeg-user thread:
https://lists.ffmpeg.org/pipermail/ffmpeg-user/2019-October/045732.html

Attachments (1)

duplicate_frames_in_decklink_stream.log (1.5 MB ) - added by vschweitzer 3 years ago.
The ffmpeg log showing at least one buffer underflow

Download all attachments as: .zip

Change History (6)

by vschweitzer, 3 years ago

The ffmpeg log showing at least one buffer underflow

comment:1 by vschweitzer, 3 years ago

I had trouble connecting to the FTP server and used the VideoLAN uploader instead. The file name is the same as mentioned in the ticket.

comment:2 by Marton Balint, 3 years ago

You should double check that your .mov file with uncompressed audio has _exactly_ the same audio and video length.

comment:3 by Marton Balint, 3 years ago

Cc: Marton Balint added

Ok, I can see that it is not. You should try creating the file with uncompressed audio this way:

ffmpeg -i trailer_1080p.mov -ac 2 -acodec pcm_s16le -vcodec copy -af atrim=end=32.48 trailer_uncompressed.mov

Now the length of audio and video should be the same (you can check with mediainfo). Decklink output looping (NO -re option!!!) should now just work.

comment:4 by Marton Balint, 3 years ago

Resolution: invalid
Status: newclosed

comment:5 by Carl Eugen Hoyos, 3 years ago

Keywords: decklink added
Note: See TracTickets for help on using tickets.