[FFmpeg-trac] #4885(avdevice:new): DeckLink Device Not Freeing Nonpage Pool RAM

FFmpeg trac at avcodec.org
Sun Sep 27 08:46:42 CEST 2015

#4885: DeckLink Device Not Freeing Nonpage Pool RAM
             Reporter:  bbostwick    |                     Type:  defect
               Status:  new          |                 Priority:  important
            Component:  avdevice     |                  Version:  git-
             Keywords:  decklink     |  master
  memory leak cleanup                |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
 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

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

 My console output:

 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
 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 at 14" ^
 -thread_queue_size 32 -rtbufsize %rtbufsize% -f dshow -i
 audio=%microphone% ^
 -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://live-jfk.twitch.tv/app/" ^
 -map 0:v ^
 -vcodec mjpeg -q:v %quality% ^
 -f mov "%output_path%\video.mov" ^
 -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.

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

More information about the FFmpeg-trac mailing list