After upgrading to Ubuntu 22.04, which includes Handbrake 1.5.1, the subtitles generated by HandBrakeCLI seem wrong — at least when played with VLC version 3. They have a fixed (to my taste ugly) font that I cannot change, and they show a *big* shadow that I cannot remove. This is an example (snapshot from actual Buffy converted DVD shown under _Fair Use_ provision): These are the settings (actual screen capture of the settings dialog box): You can see that there is no shadow, no outline, the configured font is DejaVu Sans, which is not what the actual subtitles show. Notice: the subtitles are not "burned" onto the video — I can enable/disable them. The workflow to go from my DVDs to individual .mkv files for each episode is as follows: - Run dvdbackup --mirror to create an image of the DVD on my hard drive (directory Buffy-S2D2, subdirectory VIDEO_TS and so on). - Then, run the following script to use HandBrakeCLI to encode the episodes:

#!/bin/bash
    
SHOW="Buffy"
SEASON="2"
DISC="2"
    
SRC="/home/cal-linux/Videos/Buffy-S$SEASON""D$DISC"
    
DIR="/home/cal-linux/tv/Buffy-the-Vampire-Slayer"
QUALITY=16.0
HIGHQUALITY=12.0
    
T1="05--Reptile-Boy"
T2="06--Halloween"
T3="07--Lie-to-Me"
T4="08--The-Dark-Age"
    
Q1=$QUALITY
Q2=$HIGHQUALITY
Q3=$HIGHQUALITY
Q4=$QUALITY
   
CC1=HandBrakeCLI --scan -i $SRC -t 1 2>&1 | grep "Closed Caption" | grep -v VOBSUB | cut -f2 -d"+" | cut -f1 -d","
CC2=HandBrakeCLI --scan -i $SRC -t 2 2>&1 | grep "Closed Caption" | grep -v VOBSUB | cut -f2 -d"+" | cut -f1 -d","
... (same for the remaining episodes)

## The above commands, in this case for this DVD, assign 4 to each of the variables CC1 to CC4 (that happens to be the "track number" for the English captions)

HandBrakeCLI --decomb --deinterlace --markers -e x264 --quality $Q1 --two-pass --no-turbo --encoder-level 5.2 --encoder-preset veryslow --subtitle $CC1 -i $SRC -t 1 -o "$DIR/$SHOW-S$SEASON""E$T1.mkv"
.... (similar for the other three episodes)

The thing is, this is the _exact same script_ that I had used two or three years ago to encode these same DVDs — except for the --decomb --deinterlace switches (my recent discovery/noticing these features is what prompted me to repeat the encoding of my Buffy DVDs). When I encoded these DVDs something like two or three years ago (back then, running Ubuntu 18.04, which I believe included Handbrake 1.3), the subtitles worked as expected. Now, re-doing the same DVDs with the same command (other than decombing and deinterlacing), the subtitles come out "wrong". This is a sample (a screenshot, taken just now) of one of the originally encoded files, showing the subtitles as they should show (i.e., respecting the settings of the player): I'm puzzled as to why this is happening, but more importantly I'm interested in: how do I fix it?

I'm looking for an alternative to Handbrake. Sadly, it doesn't support VA-API, so you have to install separate support for QSV/VCN/NVENC. While I don't know how bad the situation with Intel and NVIDIA is, the situation for AMD is abysmal. To get hardware encoding for Handbrake, you need to install the AMDGPU-Pro Stack and the separate AMF module. AMDGPU support for various Linux distributions is slim at best, so that's basically no option for many. On the other hand, it's a really great toolbox. Sure, you can simply use FFMPEG, but that's not really a practical option as you have to do too much googling to find anything. Does anybody know any alternative, like Handbrake with added VA-API support, or a similarly good GUI for FFMPEG?

I'm encoding video in 6 instances of Handbrake, but CPU usage is never above 85%. Why is this/how do I diagnose the issue?

Passing CFLAGS and CXXFLAGS to a HandBrake build for the latest version (v1.3.3 at the time of this writing) will work until you add -flto which will **FAIL** the whole build. How to build HandBrake with LTO option -flto and as a stretch goal, with FDO as well (feedback directed optimisation aka FDO aka PGO)? Most of the codecs within HandBrake are developed with "hand-coded" assembly, so many assert that the compiler optimisation gains would not be that much. I would like to test and challenge that assertion!

Trying to load the preset offered here , after saving as json and importing the preset, I cannot enable it. It is absent in the list of presets under any category. And I don't see a separate custom category. What am I missing? This is on Linux Mint 19.2 Xfce, Handbrake 1.1.0

I have a lot of DVD isos (I also have the physical DVD's, but I have ripped them, so they shouldn't be needed for this), of various TV series. Each DVD contains several episodes of the series, but typically several audio tracks and sets of subtitles. Now I'd like to make a series of files, each one containing just one episode, and just one audio track and (in most cases) no subtitles. As space is not really an issue, but quality matters to me, I would prefer if it can be done with no new encoding (it is theoretically impossible that it improves quality, that would require magic), and it takes time/CPU cycles that is not needed. As long as my XMBC/OpenElec/Kodi (I don't care about those things, so I don't know what is the relevant component to name here, those are the names I was able to quickly find in it's "setup" menu) can play the result I don't really care about the format(s) involved. I've found out that HandBrake can do something, but many of it's options are greek to me, and what I've managed to get it to do seems to involve re-encoding. Any advice on how I can accomplish what I want? (I want to run this on a Debian box)

Handbrake new VP9 codec is grayed out and could not be used. I installed Linux Mint fresh from ppa repo that is referenced on their homepage. libav and the vpx-tools are installed. What have I missed? What can I check?

**TLDR:** How do I run handbrakecli, get progress **and** ETA, pipe into dialog without flickering. **Details:** I have a script that finds all video files in a directory and then runs handbrakecli on them one at a time. Everytime handbrakecli runs it spits out a bunch of information about the file etc. and then the line: Encoding: task 1 of 1, 3.30 % (295.53 fps, avg 303.23 fps, ETA 00h02m54s) In my script I pipe the handbrakecli command to some other commands to filter out everything except the progress and then I pipe that to dialog like so: **Snippet 1** HandBrakeCLI --preset "Normal" -i "$f" -o "$DEST" | \ stdbuf -o0 tr -s '\r' '\n' | \ stdbuf -o0 grep -oP '(?<=, )\d+(?=\.\d\d \%)' | \ dialog --gauge "$DIALOG_MSG" 10 70; This works fine. It shows the progress and it doesn't flicker. Second task was to come up with a way to show both the progress AND the ETA and this is what I came up with: **Snippet 2** HandBrakeCLI --preset "Normal" -i "$f" -o "$DEST_FULL_FILE" | \ stdbuf -oL tr -s '\r' '\n' | \ while read -r str; do local REMAINING=$(echo "$str" | grep -oP "(?<=ETA )\d\dh\d\dm\d\ds(?=\))"); local PROGRESS=$(echo "$str" | grep -oP "(?<=, )\d+(?=.\d\d)"); echo "$PROGRESS" | dialog --gauge "$DIALOG_MSG Time remaining: $REMAINING" 10 70; done This works but the dialog window flickers. I don't know if it's performance related (doubt it) or if the whole *while read* loop just doesn't work well with dialog. I also tried doing it without piping to dialog but that just showed dialog once and then didn't update it at all. **Snippet 3** HandBrakeCLI --preset "Normal" -i "$f" -o "$DEST_FULL_FILE" | \ stdbuf -oL tr -s '\r' '\n' | \ while read -r str; do local REMAINING=$(echo "$str" | grep -oP "(?<=ETA )\d\dh\d\dm\d\ds(?=\))"); local PROGRESS=$(echo "$str" | grep -oP "(?<=, )\d+(?=.\d\d)"); dialog --gauge "$DIALOG_MSG Time remaining: $REMAINING" 10 70 $PROGRESS; done Finally I tried this: **Snippet 4** HandBrakeCLI --preset "Normal" -i "$f" -o "$DEST_FULL_FILE" | \ stdbuf -o0 tr -s '\r' '\n' | ( read -r str; local REMAINING=$(echo "$str" | grep -oP "(?<=ETA )\d\dh\d\dm\d\ds(?=\))"); local PROGRESS=$(echo "$str" | grep -oP "(?<=, )\d+(?=.\d\d)"); echo "$PROGRESS"; ) | dialog --gauge "$DIALOG_MSG Time remaining: $REMAINING" 10 70; And that didn't work out well at all. I'm aware there are some fundamental things wrong here.

I am about to convert a lot of old MKV files encoded with x264 , which at the moment are un-downloadable, to more efficient HEVC (x265, H.265) format, using HandBrake software. My system being Debian Jessie 8.6, fully updated. I have installed handbrake and x265 packages from official repositories. The problem is, I can't seem to be able to choose x265 in HandBrake . On Linux Mint 18, there is no problem, it's just there. On Debian 8.6, there is a package called handbrake, on Linux Mint 18 I have added a PPA and installed handbrake-gtk. Versions seem to matter in this case: Debian: **0.9.9 (x86_64)** Mint: **0.10.5 (x86_64)**

On my CentOS 7 (64 bit) machine some strange directories are appearing in the root directory / I can't work out what's causing it, if I delete them they slowly start to reappear. Here is a sample: drwxr-xr-x 2 root root 4096 Apr 19 09:15 Y-8f9479b39a92bac7-0000000000 drwxr-xr-x 2 root root 4096 Apr 15 08:20 Y-af72e17029b2d6c1-0000000000 drwxr-xr-x 2 root root 4096 Apr 20 09:30 YAg*-f8fe9fbc16e2d7e3-0000000000 drwxr-xr-x 2 root root 4096 Apr 20 20:15 y:-cd1a6f4e05353e19-0000000000 drwxr-xr-x 2 root root 4096 Apr 27 15:45 Y-df78a7ff0627a98c-0000000000 drwxr-xr-x 2 root root 4096 Apr 22 14:50 Y-e340633e382d2dfa-0000000000 drwxr-xr-x 2 root root 4096 Apr 22 11:10 Y-f63ddb0510f522bd-0000000000 drwxr-xr-x 2 root root 4096 Apr 23 12:25 Yg=B-d85f91f40842530a-0000000000 drwxr-xr-x 2 root root 4096 Apr 28 04:25 y:N-d16c3206c12f5644-0000000000 drwxr-xr-x 2 root root 4096 Apr 26 17:50 Y:p-05b9ee59a8e426da-0000000000 drwxr-xr-x 2 root root 4096 Apr 22 19:20 yp-6131660bc56433f0-0000000000 drwxr-xr-x 2 root root 4096 Apr 26 21:20 Yz-57ca695582281830-0000000000 drwxr-xr-x 2 root root 4096 Apr 22 12:20 Z-056bc56238327542-0000000000 drwxr-xr-x 2 root root 4096 Apr 22 17:05 Z-06d6559ea7d8d81e-0000000000 drwxr-xr-x 2 root root 4096 Apr 15 09:15 z-078580c414cd831a-0000000000 drwxr-xr-x 2 root root 4096 Apr 14 15:05 z-1c234db314fd3d4f-0000000000 drwxr-xr-x 2 root root 4096 Apr 17 16:40 Z3-fb84f61e06366829-0000000000 drwxr-xr-x 2 root root 4096 Apr 16 10:00 _Z-475f2f63ed961d9b-0000000000 drwxr-xr-x 2 root root 4096 Apr 22 18:45 -Z-4d85b858dd07d49a-0000000000 drwxr-xr-x 2 root root 4096 Apr 18 17:40 z-7549c367428e3062-0000000000 Edit: Is there a way to trap and log which process is writing these files?