First Draft of H.265 Spec Due in February

Our growing appetite for high-def video is putting a serious strain on operator networks, and the result is an enemy we all love to hate: bandwidth caps. So bearing that in mind, it’s good news to hear there’s continued progress on the development of a new video compression standard, the High Efficiency Video Coding specification, or H.265. According to Multichannel News, an initial draft of the new spec should be ready in February, with a completed standard due in January 2013.

The H.265 codec is expected to decrease the bandwidth needed to deliver video by 25% to 50%. The bandwidth savings come at a cost of increased processing complexity, but the benefits, particularly for mobile operators, make the cost worthwhile. GigaOM reported not long ago that data delivery will stop being profitable for mobile carriers in about a year and a half. Without increases in efficiency, you can bet your bottom dollar that carriers will raise data rates as a counter-measure. On the other hand, with a combination of network improvements and compression advances, perhaps we can stave off that outcome and continue to enjoy our mobile streaming services.

New video compression techniques will also be put to the test with the advent of Ultra High-Definition Television. UHDTV is said to increase the number of pixels crammed into a video picture by 400% to 1,600%. The ITU settled on an agreement for the basic tech specs in a UHDTV standard with an announcement last week.

4 thoughts on “First Draft of H.265 Spec Due in February”

  1. Personally I’m thinking 4K is a more relevant short term topic than UHDTV… I expect we’ll see quite a few 4K TV’s at CES in a few months. There could be some real benefits, say to upscaling or passive 3D (e.g. keeping full frame resolution of 1080i) to having 4K TV’s, even before we see any 4K sources.

    Glad to hear about progress on H.265 though. Cue first post from an open source/Google type about why it won’t be better than VP8 in 3… 2… 1…

    While I think the GigaOm post is accurate, I think its overblown. Lots of things are going on to reduce the cost of deploying bandwidth in 4G–the move to all packet/all Ethernet backbones, deployment of small cell (microcell) backhaul towers on light poles rather than towers, etc etc. Should stave off the cost issue somewhat, even if the trend line is still obvious.

  2. The GigaOm post was certainly meant to paint a worst case scenario. Nobody will let it get to a point where data is unprofitable – least of all the carriers.

    RE: anticipated Google response… giggle.

  3. That’s some significant bandwidth savings. Added complexity to the processing though… I wonder if the current state of H.264 hardware decoders are up to the task of H.265 with a simple firmware update… or if yet again we are talking about obsoleting this hardware. I mean MPEG4 / H.264 decoding set top boxes are BARELY out there in the grand scheme of things.

    I’d like to see more content at better quality too and whatever the most efficient means of getting that content to me is what I’ll take. H.265 sounds like its another step in the right direction to making this a reality.

  4. Glenn – I really don’t see Google claiming VP8 is as good as, let alone better than, HEVC. There are good arguments that put it against H.264. But H.265 is the next level. Google is probably working on VP9, or what have you, but they’d be crazy to match VP8 against H.265 and they know it.

    Cypherstream – New HW. H.264 silicon won’t do H.265, that’s the point. It is much more computationally intensive and uses new techniques. Most H.264 HW is optimized for performance and cost, so it has just enough power to decode H.264 at the resolutions it supports and no more. Any extra processing power is wasted cost in the design and silicon. To get 25-50% greater compression you’re looking at at least that much an increase in processing, probably more since it isn’t a linear relationship. It generally takes a bigger increase in processing power than the resulting increase in compression.

Comments are closed.