Hmmm.... I'm not very versed in video encoding technology but from what I gather x264 has been adding features outside of the 'official specs' for pretty much all it's existance, and looking at the list I directly recognize things like higher bit depth and cabac from x264 settings.

So I'm wondering is there some new sercet sause in h265 which makes it really much better than say x264 or is it just a new standard created around extra features which encoders like x264 already has implemented?

H265 has some quite innovative features (over H264), for instance instead of dividing the picture into rows of macroblocks, it's divided into quadtrees, which allow the compression algorithms to make more use of spatial similarity.

I naively wonder if it cannot be generalized to octrees. To embed the inter-frame analysis into a single 3d sliding adaptive octree.

>embed the inter-frame analysis into a single 3d sliding adaptive octree //

I've no idea what this means [yet] but it sounds too awesome to ignore. H266 here we come?!?

As far as I can tell they just amped up similar features from h.264. Better motion estimation, more block types in B-frames, etc. Just "more" of the same. edit: from that link I posted larger block sizes, larger transform sizes, fancier interpolation filters, improved intra prediction schemes, improved motion vector prediction, increased internal bit depth, new entropy coding schemes, and so forth.

Well they are using tricks and newer technique to make better quality pictures while still within the official specs.

So it is not exactly outside to the official specs at all.

x264 does not break spec. It looks familiar because H.265 is a very incremental improvement over H.264. I suspect the biggest single difference is the larger transform sizes.

From DarkShikari's evaluation:

After a full 6 hours, 8 frames had encoded.

Looks like it's not ready to evaluate yet.

That's from over 2 years ago. A version 10x faster (and with half the code stripped out) was available last year and I assume someone has made a sane version since.

Anyways he explains what happened: instead of choosing sane options, that encoder would iterate through every possible encoding and test each of them for PSNR, for a competition. It's not the kind of encoder you would ever use in practice.

For reference, there are 129,600 frames in a 1.5 hour long 24 fps movie.

At 0.75 hours per frame, that's 97,200 machine hours, or just under three years even if you have a cluster of 100 machines.

This might be GPU encoding's chance to shine. Right now it's generally considered to not be worth the hassle over a fast i7 machine.

And of course the algorithms will be optimized, maybe by orders of magnitude. But that's still a lot of computation power required, no matter how you slice it.

It's worse than that, as the algorithms are not simply parallelisable (frames relate to each other). Of course you could chop the film into 100 pieces, and compress each individually, but you would lose some compression rate which would (partly) defeat the whole purpose.

Not really - the encoder tends to reset quite often, e.g. it is recommended to insert an "I" frame every 5 seconds or less (stands for "intra coded", but could be thought of as "independent") - so that you have to decode at most 5 unused seconds when doing a random seek.

You wrote a whole lot here based on years-old numbers for a prototype encoder whose implementation wasn't even relevant when the numbers were posted, as acknowledged in the posting. Why did you do that?