Author Topic: EEVblog #698 - GPU Video Rendering  (Read 104433 times)

0 Members and 1 Guest are viewing this topic.

Online EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37728
  • Country: au
    • EEVblog
EEVblog #698 - GPU Video Rendering
« on: January 01, 2015, 11:52:43 pm »
Dave tests a really high end NVIDIA GTX-970 video card for accelerated CUDA GPU video rendering with Sony Movie Studio (Vegas) & also Adobe Premiere.
Will it work for the new high frame rate video ?
Will it work at all?
How about a Radeon HD7850 and OpenCL?
Does the CODEC matter ?
Does hard drive or SSD performance matter ?
This also provides some insight into how Dave edits and renders his videos.

NOTE: This is mostly trying out and real time commentary of testing video rendering speed. If you find this stuff boring then DON'T WATCH IT.
There is no electronics content here, but plenty of main channel viewers might find it interesting.

 

Offline nixfu

  • Supporter
  • ****
  • Posts: 346
  • Country: us
Re: EEVblog #698 - GPU Video Rendering
« Reply #1 on: January 02, 2015, 12:37:08 am »
I imagine it is a pretty small community of people who are doing 50/60fps right now.   On youtube for instance, I have run into more content producers if they want to 'up the quality' they are instead using 4k @still standard 30fps, than I ever have of anyone doing 50/60fps.


So, you are running into the fact that you are doing something out of the mainstream and probably not even well tested among the companies who produce the drivers/hardware/and editing software toolsets.
 

Offline Methodical

  • Newbie
  • Posts: 5
Re: EEVblog #698 - GPU Video Rendering
« Reply #2 on: January 02, 2015, 12:49:35 am »
I'm sorry the results were disappointing, but I didn't expect anything else.  GPU-accelerated functions require tight integration between the OS and it's APIs, the hardware, and the application.  This is difficult to do.  Somewhat ironically, even though you couldn't get big benefits, Apple re-wrote a lot of it's software to use intel's quick sync video accelerators built into its latest processors.  Ironic that a 10 year old with iMovie and a "slower" computer can do HD iMovie exports faster than your professional software.  It's also used for FaceTime and in-home video streaming (airplay).

If you really want hardware accelerated encoding, your best bet is trying to get Intel Quick Sync working.  It's very fast, but only some applications can use it.  The problem with hardware cores is that the encoders are, well, written in hardware, and limited by that hardware.  Quick Sync doesn't have the same quality as x264, which is by far the best AVC encoder out there, IMHO.  Unfortunately, it's written for x86 with lots of assembler built in, so while some hardware acceleration is being beta'ed, it's not ready for primetime and indeed the benefits aren't that large due to the crazy level of optimization that the x264 team has done.  Handbrake uses x264 as it's encoder, so you're good to go there.

GPU acceleration, at this point, seems mostly focused on real-time recording (for gamers) and large-scale encoding (for broadcasters such as twitch.tv that need to re-encode lots of streams at once, in real time).

I use an AMD graphics card for my gaming PC and they've rolled out some software to do real-time recording.  It really works shockingly well.  I've been able to do 1080p60 h.264 15-20mbit/sec real-time recordings of my games and noticed maybe a 10-20% performance hit to the actual game.

The technology is there.  You just can't access it.  |O
 

Online EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37728
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #3 on: January 02, 2015, 12:53:03 am »
I imagine it is a pretty small community of people who are doing 50/60fps right now.   On youtube for instance, I have run into more content producers if they want to 'up the quality' they are instead using 4k @still standard 30fps, than I ever have of anyone doing 50/60fps.

Yeah, I don't know you'd go 4K/30fps instead of 1080P/60fps
The reaction to my 50/60fps video has been great, and the majority opinion seems to be they's prefer the higher frame rate to the 4K.

Quote
So, you are running into the fact that you are doing something out of the mainstream and probably not even well tested among the companies who produce the drivers/hardware/and editing software toolsets.

Seems like that!
 

Offline selkathguy

  • Supporter
  • ****
  • Posts: 88
  • Country: us
Re: EEVblog #698 - GPU Video Rendering
« Reply #4 on: January 02, 2015, 12:56:26 am »
Dave, from what I understand there is some sort of firmware/driver limitation of the GeForce series.  I have the exact same card and while it does great for games, word on the street is that the interface for using CUDA from the CPU is gimped.  It's only unlocked in their Tesla/Quadro cards...  I can't verify that personally, but with over a decade of GPU experience that certainly seems consistent with what I've seen.

It seems wasteful to be offering the same extremely powerful silicon (GeForce) at such a lower cost than their workstation cores, but perhaps they save money in the R&D...  :-//
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 9925
  • Country: nz
Re: EEVblog #698 - GPU Video Rendering
« Reply #5 on: January 02, 2015, 01:11:51 am »
I'd only start to suspect drive speed limitations if that 1min test file was like 1.8GB or bigger for a HDD or maybe 5GB for a SSD. (Assuming the same drive for read and write)

That works out to around 60MB/s for the HDD and 160MB/s for the SSD.


For sure HDD speed really does cripple people working in uncompressed video :)
1920x1080 * 4bytes per pixel * 60FPS = 497MB/s  ???
« Last Edit: January 02, 2015, 01:18:04 am by Psi »
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline Psi

  • Super Contributor
  • ***
  • Posts: 9925
  • Country: nz
Re: EEVblog #698 - GPU Video Rendering
« Reply #6 on: January 02, 2015, 01:13:43 am »
Dave, from what I understand there is some sort of firmware/driver limitation of the GeForce series.  I have the exact same card and while it does great for games, word on the street is that the interface for using CUDA from the CPU is gimped.  It's only unlocked in their Tesla/Quadro cards... 

There's a thread on here someone about hacking Geforce cards to Tesla/Quadro cards :)
Greek letter 'Psi' (not Pounds per Square Inch)
 

Offline mariush

  • Super Contributor
  • ***
  • Posts: 5013
  • Country: ro
  • .
Re: EEVblog #698 - GPU Video Rendering
« Reply #7 on: January 02, 2015, 01:57:16 am »
It takes a lot of time to "upload" the raw video frames to video card, then analyze them and retrieve the results from the video card... that's why most times cpu is faster, the data is already in ram or in its caches.
Lots of editing software also only use cuda or video card acceleration solutions to decode input video files before they're processed (resized, have stuff overlayed on them etc) so the benefits can be minimal.

My suggestion would be to use a lossless video codec to do the initial rendering, for example MagicYUV ( http://magicyuv.com/ ) or UTVideo. On my eight core fx-8320 the magicyuv codec saves 1080p content at about 140fps so you'd probably be able to export the video at 2-3x realtime speed (if your hdd can also handle the speed).  In the Sony software, you have to select avi or video for windows (or something like that) then select the codec from the list of codecs.

The downside is that for 1080p 50-60fps the result video file will take anything between 2-5GB per minute, it depends on scene complexity.... so a one hour video would give you 150-300 GB file. And the file would be an AVI file. 
But you can easily load the avi file in Handbrake or any other software and do the second encoding and then remove this large file from your system.

Oh... and if you plan to do fast renderings, you should also disable the video preview before rendering... that window with video in the right corner slows renderings.

ps.  it's SOLID state drive ... you said solar state drive several times in the video.
« Last Edit: January 02, 2015, 02:07:49 am by mariush »
 

Offline edy

  • Super Contributor
  • ***
  • Posts: 2385
  • Country: ca
    • DevHackMod Channel
Re: EEVblog #698 - GPU Video Rendering
« Reply #8 on: January 02, 2015, 02:03:24 am »
Nice setup Dave. I'm using some very old equipment myself but squeezing what I can out of it for my YouTube channel (DevHackMod). I shoot either with my old Sony Cam which writes 640x480 video to MPG, or record with a cell phone to MP4. I prefer using the Sony with  MPG because I edit using Womble MPG DVD editor, which allows MPG editing by copying directly the video and audio stream, to avoid recoding during rendering. It only recodes when there is a transition fade or other effects, or audio mixing (but even then only the audio stream). As long as I keep my output format to same as input, Womble will simply copy streams when they are unchanged... So the final render is quick as most of the work is simply stream copying with a few recoded renders for transitions along the way. As I usually do simple cuts and a title slide, the main job is a few seconds of title video being rendered and the rest  pure stream copying with no recoding!

Of course, I also run my videos through Handbrake to convert the MPEG to MP4 while shrinking down the size (using web optimizing option) which makes it easier to upload to YouTube.
YouTube: www.devhackmod.com LBRY: https://lbry.tv/@winegaming:b Bandcamp Music Link
"Ye cannae change the laws of physics, captain" - Scotty
 

Offline lightman

  • Newbie
  • Posts: 8
Re: EEVblog #698 - GPU Video Rendering
« Reply #9 on: January 02, 2015, 02:30:45 am »
Hello Dave

I thought you will show how the mainconcept encoder performs vs the other ones with the 970, since that one DID detected the cuda device, at least in my tests mainconcept usually works well with GPUs (however I have only tested it with openCL but i will love to do it with a maxwell card) :) can you run some tests with it if you have the time?

how about buying a dual or quad cpu, server class, machine, like supermicro?, i know, expensive, but hey you will reeeeaallly use it!.
 

Offline gnif

  • Administrator
  • *****
  • Posts: 1675
  • Country: au
Re: EEVblog #698 - GPU Video Rendering
« Reply #10 on: January 02, 2015, 02:47:55 am »
It's only unlocked in their Tesla/Quadro cards...  I can't verify that personally, but with over a decade of GPU experience that certainly seems consistent with what I've seen.

Confirmed, the card does not do any encoding offloading if you do not have a quadro/tesla, these features are disabled.
 

Offline OilsFan

  • Regular Contributor
  • *
  • Posts: 52
  • Country: us
Re: EEVblog #698 - GPU Video Rendering
« Reply #11 on: January 02, 2015, 02:57:20 am »
Dave I'm actually more interested in what you are doing with Handbrake to save on upload times. Maybe you can give a quick overview?
 

Offline NiHaoMike

  • Super Contributor
  • ***
  • Posts: 9007
  • Country: us
  • "Don't turn it on - Take it apart!"
    • Facebook Page
Re: EEVblog #698 - GPU Video Rendering
« Reply #12 on: January 02, 2015, 03:25:36 am »
How does Quick Sync fare?
Cryptocurrency has taught me to love math and at the same time be baffled by it.

Cryptocurrency lesson 0: Altcoins and Bitcoin are not the same thing.
 

Offline Razor512

  • Regular Contributor
  • *
  • Posts: 156
  • Country: 00
Re: EEVblog #698 - GPU Video Rendering
« Reply #13 on: January 02, 2015, 04:38:17 am »
For the radeon cards, the openCL video rendering is not used efficiently. You can see this if you run GPUz http://www.techpowerup.com/gpuz/ you will likely see around 20% GPU usage on that card. CUDA is often better optimized as it has had more time to be improved over the years (one of the first uses of cuda), though it is still often poorly implemented, thus if a card is 3-4 time faster at gaming

Other than that, you will have to see if someone will come up with a mod for the application that will unlock the GPU support like with adobe aftereffects and premiere. e.g.,  http://www.studio1productions.com/Articles/PremiereCS5.htm  (this also works on CS6 and CC

Anyway, for the time being overclock the CPU (try to hit around 4.2 - 4.5GHz), and wait for a mod to come out for the video editor to unlock CUDA for the GTX 970. In the meantime, just use the card for gaming.

The card may have some with a few game codes. (try some far cry 4, and if needed, also play some warframe, and if you need something that is less twitch based, and thus better suited for remote streaming, you can try path of exile (interesting game, and is rated for all ages).

PS, I am 100% fine with the show going back to 25/30FPS, as firefox is my main browser and i doesn't support 60FPS on youtube anyway.
« Last Edit: January 02, 2015, 04:39:50 am by Razor512 »
 

Offline justanothercanuck

  • Frequent Contributor
  • **
  • Posts: 391
  • Country: ca
  • Doing retro repairs...
Re: EEVblog #698 - GPU Video Rendering
« Reply #14 on: January 02, 2015, 04:40:07 am »
I am still struggling with grasping the benefit of 60fps for a mailbag video. Please, someone from this majority tell me what I should be looking for. Because I see NO difference.

Are you actually getting 60fps?  I still can't get any higher than 30fps on my machines.  Maybe firefox still can't support all the HTML5 stuff yet.  :-//

Confirmed, the card does not do any encoding offloading if you do not have a quadro/tesla, these features are disabled.

That's sucky.  I knew they did it for 3d modelling apps (3dsmax, etc), but I figured they'd let people use it for video encoding.  I feel bad for anybody who bought 980's for bitcoin mining to find out that it doesn't work.
Maintain your old electronics!  If you don't preserve it, it could be lost forever!
 

Offline FrankBuss

  • Supporter
  • ****
  • Posts: 2365
  • Country: de
    • Frank Buss
Re: EEVblog #698 - GPU Video Rendering
« Reply #15 on: January 02, 2015, 04:53:35 am »
Would be interesting to see the details how they implemented the CUDA rendering. Some time ago I wrote programs with CUDA suppport (see this page, sorry in German) and depending on the graphics card it improved the speed about a factor from 20 to 100 compared to CPU calculation. But the problem was very easy to parallelize. Maybe it is not that easy to parallelize video rendering?

Did you ask Sony, Adobe or NVIDIA about the problem? CUDA should work always, the developer side the interface is simple and doesn't have many parameters which could prevent that the code works, if you code carefully.

But I think it doesn't matter anyway, because you can start the rendering in the evening and it will be done the next morning, unless you want to produce 8 hours video each day :)
So Long, and Thanks for All the Fish
Electronics, hiking, retro-computing, electronic music etc.: https://www.youtube.com/c/FrankBussProgrammer
 

Offline Razor512

  • Regular Contributor
  • *
  • Posts: 156
  • Country: 00
Re: EEVblog #698 - GPU Video Rendering
« Reply #16 on: January 02, 2015, 04:58:15 am »
GPU mining died long ago. it was also a good time to get cheap radeon r290x cards. overall the mining rate stays constant, and thus as more people upgrade to ASIC's, you end up with the mining difficulty increasing exponentially. A GPU can no longer hope to even generate enough income the cover its power use.


For 60FPS, you need to use google chrome.

I personally can't use chrome as it doesn't have the addons that I need. (I need classic compact (gives as much screen space as possible without burying anything behind a menu or slider), mouse control, the weather in the title bar.

The quadro limitations are purely software imposed. the difference between a gaming card and the quadro, is that the quadro does not have the vast majority the components for double precision calculations disabled, this is why the GPU unlock mods for some of those applications are so popular. They allow you to use features that would otherwise be restricted  to quadro for no reason, especially when they lock a feature that does not need double precision calculations.

The GTX titan is a fully unlocked GPU, thus no difference between it and the quadro, it can even be modded to be a quadro card fairly easily.
this is why you see the massive boost in double precision calculations (not used very often, and not be many 3D modeling applications or video editors)
http://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units#GeForce_700_Series
« Last Edit: January 02, 2015, 05:03:44 am by Razor512 »
 

Edgar Amalyan

  • Guest
Re: EEVblog #698 - GPU Video Rendering
« Reply #17 on: January 02, 2015, 06:18:17 am »
4k at 30fps would no doubt provide better quality for your videos compared to higher frame rate at 1080p. Most of the time you are just zoomed in and the camera/object isn't moving, it's just wasting bandwidth. Also for mobile users, you can get a YouTube app that supports resolutions higher than 1080p, but not higher frame rates.
 

Offline mpl

  • Newbie
  • Posts: 1
Re: EEVblog #698 - GPU Video Rendering
« Reply #18 on: January 02, 2015, 06:45:26 am »
Video encoding is multicore CPU operation.
Here you have some benchmarks with modern CPUs

http://www.anandtech.com/bench/CPU/1052
http://www.anandtech.com/bench/CPU/28

If you want to still use GTX970 you should wait for update from Sony.

Keep in mind that nvidia removed nvcuvenc.dll in drivers newer then 340.43, fix for that: http://www.bandicam.com/support/tips/nvidia-cuda/
 

Offline nitro2k01

  • Frequent Contributor
  • **
  • Posts: 843
  • Country: 00
Re: EEVblog #698 - GPU Video Rendering
« Reply #19 on: January 02, 2015, 06:45:44 am »
A question that goes unanswered is, how long does the second rendering pass in HandBrake take? How does exporting AVC directly from Movie Studio take compared to the total time of the two step process?
Whoa! How the hell did Dave know that Bob is my uncle? Amazing!
 

Offline ThaHandy

  • Newbie
  • Posts: 7
Re: EEVblog #698 - GPU Video Rendering
« Reply #20 on: January 02, 2015, 06:49:40 am »
As far i can tell there is none to tiny benefits encoding by a GPU.  Its what a CPU can do and a GPU can't, if it comes to encoding. It all depends on the profile your using.

You want more faster encoding, get more cores! (dual Xeon hexa/octa CPU's  8) )

I assume you use XDCAM (lossless codec) to create your video and handbrake to encode in 264.

Few things you can try.

Install x264vfw codec so you might (not sure Movie studio can use vfw codec's) encode straight to 264 from Movie studio.

and if you didn't know HandBrake v0.10 is now supporting H265 codec and Intel QuickSync Video encoding.

Btw, HandBrake can encode in 10fps to 200fps depending on the used profile. The "slower" the profile the better the the quality

« Last Edit: January 02, 2015, 06:53:56 am by ThaHandy »
 

Offline wilhelm

  • Contributor
  • Posts: 14
  • Country: se
Re: EEVblog #698 - GPU Video Rendering
« Reply #21 on: January 02, 2015, 07:58:01 am »
In premiere pro you need to "hack" cuda_supported_cards.txt by adding your card to it. After that Mercury Playback Engine GPU Acceleration is avalible under Project Settings.
 

Offline firewalker

  • Super Contributor
  • ***
  • Posts: 2450
  • Country: gr
Re: EEVblog #698 - GPU Video Rendering
« Reply #22 on: January 02, 2015, 08:22:24 am »
Is there any software that can encode using multiple PCs?

Alexander.
Become a realist, stay a dreamer.

 

Online EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37728
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #23 on: January 02, 2015, 08:51:42 am »
I assume you use XDCAM (lossless codec) to create your video and handbrake to encode in 264.

As explained in the video, I used to use XDCAM, but Sony does not allow 50 or 60fps using that.

 

Online EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37728
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #24 on: January 02, 2015, 08:52:54 am »
Keep in mind that nvidia removed nvcuvenc.dll in drivers newer then 340.43, fix for that: http://www.bandicam.com/support/tips/nvidia-cuda/

Thanks, I might try that before I get rid of the card.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf