Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Media Graphics The Internet

BBC Confirms 50% Bitrate Savings For H.265/HEVC Vs H.264/AVC (bbc.co.uk) 110

An anonymous reader writes: A research team from the BBC has done a series of tests to confirm earlier computations showing a ~50% savings in bit rate for H.265/HEVC compared to video using H.264/AVC at comparable quality. "The subjective tests used a carefully selected set of coded video sequences at four different picture sizes: UHD (3840x2160 and 4096x2048), 1080p (1920x1080), 720p (1280x720) and 480p (832x480), at frame rates of 30Hz, 50Hz, or 60Hz. The video content was chosen to represent diverse spatial and temporal characteristics, and then coded using HEVC and AVC standards at a wide span of bit rates producing a variety of quality levels." Here is the full published analysis. "The tests confirmed the significant compression efficiency improvements achieved in HEVC, verifying the results previously reported using objective quality metrics (PSNR based methods)." The team did not test against VP9, which is shaping up to be an impressive standard as well.
This discussion has been archived. No new comments can be posted.

BBC Confirms 50% Bitrate Savings For H.265/HEVC Vs H.264/AVC

Comments Filter:
  • by Anonymous Coward

    What is it's Weissman Score?

  • by kbonin ( 58917 ) on Tuesday January 12, 2016 @05:19PM (#51290201)

    I've played in this space in a former position. Interesting lessons learned:
    - PSNR is nearly worthless: An image with almost the same score can look terrible. Not all the time, but enough of the time.
    - The only quantitative test I found that worked reliably was an old analog Tektronix PQA500 (lots of work to use for digital CODEC.)
    - Management didn't like the PQA data (it said our product was terrible), decided to use PSNR data (product is great!)
    - Customers fixed this discrepancy and product line failed spectacularly (due to video quality, surprise!)
    - I never could find any published information sufficient to recreate the Tek PQA algorithm.

    • by Fwipp ( 1473271 ) on Tuesday January 12, 2016 @05:30PM (#51290301)

      Which, if you click through, is why the study performed subjective tests; by asking viewers to rate the quality of several videos at several bitrates on a 10-point scale in a series of tests. They found that PSNR systematically underestimated the perceived quality of H.265 (relative to H.264).

      • by kbonin ( 58917 )

        I saw that in the paper, I was hoping someone might know something about Tek's old JND algorithm that's become known since then, or how it performs relative to SSIM or VQM in human subjective studies. Almost all the work in these spaces is patented or commercial...

      • Subjective quality perception is a very weird metric. If you add high-frequency random noise, people perceive it as a more detailed image - an optical illusion causing them to interpret small-scale noise artifacts according to their expectation according to surroundings.

    • PSNR is nearly worthless

      Yes it is. A million ways to fool it. However, SSIM is getting widespread usage, and highly regarded among all of those who hate PSNR.

  • vs H.264 yes (Score:5, Informative)

    by SirMasterboy ( 872152 ) on Tuesday January 12, 2016 @05:24PM (#51290255)

    50% bitrate reduction vs H.264 sure, but not vs x264 which is the current gold standard for HQ video compression.

    It's like comparing a new audio codec to the original fraunhofer MP3 encoder. LAME on the other hand is a significantly better MP3 encoder like x264 is a better H.264 encoder.

    My own compression testing between HEVC and x264 show that at verty low bitrates, yes HEVC is better, but only at bitrates below what I would normally use and what I would consider "quality" encodes.

    When you compare say a 10GB x264 encode of a full-length BluRay film, even 8GB for the HEVC does not provide an equal or superior copy.

    • So if a crude HEVC encoder is equivalent to a very refined h264 encoder, what might a refined HEVC encoder be able to achieve given enough development?

    • Additional info as to which encoders they used:
      "HEVC HM Reference Software Codebase, Version 12.1. [Online]. Available: http://hevc.hhi.fraunhofer.de/... [fraunhofer.de] "
      "AVC JM Reference Software Codebase, Version 18.5. [Online]. Available: http://iphome.hhi.de/suehring/... [iphome.hhi.de] "

      Also, my experience with x265 encodes have been that (dark) low detail areas tend to look terrible, whereas everything else looks extremely good given the bitrate (be it high or low). I remember reading that this was a known (and non-trivial) issue i

    • Comment removed based on user account deletion
      • I was referring to an H.264 reference encoder...

        Also I mentioned x265 in another comment. At this point x265 is hardly better than an HEVC reference encoder. Something you would know if you actually knew what you were talking about and have actually used these encoders and done lots of testing and comparisons.

        How is describing my results from my own encoding comparisons rambling?

        • Comment removed based on user account deletion
          • I think it's safe to assume that the article is talking about reference encoders. The HEVC consortium set out to reduce bit-rate by 50% at equal quality for the HEVC standard and for reference H.264 vs reference HEVC they came out pretty close to that goal.

            I was merely pointing out that if you instead compare a reference HEVC encoder or even the current "best" HEVC encoder compared to the best H.264 encoder (x264), the different in quality is negligible so far, especially for bitrates that actually yield a

            • by Goaway ( 82658 )

              I think it's safe to assume that the article is talking about reference encoders.

              Why would that be safe to assume? That is a useless comparison, and not one that would interest the BBC in the slightest.

              What is far more safe to assume is that it is a comparison between their current h.264 encoding setup vs. whatever h.265 coded they would use in practice. Neither would be the reference codec.

              • What is far more safe to assume is that it is a comparison between their current h.264 encoding setup vs. whatever h.265 coded they would use in practice.

                I don't find that more safe to assume because if they were comparing any HEVC encoder to a non-reference H.264 encoder, i.e. a newer, higher quality H.264 encoder then their claims of 50% reduction in bitrate would not be possible.

                Nobody in the encoder community has posted any sorts of encoder results with such a reduction in bitrate. What has BBC done that is so incredibly special to achieve what nobody else has?

                I find it much more likely that they are comparing to a reference H.264 encoder as that would

  • by Anonymous Coward
    That means it'll take half the time to bittorrent Doctor Who episodes. :-)
  • by Sivar ( 316343 ) <charlesnburns[ AT ]gmail DOT com> on Tuesday January 12, 2016 @06:00PM (#51290505)

    I have done my own comparisons of AVC (using x264, single-thread, veryslow preset) and HEVC (using x265, disabling wavefront processing because it slightly reduces quality, veryslow preset). All 1080p video, significant because HEVC is supposed to scale to 4K better than AVC.

    My conclusions:

    1) x265 takes FAR longer to encode, but we knew that. Understandable.
    2) When "low in bits", x265 blurs images rather than making them look blocky. This sometimes looks better but to me often looks worse.
    3) x265 seems to force a denoise filter. Video is far easier to encode efficiently when denoised, so I figure this is part of the data savings. It's a bit of a cheat, however, because I can get far smaller file sizes by running a denoise filter myself for x264-encoded video.

    I looked closely, for example, at Captain America the Blu-ray. Much of the detail of, e.g. car leather and grass and tree leaves is lost in an x265 encode, even at about the same overall data rate as x265/

    x265 supports "--tune grain", roughly analogous to "--tune film" for x264, but it makes the video vastly larger -- often larger than x264's version, and it often looks worse. It does a better job of keeping grain, however.

    My experience is very similar to many others' in forums. I had committed to switching my encoding to HEVC, but the results of my tests showed it is not ready for prime time. Some may not mind blurry ("soft" is probably a better word) video, or video that looks like it has been through a denoise filter, but I do.

    This is not to say that x265 is junk. I am sure it will mature over time just like x264 had to over time. x264 started out as being not all that much better than divx, the previous generation.

    • by Sivar ( 316343 )

      Forgot to add: I was using recent builds (about a month back) of x265.
      Whenever a comparison is made, the x265 folks always say that the latest versions are much improved over whatever was used in the comparison. They may be, but they still need some work based on my tests.

    • Comment removed based on user account deletion
      • Re: (Score:2, Informative)

        by Anonymous Coward

        HandBrake has x265 built in.

        https://handbrake.fr/ [handbrake.fr]

        It has some quirks though. It's GUI based, but some of the defaults are plain stupid. Someone wanting "simple" is at risk of getting "inferior" instead.

        If you want to devote the time to learning the quirks, you can export a preset for your users once you've got the settings right.

        I made a simple preset to get you (and anyone else) started. MKV container, no cropping/resizing, no filters, default x265 settings (which you'll need to play with), untouched audio

      • by Sivar ( 316343 )

        I always use Staxrip
        https://github.com/stax76/stax... [github.com]

    • I don't understand how people produce decent encoding (using any format). But, they do exist. Download anything you like from a reputable pirate group, the x265 encoded videos simply come out significantly smaller with a similar quality. I do not pretend to be an videophile, but these groups are. And they use x265 and it comes out SIGNIFIGANTLY smaller than x264 every time.

      • by Sivar ( 316343 )

        This is because release groups are completely, utterly clueless about video. The file size is set ahead of time. Most groups set e.g. "8GB for 1080p movie", "4GB for a 720p movie" etc. in x264. Historically speaking, these pre-selected sizes were designed to fit on different media types, such as CD, single-layer DVD, dual-layer DVD.
        Few people use DVDs anymore, but most groups still make files far larger than they need to be.

        I rarely download pre-made videos because of this, so haven't downloaded any encoded

        • I have never seen a competent current group do that. They all encode based on quality, some full length movies come out 200M, others 900M+. Based on the content. They all come out looking good, and for 265, all come out significantly smaller than their 264 counterparts.
          I used to do a lot of 480, horrible quality, but the smallest file size you could find anywhere. Now groups using 265 come out with smaller files in 720. Crystal clear, amazing video, at less then the smallest worst quality used to provide.

    • I would be great if you could try with recent VP9, which is said to be close to x265.
    • by Bengie ( 1121981 )

      2) When "low in bits", x265 blurs images rather than making them look blocky. This sometimes looks better but to me often looks worse.

      Blocking is because of a limited amount of information to display data. Blurring is about adding noise. Noise is annoying.

  • by AbRASiON ( 589899 ) * on Tuesday January 12, 2016 @06:34PM (#51290649) Journal

    I've read many many posts indicating that for low bitrate stuff, 265 is doing very well but for the higher end stuff, it's only marginally better than 265 (more like 25%)
    That's an approximation, I don't recall the exact figure, but I do recall it being significantly less than 50%

    This is pretty disappointing, perhaps other tweaks and improvements will be eeked out over time, but as it stands, I can't see a 3TB movies folder being recompressed to 1.5TB with the same quality at this point in time.
    (I know that would be lossy to lossy and stupid, that's not the intention of the post)

    • by AHuxley ( 892839 )
      It really depends what the end game is for the codec that has to be paid for or designed is.
      Addition of an extra channel in the space of one existing channel . Great for more branded content on existing bandwidth or spectrum.
      Two times the nation building UK content to limit the impact of foreign broadcasting having an impact on traditional UK news and documentaries.
      The role of video over IP considering the limitations of infrastructure going to most towns, cities, villages and its ability to support
  • by jpellino ( 202698 ) on Tuesday January 12, 2016 @09:17PM (#51291243)
    Lawyer up.
  • I don't see any mention of how motion compensation and other "smart" features of the display devices influenced the perceived quality. Software in these devices may work in both positive and negative ways.
    • I don't see any mention of how motion compensation and other "smart" features of the display devices influenced the perceived quality.

      Probably because the BBC are smart enough to use professional monitors without any of that crap.

      And even if they did, as long as the settings are the same for both showings, it shouldn't be a big problem.

      • As listed in the test setup, they used TV sets (although really expensive ones) for the (U)HD setups. The Pioneer PDP-5000EX for instance has Pure Drive 2 software on it that I am not sure you can even disable. The software has MPEG noise reduction... It should at least be listed in the paper how to reproduce their setup, if they fiddled with the TV's settings.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Working...