[BUG] Handbrake CLI bundled with latest 2.4.7 (July) has memory leak


I downloaded and used the latest 64 bit version of mcebuddy and converting a 1.6 gb file the handbrakecli.exe memory usage climbed to 100% (of 32GB) till it locked up my computer. I went to handbrakes website and downloaded CLI stable 64bit 1.0.7 and the issue went away for the same file.

(RBoy) #2

Thanks for letting us know. Can you upload the original video that caused you to detect this issue so we can put it into our testing suite. None of our current test video have caused the issue so far so this would be a good addition.

You can find the upload FTP server details on the ReadMe post


Unfortunately, I have already successfully converted the file, so I deleted the original. I am attaching my profiles and config if it helps.mcebuddy.conf (5.9 KB)
profiles.conf (17.1 KB)
The profile used was the first one. (MP4 Matthew’s Custom 16:9 Rip 23.976)

(RBoy) #4

Thanks. 1.0.7 is undergoing testing and will be included in the next release if there are no issues.

(RBoy) #5

Update on this, the latest handbrake stable version 1.0.7 hangs when using Intel QuickSync encoding with some test files. So we cannot update handbrake just yet until they fix the issue. I’ll leave this open for now. If you do come across another file with the memory leak issue please upload it to the server.


I compiled the latest HandBreak package from the git master branch. The nightly builds are still a few days behind and do not have the sound and QSV fix that this build does. handbreakCLI_20170716_b77f66d.zip

(RBoy) #7

In the next major release 2.4.8 we’re planning on overhauling the H/W encoding to improve performance. Will update the handbrake version in 2.4.8 release.


I have encountered this error again. I have uploaded my profile, config, and video file to the ftp folder with a short description text file.

(RBoy) #9

We can replicate the issue. First upgrade to the latest nightly build of handbrake, it will solve the 100% memory issue.

Second, your file is corrupted:, it has EOF’s (end of file) in the middle of the stream

hb_ts_stream_decode - eof

If you’re recording this OTA then you have a faulty TV tuner driver/firmware which is inserting EOF’s in the middle of the file.

(RBoy) #10

I also noticed that you’ve removed the -ss 5 from the remux profile and your custom profile, those are there to help in situations like this when files startings are corrupted. Try adding it back and it should work fine.


This time it wasn’t an OTA, it was a web rip. (Hence the removal of the -ss 5, I wanted to keep the first 5 seconds of the video). Could you perhaps help me convert my handbrake profile to an ffmpeg profile with the -ss 5? My thinking is, I’ll order them handbrake,ffmpeg and have the handbrake without the -ss 5 and the ffmepg with. So that when handbrake fails on one like this, it automatically goes to the -ss 5 and that way I only lose those 5 seconds when I absolutely have to. I’ve already tried to convert to ffmpeg, but I’m not nearly as familiar with it as I am with handbrake

(RBoy) #12

This has been fixed in today 2.4.8 BETA build. We’ve also added support for quicksync hardware decoding with this build and various other hardware performance optmizations.

(Geoffrey Morin) #13

Yeah…I noticed that while back. I just downloaded the newest CLI release and replaced it in the MCEBuddy install directory. Fixed my HW encoding problem with QuickSync and Intel HD Graphics 530, too.