While I was writing a shell script (doing this the past several days) just a few minutes ago my PC fans spinned up without any seemingly reason. I thought it might be the baloo process, but looking at the running processes I see it’s names block-rate-estim . It takes 6.2% CPU time and is running since minutes, on my modern 8 core CPU. And uses up 252 KiB. The command is shown as block-rate-estim --help, which when I run on the commandline myself will just run the program without output and blocking until I end the process. Sounds alarming to me first. Is something mining going on?
I looked up where the command is coming from:
$ ls -l /usr/bin/block-rate-estim
.rwxr-xr-x 14k root 20 Dez 2023 /usr/bin/block-rate-estim
$ yay -F block-rate-estim
extra/libde265 1.0.12-1 [installed: 1.0.15-1]
usr/bin/block-rate-estim
$ yay -Si libde265
Repository : extra
Name : libde265
Version : 1.0.15-1
Description : Open h.265 video codec implementation
Architecture : x86_64
URL : https://github.com/strukturag/libde265
Licenses : LGPL3
Groups : None
Provides : None
Depends On : gcc-libs glibc
Optional Deps : ffmpeg: for sherlock265
qt5-base: for sherlock265
sdl: dec265 YUV overlay output
Conflicts With : None
Replaces : None
Download Size : 270,31 KiB
Installed Size : 783,53 KiB
Packager : Antonio Rojas
Build Date : Mi 20 Dez 2023 20:06:16 CET
Validated By : MD5 Sum SHA-256 Sum Signature
It’s still going on the background, I have no idea what this is. The thing is, I didn’t start any process that is related to video codec. Other than FreeTube being in the background with video in Pause mode since 2 hours or so. I use FreeTube since months and this never happened before, I see this block-rate-estim process the first time.
What should I do? I’m on an up-to-date EndeavourOS installation.
You must log in or register to comment.
block rate estim is part of the libde265 package, a library for decoding h265 video.
i haven’t dealt with video decoding in a while but it looks like your paused video (encoded in space-saving h265, natch!) is what this library is being called for.
pstree would be a good start, but i’d bet it would just lead back to the browser you were watching the video in.
e: pstree is what i meant to say, fixed. pstree.x11 too!
Good to know its actually a part of the package and not something that is compromised. The strange thing is, this never happened before and I am using FreeTube for half a year or so. And the program started running after 1 or so pause (i don’t know how long, maybe half hour maybe 2 hours) of the video, so not sure what this might be doing. I forgot that the app was on a different virtual desktop, while I was editing a text file (Bash script). That’s why I got a little bit nervous.
BTW it wasn’t a browser, its FreeTube, a dedicated application to watch YouTube videos. When I think about, just since today morning FreeTube acted not normal, always taking long time to start. Which is resolved now. So you might be right that this is the connection. I will watch an eye on it and if this happens again, I will reply here (if I don’t forget) and make an issue on the issue tracker for this app. Thank you for the explanation. Right now there is nothing else to do for me.
Freetube won’t have anything to do with h265 as youtube does not serve that format in any way.
Maybe you have some sort of auto-completion plugin that attempts to parse
--helpoutput? And that particular binary doesn’t understand--helpprobably.Maybe try running pstree to see who spawns that process?
It could be something like that, as I use Neovim and have bunch of plugins and stuff installed (LazyVim). And I frequently update those plugins within Neovim. So it’s possible that a system software and one of those plugins (or LazyVim itself) does not match anymore. Good hint!
Unfortunately I restarted my system already, as it did not stop even after 10 minutes of waiting. It didn’t even stop my fans spinning, when logging out from my KDE session (however it could be that the fans just spin a little bit after closing app, to get normal temps?). So checking who spawns that process is no longer possible. I’m currently editing a file again and if this happens again, then I will check with pstree.
I think you may be able to log all started processes with strace or some similar tool, if you are interested
Oh yes! I know the name of this program but never looked into it. Well guess this would be an excellent use case. I saved a bookmark to remember using it when this issue occurs again. Thanks.
Btw, based on the name, and looking at the source, I think this block-rate-estim is a benchmark helper program for the libde265 video decoder. I think it takes in a file with log data (like debug output or something) and does some statistical calculation on it. My guess is the “block rate” is the speed/throughput.
It’s not available on Debian here (not part of any package, i.e. not installed/compiled, not sure why
FedoraArch would include this in the package tbh), since I think it’s supposed to be an internal dev tool or something like that.It expects two arguments: a tag (whatever that is) and a filename for input data. It definitely doesn’t understand
--helpand I suspect it endlessly loops when it doesn’t get valid filename as the second argument.I’m sticking to my hunch from my other comment, that it is one of your vim (or maybe shell) plugins. It possibly runs every binary installed on your system with
--help, to provide some sort of autocomplete or something like that. If that is the case, that seems like a bad idea honestly.I see no reason why FreeTube would run this, but if it did, it surely wouldn’t incorrectly run it with just
--helpas an argument.yay is an Arch package manager. Fedora doesn’t include this package due to patents. Arch does minimal customization so that’s probably part of it.
