How would you guys (k-lite team) handle a second MPC-HC build?

I have seen this PR on clsid2's MPC-HC github page: https://github.com/clsid2/mpc-hc/pull/358
the TLDR version is: we might see 2 builds of HPC-HC one with libass and one without.

so my question is: how would you guys handle this for existing installations and for new ones.

and thank you for your work.

You have made the wrong conclusion. There won't be two builds. The branch will be merged in the future, when it is ready.

Admin wrote:You have made the wrong conclusion. There won't be two builds. The branch will be merged in the future, when it is ready.

thank you for answering, I'm just excited about the libass inclusion .. and can't wait to use it.

I made my conclusion based on the last two comments, and I cannot see it without thinking of 2 builds.

clsid2:
Yes, I prefer to keep the #if USE_LIBASS around the added code to be able to make a build without libass included.

adipose:
OK, it now should pretty much exclude all the libass related code, minus a couple minor configuration items. I left those in so it won't lose libass options when switching builds (they will not actually do anything in non-libass builds).

The gui options will be hidden in non-libass builds. Form objects are still there, but are disabled.

Finally, I had added some code for opentype languages, which is working in libass. I think I can make it work in the internal renderer if desired, so I'm leaving that option "on" even when libass is disabled. It currently won't work for internal renderer but it won't do any harm either.

That is to simplify future integration and to make test builds. There are still bugs and it is still a work in progress. There will not be a separate release build. Branches are for unfinished work.

What is the biggest reason you want to use libass?

Don't expect a big performance improvement. In fact, I did some tests where it was actually a bit slower. If you have good samples where you expect libass to be better than the current renderer, then feel free to share some links.

Admin wrote:That is to simplify future integration and to make test builds. There are still bugs and it is still a work in progress. There will not be a separate release build. Branches are for unfinished work.

What is the biggest reason you want to use libass?

Don't expect a big performance improvement. In fact, I did some tests where it was actually a bit slower. If you have good samples where you expect libass to be better than the current renderer, then feel free to share some links.

I don't want it for performance reasons.
aegisub (the program that is used by most fansub groups) uses libass by default so when a fansub group do some advanced typisting or fancy Karaoke it's guaranteed to work with libass (it usually works with xysubfilter but not always).

here is an example (not my work): https://drive.google.com/u/0/uc?id=1ITgdGyGpxMdQikHMqN_fZ-8Wywak7bL0&export=download
play it with xysubfilter and see the karaoke (on top) it's not working properly, then play it using MPV (uses libass) and see how it's supposed to look.
you can also play it properly on mpc-hc using: assfiltermod (https://github.com/Blitzker/assfiltermod/releases) it uses libass as will and will play the karaoke as intended.

assfiltermod is not maintained now and the mpc-hc solution is based on libass git if I'm not mistaken also the mpc-hc solution uses libass WHEN possible and not always.

The karaoke sub works fine here with the current internal subtitle renderer. Unless typsetters do very stupid stuff, things generally will work with the internal renderer. Libass is designed with compatibility for the MPC/VSFilter renderer implementation.

You shouldn't use xySubFilter.

Admin wrote:The karaoke sub works fine here with the current internal subtitle renderer. Unless typsetters do very stupid stuff, things generally will work with the internal renderer. Libass is designed with compatibility for the MPC/VSFilter renderer implementation.

You shouldn't use xySubFilter.

this is a comparison between the internal and assfiltermod on the same video (linked above)
internal: https://i.ibb.co/KwyWjqw/internal.jpg
assfiltermod: https://i.ibb.co/sbjc5Dq/assfiltermod.jpg
there shouldn't be stacked letters on the upper right corner.

and as I said before usually it's not a problem but just in same rare cases.
for xysubfilter vs the internal I don't have a preference and I didn't see any difference between them.

I see it now. In upper left corner.

But I also have an anime karaoke sample where libass completely messes up with wrong letters.