show languages on statusbar

[adipose]

No description provided.

[clsid2]

When track language is unknown it incorrectly shows the locale language. It also shows squares (invalid char) for the two unicode chars here.

[lifegpc]

It seems it only works for internal track.

[clsid2]

I fixed it by checking if lcid is null.

[clsid2]

Yes, it also seems to fail for external subs.

[lifegpc]

Do not display subtitle on statusbar may become better in this situation.

[clsid2]

Another bug: it only updates the audio language when creating the menu, not when changing the selection in the menu

[clsid2]

External sub can signal language in filename: movie.eng.srt
Maybe store sub lang when generating the sub menu?

[clsid2]

Good sample to test the audio menu issue:
https://www.sendspace.com/file/vwxuh2

[adipose]

Another bug: it only updates the audio language when creating the menu, not when changing the selection in the menu

should be fixed

Yes, it also seems to fail for external subs.

Will look into that

[adipose]

It seems GetStreamInfo() doesn't get the lcid without passing the pName as well, should be fixed.

[lifegpc]

It seems has bug when deal with internal subtitle.
Try this video, external subtitles can be find here.
The internal subtitle:

The external subtitle:

[lifegpc]

Chinese have many variants, such as zh_cn, zh_tw, zh_hk, zh_hans, zh_hant etc. It seems mpc-hc identify them all as zh_hans. This is another problem.

[adipose]

Maybe, but I misread your other statement, it was talking about internal (which I had thought before was working, but in this case it wasn't).

[lifegpc]

Yea. It also only display zh- on OSD. It seems missing the variant of a language.

[adipose]

LAVFilters did not get an LCID at all. The name gets [zh-] only.

[adipose]

I'm not sure it's mpc-hc's fault. VLC only identifies the tracks as "Chinese":

[lifegpc]

So vlc has same bugs.
zh_cn Chinese(China)
zh_hans Simplified Chinese
zh_tw Chinese(Taiwan)
zh_hk Chinese(HongKong)
zh_hant Traditional Chinese

[adipose]

How do you know it's a bug?

[adipose]

This is what I could extract using mkvinfo:

| + Track
| + Track number: 3 (track ID for mkvmerge & mkvextract: 2)
| + Track UID: 3
| + Lacing flag: 0
| + Name: 中文（简体）
| + Language: zh-Hans
| + Default track flag: 0
| + Codec ID: S_TEXT/ASS
| + Track type: subtitles
| + Codec's private data: size 853
| + Track
| + Track number: 4 (track ID for mkvmerge & mkvextract: 3)
| + Track UID: 4
| + Lacing flag: 0
| + Name: 中文（中国）
| + Language: zh-CN
| + Default track flag: 0
| + Codec ID: S_TEXT/ASS
| + Track type: subtitles
| + Codec's private data: size 851

Looks like it knows more about the languages than mpc-hc

[lifegpc]

Maybe MPC-HC should just display Chinese but not Chinese(Simplified).

[adipose]

Looks like it's a bug in MatroskaParser. It's quite an old source and can only read 3 characters of the lang, hence the zh- that shows up.

[adipose]

I do think matroskaparser is pulling too little data, as the matroska spec allows for a 639-2 code plus a dash and country code. But this mkv is actually not following spec. The "Language" tag cannot have a bcp47 code, yet that's exactly what zh-Hans is. And mkvtoolnix does not recognize it but changes it to zh.

If you want to use bcp47 you have to use languageietf. Once I've done that, the mkv actually shows ZHO, and chose "chi" in the menu. I'm not sure how it did that, as matroskaparser doesn't even understand languageietf--maybe it defaulted to something else.

So, mpc-hc doesn't parse the whole tag, but it's not a valid tag anyway. If it were a valid tag, it probably would work better. But to get zh-hans you would need ietf tag, which mpc-hc doesn't support.

[adipose]

Some related PRs:

clsid2/FFmpeg#1
clsid2/LAVFilters#2

After these changes and updating your MKV to have the same tags, but in a valid field (LanguageIETF), we get the following: