Good article about H.265

http://www.tomshardware.com/reviews/x265-hevc-encoder,3565.html

First actual H.265 products are announced:

LG has announced an expansion to its ultra high-definition 4K line of TVs, this time with full-backlit LED 55-inch and 65-inch models. In addition, there has also been unveiled an 84-inch UHD model, which is the first to be made available to buyers in the United States.

The TVs feature a picture resolution of 3840 x 2160, as well as the Tru-Ultra HD engine that upscales content via a four-step process. In addition, the LA9700 utilized an H.265 HEVC (high-efficiency video coding) decoder, which will make the sets compatible with new 4K standards that may be implemented in the future for streaming and broadcast.

The first production units will provide this decoding in a USB dongle, but as the new standard becomes more widely implemented, H.265 will be built into the sets themselves.

Via: http://www.slashgear.com/lg-unveils-la9700-series-4k-ultra-hd-led-55-inch-and-65-inch-tvs-11290175/

@igorek7

Another one? Ouch. Sad thing no one will use it.

But seem to use interesting ideas.

I think Samsung is relying on the Qualcomm SnapDragon S4's media processor to do H.265 decoding. I don't know yet whether it can also do H.265 encoding - they don't actually claim that they can, rather their demo shows decoding of H.265 streams. I should know within a month or so what it is capable of. Decoding is much easier (less processor intensive) than encoding. In fact, decoding H.265 probably isn't all that much more processor intensive than decoding H.264. It's the encoder that has to do extensive processing to try numerous permutations to get the desired result; once content is encoded it includes metadata that tells the decoder exactly what it has to do. Mobile devices typically support many more formats for decoding than encoding. I think H.265 is currently mostly of interest to commercial content providers. Even if these new devices can only decode H.265, that would still be of significant interest to those consuming content.

I'll report back when I figure out what the new Samsung devices can do on the encoding side.

I agree - Raw and Prores actually require considerably less processing than H.264 and H.265. It seems to me that they could write Prores files at close to the maximum speed of the Flash (they aren't getting very close with current CODECS). Of course, Prores uses much more bandwidth - up to 220Mbps for these kinds of applications but that falls within what a 300x (360Mbps) write speed flash should be able to do (in the near future).

I suppose it is difficult to accommodate the consumer and semi-professional markets with the same camera lines. Who knows where all this will go.

I suspect what we'll see is H.265 encoders in cameras and mobile devices producing 10Mbps, or so, video first. The higher bandwidth stuff will take a while. After all, H.265 isn't intended to be higher quality than H.264, rather it is designed to produce smaller files (or lower bandwidth streams).

H.265 will be a boon for consumer cameras - where small video files is the priority. For work where image quality is a priority I think it will take much longer to implement. Consider some of the newer cameras in this market segment - they rely on simpler CODECs (such as Prores, etc...), or Raw, and faster memories. The idea that you can get twice the quality with H.265 at equal bitrates for high IQ applications is a ways off. With disk drives and faster flash memory getting cheaper by the month I'm not sure the high IQ video market will care all that much about using less storage space.

People tout that H.265 will be twice as efficient (from a bandwidth standpoint) as H.264. However, by throwing more processing power at H.264 real time codecs you could probably already make them twice as efficient as current implementations. In order to improve on that with H.265 you'll probably have to do ten times as much processing.

The problem is that the primary ways H.265 achieves better efficiency involves techniques that require radically more processing. For example, intra encoding with H.264 involves encoding blocks with nine different directional (actually, eight directions and DC) methods. H.265 expands that to 35 different methods. The GH2 supports these nine methods, but only with 4x4 blocks (not supporting 8x8 blocks). H.265 has 4x4, 8x8, 8x4, 4x8, 16x16, etc... (I can't remember them all right now). Also the GH2 uses very limited QP ranges (typically ranges of less than 5 on I frames and 1 on P and B frames. NIkon, as a contrast, uses very wide QP ranges on all frame types (which is why I believe they are using a lot of hardware). To calculate how much work is being done you have to use a formula that, for example, takes the number of directional methods multiplied by the number of block sizes, multiplied by the number of QP values into account. Clearly, the GH2 only does a small fraction of the amount of work required to achieve maximum efficiency with H.264. The GH3 does somewhat more work (but not really so much more) and the Nikon does much more work (using all available block sizes and a wide range of QP values). I think for there to be much hope in using H.265 effectively on Panasonic cameras such as the Gxx series they will have to rely heavily on hardware acceleration. Of, course, that would probably double the efficiency of the H.264 encoders as well.

Your point about market demand is well taken - after all marketing claims carry more weight than actual image quality improvements.

I think Nikon relies on hardware for major parts of compression too. I didn't mean to imply that we won't see hardware based compression for a while - I meant that it takes longer to implement new things in hardware than it does in software. Sorry for the confusion.

I think Broadcomm and Qualcomm are producing hardware based H.265 capabilities - but I suspect it will take some time for camera manufacturers to catch up. Also I'm still not convinced that H.265 is all that viable as a real time encoder - especially in light of the fact that H.264 real time encoders as they are currently implemented are considerably less efficient than they could be if more processing power were thrown at them. Until the full potential of H.264 is realized in real time encoders, I don't see the point of implementing H.265 - which requires much, much more processing to realize its full potential.

For play-back it makes much more sense as content can be encoded on bigger machines and bandwidth requirements would be reduced. It's not the decoder that is the issue with small real time devices, it's the encoder - which has to do much more work.

BSkyB satellite broadcasting will be using Broadcom chips in their new set-top boxes.

I'm not sure how suitable H.265 will be for real time encoding - it requires much more processing power. Camera's like the Panasonic Gxx series (which use software compression) don't even use many of the compression features of H.264 because of processing limitations. You could get considerably better compression with H.264 with these cameras by just using all the compression features H.264 already supports. Real time software compression in devices such as cameras is usually pretty inefficient compared to what you get when using a computer. If these cameras can't really keep up with the full potential of H.264 because of processing limitations, how are they going to do any better with H.265? Now, if hardware based compression were to be used that could be a different situation, but we won't see that in camera's for a while.

Roughly same file size w/ twice more compression ratio. Not bad at all. It will improve Vimeo streaming quality if machine/player is capable of decoding it fast enough.

Download the JCT dev reference software manual here to get an idea of the new HVEC standard;-

https://hevc.hhi.fraunhofer.de/trac/hevc/browser/trunk/doc/software-manual.pdf