[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) {
ctx->dli->StopStreams();
ctx->dli->DisableVideoInput();
ctx->dli->DisableAudioInput();
''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 at 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://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