Good Question Tiddles88 -
Like an earlier poster said, "x265" is nonexistent (to my knowledge) and would likely be *one way* to decode h.265/HEVC. (i.e. a "filter" in our world, a decoder)
h.265 would be the codec standard's name. (For both encode and decode) and various organizations and companies could choose to decode it as they wish. Encode is the most important, with decode as a reference in the standard, when it comes to h.265 or any other video codec. Many companies try all sorts of tricks and gimmicks to decode codecs of all manner today. It's easier if we change the names:
I am going to make a new way of using lossy encoding methods to compress video. I'm going to call it Monkey Poop in. Monkey Poop In compresses raw video data or decompressed data from another codec in a very specific way. I am also releasing Monkey Poop Out, which is my preferred way of getting Monkey Poop back to the raw video needed for your display to show 1920x1080 pixels 60 times a second. I'm calling both of these methods together "Monkey Poop" and I will charge money to use either method in your product. To further make it complicated, I will charge less money to just use Monkey Poop In or just Monkey Poop Out in your product. (Think a BluRay Player - it only needs Monkey Poop Out)
Now let's say some enterprising people come along. They want to find another way to decode Monkey Poop In. (Since many more people are interested in free ways to decode than encode) We'll call this group of people FFMpeg
. They reverse engineer the mathematical tricks I am using to encode 60 bitmaps of 1920x1080 images every second into much smaller files. They release "xMonkeyPoop" since they want their version of Monkey Poop Out to look as much as an official decoder as possible. They could also reverse engineer the encoding methods of Monkey Poop In to where their code is indistinguishable from Monkey Poop In, and everyone can use it. They could be really confusing and call this same method "xMonkey Poop" So now we would have:
Monkey Poop: A pair of Encoder and Decoder software mechanisms (Monkey Poop In and Monkey Poop Out) that is commercial. It costs you money to use this in your product.
xMonkey Poop: A pair of Encoder and Decoder software mechanisms (xMonkey Poop refers to both directions) that is free (or free-ish) to use in your product.
h.265 is an effort to make a real standard that we can all conform to. It would be non-commercial but many people want it to be commercial. Decode, like any lossy algorithm, would be much less compute-intensive than encode (finally getting to your question) but the methods employed by the proposed h.265 algorithm(s) are extremely compute intensive on both sides of the equation, especially due to some advanced mathematics involved at very high frequencies which were not possible even 5 years ago on common hardware. Specifically things like "dot product" and DiffEq on a CPU were very expensive in terms of cycles and better suited to GPUs. The decode will still need to do those complex parallel operations. Perhaps the advent of this "APU" will make things more common, but there is also a huge push to mobile and ARM which is slowing down the whole concept, but is important for wide user adoption.