player/loadfile: rewrite sub autoselection logic

[Dudemanguy]

I'm sure something's broken since there's way too many sub options (whose fault could that be). Anyways, please test. cc @dawidpotocki

[github-actions[bot]]

Download the artifacts for this pull request:

Windows

• mpv-i686-w64-mingw32
• mpv-x86_64-w64-mingw32

[dawidpotocki]

--subs-fallback-forced=<yes|no|always> When autoselecting a subtitle track, the default value of yes will prefer using a forced subtitle track if the subtitle language matches the audio language and matches your list of preferred languages. The special value always will only select forced subtitle tracks and never fallback on a non-forced track. Conversely, no will never select a forced subtitle track.

Now that I checked the docs, it looks like forced tracks should only ever be picked if the sub and audio lang matches.

This means my table in #13280 was wrong (I updated it), sorry.

File	c9c917c	eca51d8	master	This PR	Expected
aPL,sfEN,sfPL.mkv	sfPL	sfEN	sfEN	sfEN	sfPL
aPL,sfEN.mkv	sfEN	sfEN	sfEN	sfEN

The docs could be changed to fit this new behaviour, but I think it makes more sense to "fix" it. Overall, I don't think this is a big deal as such files are probably very rare and just a case of bad muxing.

This is similar to my suggestion from the other PR, kinda funny. https://github.com/mpv-player/mpv/pull/13281#issuecomment-1891337472

---

I also am not a fan of this behaviour:

slang=en,pl
subs-with-matching-audio=no

File	c9c917c	master	This PR	Expected
aEN,sEN,sPL.mkv			sPL
aPL,sEN,sPL.mkv	sEN	sEN	sEN

I would personally expect no subs to appear in either scenario given that I understand both languages, which is why they are in slang.

It could be a preference thing, but not sure why anyone would want this.

Example files

[Dudemanguy]

Sorry if the docs aren't clear about this but the setting in --slang is supposed to always "win" over a track being tagged as forced or default. So your original interpretation was correct. --slang=en should always pick an english subtitle if one is available barring subs-with-matching-audio.

I also am not a fan of this behaviour:

But that's what you selected. You requested en and pl subs. Because of subs-with-matching-audio=no, it did not select the subtitles that matched the language of the audio. The other one was selected since it was in the list of your preferred languages. For the aEN,sEN,sPL.mkv, it not selecting the pl subtitles on master is actually a bug. You can see the master behavior is inconsistent with aPL,sEN,sPL.mkv.

[dawidpotocki]

Sorry if the docs aren't clear about this but the setting in --slang is supposed to always "win" over a track being tagged as forced or default. So your original interpretation was correct. --slang=en should always pick an english subtitle if one is available barring subs-with-matching-audio.

So this should be clarified in the docs then?

I got confused by the "and matches your list of preferred languages", which to me sounds like slang. If this is how it's supposed to behave, shouldn't it be "or" instead of "and"?

But that's what you selected. You requested en and pl subs. Because of subs-with-matching-audio=no, it did not select the subtitles that matched the language of the audio.

Right, right, I get this, but like I said, I personally dislike it.

I don't see the point of this setting behaving this way. To me, disabling all subs on matching audio makes much more sense.

Watching videos with audio in one language you understand and subtitle in another language you also understand is weird to me. You have to either focus on the subs or the audio. It especially gets wack when the localisation team decides to replace a reference or a joke with a different one that the audience of the translation would understand.

I have a lot of videos with a bunch of subtitles, which typically includes English and Polish. With this behaviour, I would have to manually disable subtitles. This makes the entire setting pointless to me.

I'm sure there is someone who would want this, but I feel like such people would just always want to read subs, which is what subs-with-matching-audio=yes would do.

Anyway… it's just my opinion…

---

Other than that… I don't think there is any issue I noticed…

[Dudemanguy]

So this should be clarified in the docs then?

Yeah it's probably worth adding a small section briefly explaining the autoselection behavior since it's so complicated.

I don't see the point of this setting behaving this way. To me, disabling all subs on matching audio makes much more sense.

Well we could add even more choices to subs-with-matching-audio I guess... Something like slang and slang-forced. Could follow up on this afterwards.

Other than that… I don't think there is any issue I noticed

Thanks for checking!

[Dudemanguy]

So I thought about the subs-with-matching-audio thing some more and checked the docs and original commit and actually I think your interpretation is correct. It's supposed to match with the list of preferred languages in slang. However the original implementation didn't apply if the subtitle language matched the audio language but was not in your list of preferred languages. So that means for the example in your issue with --slang=en --subs-with-matching-audio=forced, it would select the normal polish subtitles on the aPL,sPL.mkv video. Kind of unintuitive in my opinion.

Should we just take both possibilities into account for this option?

[dawidpotocki]

Should we just take both possibilities into account for this option?

I don't think so. I have been trying really hard to come up with a use case, but I can't think of anything.

[Dudemanguy]

So I changed subs-with-matching-audio to make it match languages in slang and not the actual language of the audio. I guess that's where I'm leaning now.

[Dudemanguy]

Fixed an edge case I just found