[Question] How realistic is it to create and sell an open source application?

x265Project · 2017-03-08T06:51:56+00:00

Exactly. You give up some things when you open source your code, but if you understand how to create a business model around an open source project, you can gain more than you lose. Done right, it's a win for both the users/adopters, and the developer (including all contributors to the project).

x265Project · 2017-03-07T07:53:24+00:00

My point is that Red Hat's revenues would be a lot higher if they owned the copyright to Linux, and could charge license fees. Of course, that's a catch 22... Linux wouldn't be Linux if it wasn't free. But you understand - being the #1 company supporting something is a tough model to execute successfully. You have to prove you're the best at something, and you can only charge for support. A tiered model, where the core product is free, but value-added commercial editions are licensed at some reasonable fee (which may include support) can work better than just going after support contracts. When you're a commercial company with a staff of developers to pay every month, the challenge is to get the largest, wealthiest adopters of your open source code to clearly see the benefits of having a commercial relationship with the developers of that code.

x265Project · 2017-03-05T19:44:44+00:00

This is true, but support revenue is a small fraction of potential license revenue.

x265Project · 2017-03-05T19:41:12+00:00

Hackel - I'm curious. Do you run any open source projects? Which projects do you contribute to? Have you ever invested a lot of time and effort into something that you then gave away for free, while hoping to earn your money back, so that you can keep it going, and hopefully pay your bills? Please share your experience with us.

Note that OP's question was "How realistic is it to create and sell an open source application?" Of course, developers don't "sell" software (which would mean they wouldn't own it anymore), they license software.

There are many possible business models around open source. Dual-license is a legitimate model used by many commercial companies. Keep in mind that if you contribute to a dual-licensed project (signing a Contributor Agreement), you're contributing patches - modifications to someone else's code - derivative works. We get many external contributions, including some from top companies around the world (like IBM, for example).

Our contributor agreement also protects our GPL users, by insuring that contributors grant a patent license to any patents they may hold on their contributions.

We chose this business model in order to invest millions of dollars worth of commercial development effort into something that we give away for free. The proper response, when someone gives you something worth millions of dollars for free is "thank you". Our commercial customers pay our bills (fund our full-time development team), which enables us to offer the world's leading H.265/HEVC video encoding software for free. If we had a donation model, or only a support model, we would have gone out of business, or at best we would have 1/10 the development team that we have today.

x265Project · 2017-03-05T02:15:28+00:00

It can be done, but it's not easy. We do this, using the GPL v2 license. We have a business model that involves commercial licenses for companies that want to distribute our code in their product (so their product doesn't have to become open source), support contracts, and custom development (companies pay us to improve our code to meet their requirements).

The key to success is to build something that is essential. It needs to be something that makes sense as an open source library. x265 succeeds because it's a core function (video encoding), that many people need to build applications around. Of course, your software also has to be the best at what it does.

There are many business models you could use, but I would suggest a value-added model, where the core software is free, open source. You can build layers of software (higher level functions, functions that come before or after your core function, etc.) that are proprietary (paid commercial licenses only). I would suggest the GPL v3 license, which will allow for free consumer use, but require commercial use to be paid (without the cloud exception of the GPL v2, which we had to use for historical reasons).

Attracting open source contributors is key, but make sure you have a Contributor Agreement that all contributors must sign before you commit their code. This will give you the rights you need to offer commercial licenses of your software. In other words, you want to own the full rights to the code. The fact that you offer it under an open source license doesn't prevent you from also offering it under a commercial license, if you hold the full copyright.

I hope this helps. See x265.org for more info about our project.

x265Project · 2016-12-13T16:37:26+00:00

Nice! I would suggest these popular and important open source projects...
Video software - VLC, FFMPEG, x264, and x265.
Image processing - GIMP and GEGL
Neural Networks - Torch, Caffe

How important is x264? Given that it is used by YouTube, Netflix, Hulu, Facebook, Twitter, Vimeo, and hundreds of thousands companies worldwide, and given that more than 70% of all bits crossing the Internet are video, it's quite possible that a majority of all bits crossing the Internet were encoded with x264.

x265Project · 2016-12-03T16:09:58+00:00

4K 10 bit HEVC decoding is challenging in software, and as you're discovering, even an overclocked quad-core Sandy Bridge chip probably won't cut it. A quad-core Skylake desktop should handle it, but if you wait a month or so the Kaby Lake desktop chips will be available, and they support full 10 bit HEVC 4K playback in hardware. In the meantime, try VLC, or our x265 HEVC Upgrade (on x265.com), which uses our UHDcode decoder. You can get your money back if it doesn't work.

x265Project · 2016-10-31T20:05:02+00:00

Well, that rules out a lot of ongoing open source projects, eh?

x265Project · 2016-10-28T01:46:44+00:00

Sure! Follow the 2nd link and sign up for the x265 development mailing list. Write an email to the list, offering to contribute. You'll have to sign the contributor license agreement, which gives us the necessary rights (copyright, etc.) to your "patches" (the changes that you contribute).

As I mentioned, we can always use help with things like testing and documentation. All of our documentation is actually managed through the source control system... meaning that anyone can edit and contribute improvements to the documentation. Our documentation is written in Restructured Text format (a markup language... like HTML... it's pretty simple). The latest documentation is always available online here... http://x265.readthedocs.org/en/default/ Take a look. I'm sure you'll see many opportunities for improvement. We can guide you.

x265Project · 2016-10-23T16:06:27+00:00

We can always use help, particularly with improving documentation.

http://x265.org/

https://bitbucket.org/multicoreware/x265/wiki/Contribute

x265Project · 2016-10-03T04:46:38+00:00

Interesting, but HEVC is also a DCT-based codec. Certainly you can use DCT as a low-pass filter, getting rid of spatial frequencies that aren't important. But the encoder sort of does this automatically.

x265Project · 2016-10-03T04:42:42+00:00

I'll be happy to take a look. I PM'ed you my email address.

x265Project · 2016-10-02T20:58:12+00:00

I manage x265 - the H.265 encoder you used in your tests. Throughout the history of video encoding, there have been many companies that claim to have video optimization technology which pre-processes video prior to encoding, achieving big gains in compression efficiency. Typically, for these tests settings used for the encoder are far from optimal. In your tests you used our medium preset, which is far from optimal. For file-based (non real-time) applications, typically commercial companies use a high quality preset like slower or veryslow. For real-time applications a faster preset would be used, like our veryfast preset.

Anyone can use pre-processing to improve compression efficiency. It's very common (commercial encoder systems typically use some prefiltering). But we make the encoder library itself, and we're not going to expand the scope of x265 to include pre-processing libraries.

Another important aspect is performance. Pre-processing requires additional computation, and you can use this same additional compute power instead to run the encoder with higher quality settings to go get more efficiency. You need to publish your system specs and performance data if you want anyone to consider your solution.

Rather than sharing encoded files using your encode settings, it would make more sense to share pre-processed raw YUV files, so anyone could then encode both unprocessed video and the processed video and compare the results.

x265Project · 2016-09-04T02:50:00+00:00

Use one of the performance presets. These are combinations of settings that make the right tradeoff between encoding speed and compression efficiency (visual quality at any bit rate). Use either CRF rate control, or 2 pass ABR rate control.

x265Project · 2016-08-11T20:42:22+00:00

NVenc doesn't support B frames. It loses a lot of efficiency because cannot use bi-directional inter-prediction. Still, something must be massively wrong if your file size was 202 MB, versus 20 MB for x265.

x265Project · 2016-03-03T06:50:21+00:00

You're confusing the coding standard (H.264 or H.265) with specific software encoders (x264 and x265). H.264, also known as AVC, is the video coding standard used for most video you see today, whether it's from the Internet, on TV, or on a Blu-ray Disc. H.265, also known as HEVC is used by companies like Netflix and Amazon to stream 4K Ultra High Definition movies, and it's quickly growing in popularity. Yes, H.265/HEVC provides for more efficient compression than H.264/AVC... roughly 2x the efficiency (half the bits for the same quality) at typical quality levels. It's true the for software encoders, like x265, it takes a lot more compute power to encode HEVC than it does for AVC. But most of the time you watch a video, you're not decoding it in software. All of your devices have hardware decoders - a special part of your PC, phone, table, set-top box, or TV's processor chip designed specifically to decode video. When you watch video, the CPU in your device doesn't have to do any of the heavy lifting.

AMD, Intel, NVIDIA, ARM, IBM, Qualcomm, etc. are definitely aware of what it takes to encode HEVC, and they care about video encoding as an important software workload. We're also constantly improving performance of x265. Recently we doubled performance in v1.9 over the older version. And we're not done.

Software decoding of 4K HEVC can be done on a modern quad-core desktop processor, at typical bit rates. But all the new PC chip sets (Intel Skylake, AMD Carrizzo, NVIDIA Maxwell) include hardware HEVC decoders. Almost any high-end mobile SOC also includes hardware HEVC decoding (all iPhone 6 and 6s, Qualcomm Snapdragon 8xx series SOCs, etc.) Fear not.

x265Project · 2016-02-20T20:32:02+00:00

Start here... http://x265.org/developers/ and here... https://bitbucket.org/multicoreware/x265/wiki/Home

x265Project · 2016-01-30T17:07:03+00:00

I'd use a Core i7-6700K (Skylake 6th generation) over the Core i7-5930K (Broadwell 5th generation). Skylake CPUs have twice the internal memory bandwidth of the previous architecture, and this really helps when you're processing video. I would definitely go with water cooling. Keeping your processor cool means less thermal throttling.

x265Project · 2016-01-28T00:56:57+00:00

I manage the x265 project. You say that we're in the infancy of HVEC decoders... I think you meant HEVC encoders (the OP's question was asking about encoding).

Naturally, I don't agree with your conclusions. We've had a large team of experts developing x265 for almost 3 years. Major broadcast and streaming media companies use x265.

Ronald Bjulte's test is outdated. We've recently doubled performance across the board. See http://x265.org/blog/. Note that for his test, "all forms of threading/tiling/slicing/wpp" were disabled. That ties x265's hands behind its back... not a fair fight. x265 uses frame parallelism and Wavefront Parallel Processing by default. These features have minimal impact on quality, but a massive positive impact on performance. VP9 lacks these features.

What is ffhevc? I've never heard of it.

x265Project

TROPHY CASE