Encoding: Tell me why...

[JCNiest5]

It takes so much of computing power to encode, let's say a movie or video file? What's different about it from ie: playing games (executing thousands of lines) or just plain computing? I'm trying to encode a video file and the computer just goes on a crawling mode, even on an i7 2600K OCed to 4.5Ghz! WTH!!!

 

[Silentbob343]

Because racecar

 

[Blahman]

Fundamentally it comes down to general computing hardware vs single-purpose computing hardware vs raw bandwidth vs compression algorithms. Digital video is ultimately just a bunch of bits of 1's and 0's, but the emphasis being on bunch. A 1080p video frame is 1920x1080 = 2,073,600 pixels, each pixel is usually 8 bits, so depending on your framerate you're talking anywhere between 60 and 120 megabytes per second of bandwidth for uncompressed full frame video. Now adding in compression reduces the amount of raw bandwidth needed but introduces a whole lot of computation overhead such as motion interpolation, blocking/deblocking etc. So you can imagine it is very computationally intensive. CPUs are meant to be general-purpose devices meaning they can run nearly any algorithm or instruction, but may not be as good at specific algorithms as single-purpose hardware such as professional video equipment. Now some CPUs are getting more purpose-built subsystems like the integrated graphics on the Sandy Bridge CPUs so that's why they are better at video encoding than the general compute part of the CPU.

 

[GushpinBob]

Well, your GPU does play a rather important part when playing games.

 

[Cyberbeing]

x264 (open-source h264 encoder) for example is extremely optimized with hand-written assembly, and scales well with fast CPUs, special instructions, multiple cores, and threads. x264 will peg all your CPU cores at 100% and can often identify a poor overclock (video corruption or outright encoding failure) even when common stress-test applications like Prime95, Linpack, and/or OCCT pass just fine. The more computational power (99% integer, 1% float) you give x264 the faster encoding speed will go. Slow encoding speed is just a compromise you need to make for top-notch compression and video quality.

When the successor to h264, HEVC (aka h265) is finalized in the coming years, expect encoding speed to become at least an order of magnitude slower than it is now. There is no avoiding things getting slower when using increasingly advanced and computation heavy compression schemes designed to maintain video fidelity as close to visually lossless as possible, all while producing the smallest output stream in a lossy way.

 

[JCNiest5]

You guys think if I enable the built-in GPU on the SB CPU, would that speed up any encode/decode task as far as movie rendering is concerned? Although my mobo is capable of using the GPU on the SB CPU, I currently have it Disabled and am using a GTX570. I tried the same video file on my Rampage III Gene with a Dual Core 1.86Ghz Xeon and it just seemed to have stopped working...so I put it on the SB rig and was able to finish it, but boy, did it take long!

 

[Blahman]

I don't know exactly how it works because it isn't compatible with my board, I don't think it's compaitble with the ones in your sig either (MIVE and P8P67 Deluxe), but yes it should be quite a bit faster than normal CPU encoding.

 

[JCNiest5]

I don't know exactly how it works because it isn't compatible with my board, I don't think it's compaitble with the ones in your sig either (MIVE and P8P67 Deluxe), but yes it should be quite a bit faster than normal CPU encoding.

I just updated my signature to show the correct board.

 

[Cyberbeing]

Compared to x264, AMD's and NVIDIA's encoders have poor quality and compression, while Intel's QuickSync is only decent for its speed. The only valid reason to use a GPU encoder, is if you need your CPU cycles free for some other task.

With a fast CPU like yours, x264 can match or beat GPU/QuickSync encoding speed, quality, and compression. For GPU-like encoding speed with better quality, try using x264 --preset superfast.

x264 has a large range of presets to adjust encoding speed and quality. If you are not time constrained, consider using a preset in the slow to veryslow range for maximum quality.

fast encoding | lower quality <--- ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo--->slow encoding | higher quality

 

[TyrantTru]

Cyber explained it perfectly. I do recommend using the x264 as well - I use it w/Vegas and it does quite nicely. Even though you're pegged - depending on the rest of your specs you can game or even record more at the same time...thats how I do anyways.

 

[aphexcoil]

Since we're on the subject of video encoding, does anyone have any recommendations on which program to use within Ubuntu?

 

[defaultluser]

Games are designed to be REAL-TIME: that's why they are fluid. But they make concessions to do the rendering in real time: lower-quality, less complex geometry and simpler physics. This is why a rendered movie (e.g a Pixar film) can look so much better than a scene right out of a real-time game engine: the renderer and components of the scene are optimized for QUALITY at the cost of speed.

Your typical movie encoder is optimized for quality over speed, so the typical settings produce framerates that are not real-time. And even if you hit real-time, it still takes 2 hours to convert a 2 hour movie. People just don't realize how much data they have to convert - if you asked a game engine to render 2 hours of footage in the span of a couple minutes, it would also just slow to a crawl

As for why encoding is so much heavier on processing power than decoding, that's designed-in to the codec so that you can playback on low-power, low-cost devices. And the processing complexity depends on how densely you want to pack your video information: you can probably use an older codec like MPEG/MPEG2 and perform the conversion several times faster, but your resulting movie will be much larger at the same level of quality.

 

[Antiuniverse]

There's another simple and important factor to consider here: if your desktop becomes sluggish and unresponsive while encoding, and that doesn't happen to you when you're running other processor-intensive applications, it's probably because the encoder is running at too high a priority.

If a process is at a higher priority, it's essentially permitted to starve all processes at a lower priority from getting CPU cycles. Depending on how high, this could even be to the exclusion of things like updating your mouse cursor. Similarly, a process running at low priority should never be allowed to trump any applications at a higher priority, no matter how much work it wants to do.

Imagine how few people would run distributed computing applications if they made your computer unresponsive while they were crunching; that's why they default to an extremely low priority.

 

[Ryokurin]

You guys think if I enable the built-in GPU on the SB CPU, would that speed up any encode/decode task as far as movie rendering is concerned? Although my mobo is capable of using the GPU on the SB CPU, I currently have it Disabled and am using a GTX570. I tried the same video file on my Rampage III Gene with a Dual Core 1.86Ghz Xeon and it just seemed to have stopped working...so I put it on the SB rig and was able to finish it, but boy, did it take long!

It's basically is like using CUDA to encode files. That is it only works for preset things in most programs, and x264 can outperform it. It also can't be used to accelerate x264 because it specifically accelerates things that x264 does not use in encoding.

 

[Omophorus]

It takes so much of computing power to encode, let's say a movie or video file? What's different about it from ie: playing games (executing thousands of lines) or just plain computing? I'm trying to encode a video file and the computer just goes on a crawling mode, even on an i7 2600K OCed to 4.5Ghz! WTH!!!

Lots of goodness already in this thread, but the one thing I see missing is a concise answer to the original question.

Why does it take so much CPU power? Because the encoding algorithms needed to maximize quality while minimizing storage and bitrate are extremely complex.

H.264, for example, is capable of an order of magnitude reduction in streaming bandwidth and storage requirements over uncompressed video, with very low perceptible degradation of quality. It is computationally and time intensive to do that.

WMV, on the other hand, has a much simpler encoder that can run a lot faster and use less CPU power, but the result is much crappier compression.

 

[Abula]

Interesting subject.

Just wondering for transcoding Cuda is also much worst? i mean like to make your movies/videos able to play on mobile phones/tablets?

 

[Blahman]

Lots of goodness already in this thread, but the one thing I see missing is a concise answer to the original question.

Why does it take so much CPU power? Because the encoding algorithms needed to maximize quality while minimizing storage and bitrate are extremely complex.

H.264, for example, is capable of an order of magnitude reduction in streaming bandwidth and storage requirements over uncompressed video, with very low perceptible degradation of quality. It is computationally and time intensive to do that.

WMV, on the other hand, has a much simpler encoder that can run a lot faster and use less CPU power, but the result is much crappier compression.

I think my answer covered that

 

[Mr34727]

Since we're on the subject of video encoding, does anyone have any recommendations on which program to use within Ubuntu?

Handbrake, and though you will need to do a bit more digging if you are wanting to encode DVDs


To the OP- you could use badaboom or ATI Avivo instead...but personally cpu encoding has always worked better for me (handbrake). I am not sure what you consider crawling, but my x6 will do a DVD in 22mins, which I consider to be very fast. Your 2600k should be = or faster, so I am not sure if your system has a problem or you are thinking it should take less time than that

 

[Blahman]

DVD is only 720x480 (0.34 megapixels) which most CPUs will tear through. If you want a challenge, try 1080p = 1920x1080 (2.07 megapixels).

 

[Omophorus]

I think my answer covered that

I said concise.

Your answer covered it, but you were in the weeds.

 

[ramicio]

If your source is from DVD, Blu-ray, or somehow HD-DVD, DgDecNV is a very good way to offload decoding to your GPU, provided you have an nVidia card with CUDA. To me, Windows is king of video encoding just because of the support out there.

A 64-bit chain also makes things a lot faster than x86 stuff. You'd need:

1. DGDecNV (comes with both x86 and x64 binaries and plugins)
2. AviSynth x64
3. x264 64-bit