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

0 Members and 1 Guest are viewing this topic.

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #25 on: January 02, 2015, 08:54:36 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

Yes, it's all CPU.
How much would one of the latest high end Xeon machines cost me?
 

Offline SeanB

  • Super Contributor
  • ***
  • Posts: 16272
  • Country: za
Re: EEVblog #698 - GPU Video Rendering
« Reply #26 on: January 02, 2015, 09:52:43 am »
Is there any software that can encode using multiple PCs?

Alexander.

Yes, it is from Silicon Graphics, used by Pixar a lot to do movies. Do you have a small Beowulf cluster to use it on, or a small supercomputer cluster with spare time.
 

Offline george graves

  • Super Contributor
  • ***
  • Posts: 1257
  • Country: us
Re: EEVblog #698 - GPU Video Rendering
« Reply #27 on: January 02, 2015, 09:56:15 am »
As I mentioned on youtube....

http://www.videoguys.com/Guide/E/Videoguys+DIY+10+++Our+wait+for+Thunderbolt+is+over/0x86959ff2ee4098c3eef68b2070f368dd.aspx

They know what they are doing - off the top of my head, I know one of there clients is a Academy Award winner for Editing, and guys on the AVID forum follow their lead on system set up.  Avid (you most likely have never heard of it), is the Altium of editing software.  That's what I've edited on since 1997(myself and a few other wrote the guide on how to set up a real editing system - now totally out of date - but I digress).  I think it would be wise to switch to a real editing program.  Premiere is so affordable now,  it's kinda hard not to go that way.   Plus, do you have the right drivers?  Why no SSD? That's just penny wise and pound foolish.  It's literally $2-3k for a kick ass editing rig. Stop being a cheap ass, and then complaining why things don't work!  Isn't that what you would say about someone buying a cheap scope?
« Last Edit: January 02, 2015, 10:00:08 am by george graves »
 

Offline nitro2k01

  • Frequent Contributor
  • **
  • Posts: 843
  • Country: 00
Re: EEVblog #698 - GPU Video Rendering
« Reply #28 on: January 02, 2015, 10:49:56 am »
Why no SSD?
How would an SSD help Dave in this case? An SSD is good for random access, and for high throughput. Dave would be editing one stream at a time, as opposed to a typical video director who might have a lot of different layers with special effect or whatever it might be. The encoding is a sequential access operation, and the CPU/GPU would likely be the bottleneck even if the encoding was 5 or even 10 times faster. An SSD is nice overall, but would hardly be a make or break for the work Dave is doing.
Whoa! How the hell did Dave know that Bob is my uncle? Amazing!
 

Online sleemanj

  • Super Contributor
  • ***
  • Posts: 3020
  • Country: nz
  • Professional tightwad.
    • The electronics hobby components I sell.
Re: EEVblog #698 - GPU Video Rendering
« Reply #29 on: January 02, 2015, 10:53:59 am »
You're spending quite a lot of time, energy, and money trying to get 60 fps rendering in a reasonable rate. 

One might ask, does any increased viewer numbers (and thus income) that you can attribute to 60fps really justify this?
~~~
EEVBlog Members - get yourself 10% discount off all my electronic components for sale just use the Buy Direct links and use Coupon Code "eevblog" during checkout.  Shipping from New Zealand, international orders welcome :-)
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: EEVblog #698 - GPU Video Rendering
« Reply #30 on: January 02, 2015, 10:57:33 am »
In a lot of ways, this is the same situation I found five years ago when I last did any significant transcoding, when I spent many days converting a large HD-DVD and BluRay collection to 1080p streamable content. Spent a very long time fannying around with lots of different software options including offloading to a seriously high end GPU, and was dissapointed with the results in terms of performance.

Regarding hard drives, and back then SSD wasn't financially viable, spindle management did have a marked effect, particularly if no transcoding was required (ie, merging audio and video tracks in their native formats).

Sad that it still appears to be an immature technology, in that it doesn't "just work".
 

Offline rollatorwieltje

  • Supporter
  • ****
  • Posts: 571
  • Country: nl
  • I brick your boards.
Re: EEVblog #698 - GPU Video Rendering
« Reply #31 on: January 02, 2015, 11:10:26 am »
I did some testing on my system as well, for me using the MainConcept AVC codec in 1080p50 using the GPU is several times faster.
Core i5 2500k, 8GB ram, HD6970, rendering to SSD, source video is on a raid0 array.
Over 8 minutes for CPU, and about 1:30 for the GPU. Source video is a 50FPS mJPEG screen capture of about 1 minute 7 seconds.

edit:
Not sure why, but I can't open the generated .avc file with anything. VLC shows nothing and Handbrake doesn't seem to like it either.

edit2:
Funny, Youtube can actually read it properly.
« Last Edit: January 02, 2015, 12:17:26 pm by rollatorwieltje »
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #32 on: January 02, 2015, 11:29:48 am »
One might ask, does any increased viewer numbers (and thus income) that you can attribute to 60fps really justify this?

They same could have been said when I switched cameras, or switched to HD, or *insert any other change* I've made over the years.
Many people do like it, so it's not wasted effort.
You can't in any way accurately attribute increased quality of content to increased viewership, it ain't that easy.
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #33 on: January 02, 2015, 11:33:44 am »
Why no SSD?
How would an SSD help Dave in this case?

It doesn't. George is our resident pedant when it comes to this stuff, he keeps harping on and harping without taking circumstances into account.
I do have a SSD for my main drive. I do not have it for my secondary drive, and as you and I have explained, it doesn't make a difference in my case.
 

Offline SeanB

  • Super Contributor
  • ***
  • Posts: 16272
  • Country: za
Re: EEVblog #698 - GPU Video Rendering
« Reply #34 on: January 02, 2015, 11:39:42 am »
Max out the RAM rather than the SSD. RAM is going to have a larger influence on the speed than the tertiary storage used. Large RAM makes it possible to use cache to smooth the data into and out of the conversion, and then it will make little difference as to the speed of the storage media.
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #35 on: January 02, 2015, 11:45:22 am »
They know what they are doing

So I'm just supposed to blindly follow them?
My machine is almost equal to the highest end editing rig in your 3rd party recommendation!
The 4770K offers sub 10% improvement over my current 3770K.
The GPU card almost certainly won't work, and nothing else in there is going to matter.

The ONLY thing that really matters for my application is the CPU. Everything else is faffing around the edges.

Quote
Avid (you most likely have never heard of it)

I have, and I have tried it. It wasn't right for me in several ways, had several issues, and at the time was slower to render then Sony.

Quote
That's what I've edited on since 1997(myself and a few other wrote the guide on how to set up a real editing system - now totally out of date - but I digress).

The machine I have now was perfectly adequate and speced for the task at the time I bought it, which you of course got wrong last time we discussed this.
You bitched that I didn't have good enough machine, and gave me a spec for good one, only to embarrassingly find out my machine exceeded your recommended spec.

Quote
  I think it would be wise to switch to a real editing program.  Premiere is so affordable now,  it's kinda hard not to go that way.   

I have tried it and I don't like it for my purposes. And it is slower than Sony.
Switching to Premiere is not going to solve my problem, it will just create more where no change is needed.

Quote
Plus, do you have the right drivers?

Of course I do.

Quote
  Why no SSD? That's just penny wise and pound foolish.

a) I do have an SSD for my OS
b) It makes no real difference for my needs, I have measured this.

Quote
  It's literally $2-3k for a kick ass editing rig. Stop being a cheap ass, and then complaining why things don't work!  Isn't that what you would say about someone buying a cheap scope?

Why don't you stop harping on about this?
I'm trying to learn how GPU can make a difference, and it turns out I learned a lot for my effort.
This applies to my current rig and any future rig.
Only very recently have my needs changed, so I'm trying to figure out the best way to proceed.
« Last Edit: January 02, 2015, 11:59:34 am by EEVblog »
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #36 on: January 02, 2015, 11:46:07 am »
Max out the RAM rather than the SSD. RAM is going to have a larger influence on the speed than the tertiary storage used.

Not in my case. I hardly use any of my 16GB.
 

Offline s55

  • Newbie
  • Posts: 5
Re: EEVblog #698 - GPU Video Rendering
« Reply #37 on: January 02, 2015, 11:57:21 am »
You mentioned at the end of the video that QuickSync isn't that great.  It's actually not bad if you have a Haswell Core i7. Intel has made significant improvements going from Sandy Bridge to Ivy Bridge to Haswell.  It doesn't match up with what most consider the leader, x264 but it's certainly more than sufficient for many usage scenarios.  Whether it fits yours I can't say, but worth a look, even on Ivy Bridge CPU that you have.

We added QuickSync support to HandBrake last year and from the results we've seen, you can achieve a similar quality but at a 10~20% increase in file size. So, you'd save time encoding, but increase upload time.

The problem with video encoding is, the algorithms that are currently used on the CPU, don't scale on the GPU and infact are very often thousands of times slower.  They do all sorts of tricks to get around this, including just not running some of the algorithms that x264 will run. GPU's are massively parallel beasts, so you need to be able to do lots of different units of work at once, which is not easy with Video. Atleast, not at the scale you need to get good performance gains.

QuickSync is a bit different to CUDA. It's dedicated ASIC like hardware so gets around a lot of the limitations of the GPU hardware. 
Nvidia has been working on replacing CUDA with a much improved NVEnc.  Again, I believe NVEnc is ASIC based so in theory, you'd get the same performance on a low end GPU as a high end, assuming they don't cripple it deliberately in some way.

It is a bit of a minefield and as the developer of HandBrake myself, I can tell you it's a bit of a pain at the best of times.

Anyway, If you ever need any help with HandBrake (or anyone else in the community for that matter), feel free to drop me a line. (I'm one of the crazy people that actually develops it)

« Last Edit: January 02, 2015, 12:06:13 pm by s55 »
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #38 on: January 02, 2015, 12:01:32 pm »
Anyway, If you ever need any help with HandBrake (or anyone else in the community for that matter), feel free to drop me a line. (I'm one of the crazy people that actually develops it)

Thanks, appreciated.
Good to have someone on this topic who actually has a clue what they are talking about!  ;D
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #39 on: January 02, 2015, 12:13:46 pm »
12 core Xeon E5 2697 costs over $3K alone, yikes!
8 core Core i7 5960X is about $1400, that would give me maybe double the speed I have now and likely bring it back down to real-time rendering.
http://www.anandtech.com/bench/CPU/1052
 

Offline s55

  • Newbie
  • Posts: 5
Re: EEVblog #698 - GPU Video Rendering
« Reply #40 on: January 02, 2015, 12:27:54 pm »
Dave,

While HandBrake side of the conversion should get faster with more cores. (It typically scales well to 6~8 cores depending on settings), you'll also want to check if the Sony side scales as well. For example, if it's not maxing out the CPU when your converting to your intermediate format, it probably won't see much benefit from more cores.  In this case, you may be better with a higher clocked 6 core than a slower clocked 8 core.

If you want, throw me an encode log over from HandBrake and I can check over your settings. Your video's don't have an awful lot of motion in them, so you might be able to relax some of the settings to improve performance without any noticeable quality loss or increase in filesize. Depends really what settings your using at the moment.
 

Offline s55

  • Newbie
  • Posts: 5
Re: EEVblog #698 - GPU Video Rendering
« Reply #41 on: January 02, 2015, 12:30:07 pm »
@wilfred - Video encoding is very much personal preference. Different people have different eyes, different monitors, different playback software. Depending on your setup, your eyesight, you may or may not get any benefit from 60fps.  Personally, I'm not fussed either way, but it's nice to have the option.
 

Offline EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37661
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #42 on: January 02, 2015, 12:45:16 pm »
While HandBrake side of the conversion should get faster with more cores. (It typically scales well to 6~8 cores depending on settings), you'll also want to check if the Sony side scales as well. For example, if it's not maxing out the CPU when your converting to your intermediate format, it probably won't see much benefit from more cores.  In this case, you may be better with a higher clocked 6 core than a slower clocked 8 core.

Sony maxes out all 8 cores (4 physical, 4 virtual) when rendering, so very likely more cores = better.
I can check with other Sony users just to make sure though.

Quote
If you want, throw me an encode log over from HandBrake and I can check over your settings. Your video's don't have an awful lot of motion in them, so you might be able to relax some of the settings to improve performance without any noticeable quality loss or increase in filesize. Depends really what settings your using at the moment.

PM on it's way, thanks.
Oops, latest script not on my home machine, will send tomorrow.
« Last Edit: January 02, 2015, 12:48:39 pm by EEVblog »
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: EEVblog #698 - GPU Video Rendering
« Reply #43 on: January 02, 2015, 01:25:08 pm »
I've done similar test on my machine with i5-4570 and Radeon R7 200 with 1GB GDDR5.

One minute 720p video @ 25fps took about 40-45 seconds to render both in case of CPU-only operation and with GPU acceleration via OpenCL.

One thing I've noticed was that when GPU acceleration was enabled I was still getting serious usage of all the CPU cores and the GPU load was only around 25-30% according to my system monitor.

Perhaps the usage of GPU is not optimal, as only part of its processing power seems to be utilized.
I love the smell of FR4 in the morning!
 

Offline s55

  • Newbie
  • Posts: 5
Re: EEVblog #698 - GPU Video Rendering
« Reply #44 on: January 02, 2015, 01:35:42 pm »
@poorchava -> What software are you using?

It's not uncommon for OpenCL to augment video encoding but not fully replace it.  For example, x264 has OpenCL offload of Lookahead, but the rest of the encoder is CPU based.
 

Offline IanJ

  • Supporter
  • ****
  • Posts: 1580
  • Country: scotland
  • Full time EE biz & Youtuber
    • IanJohnston.com
Re: EEVblog #698 - GPU Video Rendering
« Reply #45 on: January 02, 2015, 01:53:17 pm »
Hi Dave et al,

I have a very similar setup to Dave.....thought I'd offer my findings:-

i7-4770@3.4GHz, 8gig ram, GeForceGT640, Win7_64bit.
Test rendering of a 1min15sec clip using Movie Studio 13 Platinum.

Most codecs etc worked out at 3min26sec to render (1080p50), the GPU rendering a few secs more!.......but then I tried XDCAM EX .mp4 file = 1min1sec
The caveat is that you can only get 720p50 at the fast rendering rate.
The rendered file size is just slightly bigger than the original footage.

Note: You will need to purchase the codec pack before you can play the rendered file locally, but YouTube does support it without of course.

Ian.
Ian Johnston - Manufacturer of the PDVS2mini & author of the free WinGPIB app.
Website & Online Shop: www.ianjohnston.com
YT Channel (electronics repairs & projects): www.youtube.com/user/IanScottJohnston, Twitter (X): https://twitter.com/IanSJohnston
 

Offline dentaku

  • Frequent Contributor
  • **
  • Posts: 881
  • Country: ca
Re: EEVblog #698 - GPU Video Rendering
« Reply #46 on: January 02, 2015, 02:04:06 pm »
Since 50/60 fps doesn't work for everyone is it even worth bothering with? If you were walking around at a tradeshow then it would be useful but it's not for static shots inside your office.
If I play a video fullscreen, Youtube will figure out that I have the bandwidth to play in 1080p and automatically switches but then the audio and video go out of sync so I have to manually switch to 720, rewind a few seconds and then everything syncs up again. This is in IE 11.
30fps 1080p videos have always played fine on this setup.
Your latest mailbag seems to work in 50 fps 1080p on my mother's inexpensive laptop in Firefox though.

It's a good learning experience I guess (in video encoding and GPU computing) and at least I know how to change my settings to get it working so i's not a terrible inconvenience but this shows what it's like experimenting with brand new technology that nobody's settled on a standard for yet.
« Last Edit: January 02, 2015, 02:06:05 pm by dentaku »
 

Offline Razor512

  • Regular Contributor
  • *
  • Posts: 156
  • Country: 00
Re: EEVblog #698 - GPU Video Rendering
« Reply #47 on: January 02, 2015, 02:06:07 pm »
How far has he pushed his 3770K?

It is a good overclocker and it will be painful to run it at 3.5GHz instead of something more reasonable like 4.2 to 4.5 GHz

The dedicated nvidia encoder will encode directly to h.264 at up to 1440p at 60FPS.

It is an ASIC designed for the nvidia shadow play, thus it has no noticeable performance impact when gaming.
 

Offline edy

  • Super Contributor
  • ***
  • Posts: 2385
  • Country: ca
    • DevHackMod Channel
Re: EEVblog #698 - GPU Video Rendering
« Reply #48 on: January 02, 2015, 02:16:50 pm »
Dave, here is a suggestion... perhaps others can chime in.

I record and edit everything in MPEG which is what my camera records. I use Womble (although other editors probably exist) which edit MPEG without any recoding when I set my output to the same as my input. Basically just stream copying. That is extremely FAST and there is no "loss" from decompression and compression which may introduce artifacts, and also no CPU work involved.

Once I have a complete final edited MPEG output, I apply Handbrake to it and it recodes and compresses to a nice MP4 which I upload to YouTube. Why? Because it is faster to use Handbrake and upload the smaller file compared to just uploading the bigger file.

So my suggestion is to not worry about any compression or decompression during editing if you are simply doing mostly straight cuts, and use software which can handle direct stream copying like Womble does with MPEG. Then your limitation is not so much the CPU but how fast your machine can copy a file. Let Handbrake do the heavy work to produce a file you can upload.

What do you think? Is anyone using "lossless" editors? Do they have it available for other formats or only MPEG?

Perhaps I will do a video showing my setup and how fast it works on my crappy old ASUS M51a laptop.
« Last Edit: January 02, 2015, 02:40:09 pm by edy »
YouTube: www.devhackmod.com LBRY: https://lbry.tv/@winegaming:b Bandcamp Music Link
"Ye cannae change the laws of physics, captain" - Scotty
 

Offline poorchava

  • Super Contributor
  • ***
  • Posts: 1672
  • Country: pl
  • Troll Cave Electronics!
Re: EEVblog #698 - GPU Video Rendering
« Reply #49 on: January 02, 2015, 02:21:03 pm »
@poorchava -> What software are you using?

It's not uncommon for OpenCL to augment video encoding but not fully replace it.  For example, x264 has OpenCL offload of Lookahead, but the rest of the encoder is CPU based.

Same as Dave did, a relative of mine happened to have a license for the Sony software which they are not using at the moment. I use different video editing software though.

Btw, the Youtube bandwidth sensign doesn't work very well for me. It tends to set itself to 720p/25fps while my connection is this:
I love the smell of FR4 in the morning!
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf