HandBrake incorrectly sets subtitle track as default

[kurtunderhay]

Description of problem or question:
Using one of the Matroska presets (e.g. H.265 MKV 480p30, but it seems to happen for any Matroska preset), even when the single subtitle track is specified NOT as default, HandBrake produces a video file with the subtitle track as default.
When playing the output video file in VLC, the subtitle track is already selected. I don't believe this is a VLC problem as video files encoded in older versions of HandBrake behave correctly, i.e. a non-default subtitle track is not selected by default when playing in VLC.

This bug makes HandBrake unusable for producing an MKV file with a non-default subtitle track.


Steps to reproduce the problem (If Applicable):
1. Scan a video title that has at least one subtitle track
2. Select a Matroska preset
3. Specify one subtitle track. Ensure that the "Default" checkbox is NOT selected
4. Encode the file
5. Play the file in VLC.
6. Observe that the non-default subtitle track is selected by default when playing the file


HandBrake version (e.g., 1.0.0):
Nightly 20201213215036-a6da3412f-master (2020121501)


Operating system and version (e.g., Ubuntu 16.04 LTS, macOS 10.13 High Sierra, Windows 10 Creators Update):
Windows 10 Home 64bit 19041.685


HandBrake Activity Log ***required***

Code: Select all

https://pastebin.com/k6QcyDCe

[Woodstock]

Are you sure you're looking at the correct culprit?

VLC tends to play the first subtitle found, regardless of flags. You can test this by changing the order of the subtitles.

[Deleted User 11865]

Known bug, it's somewhere on github.

[kurtunderhay]

Are you sure you're looking at the correct culprit?

VLC tends to play the first subtitle found, regardless of flags. You can test this by changing the order of the subtitles.

Yes I’m sure - I explicitly and specifically noted this.

No VLC does not tend to play the first subtitle found regardless of flags.

[kurtunderhay]

Known bug, it's somewhere on github.

Thanks for confirming bug. Perhaps a corresponding unit test can be added to release testing to trap this in future.

ETA on fix please? As noted this makes HandBrake GUI unusable in what I’m sure are many common use cases.

Alternatively please advise most recent version not having this bug.

[Deleted User 11865]

I haven't bisected it, so no idea when it started happening. It's most likely an upstream change in FFmpeg anyway. No ETA on a fix.

[kurtunderhay]

I haven't bisected it, so no idea when it started happening. It's most likely an upstream change in FFmpeg anyway. No ETA on a fix.

Right ... not particularly helpful.
When do you expect to be able to provide an ETA on a fix?

[Deleted User 11865]

I don't have enough time to look into fixing this for a while. So the ETA is "whenever someone else has time to look into it".

[mduell]

I haven't bisected it, so no idea when it started happening. It's most likely an upstream change in FFmpeg anyway. No ETA on a fix.

Right ... not particularly helpful.
When do you expect to be able to provide an ETA on a fix?

A few days after you submit a pull request.

[kurtunderhay]

Awesome. Clearly not really going to get anywhere with this - entirely reasonable - line of enquiry.
Thanks for the very helpful responses.

FYI for anybody who is interested - 1.3.3 official release appears not to have this critical bug, so it seems to have come about somewhere between 1.3.3 and Nightly 20201213215036-a6da3412f-master (2020121501).

[s55]

The attitude is not going to get this issue fixed any quicker. Everyone that works on the project is a volunteer and all have day jobs/family and 2020 hasn't been a year where much time is being spent on the project.

Locking Thread.

For anyone interested in tracking the fix, please see https://github.com/HandBrake/HandBrake/issues/3200

[kurtunderhay]

I was just asking a question. A totally sufficient and non-sarcastic answer would have been "I'm unable to say yet when an ETA will be available."
Being a volunteer doesn't justify being an ass.