VLC Removal in 13.24 Breaks Custom Themes with Complex Video Layouts

[Bussifrog]

Hi all,

I'm a long-time theme developer and curator of a heavily customized BigBox build designed not just for personal use, but for distribution to others who rely on it. After extensive testing, I’ve confirmed that the removal of VLC support in version 13.24 has introduced a critical regression in video playback for custom themes — especially those using TransitionPresenter, IsContentVideo, or complex media-bound layouts.

The new FFmpeg-based engine simply cannot handle the same load and binding behavior as VLC could. It struggles with:

• Real-time video swapping within complex WPF grids

• TransitionPresenter bindings with IsContentVideo

• Non-standard or high-bitrate MP4s that previously worked fine

• Layouts with layered or animated transitions (crashes, freezing, no playback)

These issues are not due to video corruption or theme bugs. The exact same themes and video files work flawlessly in 13.23 and earlier, and still play in LaunchBox (not BigBox) because the layout complexity isn’t a factor there.

For now, the only solution for theme developers is to roll back to 13.23 and lock that version for end users, which is not a sustainable or scalable solution — especially for those of us supporting others through platforms like Patreon.

I strongly urge the LaunchBox team to consider:

• Reinstating VLC as an optional playback engine

• Or providing an advanced setting to toggle VLC support for users/themes that require it

Please understand that for some of us, this update didn't just change playback — it broke entire curated projects. We're not resistant to progress, but this was a step backwards for those relying on VLC’s capabilities to power ambitious designs.

This has been based on my personal observations. If any one else is experiencing this or knows of an actionable solution I welcome your reply.
Thanks for your time and consideration.

[Bussifrog]

Hi team,

After testing post-13.24 and beta hotfixes, I’ve confirmed that custom BigBox themes relying on VLC for complex video playback (e.g., multiple TransitionPresenters, background game videos, overlays, etc.) are now broken. While stability may have improved with FFMPEG, functionality has taken a major hit — many MP4 videos that previously worked fine in VLC either won’t play at all or fail silently under FFMPEG or WMP. My custom theme (FightersDLX) was working flawlessly across thousands of videos until the VLC support was removed. Now, even simple background videos used in specific layout zones don’t consistently play, though the exact same files work elsewhere (e.g., in playlist BGs or LaunchBox proper).

This change essentially cripples years of theme work. VLC had broad compatibility and should remain an option for advanced users. FFMPEG is simply not viable for every use case — especially for curated arcade or console cabinets running custom themes.

Can VLC be restored as an optional engine?

Thanks.

Edited Wednesday at 09:02 PM by Bussifrog

[skizzosjt]

Hi @Bussifrog I will provide some backstory. 13.18 is the last version that runs VLC as expected without known bugs. Users experienced random hard freezing in Big Box that requires terminating the program's process in 13.19 and onward through 13.22 while using VLC....

Using Big Box became a roll of the dice in those versions I mention. Is it gonna freeze after 90 seconds or 1 hour or 3 hours, who knows, but it was guaranteed to freeze at some point on 13.19 through 13.22 when using VLC. It might be possible to have used Big Box with VLC and not get a freeze as it was random, but lots of users ran into it with standard casual use. 

You're trying to say it was "flawless" in  in 13.23 and prior. That would include 13.19 - 13.22. To set the record straight VLC was far from flawless in that version range. This was the period that raised the red flag to the devs that something has hit the fan and they eventually waived the white flag trying to fix VLC and went with implementing FFMPEG. So far that has been subpar by comparison. 

13.23 was first version to include FFMPEG to replace VLC with VLC no longer being available within the app. 

Removing VLC is still a hard pill to swallow and I will likely forever be annoyed with it! The media engine has been a crap shoot since February and I'm not optimistic there is going to be an acceptable solution that matches how well VLC worked. They have dug their heels in on FFMPEG which is subpar both objectively and subjectively. They have painted themselves into a corner with no get out of jail free card in the deck left. So....join the club, these events negatively impacted custom themes and video playback in general for me too!

[Bussifrog]

19 hours ago, skizzosjt said:

Hi @Bussifrog I will provide some backstory. 13.18 is the last version that runs VLC as expected without known bugs. Users experienced random hard freezing in Big Box that requires terminating the program's process in 13.19 and onward through 13.22 while using VLC....

Using Big Box became a roll of the dice in those versions I mention. Is it gonna freeze after 90 seconds or 1 hour or 3 hours, who knows, but it was guaranteed to freeze at some point on 13.19 through 13.22 when using VLC. It might be possible to have used Big Box with VLC and not get a freeze as it was random, but lots of users ran into it with standard casual use. 

You're trying to say it was "flawless" in  in 13.23 and prior. That would include 13.19 - 13.22. To set the record straight VLC was far from flawless in that version range. This was the period that raised the red flag to the devs that something has hit the fan and they eventually waived the white flag trying to fix VLC and went with implementing FFMPEG. So far that has been subpar by comparison. 

13.23 was first version to include FFMPEG to replace VLC with VLC no longer being available within the app. 

Removing VLC is still a hard pill to swallow and I will likely forever be annoyed with it! The media engine has been a crap shoot since February and I'm not optimistic there is going to be an acceptable solution that matches how well VLC worked. They have dug their heels in on FFMPEG which is subpar both objectively and subjectively. They have painted themselves into a corner with no get out of jail free card in the deck left. So....join the club, these events negatively impacted custom themes and video playback in general for me too!

Thanks for the reply @skizzosjt  Yeah I don't know what to do...the current options are a no go..they just can't handle it. I do get the crashes now but that is of very recent update. I have had a stable build for like 10 years now. This is all quite the annoyance but I rolled my system back and turned off ask about updates and I guess that's that. Sad but true. I wish you luck on you builds. 

[AstroBob]

Hey folks, really appreciate you both laying all this out in detail.

To provide a bit of backstory: VLC has always been a bit of a double-edged sword for us. On one hand, it had some really powerful capabilities that made ambitious themes possible. On the other hand, it has always been heavier than Windows Media Player in terms of resource use, and once we hit versions 13.19 through 13.22, the old VLC wrapper started freezing Big Box randomly for a lot of users. That was the red flag that forced us to take a hard look at things.

The real problem is that the .NET wrapper we used to make VLC work inside Big Box has not been updated in over 8 years. Once it started breaking down, we were stuck because we could not patch it ourselves, and the author is long gone. Even if it still worked fine for some users back on 13.18, the truth is it was a ticking time bomb. Every new Windows, .NET, or driver update risked breaking it further, and there was no path forward.

That is why we moved to FFmpeg in 13.23. It is not perfect yet, and you are absolutely right to call out the regressions with TransitionPresenter, IsContentVideo, complex grids, and higher bitrate files. VLC could handle those scenarios better, and we know this change hit curated builds and custom themes especially hard. But FFmpeg gives us something we can actually maintain and improve. Unlike VLC, it is not frozen in time and we can keep iterating on it.

I also want to set expectations clearly. Rolling back is not really an option. If we reintroduced VLC, we would just be bringing back instability and freezing that we cannot fix. It might look like a step forward for some users, but it would be a step backward for everyone else in the long run.

What we can do is keep improving FFmpeg to close the gap. That is where your feedback is huge. @Bussifrog, if you are open to it, we would love to test your theme directly so we can see exactly where the playback is falling short. The more complex examples we can test against, the better job we can do making sure FFmpeg holds up under those loads. Feel free to PM me if you'd like to explore this

We hear you. This was not just a cosmetic change, it affected real projects. But our goal is to build a video engine that is stable today and sustainable for tomorrow. VLC had the features but not the stability. FFmpeg has the stability, and now we are focused on bringing the features up to par.

Thanks again for the honest feedback. Please keep the specific examples coming, because that is what helps us move this forward.

[Bussifrog]

Thanks so much for the detailed and thoughtful response — I really appreciate you taking the time to explain the situation clearly.

For now, I’ve rolled back to 13.18 and disabled updates to preserve stability on my end. FightersDLX is more than just a theme — it’s a fully integrated arcade frontend system with specific folder structures, embedded transitions, video layering, and curated media packs. So unfortunately, it’s not as simple as sending over a theme file for testing.

That said, I totally understand the decision to move toward a more maintainable video engine. I’ll keep an eye on FFmpeg improvements going forward, and I’m happy to continue providing feedback where I can.

Thanks again for the transparency and the offer to collaborate — it really does mean a lot.

[HolyLegend]

Any chance of adding MPV as a option? I feel like MPV is the best media player, even with watching anime and shows, there were plenty files that VLC could not play that MPV played flawlessly. Hoping you all take it into consideration.

[C-Beats]

17 minutes ago, HolyLegend said:

Any chance of adding MPV as a option? I feel like MPV is the best media player, even with watching anime and shows, there were plenty files that VLC could not play that MPV played flawlessly. Hoping you all take it into consideration.

We actually implemented that before FFMPEG internally and the only wrapper we found we could use without breaking license resulted in really heavy playback stuttering to the point it was scrapped since it didn't seem quality enough to use in a public release.

[HolyLegend]

6 minutes ago, C-Beats said:

without breaking license

Sooo....break license 👀 lol but oh I see, I don't know much about coding so can't comment on that side of things, but I do hope you all will continue to consider MPV, it is updated pretty frequently. Maybe it will be a more stable wrapper in the future. The more updated stuff is on their website under "Installation" instead of going to the outdated github. Just throwing that out there, I don't know what all you need to make the wrapper. Thanks for the response

[C-Beats]

7 hours ago, HolyLegend said:

Sooo....break license 👀 lol but oh I see, I don't know much about coding so can't comment on that side of things, but I do hope you all will continue to consider MPV, it is updated pretty frequently. Maybe it will be a more stable wrapper in the future. The more updated stuff is on their website under "Installation" instead of going to the outdated github. Just throwing that out there, I don't know what all you need to make the wrapper. Thanks for the response

Basically need something that can translate the raw frame output of MPV into something WPF can consume (as well as audio) and then make sure the two streams stay in sync. I'm unsure if the stutter issue was just in how that translation from MPV -> WPF was happening or MPV itself (though I highly suspect the former)

[HolyLegend]

3 minutes ago, C-Beats said:

Basically need something that can translate the raw frame output of MPV into something WPF can consume (as well as audio) and then make sure the two streams stay in sync. I'm unsure if the stutter issue was just in how that translation from MPV -> WPF was happening or MPV itself (though I highly suspect the former)

Thanks, I ended up looking it up and got the gist of it. I basically see it as like a Virtual Machine (VM) or even sort of like an emulator. I know it all sounds simple in theory but can be hard to implement, you guys are all appreciated even if it seems like lots of nagging and not enough praise.