HEVC / H265 encoding... let's end this mystery!

  • Warning: "Geek" post below!


    Ok, So I'm currently putting together a new rig (PC hardware) - it will be used for music production and video production. Absolutely no MAC for me! For compatibility reasons...


    So, I already have 64GB of fast DDR4-3000-RAM in hand.
    Now I'm looking for the right CPU-platform.


    The thing is, I'm looking to do a lot of video encoding in 1080p and/or 4K using the HEVC/H265 codec.
    With my current AMD 8350 8-core - oc'ed at 4.5Ghz - it's taking 2 hours plus for a 30min video. I don't have that much patience - so I'd rather throw some money at the problem!


    I've looked around and it appears that you can get much faster results using a GPU for encoding (either AMD or the current gen NVidia GTX960 or new GTX1070/1080) - but they say while you gain significant speed - the quality takes a huge hit.
    So GPU encoding is out of the question - unless you're using the igpu of an Intel processor which has Intel's quick sync video feature (that apparently has great quality)...


    So, it seems my only option is to go with a current gen Skylake or next gen Kaby Lake processor/platform.


    I originally wanted to go for a quad-channel 2011-3 platform with a 6-core CPU but you don't get the quick sync video feature there, as these don't have an integrated GPU - but maybe these are strong enough to encode H265 via software in a fast pace.


    So - what's your take on this? What to do?


    a.)Get a Skylake / Kaby Lake and use the igpu to encode?
    b.)Get a 6-core Broadwell-E/Skylake-E and use software to encode?
    c.)Wait for AMD Zen...? (no info on this currently)

  • I assume you need to use that codec 'cause you're producing the vids for streaming?


    It's just that I cannot stand H265 and won't touch it with a 10-foot pole... and I know nothing about video. It seems to me as if all depth is missing from all the vids I've seen of this flavour, whereas H264, whilst not perfect as it's obviously still lossy, is IMHO infinitely superior picture-quality wise.


    My guess is that you have to go HEVC for what you're doing; I can't understand it otherwise. I'm also guessing that 'cause it's so heavily compressed it takes a helluva lot longer to encode due to all the extra number crunching that'd logically be required.


    I don't envy your situation. Still, if and when you upgrade to a faster machine or CPUs (not really applicable to GPU) you'll have a blitzin', super-responsive audio setup.

  • Interesting you say that, oh wise Monkey! :D


    Seriously, I have done a bit of research the last couple of days and it seems that H265 has more intelligent compression...


    I'm just going for the least possible size while retaining the best possible quality. How 'bout this as a sample:


    External Content www.youtube.com
    Content embedded from external sources will not be displayed without your consent.
    Through the activation of external content, you agree that personal data may be transferred to third party platforms. We have provided more information on this in our privacy policy.

  • Or he is using a Samsung camera?On topic: Why would the quality suffer if the rendering is done by the GPU, is this the "nitro sounds better then poly" mojo type of thing in the video world :D ? I never heard anything like that, have to check that out later (running a 6800K with a GTX1080).

    MJT Strats / PRS Guitars / Many DIY Guitars -- Kemper Profiler Rack / Kemper Remote / InEar

  • mDan, I have asked the same question and got this answer: (sorry it is in German)


    "Das hat damit zu tun dass GPu encoding größere Blöcke berechnet ohne dabei zu prüfen ob Veränderungen innerhalb der Blöcke besteht. Also entstehen bei gpu Encoding so Vierecke bei nahliegende Farben. Wirkt wie wenn etwas geblurt wird. Also am deutlichsten sieht man das wenn man mpeg2 mit gpu encoding ins h264 encodiert. Die Zeitersparnis bei h264 gpu ist minimal [...] und dabei wird die Datei sogar größer wenn man keine Qualitätsverluste haben will. Datei ist dann um Faktor 2 größer. Darum encodet keiner mit gpu, und wenn dann nur für webvideos ohne Anspruch YT"

  • mDan, I have asked the same question and got this answer: (sorry it is in German)


    "Das hat damit zu tun dass GPu encoding größere Blöcke berechnet ohne dabei zu prüfen ob Veränderungen innerhalb der Blöcke besteht. Also entstehen bei gpu Encoding so Vierecke bei nahliegende Farben. Wirkt wie wenn etwas geblurt wird. Also am deutlichsten sieht man das wenn man mpeg2 mit gpu encoding ins h264 encodiert. Die Zeitersparnis bei h264 gpu ist minimal [...] und dabei wird die Datei sogar größer wenn man keine Qualitätsverluste haben will. Datei ist dann um Faktor 2 größer. Darum encodet keiner mit gpu, und wenn dann nur für webvideos ohne Anspruch YT"


    I am pretty sure that in this comparison is based on using different encoders that use different methods for compression. Using the same encoder with GPU support should result in much higher speeds. Anyway, you will definitely need at least a NVIDIA 9 series GPU because earlier series will not support HDMI 2.0 and thus not 60Hz@4k. I would also recommend a Nvidia 970/980/1070/1080 for smooth HEVC playback. At the moment i am having big trouble with my media center PC, because there are no HMDI 2.0 GPUs with low profile format. 4K Playback with H264 is no problem but HEVC is just impossible without hardware acceleration.

  • EDIT: I posted this in response to schneidas' video; I wasn't aware of the subsequent replies as I'm a slow typist. Please feel free to ignore this, of course.

    OK, firstly you'd never, ever use 1024 kbps for a 1080p video. Never.


    That "comparison" is a stacked deck - it's set up to show you what H265 is good at, which is the very reason I suspected you were looking at streaming the content you create. That's it's strength, and I'm guessing the reason it exists. It can provide you with better resolution for any given file size.


    To me 'though, the comparison is irrelevant. 1080p videos, and I only know this 'cause I download so damned much... Asian pop (you thought I was going to say something else, didn't you, you naughty, naughty boy!), tend to start looking good at above at least 8000 kbps. Around 12000 they start to look fantastic IMHO.


    On the other hand, every H265 vid I've seen has been impressive from one point of view only - its small size. Depth just seems to disappear; the scenes simply look flat, like they seriously lack a third dimension (depth). I'm not kidding you, brother. As I said, I'm no video expert, but I know a lousy picture when I see one. Heck, I don't even care about frame rates, the discussion of which seems to be all the rage in the racing-simulation world at the moment; I care only for the picture quality.


    To me, the difference between, say, an old (35 or 70mm?) Technicolour movie (such as a Western) and H264, in terms of depth and immersive potential, is the same again but exaggerated when one goes from 264 to 265. Seriously whacked, man.


    If I said to you, "Here, I've invented a new MP3 codec that allows decent-quality music to be heard for a quarter of the size (not sure what the differential with these video formats is, but I've a feeling that it's huge, and possibly way more than a factor of 4 for the same "quality" - remember that the video comparison you posted didn't show comparable qualities and focus on the size difference; it sought only to try to make H265 look good by restricting the H264 size to be similar to the '65s one), so your 320k MP3s, which are usually 10 megs a song, will now be 2.5, what would you think? Would you intuitively figure that more chunks have been pulled at every opportunity than previously, such as the removal of sound where it's preceded by a louder one (the masking effect)? Well, you'd be right. You can only compress to represent a string of data with a certain efficiency right now, and whilst slight improvements will always be possible with time due to heftier algorithms' representing ever-larger "shapes" or strings, the codecs would have to keep growing and require ever-more grunt to implement in real time. What I'm suggesting is that H264 is at a safe, best-for-most level - not too demanding and not to large in size, with great (relatively speaking, for the size and playability) picture quality... IMHO.


    Rant over. Can't believe I made all that stuff up based upon a few threads of experience, but then again, as we all know, Analogy City™ tends to creep into everyday-life experiences like water into cracks in the ground, air into an insect's respiration pores, oxygen into a fish's gills, bad language into a teenager's vernacular, addiction to junk food through ever-increasing-sized bites that start out as "just a taste", alcoholism via "just one more for the road", light into a dark cupboard through the cracks in the door, bad language and adult themes on the tele-titty-vision's movement towards prime time and last but not least, the ever-growing love Kemperites feel for their beasties. Yup. Analogy City™ rocks like the Flintstones on a Saturday night, like Elvis in the back of a panel van, like Analogy City™ when the Rocks... I mean, Stones play there on a Friday night, like the circular analogy that's befitting of Analogy City™ that I just wrote...


    Dang. 8| Hope everything made sense before that last paragraph, schneidas. :D

  • mDan, I have asked the same question and got this answer: (sorry it is in German)


    "Das hat damit zu tun dass GPu encoding größere Blöcke berechnet ohne dabei zu prüfen ob Veränderungen innerhalb der Blöcke besteht. Also entstehen bei gpu Encoding so Vierecke bei nahliegende Farben. Wirkt wie wenn etwas geblurt wird. Also am deutlichsten sieht man das wenn man mpeg2 mit gpu encoding ins h264 encodiert. Die Zeitersparnis bei h264 gpu ist minimal [...] und dabei wird die Datei sogar größer wenn man keine Qualitätsverluste haben will. Datei ist dann um Faktor 2 größer. Darum encodet keiner mit gpu, und wenn dann nur für webvideos ohne Anspruch YT"


    Interesting, really didn't know that. Maybe because the instruction set for the CPU is more complex then for a GPU?


    @tylerhb: Why would the output refresh rate matter in this case? I thought we are talking about GPGPU computing and not playback?

    MJT Strats / PRS Guitars / Many DIY Guitars -- Kemper Profiler Rack / Kemper Remote / InEar

  • Interesting, really didn't know that. Maybe because the instruction set for the CPU is more complex then for a GPU?


    @tylerhb: Why would the output refresh rate matter in this case? I thought we are talking about GPGPU computing and not playback?


    Because encoding 4K Videos is pretty useless if you are not able to playback the files that you just encoded for testing. I just wanted to point that getting a powerful GPU is necessary anyway, even if you are not using the GPU for encoding.


  • Ok I'm still too new at this... How much would you use for 1080p?
    And how much for 4K por...errr... videos?


    :D


    If I'm converting from, say, an AVI (which I think falls under the DivX banner) format or something, I'll always go for a minimum of 7 or 8000k, depending on how critical picture quality is. 10k is pretty safe for most situations, like watching a movie at home, but if you want more-or-less flawless quality, like if you were going to watch something like Star Wars or another CGI-intensive sci-fi flick, it might be worth looking at 12 000k+.


    The main differences you'll see between, say, 7000k and 12 000k are firstly where colour and shading graduations occur, like for instance on a leg, where it's cylindrical and shaded according to lighting, but always varies around the cylinder in colour and / or brightness. The lower the bit rate, the more obvious the "steps" in what would otherwise be a smooth transition between the lighter and darker parts of the leg become. The other main indicator, for me at least, is the "blockiness" that occurs when, using the example of the leg, it moves. The more and faster it moves and the lower the bit rate, the more "graininess" or "blockiness" you'll see. Easy, peasy.


    So, when determining a bit rate to use for any given conversion, the first thing I do is look for a section or sections where that shading-gradation area is large and easy to see, and one where there's added movement as well. I'll then convert only that small section (15 seconds or so) at the lowest rate I think I can get away with, and make an initial judgement on whether or not and how much to increase the bit rate. With practice you will easily be able to say, "I know that for this amount of blockiness, if I increase the rate 30% it'll get me to where it'll be good enough for me". Easy, peasy.


    One other important thing: The other critical factor besides the bit rate is how long you give the app to crunch the numbers - the longer you allow it to scrutinise the task at hand, the more efficient the result will be. The picture will not only be better at your chosen rate, but the file size will be slightly smaller as well, so whenever you have the options of choosing conversion speed (slowest, slow, medium, fast and fastest, for instance), choose the slowest, and where there's a "2-pass" option, choose that too, along with "retain quality" or "same quality".


    Trust me, those are your best friends - retaining quality (a relative term, of course; it's never quite the same), 2-pass (gives the app time to give it the once-over and focus more intelligently on the second pass), conversion speed and the bit rate you choose. You'll soon find yourself enabling all but the latter option by default; the only one you'll change depending on the source will be the bit rate. All the others, in order to squeeze the best quality you can out of conversion, must be set as I described. The only reason they're there is so folks who're in a hurry can disable them in order to save time, sacrificing quality and file size in the process. You might want to choose the minimum speed (shortest time) for when you do those "test snippets" I talked about. Again, with practice, you'll be able to make the bit-rate judgement I explained, but also taking into account the fact that when you choose the slowest option, a measure of quality-increase will occur on top of the bit-rate incurred one. You could also try your minimum rate at top speed, make an assessment, choose perhaps a higher bit rate if need be, and then, if that gets you really close, convert the snipped clip one last time but at the slowest rate, just to be sure. There's no point waiting for a long clip or movie to be converted at the slowest speed only to find out that a 15% higher bit rate would've made a world of difference.


    You now know everything I do, brother! That surely will help you; I just wish someone had explained that to me 'cause I learned through trial and error, having to seek out originals time and again in order to reconvert my various libraries as I stumbled across parameters who's functions I'd not bothered to explore.


    Good luck, schneidas! Do some experiment-titty-lactation and let us know how you go, eh?


    PS: You asked about 4K. I haven't even seen a 4K vid yet, and I'm not sure I want to; if I don't know what I'm missing out on, no harm done in my book, and it's not like I've ever got much disk space... or a 4K monitor. If I download from PooToob I never choose above 1080p 30fps. The standard (30fps) isn't specified; it'll just say [1080p], but rather assumed, whereas the many videos that are now 60 fps are tagged that way in, say, ClipGrab, which is the best free (German!) PooToob downloader I know of and have sworn by for some years, as [1080p 60fps] and as I said, more frames per second seems to be all the rage these days, but I'm not fussed by that.


    Just know that all the same principles will apply to 4K video, only all the figures will be much higher, principally the bit rates, file sizes and conversion times.


    PPS: If you equate bit rates to sample rates in audio and bit rates for MP3s, it might help you understand what's going on. They amount to the same thing from my perspective. Higher rate = higher quality and larger file.