I'm gonna be trying it out, since another commenter mentioned it's powered by mpv. Although, as I have very basic requirements, I'm already perfectly content with starting up mpv from the cli or by using mpv.app.

If you try this out and feel like it's not what you're looking for, I'd suggest trying out mpv [0] directly.

It integrates youtube-dl [1], so you can easily watch YouTube, as well as from the other hundreds of sources they support, very easily. For example:

    mpv "https://www.youtube.com/watch?v=dQw4w9WgXcQ"

The most recent macOS update brought a picture-in-picture feature, where you could keep videos playing on top of everything else in one side of the screen. With mpv you can get a close approximation by using the "--ontop" flag. Although admittedly it's not quite as nice as the new built-in feature.

And a bit tangential to the whole thing, I found mpv's C API [2] to be very approachable and well documented.

[0] https://mpv.io/

[1] https://rg3.github.io/youtube-dl/

[2] https://github.com/mpv-player/mpv/blob/master/libmpv/client....

Looks like this is powered by mpv, which is handling all the media parsing and playback, which is awesome.

I've been wanting "mpv with a modern UI for years now for mac" for years now.

Well, you can use mpv now -- build using homebrew and then make a config file (yeah, config file sucks, but then you get something you want) :)

    brew install mpv

I've been using mpv from the command line for as long as I can remember. Config file synced with the rest of my dotfiles.

The killer feature here is the modern native UI.

Looks really nice! I just played back a 1080p / 5.1 AC3 file, a 4K 5.1 DTS-HD file, and an audio ALAC file completely seamlessly. Only complaint so far is the playlist sidebar slid in from the side with every new track, obscuring 1/3rd of the content, and I kept having to manually dismiss it.

Good to see VLC get some competition. VLC has a pretty decent UI (assuming you don't end up in settings hell), but hasn't really evolved to match modern software design. A reasonable competitor could light a bit of fire under them to get that fixed.

Edit: tried it out with some streaming media. Buffering seems to be more intelligent that VLC (saner default). It is really pretty UI too. Great start for a project.

> A reasonable competitor could light a bit of fire under them to get that fixed.

Is there anything in particular that you'd have them change?

> Is there anything in particular that you'd have them change?

I'm no UI/UX expect, but here's my impression of deficiencies (as a fairly heavy VLC user)

- Media player default window is super busy. I rarely use any of those options. - Audio/subtitle sync is tricky. There are keybindings but I can never remember them. - Open dialog is really complex for what you are usually wanting to do - Preferences is just crazy. It used to be tough to configure caching, but that seems to be fixed now (cool!)

The VLC UI is a lot better than it used to be in fairness, but it still has a ways to go before I'd consider it to be modern and clean.

I'd be a fan of maybe reorganizing the options, but the flexibility of the software is the reason that I use it over other players.

I like the idea of a cleaner interface, but if the choice turns out to be between a cleaner interface and the number of options in the software, I'll stick with the version with the ugly UI until it stops working.

And that's really what I'm afraid of. Most things that get labeled "modern and clean" are programs that I think of as "insufficient and featureless", and they're the ones that I abandon. I don't want to abandon VLC; it's been my good friend for 10 or 11 years, at this point.

Another thing that irks me is the inconsistency of VLC's UX/UI from Windows/Linux and MacOS.

In my experience, VLC on MacOS feels rather unpolished compared to the Windows/Linux variants (maybe because they're using Qt and MacOS presumably isn't) but I've generally always have had a smoother experience with VLC on Windows and Linux as opposed to Mac from everything from playing local files to streaming over the network.

Only one video can be open at a time by default.

I'd never considered that a shortcoming before, and it is just a single option to change if you don't like the behavior.

Feature suggestion: multiple subtitles, and subtitle time shifting.

It's theoretically possible in VLC, but failing after half an hour of trying to get the settings to work led to the movie being shown without any subtitles. This was for a group discussion, with mixed English & Chinese native speakers. It's publicly embarrassing for everyone, and I'm planning to write my own app to just show subtitles so this might work next time.

I looked at the screenshots, and I am not sure what's more modern about it than VLC. Only thing attracting in the screens is the video being played.

Supported formats would be good information on the website, also signing the app.

Looks great!

You have a typo on your homepage, though. "A more stable release should be able in one month." should probably be "A more stable release should be available in one month."

I looked at the docs but it's unclear what "modern" refers to? Does it just mean it's new?

Perhaps: it is written in Swift and supports the touch bar on the new MacBook Pros.

PotPlayer is my favorite media+music player. Inbuilt file seeking interface like potplayer in IINA can be helpful.

Pinning playlist in front to drag and drop additional files is also required.

Support to take screen shot without quality loss.

Any plan to support mp3/flac files?

Thanks for this great app, looking forward for stable release.

Works well so far.

Only complaint - it doesn't prevent the screensaver. That does seem like it should be a given.

How is this pure swift? What about the codecs?

I would assume they mean every line of code in IINA is Swift code. It's using libraries which are presumably not written in Swift, but you could make the same argument about literally every Swift program ever (even if they don't use Foundation, they'll at least be using libc and that's obviously not written in Swift).

I can't agree with that. If you develop a videoplayer and you state it's pure Swift I think it's fair to assume the codecs and other core components (i.e. dsp) of the said player are not imported C libs. How can it be pure Swift if it imports C libraries? The std library and toolchain(i.e runtime) may make an exception because these are usually portable, maintained by the language authors and invisible to the end developer so I think your libc argument is not valid.

If you developed the libraries yourself, then you have a point. But if you're using someone else's library, which they maintain, then it seems reasonable to say your application is pure Swift.

Note that there's a difference between saying "my application is pure Swift" and "everything is pure Swift". If you're trying to make an argument about safety (as happens when people talk about writing things in Rust), then having the libraries written in that language is important. If you're just trying to say "this is a modern codebase using the latest tooling and APIs", then all that matters is the code you wrote, and not the pre-existing libraries that you link to.

You turn this into a blame game. If it's pure Swift then 100% of its source code should be Swift. This particular repository is mixed with C libs.

From the dictionary:

Pure - not mixed or adulterated with any other substance or material.

So, everything has to be Swift, except for the libraries that you personally have decided don't matter (such as libc)? That's not a very useful definition.