EEVblog #698 - GPU Video Rendering

[wholder]

I'm wondering if a bit of crowd sourcing could help, here.

This is pretty simple really. I either need a faster processor, or I need a codec available on Sony that can be rendered too faster.

Have you considered a solution that uses a rendering farm of multiple computers to handle the encoding?  In the Mac world we use Compressor (http://www.apple.com/final-cut-pro/compressor/#distributed-encoding) to use an array of shared computers to distribute the task.  Perhaps you could use some of those "dumpster" computers you're always finding to build something similar using Windows.

Wayne

[EEVblog]

I think I might get back into trying x264vfw and see if I can get it working. Never had success before, but that should allow the skipping of the Handbrake step. At least for the main part. Still have to transcode for the podcast version using my existing script.

[Corporate666]

I don't get why everyone insists that it must be things that Dave has already tried (memory, drives) that is slowing him down... it's only 2 things, the CPU and the software.

Dave, how tied are you to Sony Vegas?  You say it suits your workflow... is it that you know the software well and don't want to change, or does Vegas do something that other software doesn't do?  On the other hand, I don't think offloading to a GPU is going to make all that much difference at all, even if the software did support it.

Depending on what you want to spend and how much tinkering you're willing to do, I think you should look at

1) Overclocking your machine as much as possible.  Water cooling, etc.  You can probably increase speeds quite significantly this way.
2) Can you automate your process with scripts/macros/software such that you just dump a file into a folder, hit "go" and the next morning it's rendered/converted and uploaded to Youtube?
3) Possible to find a camera that outputs in a format that eliminates one of your steps?
4) A Xeon processor will be a fair bit faster, but nowhere near the bang for the buck of an i7.  But if you need speed more than you need to control costs, a Xeon (or dual Xeons) will help a LOT
5) There are numerous cloud computing services available.  You could pay-by-the-hour with Amazon AWS and render your stuff faster than you can imagine, but you may be limited then by bandwidth getting the data to/from them?  https://aws.amazon.com/ec2/  and there are other services that cater specifically to video rendering that can give you massive computing power at the drop of a hat.

[EEVblog]

I think I might get back into trying x264vfw and see if I can get it working. Never had success before, but that should allow the skipping of the Handbrake step. At least for the main part. Still have to transcode for the podcast version using my existing script.

Turns out that x264vfw  finally worked.
Rendered 1:00 file in 2:20 whcih is not bad considering I don't need the 2nd Handbrake step.
Audio is way out of sync though, so more experimentation required.
And there is the ability to add my existing Handbrake command line options manually too.

[EEVblog]

1) Overclocking your machine as much as possible.  Water cooling, etc.  You can probably increase speeds quite significantly this way.

Of course. But it's pretty linear.

2) Can you automate your process with scripts/macros/software such that you just dump a file into a folder, hit "go" and the next morning it's rendered/converted and uploaded to Youtube?

I already do that with handbrake, it's drag'n'drop onto desktop icons.
I have different scripts for different tasks I need.

3) Possible to find a camera that outputs in a format that eliminates one of your steps?

You wouldn't buy a camera based on that. And it's either H.264, AVCHD, both of which I use presently, or some form of raw.
Raw video provides a nightmare in transfer and storage.
Only the craziest pixel peepers, or people who need documentary film quality do that.

4) A Xeon processor will be a fair bit faster, but nowhere near the bang for the buck of an i7.  But if you need speed more than you need to control costs, a Xeon (or dual Xeons) will help a LOT

Of course it will, it's simply a matter of cost.

5) There are numerous cloud computing services available.  You could pay-by-the-hour with Amazon AWS and render your stuff faster than you can imagine, but you may be limited then by bandwidth getting the data to/from them?  https://aws.amazon.com/ec2/  and there are other services that cater specifically to video rendering that can give you massive computing power at the drop of a hat.

Not an option due to bandwidth caps and upload/download speeds. Pointless to even consider, will always be faster to render locally.

[EEVblog]

Dave, how tied are you to Sony Vegas?  You say it suits your workflow... is it that you know the software well and don't want to change, or does Vegas do something that other software doesn't do?

Don't mention the war, or editing software.
I've spent years investigating other packages and have settled on Sony for various reasons.
Changing to another package will not solve the problem to hand, only create new ones.

[gildasd]

I saw the server farm thing done a few years back by a company that does events for the medical sector.
They also did the video of the blablablanosideeffectsoncowsblablabla and their typical client NEEDED the finished edit in 24h for global release/denial.
The finished vids were hellish long, 3 to 8 hours.
They had a guy on a motorbike bringing in the rushes during the event to start derushing the thing.
There were like 4 minions doing that, and the head honcho in an edit room with a wall of screens yelling with interns grabbing notes of x time on y screen...
Then other people would patch the thing together.
10 people in the office.
4 or 5 at the event...

The one event I did had 1 wide shot (safety cam).
2 or 3 fixed shot.
1 mobile on the person speaking.
All on non stop (2cams in each spot, when a cam was on the last 5 min of a tape they would start the parallel cam).

Won't name names because I nearly had to sue them to get paid something they had had signed etc.

The "farm" was a room of DELL's (10/12) with onboard graphics with 2 drives (RAID set for safety), 8gig of ram and the biggest CPU that could be ordered standard on the cheapest model...
They would literally run them till they burnt, but had boxes of new units to swap in when they did.
All were all on ethernet and run from a Mac where the edit was done.

Can't tell you more, this not my domain.


Edit: added more memories...

[PinheadBE]

Gosh 
Everyone seems obsessed by HDD, CPU or GPU performances, and no one even mentionned the link between all of them: your system bus!

All in all, you'll only get the performance of the weakest (= slowest) link in your system.   You may increase your CPU or GPU power as much as you can, but in the end, if your bus, for somewhat reason, cannot deal with the higher throuput, you'll stay exactly where you are. 

(btw, for what it's worth, I don't give it a kopeck to 60 fps or over-the-rainbow-superb-HD definition....  We are not talking National Geographic here !  We just look at the guts of some electronic trash....  I personnally always download the videos at 480p to my tablet to watch them in the train while I commute... So.... AFAIC, this is all a waste of time....  just my 2c  )

[free_electron]

I'm not fussed with the exact terminology. It is common to call anything your video editor spits out to be "rendering".
And then anything after that "transcoding".
And that is what what I call them.

i gave the terminology to make sure we are talking about the same thing. So we have established your problem is decoding, encoding. Encoding as this takes a long time but can be run as last step in handbrake. Even then, we want to skip all the intermediate decoding/ encoding steps to speed up the creation of the input file for handbrake.

Rendering is for crossfades. Transcoding is converting one video format to another. You dont do a lot of renders. Splices arent reallly renders unless they need to be done on non i frames.

If you can tell me how that's possible in Sony I'm all ears.

There should be a setting for that in the editing preferences. Lok for so ething called 'adjust cut point to gop end' or something to that terms.

Found it : http://www.sonycreativesoftware.com/webhelp/vegaspro/12/ENU/Content/Render.htm
Play with that checkbox and see what happens.

It's all well and good to say all this and show how studios us it etc, but it's not really relevant to my situation I'm afraid.

I gave that as an example that the bottleneck is not the video manipulation in itself, it's the deco press-recompress stuff that eats your time. That is why studios stream a n uncompressed format.
You may be able to do such thing also. Your camera has a live video output over usb ?  Meaning if you plug it in and launch a video capture tool it sees the live feed ?   You may want to try to capture, using a laptop , directly in an uncompressed format , or a format that only uses i frames. As opposed to usng the in camera encoding. You will have very large files but there is no deco pression step anymore. You have raw uncompressed video and audio.
[/quote]

I couldn't think of anything more horrendous that would kill my productivity than to live capture from the camera to a PC. (could be done via HDMI)
Just the logistics of it would be a nightmare.

Why ? Now you capture to sdcard right ? You would simply capture to a harddisk. It would still be drag n drop to get the files over to your editing station.

You would use a pc instead to grab uncompressed video. Speeding up the backend.

Read that link. They explain which formats allow gop passthrough meaning there is no decoding encoding sedning data from an input to ouput.
Play with that re-encode option. Turn that off. That will symply copy over bytes from file to file.

[Lightages]

For reference:

I have an MSI GT70 laptop with an i7-3610QM at 2.3GHz 16GB ram, 2x 128SSD in RAID0, 1TB 7200 secondary, NVidia GT675M 4GB, Sony Vegas Pro 13, Win7 x64 Pro.  I get basically no difference using the Sony AVC, that Dave demonstrated, between just CPU or with GPU, around 30 seconds to render the windows video ample file to 1080 30P. When I use the Main Concept codec instead it goes to around 2:00 to render with only CPU but drops to under 30 seconds with CUDA enabled.

[edy]

I looked up your camera models... I am assuming that you were using a Canon HFG30 and now you are using the Sony NEX-VG30. The Sony video format is not universal yet (I saw a few forums in which Mac users are complaining of not having codecs for some of their software) and nobody has created a video editor which does "direct stream copy" with this format (or have they?) when editing simple CUT edits in videos. Perhaps looking for an MP4 "lossless" editor for simple cut edits is the key?

When software is not optimized for lossless, even if you are just going from and to the same exact format, it will STILL go through the usual method of having a decompression and recompression. Software written for "lossless" stream copying for edits (whenever possible) are much faster by avoiding the re-encoding when they see the input/output will be identical.

So with my antique Sony DCR-SR200, it outputs vanilla MPEG-2 files at 720x480 resolution, 29 fps, 9100 kbps video and 448 kbps 6 channel (5.1) audio at 48 khz sample rate. This is much smaller and lower resolution than what you are using, but because this format has been around forever, there are lots of tools available (like Womble MPEG Video Wizard DVD) that allow "lossless" cut edits. It even shows me how much of the copying will be "re-encoded" and how much is "stream copy". See here:




With this in mind, my basic video cut edits are done in seconds for videos that are many minutes long. The only bottle-neck is how fast my hard-drive can read and write the exact same data pretty much. The CPU does nothing and the software can do this because it knows how to properly cut and regenerate "keyframes" with the proper "inter" frames so that cuts work properly (so you don't get those strange inter-frame artifacts when you try to simply concatenate or "fix" corrupt files that are missing keyframes and the inter-frames are working on the wrong data until another keyframe pops up in the stream).

Once my edit is done, Handbrake takes it up to the proper level.

What you may wish to do (not sure how the quality will be) is convert the Sony video output to a format that you can get a "lossless" editor for.... Look for them and see what options are available to handle your high resolution and frame rate. It may be faster to just convert it to this intermediate format and then work with the intermediate format in your lossless video editor... output the edited video to your intermediate format. The cut edits would be mostly stream-copied and it should output in a matter of seconds. Then just Handbrake it back to MP4 for YouTube.

That's essentially what I do now except my camera outputs MPEG-2 already. When I wish to edit MP4 videos I am usually converting it to MPEG-2 with WinFF but keeping high quality bitrate settings, doing all my editing in MPEG-2 within Womble and then back to MP4. Otherwise if I try to edit MP4 directly in Womble (which it will accept) it is very SLUGGISH.... especially when I try to SEEK back and forth to certain parts of my video, do splits and drags, etc. It is impossible to use MP4 on my system because of my slow CPU. But MPEG-2 at high bitrates so it is relatively uncompressed is fast and easy to work with. Then I just delete the huge files when I am done. It is just intermediate format to help the workflow go faster.

[JoeO]

I'm wondering if a bit of crowd sourcing could help, here.  Perhaps you could post a RAW, one minute clip in the same 60fps format you tested and see what results your viewers can get.  Perhaps not every solution would be useful to you, but it would give an idea as to what is possible.

Wayne

I proposed the exact same idea in post #54.

[Richard Crowley]

The ONLY "benefit" from 50 or 60 FPS appears to be the geek wow factor. "Just because we can do it."
If there is any actual significant benefit to viewing talking head videos in 60 FPS, I would certainly like to hear it.
Now, people who do video blogs about how to improve your golf swing or something may benefit from 60 FPS (or even higher).
Don't get me wrong. Dave's content is top-drawer and there is no doubt that thousands of people all around the planet are entertained and educated by watching the EEVblog videos. But I just don't get what is the fascination with high frame rate. Surely people aren't confusing spatial resolution with temporal resolution (which are two independent functions).

[george graves]

Well said Richard.  60FPS for a "long form" "talking head" video blog is just playing with tools - having fun - and showing off.   Yes it is cool! And smooth playback, blah, blah, blah.  But sooooo not needed.   I was going to bring that up, but Dave currently is having an aneurysm already when ever I mention video workflow.

The smart choice might actually be 24 FPS, and with the reduce frame rate, give the bandwith to image fidelity/quality, smaller file size, and quicker upload times.  The EEVBLOG is not a F1 race, or a football match.  It's a freaking video blog!  It's cool you can do it.  But it's the video production equivalent of blinking an LED with an arduino.

 

So I'm just supposed to blindly follow them?

Yes, they know more then you.  But you know more then they do in other areas.  So....what's the issue?  Why is this a pissing contest?

Dave, I'll give you one last piece of advice, is that the pro editing software (and only in the last few years Premiere could be put in that camp) has a much better intergration with video cards.  (You're using consumer crap.)  I don't use Premiere, so I'm not on top of what they are doing, but I know they work closely with Nivida to make thing works right.  Look into their Mercury engine.  It not only accelerate previews, but renders as well. The real time smooth playback is nice.  Scaling, and mixing multiple resolutions on the same time line.  Not to mention some cool things like stabilization, and stuff.  You do have to pay for it, so that might be a deal breaker for you.

You're using a consumer editing software, then complaining why it doesn't work with a beading edge video card.  Waaa! 

That's like me using a $50 scope, and then ranting why I can't measure fast rise times.  You got to pay to play.  No?

Don't get me wrong. Dave's content is top-drawer and there is no doubt that thousands of people all around the planet are entertained and educated by watching the EEVblog videos.

Ditto.  Make electronics videos - that's what we love you for.    Who cares?!?!?  Lets get back to basics!

[Howardlong]

Dave, I'll give you one last piece of advice, is that the pro editing software (and only in the last few years Premiere could be put in that camp) has a much better intergration with video cards.  I don't use Premiere, so I'm not on top of what they are doing, but I know they work closely with Nivida to make thing works right.  Look into their Mercury engine.  It not only accelerate previews, but renders as well. The real time smooth playback is nice.  Scaling, and mixing multiple resolutions on the same time line.  Not to mention some cool things like stabilization, and stuff.  You do have to pay for it, so that might be a deal breaker for you.

Your using a consumer editing software, then complaining why it doesn't work with a beading edge video card.

I think he mentioned the war, not sure if he got away with it though.

[george graves]

There's no war with video editors.  If you own a OSX machine, your war is with Apple for ending FCP.  That's about the end of it.  If you have a PC, or want to boot camp your OSX to win 7, you have more options now then ever.  Ask any disgruntled FCP editor, and they will talk your ear off.   But maybe on the consumer side there is.  It;s like eagle vs kicad.  It's an argument that will work it's self out eventually.

[EEVblog]

Well said Richard.  60FPS for a "long form" "talking head" video blog is just playing with tools - having fun - and showing off.   Yes it is cool! And smooth playback, blah, blah, blah.  But sooooo not needed.

So, it's cool, and it's smooth playback. Those sound like benefits to me, or at least one anyway.

The smart choice might actually be 24 FPS

I think I can safely guess no on that one.

Yes, they know more then you.  But you know more then they do in other areas.  So....what's the issue?  Why is this a pissing contest?

No pissing contest. You are simply wrong, as seems to be usual when it comes to this stuff. You pointed me to what you think is the best option and I should listen to them/you, blah blah, but the demonstrable fact this the best system on that list is hardly any better than what I have now for the purposes I need it for.

Dave, I'll give you one last piece of advice, is that the pro editing software (and only in the last few years Premiere could be put in that camp) has a much better intergration with video cards.

You don't get it do you?, it doesn't matter. It's all about CPU power. GPU's are a crock unless you have a serious editing workflow that can take very specific use of it. I don't have those requirements.

[EEVblog]

Ditto.  Make electronics videos - that's what we love you for.    Who cares?!?!?  Lets get back to basics!

I am getting back to basics, and forgetting all this GPU crap that basically will never work for my requirements.
But if I want to produce HFR video, I'll produce it, and don't forget that I've had a lot of people say they really like it. That is reason enough to keep doing it.

[EEVblog]

The ONLY "benefit" from 50 or 60 FPS appears to be the geek wow factor. "Just because we can do it."
If there is any actual significant benefit to viewing talking head videos in 60 FPS, I would certainly like to hear it.

All the people who say they like it can't be wrong.

[Marco]

The smart choice might actually be 24 FPS, and with the reduce frame rate, give the bandwith to image fidelity/quality, smaller file size, and quicker upload times.

24 FPS gets you cinematic judder, which some people associate with quality I guess ... but with a modern codec the image quality won't improve significantly and the motion smoothness will decrease significantly for the majority of people (who are on 60 FPS displays) compared to 30 FPS.

[george graves]

All the people who say they like it can't be wrong.

 

Again, you're blinking an LED with an arduino.  Sorry Dave.  Again, I'm a huge fan of yours, but you're beating a dead horse here.  Good luck in your video render times - but ever single piece of advice given to you here is falling on deaf ears. It's kinda pointless.  No good deed goes un-punished I guess. 

[Marco]

How did you establish that the majority of people are on 60fps displays?

Common sense ... I only replaced my CRT monitor with a LCD last year, but I was the last of a dying breed years before. If you are still a member of that breed that's okay, but you are in the minority. Most LCD monitors are 60 Hz.

[EEVblog]

Can you just remind me why you bought a high end graphics card. Somewhere I have gotten lost. I thought it was to speed up your rendering.

It was. It didn't work, and ultimately really never stood a chance of working.

I just want to remind you that us technology laggards have less smoothness in 60fps playback.

There are ways to play back without the 60fps.

[metacollin]

You need a Quadro/Tesla card for accelerating encoding.  The stream processors on gaming GPUs cannot usefully encode better than a CPU using OpenCL or CUDA due to architectural limitations.  Basically, you bought the wrong card. 

This is not a software problem - OpenCL and CUDA are very mature and well supported.  It's simply the stream and shader processors on GPUs cannot branch well (perform logical operations) and are pipelined like mofos.   There are custom encoding algorithms that work on GPUs, but they are sacrifice quality, though it's only noticeable at lower bitrates (like youtube . ).

If you want realtime performance without changing encoder settings, you really only have one option IMO, and that's a true Xeon Workstation, 12 cores minimum. 

I can say, don't waste anymore time with that card, I would return it if you can.  There are cards that can accelerate encoding of very specific codecs, but video encoding algorithms are still very much the domain of general purpose cpus. 

[kikr4000]

Hi Dave,

The same problem using CUDA goes a long for most video products these days.

I am having the same issue with NERO.

Apparently NVIDIA has removed some stuff in the drivers to support video encoding. Older driver versions can be used to solve this problem on older gfx cards. My guess is that you are however f..... since these older drivers will properly not support your new card.

Some Nero users have been in contact with NVidia, this is one of the answer thet got:

Response from nvidia:
Development investigated the bug and concluded that this is expected behavior due to recent changes in the recent drivers. NVIDIA support for CUDA based encoding (NVCUVENC) has been deprecated starting with the 340.xx driver release. The application will not be able to use NVIDIA CUDA for the purpose. We are no longer exposing the CUDA interface for encoding so the Nero application shouldn't list the CUDA device at all. It appears the application may be falsely detecting the CUDA interface despite the required library is no longer exposed by our drivers. They will need to update their applications to correct this and not expose the CUDA device. We are making arrangement to notify Nero that we are no longer exposing the CUDA interface so they can update their applications to reflect that. Let me know if you have any further questions.

Full thread at:
http://forum.nero.com/nero_eng/topics/nero_recode_graphics_accelerator
http://forum.nero.com/nero_eng/topics/nero_video_12_cuda_video_driver_outdated

/Kim