If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

How is it in terms of cpu efficiency? I.e., does "double" the coding efficiency mean that it compresses data twice as far, or uses half the CPU to obtain the same results? If twice the compression, does that translate to twice the CPU? 10 times the CPU? H264 is already tough on CPU, and this new stuff obviously can't be decoded by legacy hardware decoders.

How is it in terms of cpu efficiency? I.e., does "double" the coding efficiency mean that it compresses data twice as far, or uses half the CPU to obtain the same results? If twice the compression, does that translate to twice the CPU? 10 times the CPU? H264 is already tough on CPU, and this new stuff obviously can't be decoded by legacy hardware decoders.

I read an article about it yesterday and as far as I remember...

With equal quality you will get half the file size. To decode it you will need 4 times more computational power.

How is it in terms of cpu efficiency? I.e., does "double" the coding efficiency mean that it compresses data twice as far, or uses half the CPU to obtain the same results? If twice the compression, does that translate to twice the CPU? 10 times the CPU? H264 is already tough on CPU, and this new stuff obviously can't be decoded by legacy hardware decoders.

While the estimated potential is 'double' the coding efficiency there's no implementation as of now which is near that from what I can tell, and it could take years until it does reach that potential (if ever).

Also from what I understand the algorithms are heavily optimized for 1080p and upwards, so for 480p/720p content it is likely not as competitive with something like h264.

Anyway it's great to have HEVC and VP9 decoding in ffmpeg now as it means decoding these formats will work on a wide range of software all of a sudden.

How is it in terms of cpu efficiency? I.e., does "double" the coding efficiency mean that it compresses data twice as far, or uses half the CPU to obtain the same results? If twice the compression, does that translate to twice the CPU? 10 times the CPU? H264 is already tough on CPU, and this new stuff obviously can't be decoded by legacy hardware decoders.

Netbooks and tablets will hate H265 video

With equal quality you will get half the file size. To decode it you will need 4 times more computational power.

That means real trouble for netbooks and older tablets without hardware H265 support if the format becomes popular for web video. My old Atom N455 machine (before PowerVR) can just barely play an H264 video in 720p at 30fps. That is in mplayer (not flash) with a downloaded file, with a non-compositing window manager saving memory bandwidth and CPU. That means the H265 codec would also be just able to be played in mplayer, but at 360p instead of 720p, for 1/4 the pixel count. If Flash starts using the codec, it would mean that the 270p videos Liveleak puts out that Pentium 4 class machines can barely play in flash would become unplayable in both netbooks and Pentium 4 class computers, which have about the same video playback capacity in my experience. I would advise webmasters not to use a codec heavier than H264 for anything larger than the tiny "mobile" format videos somewhere around QVGA, and to use it there to improve quality, not cut bandwidth further. I don't know about you but I still see a lot of Pentium 4s in use in my community and must be careful to avoid publishing video they can't play.

On the other hand, large format 1080p video intended only for powerful machines to play could really benefit from H265 or VP9. At 1080p, small machines can't play the file except by VDPAU anyway, but files sizes get huge. If a 1080p video already needs a fast dual core or a 4 core to play, a file size that can be reasonably downloaded but will fully load the CPU might be a good tradeoff for many users. Another and even more useful application might be video camera manufacturers, who now produce AVCHD cameras whose output files require 4-core machines to edit. That already being the case, so long as a 4-core can still play and edit the files, taking up half the space on disk for raw video clips could save a lot of money on disk arrays. It would make my 4TB setup equivalent to 8TB. I do hope we have GPU rendering in Kdenlive by that time, though!

Due to the possiblity that camera makers might use H265 for this very reason, it's good to see the ffmpeg project get ahead of the curve now with support for the codec. Besides, it probably won't be long before some commercial sites start serving H265 video, and we will all need to be able to play it because those with the Windows computers will be publishing in that codec,.

Nobody is likely going to be using h.265 on the web for a few more years. It isn't done cooking and the hardware for decoding it isn't ready yet except in set-top box and mobile hardware markets, which already have decoders available. PCs need GPU-based ASICs for basic h.265 decoding before it will be viable for websites to deploy, as CPU-only decoding of high resolution h.265 - which is what h.265 is designed for - requires a high-end multi-core CPU, which most people don't have and won't get in the hardware they buy.

More CPU use for mainstream video means more electrical use

Originally Posted by TheLexMachine

Nobody is likely going to be using h.265 on the web for a few more years. It isn't done cooking and the hardware for decoding it isn't ready yet except in set-top box and mobile hardware markets, which already have decoders available. PCs need GPU-based ASICs for basic h.265 decoding before it will be viable for websites to deploy, as CPU-only decoding of high resolution h.265 - which is what h.265 is designed for - requires a high-end multi-core CPU, which most people don't have and won't get in the hardware they buy.

If people end up using a codec this processor intensive for long form HD video, electrical consumption will rise as either big multicore CPUs have to handle it, or GPU hardware decoders also have to use more power to do more. How much difference will it make in aggregate electrical use for servers to need to send half the bandwidth vs clients require 4x the processing power, assuming both servers and end user machines are NOT frequently replaced, but end users rely on GPU playback if they do upgrade and server farms also rely on best practices when they do replace equipment? Don't bet on continuing ever-smaller architectures too much longer, I hear that is nearly tapped out for silicon.

Also, for the intended audience of my videos, I am looking at 10+ year hardware replacement cycles, I didn't stop seeing Pentium III's in use until 2010 or so. I have to figure anything I publish had better be playable on a core2 laptop with Linux at least to 2020 or so. Still need to be able to read H265, though, as incoming (source) material could show up in H265 at any time after it goes into use.

The final question is this: Is MPEG-LA going to try to harass the good folks at ffmpeg or at avconv in an attempt to kill compatability with their new baby?

So sounds like this really doesn't matter one tiny bit. I sure don't want to turn my 6 or 8 core desktop into a vacuum cleaner just to annoy myself playing videos at a resolution for which nobody even has a display capable of viewing.