Announcement

Collapse
No announcement yet.

FFmpeg Now Supports HEVC/H.265 Decoding

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • FFmpeg Now Supports HEVC/H.265 Decoding

    Phoronix: FFmpeg Now Supports HEVC/H.264 Decoding

    Earlier this month FFmpeg developers added a VP9 media decoder to their open-source project and now they have added a free implementation of the HEVC/H.265 codec decoder...

    http://www.phoronix.com/vr.php?view=MTQ4Njg

  • #2
    There is a mistake in the title: you wrote 264

    Regards.

    Comment


    • #3
      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.

      Comment


      • #4
        Originally posted by droidhacker View Post
        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.

        Comment


        • #5
          Originally posted by droidhacker View Post
          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.

          Comment


          • #6
            Originally posted by droidhacker View Post
            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.
            It seems that Intel's H264 decoder (libva) depends on shaders heavily.
            Could anyone please tell me whether it's possible to improve libva to support HEVC?

            Comment


            • #7
              Netbooks and tablets will hate H265 video

              Originally posted by Silverthorn View Post
              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.
              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,.

              Comment


              • #8
                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.

                Comment


                • #9
                  More CPU use for mainstream video means more electrical use

                  Originally posted by TheLexMachine View Post
                  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?

                  Comment


                  • #10
                    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.

                    Comment


                    • #11
                      Originally posted by droidhacker View Post
                      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.
                      Meanwhile I'd enjoy having 1080p videos that you wouldn't actually need to wait half an hour to buffer.

                      Comment


                      • #12
                        Originally posted by GreatEmerald View Post
                        Meanwhile I'd enjoy having 1080p videos that you wouldn't actually need to wait half an hour to buffer.
                        That still makes a 6 or 8 core run full out and compete with your vacuum cleaner to see what is louder. Enjoy your movie... if you can actually hear it.

                        Also for... buffering? First off... who buffers? Download the damned thing. You can download an entire movie in considerably less time than that. Or are you downloading via smoke signals?

                        Comment


                        • #13
                          I was under the impression Lithuania had very fast internet? Wikipedia says you have the 2nd fastest down pipe and the fastest up pipe.

                          Comment


                          • #14
                            Originally posted by droidhacker View Post
                            That still makes a 6 or 8 core run full out and compete with your vacuum cleaner to see what is louder. Enjoy your movie... if you can actually hear it.

                            Also for... buffering? First off... who buffers? Download the damned thing. You can download an entire movie in considerably less time than that. Or are you downloading via smoke signals?
                            That is only true if you have poor ventilation or poor fans.

                            Downloading takes even longer than buffering.

                            Originally posted by curaga View Post
                            I was under the impression Lithuania had very fast internet? Wikipedia says you have the 2nd fastest down pipe and the fastest up pipe.
                            Most have. I don't. The thing is that it's very dependent on the location. In the building I live in, there are connections to two ISPs. One of the ISPs provides only cable internet, and no fibre, because they can't get their cable installed for a number of reasons (possibly having to do with the other ISP). Meanwhile the other ISP technically provides fibre internet to the building, but for some unknown reason the cable doesn't reach my flat. So I would have to rewire the whole flat for it to be routed here, and that's not worth the effort and/or cost.

                            Once I move somewhere else, though, chances are I'll be able to use fibre internet (again; my last flat had it). Then I'll be able to self-host servers and all. But until then...

                            Comment


                            • #15
                              Originally posted by GreatEmerald View Post
                              ...
                              Downloading takes even longer than buffering.
                              ...
                              Ok, well, to be fair, a given video will take the same amount of time to download regardless of what you do with it after you download it. I guess if you are writing it to persistent storage, then that will take longer than just leaving it in a buffer, but since writing to storage occurs at the same time as the download is still in progress, and since your bottleneck is the download, chances are you aren't going to see any actual difference in time between writing it to storage or not. On the other hand, if you compare the same video optimized for download and optimized for streaming, assuming equal quality the download version should be a little bit smaller and hence actually take less time downloading.

                              Comment

                              Working...
                              X