Can someone explain something to me?

[OnionRings]

What the fuck is the point of an elgato capture card if it does NOT take the load off your CPU and encode the video for you? You still need a frickin PC with a powerful processor. I get you need it to record console but what about PC, why do people use it to record PC footage?

[minibois]

because some people record to another PC?

[Aaronius_Leonius]

If they are streaming to twitch, they want the stream to be as lag free as possible so they move the extra load to another computer to give the game all the horsepower that the computer has. They can also stream a PS4 or Xbox one easily.

[dalekphalm]

The other thing is that CPU encoding still produces the best possible quality. But yeah generally these kinds of products are marketed towards the kinds of users who will use a dedicated capture PC, as @AA-RonRosen discussed.

[OnionRings]

Right ok so its best for when you want to record with NO negative effects, you then use a separate PC with the card, or for console footage. 

[dalekphalm]

7 hours ago, OnionRings said:

Right ok so its best for when you want to record with NO negative effects, you then use a separate PC with the card, or for console footage. 

Correct. If you want "easy onboard recording", something like ShadowPlay is probabloy better suited. Especially if you don't want to dedicate another PC to recording the footage.

[Misanthrope]

10 hours ago, dalekphalm said:

The other thing is that CPU encoding still produces the best possible quality.

Honest question time: Why is that though? I don't see why CPU is inherently better quality than GPU. My guess is that GPU acceleration is an afterthought/very early implementation in most software.

 

Other than that is the quality improving if you say, throw double precision at it? Like a Quadro instead of a gaming GPU for example fares any better in quality?

[dalekphalm]

1 minute ago, Misanthrope said:

Honest question time: Why is that though? I don't see why CPU is inherently better quality than GPU. My guess is that GPU acceleration is an afterthought/very early implementation in most software.

 

Other than that is the quality improving if you say, throw double precision at it? Like a Quadro instead of a gaming GPU for example fares any better in quality?

Honest Answer Time: I've no fucking clue

 

All I know is that GPU accelerated encoding has historically added more artifacts and quality reductions compared to a similar "quality level" CPU encode. I always figured it had something to do with the basic architecture of a GPU (simple parallelization vs complex instructions structure of a CPU)

 

@AshleyAshes you seem to know an unhealthy amount about video encoding - do you happen to know the answer to this question?

[AshleyAshes]

41 minutes ago, Misanthrope said:

Honest question time: Why is that though? I don't see why CPU is inherently better quality than GPU. My guess is that GPU acceleration is an afterthought/very early implementation in most software.

 

Other than that is the quality improving if you say, throw double precision at it? Like a Quadro instead of a gaming GPU for example fares any better in quality?

Because the GPUs encode unit is using a fixed ASIC within the GPU to do the job.  It is built to encode, it's just about all it does, it does it only in a specific way and you don't see changes in how efficiently it does that later.  An encoder that uses a CPU on the other hand, well, that's pure software, it can see constant refinements and tweaks in the software and the CPU just executes the code. The CPU is far, far, far less efficient speed wise since it's a general purpose device but, depending of course on how well developed the software encoder is, it can be more efficent in terms of it's bitrate vs perceived quality.

 

All of this does not account for OpenCL/CUDA type acceleration, we are talking about the dedicated ASICs built into the chip, not compuete tasks.  Since these ASICs are running as a dedicated part of the GPU that serves no other purpose, there's no real hit to performance elsewhere in the GPU.  There are also *some* encoders out there that use compute like OpenCL or CUDA but they aren't that popular and obviously those would hit the resources on the GPU since they are using the GPUs main resources rather than a dedicated ASIC that's part of it.

[dalekphalm]

4 minutes ago, AshleyAshes said:

Because the GPUs encode unit is using a fixed ASIC within the GPU to do the job.  It is built to encode, it's just about all it does, it does it only in a specific way and you don't see changes in how efficiently it does that later.  An encoder that uses a CPU on the other hand, well, that's pure software, it can see constant refinements and tweaks in the software and the CPU just executes the code. The CPU is far, far, far less efficient speed wise since it's a general purpose device but, depending of course on how well developed the software encoder is, it can be more efficent in terms of it's bitrate vs perceived quality.

 

All of this does not account for OpenCL/CUDA type acceleration, we are talking about the dedicated ASICs built into the chip, not compuete tasks.  Since these ASICs are running as a dedicated part of the GPU that serves no other purpose, there's no real hit to performance elsewhere in the GPU.  There are also *some* encoders out there that use compute like OpenCL or CUDA but they aren't that popular and obviously those would hit the resources on the GPU since they are using the GPUs main resources rather than a dedicated ASIC that's part of it.

So, in theory, you could build, say, an H.264 encoder that uses CUDA to execute the task? And this could in theory produce similar quality results of a CPU (At varying speed, depending on what GPU, compared to what CPU, etc)?

[AshleyAshes]

3 minutes ago, dalekphalm said:

So, in theory, you could build, say, an H.264 encoder that uses CUDA to execute the task? And this could in theory produce similar quality results of a CPU (At varying speed, depending on what GPU, compared to what CPU, etc)?

If you built a decoder that made us of OpenCL or CUDA, your results would only be limited by the actual limitations of the standard you are encoding to and the quality of your code.  Keeping in mind however that 'quality' has a 'time/processing' trade off.  If you want to more efficiently process your data, you'll need to put more math into it, and that'll take more resources.  This is true in any compression.  Even like ZIP or RAR programs can have different ways to approach compressing data, usually the ones that yield the most compression using the most CPU time.  Though since things are compressed to a standard, any decoder can decode that data afterwards and the results are identical.  So we're only talking about ENcoding here.  For DEcoding, every decoder should spit out the same result.  No decoder will get you 'better quality' than the other decoder.  (Not including post-processing)

 

Going to the OPs post, you can invest in more expensive capture hardware.  The cheap ones basically just take an HDMI input and spit out RGB data that a PC can convert into video using whatever software is reading that input.  There are other ones that have their own ASICs built in and instead of feeding RGB data to the PC, they'll encode the video itself and the computer is just ingesting the compressed data stream and saving it to storage.  Much more professional options will forgo an ASIC and instead use an FPGA, which then through firmware updates could have it's structure updated to make improvements since an FPGA is plastic where an ASIC is fixed.  So an FPGA board would have the same hardware decoding as an ASIC, but since the chip can be reprogrammed, it can be improved.  ...Depending of course on the quality of vendor support.

[LAwLz]

9 hours ago, AshleyAshes said:

All of this does not account for OpenCL/CUDA type acceleration, we are talking about the dedicated ASICs built into the chip, not compuete tasks.  Since these ASICs are running as a dedicated part of the GPU that serves no other purpose, there's no real hit to performance elsewhere in the GPU.  There are also *some* encoders out there that use compute like OpenCL or CUDA but they aren't that popular and obviously those would hit the resources on the GPU since they are using the GPUs main resources rather than a dedicated ASIC that's part of it.

Also, those OpenCL/CUDA encoders looks like dog-shit and should never be used.

 

 

9 hours ago, dalekphalm said:

So, in theory, you could build, say, an H.264 encoder that uses CUDA to execute the task? And this could in theory produce similar quality results of a CPU (At varying speed, depending on what GPU, compared to what CPU, etc)?

It would not. It has been tried, but GPUs are just bad at doing this type of workload. To get reasonable speeds on a GPU, they need to take lots of shortcuts.

 

I asked Henrik Gramner (one of the lead developers of x264) about this, and he dumbed it down quite a bit for me. Here is a snippet from our conversation:

Quote

Feb 08 18:11:28 <LAwLz>    I got another question that I have been wondering about as well. How come GPUs are so much worse than CPUs when it comes to H.264 encoding?
Feb 08 18:11:57 <Gramner>    because GPU:s are terrible at anything involving branches
Feb 08 18:12:06 <Gramner>    and video encoding is generally a branchy process
Feb 08 18:12:59 <Gramner>    most graphic cards and such with video encoders are using dedicated chips for the encoding, it's not using the GPU
Feb 08 18:13:15 <LAwLz>    Well yeah I know that, but wouldn't that just slow them down and not affect the quality? Or do they use shortcuts to make up for it, which affects the quality?
Feb 08 18:13:55 <LAwLz>    I am talking strictly about CUDA accelerated encoders right now (and whatever the AMD equivalence is called, ATI Streampath or something)
Feb 08 18:15:22 <Gramner>    intel's quicksync is a pretty decent hardware encoder. most encoders (as with most things in life really) are terrible because they were hastily thrown together and shipped after deemed "good enough"
Feb 08 18:17:56 <Gramner>    CUDA encoders and stuff like that usually only runs part of the process on the GPU and the rest on the CPU, and you need to simplify some algorithms in order to make them paralell enough to scale on a GPU. x264 even has some optional opencl code actually but it's not very useful, it's more of a proof of concept really
Feb 08 18:21:49 <LAwLz>    I see. So they simply don't use the same algorithms because they are not suitable to run on GPUs (at least not the ones we got today).
Feb 08 18:24:08 <Gramner>    to simplify things a bit, to run an algorithm efficiently on a GPU you need to be able to parallelize it to thousands of threads
Feb 08 18:24:56 <Gramner>    and unlike what GPU manufacturers want you to lead you to believe, most algorithms do not scale that well
Feb 08 18:26:17 <Gramner>    there's a reason why most computers have few but fast cpu cores instead of a large amount of individually slower ones - even though the latter is easier and cheaper to engineer
Feb 08 18:28:45 <LAwLz>    Okay. Well that was everything I was wondering about. Thank you for your answers. It made things very clear to me.

So if I understand it correctly.

• For this kind of task, GPUs are basically just CPUs with lots and lots of individually weak cores.
• The algorithms to produce high quality H.264 can not scale to all that many threads (lots of threads compared to how many CPU cores we got, but not compared to how many GPU cores).
• To make up for having lots of weak cores, GPU encoders use algorithms which produces lower quality video, but can be used on more cores
  Less accurate algorithm => can feed more cores => better scaling, but less efficient use of every bit.

[OnionRings]

Idk why CPU is better either, it just is, when I use my GPU to record I get checker boarding