x265 HEVC Encoder

[gonca]

Thank you for the information, I guess I'll have to install Hybrid properly and see about DGDecNV and the x265 has stopped working message.
I might have to rerun the benchmarks again
Small donation on the way

[gonca]

some new numbers with Hybrid properly installed and DGDecNV in the game
x265
1080p
ultrafast-27.43 fps
slow------06.28 fps

no crash on slower preset and ram usage doubled

no difference on divx265

[DarrellS]

I just ran a 2040x1144 avi through Virtualdub with the external encoder and DivX265 at 19.8 fps on my old Q6600.

[*] Beginning dub operation.
[i] Dub: Input (decompression) format is: RGB888.
[i] Dub: Output (compression) format is: YUV420.
[i] VideoEnc: DivX 265/HEVC Encoder (version 1.2.0.24) (c) 2000-2014 DivX, LLC (a subsidiary of Rovi Corporation).
[i] VideoEnc: Parameter information:
[i] VideoEnc: Size: 2040 x 1144
[i] VideoEnc: Framerate: 24/1 (24.000)
[i] VideoEnc: FourCC: IYUV
[i] VideoEnc: Frame count: 0
[i] VideoEnc: Profile: DivX 4K
[i] VideoEnc: Encoding...
[i] VideoEnc: HEVC validation warning W0000: Layer 0: DivX ID will not be written because layer settings exceed DivX profile constraints.
[i] VideoEnc: Warning: Const QP selected, Bitstream might not be DivX HEVC profile compliant
[i] VideoEnc: Creating MainConcept H.265/HEVC video encoder ...
[i] VideoEnc: Version: 0.0.0.0
[i] VideoEnc: Summary information: layer 0
[i] VideoEnc: Format: Main@5.0, 2040x1144 1:1
[i] VideoEnc: Number of coded frames 750
[i] VideoEnc: Total encoding time 37937 ms
[i] VideoEnc: Pure encoding time 13474 ms
[i] VideoEnc: Average time per frame 50.583 ms
[i] VideoEnc: Average speed achieved 19.8 fps
[i] VideoEnc: Average CPU load 99.1 % (4 pictures, 8 threads)
[i] VideoEnc: Peak memory usage 461.418 Mb
[i] VideoEnc: Average bitrate 226.44 kbit/sec @ 24.000 Hz (Const QP)
[i] VideoEnc:
--------------------------------------------------------------------------
------
[i] VideoEnc: HEVC Encoding Done.
[i] Mux: mkvmerge v6.8.0 ('Theme for Great Cities') 32bit built on Mar 2 2014 21:27:07
[i] Mux: 'F:\Temp 3\HEVC\114289.mkv.hevc': Using the demultiplexer for the format 'HEVC/h.265'.
[i] Mux: 'F:\Temp 3\HEVC\114289.mkv.hevc' track 0: Using the output module for the format 'HEVC/h.265 (unframed)'.
[i] Mux: The file '114289.mkv' has been opened for writing.
[i] Mux: 'F:\Temp 3\HEVC\114289.mkv.hevc' track 0: Extracted the aspect ratio information from the HEVC video data and set the display dimensions to 2048/1152.
[i] Mux: Progress: 100%
[i] Mux: Progress: 100%
[i] Mux: The cue entries (the index) are being written...
[i] Mux: Muxing took 0 seconds.[*] Ending operation.

[racer-x]

Yeah, l noticed divix265 always pads 1080p out to 1088. X265 encoder keeps it at original 1080 resolution. I guess there is no way to turn that off?

[Selur]

Nope, btw. with HEVC and H.264 always stores mod16 internally.

[LigH.de]

It is probably bound to 16×16 pixel macroblocks. 1080 isn't a multiple of 16.

But x264 encodes 1088 lines as well and stores a cropping area of 1080 lines. MediaInfo does not report this about HEVC encoded by x265 explicitly, but it is possibly encoded in the same way, except developers can tell me wrong.

DGIndex does display such details about AVC videos in its information window.

[LigH.de]

Just for the record --- the source, temp and output drives are all SSDs

I just read in the c't magazine that many SSDs don't like continuous writing access, speed may drop considerably after a few minutes. A good exception with only a moderate slowdown was an intel SSD.

But well, the required writing speed for encoded HEVC streams should be marginal.

[gonca]

The writing speed of the SSD's shouldn't be an issue, as I have it set to use RAM as a cache.
The drives just have to catch up afterwards.

[El Heggunte]

x265 Documentation

http://x265.readthedocs.org/en/latest/

[x265]

Our documentation (the document formerly known as the "Evaluator's Guide" is online in the form of RestructuredText here ... http://x265.readthedocs.org.

x265 developers will be required to update the documentation any time they make changes to the code that affect the command-line syntax, debug or log file output (or anything we've documented).

Anyone can suggest improvements to the documentation simply by submitting a patch to the x265-devel mailing list (edit the RestructuredText files, then use Mercurial to generate a patch). Patches will be reviewed just as code patches are. If the x265 developer community deems the change to be an improvement, the change will be committed.

Thanks
Tom

[Selur]

General comments:

• "API-only Options" should be inside a separate section not under 'Command line options'
• There should be some sort of rule/consitency regarding upper-case-use inside titles:
  - Stand Alone Executeable Options
  - Input Options
  - Quad-Tree analysis
  - Temporal / motion search options
  either each word or just the beginning should be upper case, some time upper sometimes lower case is just irritating.
• Command line Options->Temporal/motion search options-> --subme
  some explanation regarding the column titles should be added.
• Command line Options->Input Options-> --y4m
  this option should be removed and YUV4MPEG2 should be autodetected by simply checking the first few bytes and see if the file has a y4m header
• Command line Options->Input Options-> --input-res <wxh>
  The description should use the words 'width' and 'height' and not just 'w' and 'h'.
• Command line Options->Input Options->--input-csp <integer|string>
  "Only i420 and i444 are supported at this time." -> the other options shouldn't be mentioned then, doesn't seem to make much sense to mention options that are not supported.
• Command line Options->Input Options->--interlaceMode <false|tff|bff>
  The description should mention that the field dimension is half of the normal display dimension.
• In general the description should contain some links to explanations and/or papers.
• I like that the 'Quad-Tree analysis' descriptions mention what effect the options should have, more options should have similar comments.
• Command line Options->VUI (Video Usabitlity Information) options
  The "Default undefined" is a bit confusing since it's not clear if 'undefined' is a not mentioned/listed parameter of the option or if it means that the option simply isn't used.
  Similar confusing is caused by 'Default disabled' and 'Default None'.

[Selur]

Also it's a real shame the whole preset overview table isn't part of the documentation anymore, hope this changes soon.

[x265]

General comments:

• "API-only Options" should be inside a separate section not under 'Command line options'
• There should be some sort of rule/consitency regarding upper-case-use inside titles:
  - Stand Alone Executeable Options
  - Input Options
  - Quad-Tree analysis
  - Temporal / motion search options
  either each word or just the beginning should be upper case, some time upper sometimes lower case is just irritating.
• Command line Options->Temporal/motion search options-> --subme
  some explanation regarding the column titles should be added.
• Command line Options->Input Options-> --y4m
  this option should be removed and YUV4MPEG2 should be autodetected by simply checking the first few bytes and see if the file has a y4m header
• Command line Options->Input Options-> --input-res <wxh>
  The description should use the words 'width' and 'height' and not just 'w' and 'h'.
• Command line Options->Input Options->--input-csp <integer|string>
  "Only i420 and i444 are supported at this time." -> the other options shouldn't be mentioned then, doesn't seem to make much sense to mention options that are not supported.
• Command line Options->Input Options->--interlaceMode <false|tff|bff>
  The description should mention that the field dimension is half of the normal display dimension.
• In general the description should contain some links to explanations and/or papers.
• I like that the 'Quad-Tree analysis' descriptions mention what effect the options should have, more options should have similar comments.
• Command line Options->VUI (Video Usabitlity Information) options
  The "Default undefined" is a bit confusing since it's not clear if 'undefined' is a not mentioned/listed parameter of the option or if it means that the option simply isn't used.
  Similar confusing is caused by 'Default disabled' and 'Default None'.

Selur,
Thanks again for your excellent feedback. Would you like to submit a patch to contribute these improvements? We would love you to break the ice.

Tom

[LigH.de]

There are a few questions left about the values and the meaning of parameters which are not clearly explained in the documentation.

--asm:
A translation between the string representation and a bitmask is not mentioned, but I assume it is not very intuitive to use the bitmask integer value anyway. What's probably more interesting: Some CPU features are detected "pessimistically", e.g. a Phenom-II X4 945 (Deneb) does support extensions like SSE3 and SSE4a, but x265 avoids to report them and only enables SSE2. A reason might be a quite slow implementation of these extensions. Would this option allow to enforce the use of matching implementations? If so, I will probably have to include all less advanced CPU flags too, up to the desired one, or their use may get disabled because it is not explicitly enabled? (--asm MMX2,SSE,SSE2,SSE3)

--rdpenalty
What is its purpose, what are possible (dis)advantages? If I understood correctly, it seems to make x265 avoid intra-coded CUs in non-I frames, so it will probably save a few bits, but at the expense of quality due to not perfectly matching motion vector targets (the best found match in the ME range is such a bad match that, for quality's sake, an intra coded CU would be preferred if there was no penalty).

--hash
Probably quite irrelevant, just for curiosity: MD5 and CRC are some kind of checksums too; so which algorithm is option 3 using? Is it a special checksumming algorithm described in the HEVC specs? Hopefully not simply summing up and maybe shifting, that would be quite fast but pretty ambiguous.

[Selur]

Would you like to submit a patch to contribute these improvements?

is there some git or similar one can checkout or would it require to check the source of each file, modify it and create a diff?

[El Heggunte]

Zeranoe still is building FFmpeg with libx265, therefore

MORE people to pester him are required:

http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1889&start=10

[Selur]

Don't really see a good reason to pester anyone to support a dying OS.
And if you have to pester anyone, pester the someone who knows how to write an appropriate patch (I don't, x264 and x265 guys might).
Pestering Zeranoe will only result in him either:
a. dropping x265 altogether
or
b. dropping Windows XP support altogether (if I were Zeranoe, this would be the option I would choose, since there are bound to appear more and more code which isn't XP compatible)
both might not be the results most people are looking for.
-> doesn't seem such a wise idea to pester Zeranoe

----
If you are that motivated about the issue, why not build ffmpeg yourself and offer precompiled binaries yourself?

[El Heggunte]

I love to see how you PRETEND that you do not see my point, Selur.

But that's OK, you are a "modern" programmer, and "modern" programmers like to praise the laziness or incompetence of their dearest colleagues (namely, Steve Borho).

[Selur]

@El Huggunte: I see your point that it would be nice to have x265 not break Windows XP compatibility and I too see that you pestering people who don't have the knowledge and/or time to fix the problem for you (like Zeranoe) seems to be not so clever.
I also see that x265 is an opensource project with no official binaries, so if there were a separate source tree which would fix the Windows XP support the only change would be that people who want to build it would have to use another source tree. So me motivation on the subject is not to pester people into doing stuff the don't want to atm., but more in looking out if I know someone who could fix the issue.

But you might be right, I'm in software development for more than 10+ years (first time I sold a by me coded solution, not the first time I coded anything,.. that would be more like the C64 timeframe) so I must be a 'modern' developer and not some only complaining and not seemingly otherwise in the matter productive user.

But since you present yourself as someone who does know stuff, why don't you do more productive stuff, in example make a fork of https://github.com/jb-alvarado/media-autobuild_suite build ffmpeg whenever there are up-dates and offer them to the public?

[Selur]

@El Huggunte: you might be pleased to hear, that Steve Borho is testing some patches to bring back Windows XP support. (read the mailinglist for more information about it)

[Chris K]

Zeranoe took off libx265 in todays new build (on request) untill the XP issue is fixed.

[Marchand]

Zeranoe took off libx265 in todays new build (on request) untill the XP issue is fixed.

Latest versions libx265 suport - 28-Mar-2014

This build was compiled on: Mar 28 2014, at: 22:02:04

FFmpeg version: 2014-03-29 git-657cee1
libavutil 52. 69.100 / 52. 69.100
libavcodec 55. 55.104 / 55. 55.104
libavformat 55. 36.100 / 55. 36.100
libavdevice 55. 11.100 / 55. 11.100
libavfilter 4. 3.100 / 4. 3.100
libswscale 2. 5.102 / 2. 5.102
libswresample 0. 18.100 / 0. 18.100
libpostproc 52. 3.100 / 52. 3.100

This FFmpeg build was configured with:
--enable-gpl
--enable-version3
--disable-w32threads
--enable-avisynth
--enable-bzlib
--enable-fontconfig
--enable-frei0r
--enable-gnutls
--enable-iconv
--enable-libass
--enable-libbluray
--enable-libcaca
--enable-libfreetype
--enable-libgsm
--enable-libilbc
--enable-libmodplug
--enable-libmp3lame
--enable-libopencore-amrnb
--enable-libopencore-amrwb
--enable-libopenjpeg
--enable-libopus
--enable-librtmp
--enable-libschroedinger
--enable-libsoxr
--enable-libspeex
--enable-libtheora
--enable-libtwolame
--enable-libvidstab
--enable-libvo-aacenc
--enable-libvo-amrwbenc
--enable-libvorbis
--enable-libvpx
--enable-libwavpack
--enable-libx264
--enable-libx265
--enable-libxavs
--enable-libxvid
--enable-zlib

ffmpeg-20140329-git-657cee1-win32-static.7z
ffmpeg-20140329-git-657cee1-win64-static.7z

[x265]

Don't really see a good reason to pester anyone ...
If you are that motivated about the issue, why not build ffmpeg yourself and offer precompiled binaries yourself?

Amen brother. I'm blown away by the entitlement ethic... expecting and demanding that others do work for free, and contributing nothing but venom and harassment in return. Clearly not a believer in the 7 Habits of Highly Effective People.

[deadrats]

Amen brother. I'm blown away by the entitlement ethic... expecting and demanding that others do work for free, and contributing nothing but venom and harassment in return. Clearly not a believer in the 7 Habits of Highly Effective People.

this is really funny coming from you guys because you are not working for free; by your own admission MWC has corporate sponsors who are financing the development of your x265 branch and once it is complete you guys plan to monetize it further by following the x264 LLC dual licensing scheme.

in fact, it seems to me that it is you that is guilty of the entitlement ethic, you ask Selur if he would be willing to submit patches but the fact remains i don't see why anyone would contribute one single line of code or documentation to your project because i doubt that you plan on sharing the profits from the sponsorship and/or licensing deals with any patch contributors, are you?

but this can be extended further to why anyone would ever contribute any code to any commercialized open source project, like the Linux kernel, any of the open source desktops, x264, x265 et al.

i'm supposed to contribute work/code for free so you guys can turn around and make a profit from my contributions while giving me nothing?

my momma didn't raise no dummy.

[x265]

We've been clear about our business model from the start. We have signed up a number of charter members to the project, and we continue to sign commercial license agreements. What would otherwise take many years of volunteer developer efforts is coming together much faster thanks to the funding from these charter members and licensees. Anyone who is able to accept x265 under the GPL 2 gets a very valuable piece of software for free. Most people in the open source community appreciate that a private company stepped up to the plate, took a big risk, invested heavily, putting a large team of talented developers on this project. The project is going well, but it's uninformed to throw around the term "profits" at this point.

When you use free, open source software, you get something valuable for free, and you get it "as-is", with no promises and no warranty. There are no implied promises. No one owes you anything. Software is rarely perfect, and the development work is never done. There is always room for improvement, and there is always a long list of requests.

If you want a new feature, there are a number of ways you can go about getting it. You can wait for it. You can develop it yourself. You can pay someone to develop it. Or, you can try to talk someone into developing it for you. If you go with the last option, remember what your mama told you... you'll catch more flies with honey than vinegar. Ranting and raving and criticizing and encouraging others to pester and harass the developers is not going to win you any points or make someone more inclined to help you.

We have a contributor compensation policy, and we've shared it with open-source developers who contribute to the project. Significant valuable contributions will be rewarded. We've had some great contributors participating in the project so far, and we're always ready to welcome more to the project.

My suggestion to Selur on the documentation was to get the process started on what a number of people have asked for. Rather than posting feedback on a public forum and then waiting for another x265 developer (or me) to get the edits done (the old process), it will be faster and more efficient to use an open-source direct contribution process. In any case, given his valuable input and his friendly approach, if Selur asks me for something, I'm inclined to help. The same is true for most of the people I've interacted with here, on Doom9, and on our development mailing list.

[deadrats]

We have a contributor compensation policy, and we've shared it with open-source developers who contribute to the project. Significant valuable contributions will be rewarded. We've had some great contributors participating in the project so far, and we're always ready to welcome more to the project.

now this does earn my respect, if in fact you are compensating contributors and/or have some sort of profit sharing plan in place for if/when x265 LLC starts generating a sustainable income and a guy like Selur that is capable of contributing code will get a piece of the action for his contributions, then kudos, you guys are doing something very different than most open source projects, where a guy like Linus who owns the rights to the Linux kernel is worth something like 10 million bucks and others that have contributed code got jack squat other than a virtual pat on the back.

When you use free, open source software, you get something valuable for free, and you get it "as-is", with no promises and no warranty. There are no implied promises. No one owes you anything. Software is rarely perfect, and the development work is never done. There is always room for improvement, and there is always a long list of requests.

this is not fair, while you may view your users as getting something valuable for free and by logical implication that they don't have a right to complain, the developers, in your case, get something equally valuable, free QA. you get a massive army of beta testers with all different hardware combinations and usage patterns that test your software for free and report back bugs they find. commercial projects like those undertaken by companies like MS, Apple, Sony et al pay QA/software testers good salaries for testing the software and finding bugs so you're not contributing your software for free, you're saving the money you would have spend on salaries for QA people by opening up beta testing to the general public, so it's a symbiotic relationship in the open source world, it's not the humanitarian developers and the thankless, unappreciative users that you make it out to be.

If you want a new feature, there are a number of ways you can go about getting it. You can wait for it. You can develop it yourself. You can pay someone to develop it. Or, you can try to talk someone into developing it for you. If you go with the last option, remember what your mama told you... you'll catch more flies with honey than vinegar. Ranting and raving and criticizing and encouraging others to pester and harass the developers is not going to win you any points or make someone more inclined to help you.

you keep trying to make your interaction with certain users/posters, such as myself, as us being demanding douches that want you to work for free to give us what we want. the fact of the matter is that you seem to be too thick to understand what valuable feedback we have given you from the start.

you guys, with you as the public face, have embrace the most intractable absurd development approach one can imagine and rather than listening to the feedback have doubled down and simply accused people like me of demanding something for nothing.

we begged, harassed and insulted you and your firm to add std::in support so that the general public could test your software and instead of realizing what a huge interest your project had generated in such a short time you fought back with inane arguments that none of your corporate sponsors had any interest in std::in support. really?!? then how did they plan on using it, by feeding it raw yuv footage?

but it goes way beyond that, i have told you time and time again, you guys have taken the wrong approach in the development of x265 and have continued on this wrong approach, much like the guy that gets lost and refuses to turn on the gps or ask for directions because he's convinced he recognizes the neighborhood and will find the street soon enough.

do yourselves a favor, if you want to make some serious money, consider the following suggestion. you claim that you have over 200 engineers working for MWC that are experts in gpgpu programming. if this is true take 50 of those people and give them the following task:

take the reference h265 encoder and port it so that it runs either partially or completely on a graphics card, using either Open CL, CUDA or Direct Compute.

now i'm not talking about that half-assed OCL acceleration you added to x264, because let's be honest with ourselves you would have been better off not even bothering, it's useless in any meaningful way.

i'm talking a about a fully gpu powered encoder, ala the reference CUDA h264 encoder nvenc that nvidia released years ago, or gpeg2, the gpu powered mpeg-2 encoder coded in DX9 compatible HLSL or the gpu powered vc-1/h264/h265 encoder that Elemental offers.

forget about the limitations of gpu acceleration of old, the old CUDA enabled cards suffered from memory bandwidth limitations that killed performance, yes i know with the old cards you had to do a memory copy from system ram to graphics ram and this copy was slow so it negated any performance benefits of the gpu.

these limitations no longer apply, as of CUDA 6, CUDA now support unified memory, meaning that the graphics card can use system ram the way it can use it's ram thus memory copy needed, amd's cards are memory bandwidth monsters and that GCN architecture is custom made for gpgpu and both nvidia and amd are committed to increasing memory bandwidth with future cards.

once you develop the encoder DO NOT release it as open source, make it a proprietary product and DO NOT sell it to the general public as a standalone application.

what you do is this: if you coded it using OCL or DX Compute, approach both AMD and NVIDIA and sign licensing deals to bundle your encoder with ever new graphics card they sell. consider that in 2013 NVIDIA, AMD and Intel sold a combined 446 million gpu's, that's combined integrated and discrete gpus. assume that Intel outsold both AMD and NVIDIA by a large margin. so that just the two of them sold 200 million. let's also assume that of those it was a 75-25% split in favor on integrated gpu's, inc smart phones, tablets, cpu's, and laptops.

so let's assume that the total desktop gpu market was just 50 million discrete gpu sales worldwide. if you could sign a bundling licensing agreement with the 2 of them and get just 10 cents for each bundled copy, that would generate 5 million bucks per year in a market that projected to grow well through 2017.

do you think you would be happy with licensing deals worth 5 million a year.

code the gpu powered hevc encoder, raise hype by letting every major tech site test it but don't make it available for download or sale to the general public and then sign a licensing deal to have it a featured bundle with every new card either AMD and/or NVIDIA sell.

if you guys were really smart, you would take it one step further and work the deal so that the encoder was only included with the high end cards these companies sell, maybe you could work out a deal that it's only available with cards that cost over $300, this would allow you to negotiate a higher percentage of the take and the video card companies would have a nice marketing tool sell higher end cards that have better margins.

the final piece of the puzzle is you would want to make sure that your encoder didn't end up on the pirate bay 1 hour after the first cards were sold so maybe you could include code that tied each instance of the encoder to the specific bundled video card, maybe it could read an unique embedded string in the card's bios and only work if that specific string was present.

you guys could make a ton on money of you just stop following that ridiculous x264 LLC roadmap; DS made money despite himself, he got lucky because google bought out youtube and youtube used his encoder and he got lucky because a few south american broadcast companies stared using his software. you guys are facing a different market, google will transition youtube to vp9 by next year, the Rovi/Divx people have already started signing licensing deals and the Elemental people already have high quality broadcast ready gpu powered solutions for sale. you guys are not going to compete in that market, you need to go after a market these guys have largely ignored, the joe average enthusiast that buys a new video card every year, wants to play around with the latest encoding technology but doesn't want to go through the hassles and expense of buying a high end $500+ dollar cpu+MD+ram and then have to re-install the OS and all the apps just to barely manage real time 1080p encoding with your current encoder.

it just boggle my mind the road you guys decided to take, how anyone can look at a collection of 200 engineers that are supposedly experts in gpgpu computing and say to themselves "hey, i have a great idea, let's follow a the licensing scheme of a half-assed kid that just got his bachelors degree in 2011 and while we're at it let's employ the coding approach that basically enures that our encoder will forever be tied in most meaningful ways to x86, an approach that requires multiple code paths for each different cpu architecture and increases development time because we have to hand code and optimize x86 assembler".

that's "brilliant", that's like me earning a 3rd degree black belt in judo, getting into a street fight with slugger and not trying a single throw or choke but instead jumping around like a bunny rabbit trying to be a boxer and then wondering why i need reconstructive surgery on my face. (for the record i'm trying to illustrate a point, the above sentence is not a representation of anything that actually happened).

[Stears555]

We have a contributor compensation policy, and we've shared it with open-source developers who contribute to the project. Significant valuable contributions will be rewarded. We've had some great contributors participating in the project so far, and we're always ready to welcome more to the project.

now this does earn my respect, if in fact you are compensating contributors and/or have some sort of profit sharing plan in place for if/when x265 LLC starts generating a sustainable income and a guy like Selur that is capable of contributing code will get a piece of the action for his contributions, then kudos, you guys are doing something very different than most open source projects, where a guy like Linus who owns the rights to the Linux kernel is worth something like 10 million bucks and others that have contributed code got jack squat other than a virtual pat on the back.

When you use free, open source software, you get something valuable for free, and you get it "as-is", with no promises and no warranty. There are no implied promises. No one owes you anything. Software is rarely perfect, and the development work is never done. There is always room for improvement, and there is always a long list of requests.

this is not fair, while you may view your users as getting something valuable for free and by logical implication that they don't have a right to complain, the developers, in your case, get something equally valuable, free QA. you get a massive army of beta testers with all different hardware combinations and usage patterns that test your software for free and report back bugs they find. commercial projects like those undertaken by companies like MS, Apple, Sony et al pay QA/software testers good salaries for testing the software and finding bugs so you're not contributing your software for free, you're saving the money you would have spend on salaries for QA people by opening up beta testing to the general public, so it's a symbiotic relationship in the open source world, it's not the humanitarian developers and the thankless, unappreciative users that you make it out to be.

If you want a new feature, there are a number of ways you can go about getting it. You can wait for it. You can develop it yourself. You can pay someone to develop it. Or, you can try to talk someone into developing it for you. If you go with the last option, remember what your mama told you... you'll catch more flies with honey than vinegar. Ranting and raving and criticizing and encouraging others to pester and harass the developers is not going to win you any points or make someone more inclined to help you.

you keep trying to make your interaction with certain users/posters, such as myself, as us being demanding douches that want you to work for free to give us what we want. the fact of the matter is that you seem to be too thick to understand what valuable feedback we have given you from the start.

you guys, with you as the public face, have embrace the most intractable absurd development approach one can imagine and rather than listening to the feedback have doubled down and simply accused people like me of demanding something for nothing.

we begged, harassed and insulted you and your firm to add std::in support so that the general public could test your software and instead of realizing what a huge interest your project had generated in such a short time you fought back with inane arguments that none of your corporate sponsors had any interest in std::in support. really?!? then how did they plan on using it, by feeding it raw yuv footage?

but it goes way beyond that, i have told you time and time again, you guys have taken the wrong approach in the development of x265 and have continued on this wrong approach, much like the guy that gets lost and refuses to turn on the gps or ask for directions because he's convinced he recognizes the neighborhood and will find the street soon enough.

do yourselves a favor, if you want to make some serious money, consider the following suggestion. you claim that you have over 200 engineers working for MWC that are experts in gpgpu programming. if this is true take 50 of those people and give them the following task:

take the reference h265 encoder and port it so that it runs either partially or completely on a graphics card, using either Open CL, CUDA or Direct Compute.

now i'm not talking about that half-assed OCL acceleration you added to x264, because let's be honest with ourselves you would have been better off not even bothering, it's useless in any meaningful way.

i'm talking a about a fully gpu powered encoder, ala the reference CUDA h264 encoder nvenc that nvidia released years ago, or gpeg2, the gpu powered mpeg-2 encoder coded in DX9 compatible HLSL or the gpu powered vc-1/h264/h265 encoder that Elemental offers.

forget about the limitations of gpu acceleration of old, the old CUDA enabled cards suffered from memory bandwidth limitations that killed performance, yes i know with the old cards you had to do a memory copy from system ram to graphics ram and this copy was slow so it negated any performance benefits of the gpu.

these limitations no longer apply, as of CUDA 6, CUDA now support unified memory, meaning that the graphics card can use system ram the way it can use it's ram thus memory copy needed, amd's cards are memory bandwidth monsters and that GCN architecture is custom made for gpgpu and both nvidia and amd are committed to increasing memory bandwidth with future cards.

once you develop the encoder DO NOT release it as open source, make it a proprietary product and DO NOT sell it to the general public as a standalone application.

what you do is this: if you coded it using OCL or DX Compute, approach both AMD and NVIDIA and sign licensing deals to bundle your encoder with ever new graphics card they sell. consider that in 2013 NVIDIA, AMD and Intel sold a combined 446 million gpu's, that's combined integrated and discrete gpus. assume that Intel outsold both AMD and NVIDIA by a large margin. so that just the two of them sold 200 million. let's also assume that of those it was a 75-25% split in favor on integrated gpu's, inc smart phones, tablets, cpu's, and laptops.

so let's assume that the total desktop gpu market was just 50 million discrete gpu sales worldwide. if you could sign a bundling licensing agreement with the 2 of them and get just 10 cents for each bundled copy, that would generate 5 million bucks per year in a market that projected to grow well through 2017.

do you think you would be happy with licensing deals worth 5 million a year.

code the gpu powered hevc encoder, raise hype by letting every major tech site test it but don't make it available for download or sale to the general public and then sign a licensing deal to have it a featured bundle with every new card either AMD and/or NVIDIA sell.

if you guys were really smart, you would take it one step further and work the deal so that the encoder was only included with the high end cards these companies sell, maybe you could work out a deal that it's only available with cards that cost over $300, this would allow you to negotiate a higher percentage of the take and the video card companies would have a nice marketing tool sell higher end cards that have better margins.

the final piece of the puzzle is you would want to make sure that your encoder didn't end up on the pirate bay 1 hour after the first cards were sold so maybe you could include code that tied each instance of the encoder to the specific bundled video card, maybe it could read an unique embedded string in the card's bios and only work if that specific string was present.

you guys could make a ton on money of you just stop following that ridiculous x264 LLC roadmap; DS made money despite himself, he got lucky because google bought out youtube and youtube used his encoder and he got lucky because a few south american broadcast companies stared using his software. you guys are facing a different market, google will transition youtube to vp9 by next year, the Rovi/Divx people have already started signing licensing deals and the Elemental people already have high quality broadcast ready gpu powered solutions for sale. you guys are not going to compete in that market, you need to go after a market these guys have largely ignored, the joe average enthusiast that buys a new video card every year, wants to play around with the latest encoding technology but doesn't want to go through the hassles and expense of buying a high end $500+ dollar cpu+MD+ram and then have to re-install the OS and all the apps just to barely manage real time 1080p encoding with your current encoder.

it just boggle my mind the road you guys decided to take, how anyone can look at a collection of 200 engineers that are supposedly experts in gpgpu computing and say to themselves "hey, i have a great idea, let's follow a the licensing scheme of a half-assed kid that just got his bachelors degree in 2011 and while we're at it let's employ the coding approach that basically enures that our encoder will forever be tied in most meaningful ways to x86, an approach that requires multiple code paths for each different cpu architecture and increases development time because we have to hand code and optimize x86 assembler".

that's "brilliant", that's like me earning a 3rd degree black belt in judo, getting into a street fight with slugger and not trying a single throw or choke but instead jumping around like a bunny rabbit trying to be a boxer and then wondering why i need reconstructive surgery on my face. (for the record i'm trying to illustrate a point, the above sentence is not a representation of anything that actually happened).

Both VP9 and Divx HEVC codecs have simply low laughable performance in quality.

[deadrats]

Both VP9 and Divx HEVC codecs have simply low laughable performance in quality.

vp9 has almost no threading to speak of, none and is just a bare bones reference encoder; DivX HEVC on the slowest settings isn't any slower than x265 on the slowest settings, on my system an X6 1045t, 1080p encoding with x265+very slow is measured with an hour glass, lucky if i see .2 fps, that's point 2 not 2.

the elemental people meanwhile have a gpu powered hevc encoder that does 4k encoding in real time.

[LigH.de]

@ Stears555:

3 pages of a quite meaningless fullquote (see e.g. Netiquette rule 63).

And one almost unrelated sentence as reply.

Please avoid that waste of space. If you refer to any part of that quote at all, edit the quote so that only this relevant part remains (see e.g. Netiquette rule 25).

Sorry for backseat moderating, but #177 really is a role model of a "don't".

[LigH.de]

Ooh, sweet progress:

6642 (1fc0fda2b08b) Merge with default (feature freeze for 0.9)

Means, version 0.8+263-1fc0fda2b08b is considered a stable step towards the milestone of v0.9.