We had a discussion a long while ago on this, when MC19 was still shiny and new... Here's the rub:
They don't want to do "just another" video implementation on OSX, using the
CoreVideo framework.* Instead, the ultimate goal is to provide integrated video support similar to that in the Windows version... Meaning, supporting LAV (or something like it), and features like those enabled by madvr.
That's a big project, though, hence the "working thoughtfully".
And then there's Theater View which is probably as-important. If you're going to have good video playback, you really need a way to be able to use MC as a Home Theater front-end.
So...
When we discussed all this, I'd made the suggestion:
Do we expect to get Video support, of some kind, in the Mac version at some point during MC19?
If not, how much work would it be to add the ability to browse the files back in (using our normal view schemes like from Windows) but when you play them, they launch in the registered external player?
This would largely solve my problem on my Macs. It would, of course, be nowhere near as good as native support, but if I could play them in VLC or whatever (and launch images in Preview or whatever), I'd use the Mac version of MC much more, rather than using it inside my Windows VM.
To which Matt responded:
Launching an external player would be a good stop gap.
I agree, and I hope to see this implemented at some point in v19. It wouldn't be as good as native support, of course, but if we could see and manage our entire libraries in MC, and just launch videos you double-click in VLC Player or whatever, that would be absolutely workable for now.
I'd also like Image support that I could set up to launch in Preview (with
Right-Click > Send To > Photoshop, natch).
* This is for a good reason. The Windows version, after all, was originally built relying upon the built-in DirectShow playback engine. This left the end-users to figure out the complex set of codecs and plugins they'd need to have installed for good format support and quality, and led (eventually) to a supportability disaster. Red October fixed all of that, and did so in an elegant way. You could say that experience (and the experience of de-Windows-specific-ifying all of their existing code) "taught them a valuable lesson": If it is worth doing, it is worth doing right.