Opened 5 years ago

Closed 5 years ago

#4885 closed defect (invalid)

DeckLink Device Not Freeing Nonpage Pool RAM

Reported by: bbostwick Owned by:
Priority: normal Component: avdevice
Version: git-master Keywords: decklink leak
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Summary of the bug:

When recording using my DeckLink? Mini Recorder on Windows 8.1 the RAM usage slowly climbs over time. Killing FFMPEG does not free the memory used, which led me to believe the device driver was at fault. Reviewing the decklink_dec.cpp I tried logging output to see if the cleanup case was being hit and I believe it is not!

My changes:

in ff_decklink_read_close

if (ctx->capture_started) {


av_log(avctx, AV_LOG_WARNING, "Flushed the DeckLink? streams!\n");


av_log(avctx, AV_LOG_WARNING, "Hello!\n");

My console output:

C:\Users\brian_000\Documents\recording>record-twitchtv-capture-card.bat test
Guessed Channel Layout for Input Stream #0.0 : stereo
Guessed Channel Layout for Input Stream #1.0 : stereo
[Parsed_amerge_3 @ 0000000000c8e6a0] No channel layout for input 1
[Parsed_amerge_3 @ 0000000000c8e6a0] Input channel layouts overlap: output layou
t will be determined by the number of distinct input channels
[swscaler @ 0000000017c94b60] deprecated pixel format used, make sure you did se
t range correctly
Larger timestamp than 24-bit: 0xffffffc3
[flv @ 0000000000c5aca0] Failed to update header with correct duration.
[flv @ 0000000000c5aca0] Failed to update header with correct filesize.
[decklink @ 0000000000bbf2c0] Hello'''

As you can see the cleanup case is never hit! My nonpage pool RAM ends up at 97% and WILL NOT be freed by the OS. I am not submitting a patch. I am trying to fix this myself, but I thought I'd bring it to attention. I am experimenting with also calling ctx->dli->FlushStreams?(), which is not done anywhere, but I assume it's unnecessary if the input stream is closed correctly, which I think it isn't.

The gist of how I am using FFMPEG:

% ffmpeg -threads 4 -loglevel warning ^
-thread_queue_size 512 -rtbufsize %rtbufsize% -f decklink -re -i "DeckLink Mini Recorder@14" ^
-thread_queue_size 32 -rtbufsize %rtbufsize% -f dshow -i audio=%microphone% ^
-filter_complex "[0:v]format=pix_fmts=yuv420p,fps=30,scale=960x540[vscaled];[0:a][1:a]amerge=inputs=2[amerged]" ^
-map [vscaled] -map [amerged] ^
-vcodec libx264 -preset %preset% -g %gop% -keyint_min %keyint_min% -b:v %vbr% -minrate %vbr% -maxrate %vbr% -bufsize %vbr% ^
-x264opts rc-lookahead=30:subme=4 ^
-acodec libmp3lame -b:a %abr% -ar 44100 ^
-flags:v +global_header -flags:a +global_header ^
-f flv "rtmp://" ^
-map 0:v ^
-vcodec mjpeg -q:v %quality% ^
-f mov "%output_path%\" ^
-map 0:a ^
-f wav "%output_path%\audio-video.wav" ^
-map 1:a ^
-f wav "%output_path%\audio-microphone.wav"

ffmpeg version N-75504-gaa6c43f

Patches should be submitted to the ffmpeg-devel mailing list and not this bug tracker.

Change History (3)

comment:1 Changed 5 years ago by bbostwick

Also if this does get solved I'm assuming we can't do anything about the leak over time? Is it possible to flush the streams periodically during encoding. This is probably a problem with the DeckLink? Driver not FFMPEG, but the cleanup on exit is clearly not happening.

comment:2 Changed 5 years ago by cehoyos

  • Keywords memory cleanup removed
  • Priority changed from important to normal

Please provide a minimal command line that allows to reproduce the issue together with the complete, uncut console output to make this a valid ticket.
Most of what you describe sounds like issues outside of FFmpeg though.

comment:3 Changed 5 years ago by bbostwick

  • Resolution set to invalid
  • Status changed from new to closed

I believe this is really the symptom of a too large rtbufsize. My rtbufsize was set to the maximum value; 2147480000.

"When you set the rtbufsize "too big" it was causing an integer overflow, and thus "buffering" directshow stuff *infinitely* (which is bad since it can't keep up with the incoming stream)." -rogerdpack

"ffmpeg -loglevel panic (and with the default rtbufsize, i.e. not setting it to anything)

which is why you don't see the dropped frames messages, but they're probably still there..." -rogerdpack

This is the source of the RAM leak and I think frame drops are normal over time, I was just viewing them as an error.

Note: See TracTickets for help on using tickets.