Personal View site logo
Make sure to join PV on Telegram or Facebook! Perfect to keep up with community on your smartphone.
H.265 HEVC topic. Same quality, half file size.
  • 130 Replies sorted by
  • Why are those demo's always done so ... well .... shit?

  • @Hallvalla: It usually takes years from the prototypical implementation and standards committee to products on the shelf, so don't hold your breath ;-)

    @mozes: I think those competent to engineer video encoding algorithms are not necessarily the same people that like to spend their time shooting great videos or setting up impressive demos. And vice versa ;-)

    What I am wondering about: Do we really need even more efficient lossy video coding? After all, storage becomes bigger and cheaper, bandwidth the same, so why bother with the efforts to squeeze out some additional bytes?

  • So that the manufacturers can continue to sell us some 4.2.0 8 bit codec.

  • @karl i get that.
    What i mean is, if you create something that is better then it was before, why not show it in a way that everybody can see it.
    That video example diden't show anything..

  • @mozes: How could you possibly show that? Of course you could publish the same video encoded in H.264 and H.265, with the file size of the latter being half of the former, and ask people to download your decoder prototype to convince themselves that the quality is actually about the same.

    But those not into the details of video encoding would either not bother to do that or doubt that the comparison was fair anyway (because of course, one could have chosen an unfavorable set of parameters for the H.264 version).

    And those who are participating in the development of video encoders will probably measure their efficiency by other means than downloading one sample demo video somebody else prepared.

    (There is actually a very old standard set of totally boring video clips that have been used as somewhat representative material to prove video encoders on for decades... just like there is that decades old picture of the lady with the large white hat that you can see in hundreds of papers on still image encoding... :-) )

  • @karl we definitely need more efficient lossy video coding for streaming purpose.

    Users needs and numbers grow faster than network bandwidth, which is not infinite.

    @danyyyel Codecs the likes of H.265 are not created "so that manufacturers can continue to sell us something". We (videographers) are not the only users of video codecs. We are even probably very small and minor compared to broadcasters and content delivery services.

  • So, what does it take? 100x the processing power? I guess we won't see this in consumer encoding devices before 2020...

  • H.264 isn't being taken full advantage of in the recording space... you can do 4:4:4 intra in H.264. Seeing as hardware support for decoding H.265 will probably come before encoding support, I can see a case where cameras still record H.264 (H.265 is 1/2 to 3 times slower) and H.265 begins to emerge as a delivery codec.

    As our world becomes more mobile, it won't matter much if H.265 can be played on a PC... when smartphones, tablets, and TV media players support it, that's when its adoption as a delivery codec will begin to spread.

    Right now there is a lot of angst as the major TV piracy groups switch from XviD/AVI (which a lot of people have DVD or media players with support for) to x264/MP4 (which, although technically superior, has less widespread support.)

  • Thanks, VK. Do I see references to interlaced frames in the spec? OMG! Do we still need this to be supported?

  • Do we still need this to be supported?

    Why not?

    It is widely used in satellite TV and DVB-C.

  • H.265, 4:2:2 chroma, DSLM. I'll be a happier camper.

    4:2:2 subsampling bandwidth is 2 x 4:2:0 bandwidth. That'd be instant gratification.

  • "Encoding it is very time-intensive. It takes amazingly long," said Homer Dowlat, a senior staff engineering manager at Qualcomm.

    Time will tell, but an assessment like that doesn't sound promising for image capture applications. Lossy encoders achieve high compression ratios by eliminating redundant and imperceptible data. Spending significantly more processing time to eliminate even more image data than H.264 is not going to improve image quality, it will only make file sizes smaller. For real-time image capture, what's needed is a streamlined high-speed encoder rather than one that's even more sluggish and complex than H.264.

  • I don't care about smaller file size. I want same file size with more accurate color information.

    Hardware acceleration will catch up. Not this year. Nevertheless this is a good news. One day we'd get GH or something affordable capturing at 4:2:2. Technology advancement going only fast and faster.

  • H.265 will be more focused on 4K things, I suppose :-)

    Usually each resolution bump is accompanied by better compression :-)

  • @stonebat Right, and regardless of hardware acceleration, more intensive compression produces smaller files at the expense of image quality. H.264 already has 4:2:2 and 4:4:4 profiles that can preserve more color information than AVCHD, but that inevitably requires more data storage. What H.265 offers is the opposite - less data and smaller file sizes without "perceptible" degradation in image quality. But as we've seen with the GH2, what's imperceptible to consumers is far from adequate for even semi-pro purposes.

  • 4k 4:2:0 would suck...

    Not good for caputring input... darn.

  • 4k 4:2:0 would suck...

    LOL :-)

  • h265 will half the file size compared to h264. will this enable 1080p as default vimeo resolution for everybody?

  • I already posted above, that first it'll be adapted by satellite TV and DVB-C. More by first one. As they have limited resources and always seems to be wanting to put loads of crap on them :-)

  • Yep h265 (HEVC High Efficiency Video Coding) will be ratified by January 2013 and implemented in all new Cameras/camcorders/ and of course 4K devices by early 2014 - the codec wars begin again. Basically, HEVC achieves around avg 50% bit rate reduction while maintaining the same subjective video quality relative to its predecessor H.264/AVC (they're gonna need it for 4k). [source: fraunhofer]

    What does it mean? Here's h265 v h264 test paper


    At the moment trial-outs of h265 seem pretty scarce but people are beginning to announce things. Main Concept for example.

    x265 also has been rushed out by an unknown (x264 people will probably be unhappy with this?)

    More good reading at;-

  • Interesting. Thanks for the info! I wonder how this all fits with recording media such as SD cards. Re-spec'd, possibly denser, higher cost cards will be required I suppose.

  • @stonebat Actually, 4:2:2 doesn't require twice the bandwidth of 4:2:0. With 4:4:4 each pixel requires 3 bytes of data (8-bit uncompressed), 4:2:2 requires 2 bytes of data, and 4:2:0 requires 1.5 bytes of data. Thus 4:2:2 only requires 33% more bandwidth than 4:2:0 (or, 4:2:0 representing a 25% reduction from 4:2:2). The problem with 4:2:2 is that chroma channels use rectangular pixels instead of square ones. The result is that the horizontal resolution for chroma channels is cut in half, but the vertical resolution is not. With 4:2:0, both horizontal and vertical resolution are cut in half resulting in a more symmetrical appearance. Deblocking and filtering are used to smooth things out to make the subsampling less obvious; but nevertheless, with 4:2:2 subsampling there is a visible difference in how vertical and horizontal detail looks. I think camera manufacturers have opted for 4:2:0 over 4:2:2 because it is easier to produce a palatable image with it and there isn't enough to be gained by going with 4:2:2. I doubt that the relatively small reduction in bandwidth requirements was the main/only reason behind the decision.

  • @cbrandin Thanks. That really makes sense.

    I wonder if 2x anamorphic can work nicely with 4:2:2 subsampling by squeezing more horizontal data.

  • @ stonebat Good question. The luma channel is still the same, though.