I find these first-party interop libraries from Microsoft really interesting, in light of the fact that Oracle v. Google is still ongoing.

Depending on how that case finally comes back, I'd expect that could really affect Microsoft's strategy, here.

> Depending on how that case finally comes back, I'd expect that could really affect Microsoft's strategy, here

Remember that because there were originally patent claims in the suit, the appeal went to the Federal Circuit -- even though the patent claims were dropped -- not the Ninth Circuit where the district court is located. As a result, the Federal Circuit's ruling that APIs are not uncopyrightable is not precedent since it doesn't concern patents (the Federal Circuit's remit).

Their reasoning might influence future rulings, but precedence-wise the ruling has no bearing on the future of copyright on APIs in the US.

edit: the EFF has a little more detail:

https://www.eff.org/deeplinks/2015/06/bad-news-supreme-court...

https://www.eff.org/deeplinks/2015/06/eff-stands-innovative-...

Isn't this a wrapper lib? If its just calling public APIs I can't see a problem with that.

Can you elaborate what you mean? What risk is there to what Microsoft is doing?

If APIs are copywritable, then the GP2.1 license of ffmpeg would apply to this library, which is only licensed under the Apache license.

This issue has popped up a number of times for Linux kernel modules, and at what point they are a derived work - https://lwn.net/Articles/13398/. Here is an email thread concerning this http://yarchive.net/comp/linux/gpl_modules.html.

ffmpeg is also distributed under LGPL, which would be necessary to link this library against it, otherwise the whole product would be GPL anyway.

The way I see it, this is an open source shim layer. I don't see any copyright issue whatsoever. Whoever chooses to use the shim is using ffmpeg anyway, so they are already exposed to the license in exactly the same way. This just makes it easier to use ffmpeg 'the right way' on various devices, if I understand correctly.

If somehow MS can't make and open source clean compatibility layers for their own software, then that's a big problem.

> If APIs are copywritable

Is that distinct from being copyrightable?

I'm sure that if it becomes a big enough problem, the problem will be buried in lawsuits once Microsoft or IBM or similar stub their toes on it.

I really am liking these Microsoft projects. FFMPEG on Windows would make so many thing MUCH easier for my Audio and Video Projects. Right now ffmpeg on Windows is hit or miss for me currently.

I have never had any trouble with FFmpeg on Windows. Even building it from source or building programs that use it is pretty foolproof with MSYS2. FFmpeg also has Windows specific features like DXVA for video decoding and (recently) Schannel for TLS.

It seems like this library is specifically for integrating FFmpeg with the built-in classes for video playback in Windows Store apps, but you don't have to use those classes to use FFmpeg on Windows.

FFmpeg on the command line on Windows has been fine for me every time I use it, using the Zeranoe builds. They seem to come with the right codecs and everything.

Those are the ones I also use and it hasn't been flawless for me, BUT I tend to do a TON of video for professional production (Happens only a few times a year). I get hiccups that I don't know everyone would really notice or care about, but is HUGE for my purposes.

Edit: Works Flawlessly in Linux.

I do too. The only thing I miss is QuickSync support. But I don't feel brave enough to come up with my own build.

Title should spell Microsoft correctly.

Dang, you about? Typo! Mircosoft...

Better late than never?

:-) always appreciated, well by me at any rate!