EEVblog #698 - GPU Video Rendering

[EEVblog]

Just saw that someone has offered up a pair of E5 Xeon's.  That is the way to go moreso than any i7 chip.  Will be very interested in the results.

Should be.
Two 2630 v2's aren't a lot behind the 2650 v3's
http://www.anandtech.com/bench/CPU/1052
So should at least be close to the fastest i7 available for handbrake.
A new top end i7 is $1300 for the CPU alone + new MB
A new dual CPU Xeon MB is about $800
And I'm betting the 12 cores in the dual Xeons will beat the single 8 core i7 in some tasks.

[DanielS]

And I'm betting the 12 cores in the dual Xeons will beat the single 8 core i7 in some tasks.

One disadvantage of a multi-socket system is you end up with extra latency from cache snooping between CPUs and a bandwidth bottleneck between CPUs when one needs to access the other's memory. Applications can work around that by duplicating the working set across each CPU's local memory but that requires explicit software support.

In terms of raw processing power, if you overclock the i7-5960X to 4GHz (being conservative), you end up about even and the i7 should beat the Xeons most of the time.

[rizzy]

A new top end i7 is $1300 for the CPU alone + new MB
A new dual CPU Xeon MB is about $800
And I'm betting the 12 cores in the dual Xeons will beat the single 8 core i7 in some tasks.

But you don't even know if it will benefit from eight cores. From the video I remember a slider for "slices" which was about 3/4 to the right and was at six. So if this is the number of parallel threads, the maximum might be at eight so the i7 might be the better choice then the dual Xeons.

If you do not ask anyone who actually runs this setup or at least a similar one it is only a guess but you may be spending another couple hundred bucks without an improvement.

Well, at least you can play modern ego shooters in full hd and highest details with 60fps on your machine

[EEVblog]

But you don't even know if it will benefit from eight cores. From the video I remember a slider for "slices" which was about 3/4 to the right and was at six. So if this is the number of parallel threads, the maximum might be at eight so the i7 might be the better choice then the dual Xeons.

That was very codec specific, and in any case, no, setting it to 1 "slice" does not use only one core, it still uses all my 8 cores.
From the help:
"Drag the slider to adjust the number of slices that are created in your rendered file.
A slice is a portion of the video frame, and some hardware decoders require specific numbers of slices. Choose the setting that matches your destination playback device. "
I plan on using either x264vfw or frameserve direct to Handbrake both of which can use as many cores as you can give it.


If you do not ask anyone who actually runs this setup or at least a similar one it is only a guess but you may be spending another couple hundred bucks without an improvement.

Well, at least you can play modern ego shooters in full hd and highest details with 60fps on your machine
[/quote]

[Marco]

The refresh rate of the monitor is NOT the same as the playback frames per second.

FPS is simply a unit and it's used as a unit for refresh rate relatively frequently. Language is not math, a little good will and reading the context is necessary to understand natural language ... when I say "60 fps displays" I think you're smart enough to understand what I mean, since I simply can't be talking about the video content being played back in that context.

[steves]

Generally, I'm happy watching with Youtube 240p resolution option. Occasionally, I'll put it up to 360/480 when I want to see some detail. Alternatively, if it's mostly just talking, or my available bandwidth is low, I'll go to 144.

The discussion here has been interesting, thanks, but seems that I'm the exception in terms of not demanding resolution/quality, or then again, perhaps just a part of a silent majority?

[mariush]

The number of slices is not in relation with the number of threads x264 uses to encode stuff.

Unless you select otherwise (using command line parameters), x264 will default to physical cores count + 20% or something like that - for my fx-8320 (8 core cpu), x264 defaults to 10 encoding threads. There's some other threads that do less work so i don't mention those.

I'm not sure if it's still valid, but if I remember correctly there was a note on developer's blog or on Doom9 forum where developer was saying more than 20-24 threads isn't recommended. Something to do with quality or efficiency dropping when there's more than one thread for a 64 pixels stripe of image or something like that  ( for a 1080p video, you'd have 17 stripes of pixels)

Anyway, it's kind of pointless when encoding to constant quality per frame, as the encoder won't "work hard" to analyze the video frames and do all kinds of things it would normally do to achieve highest quality per bitrate, so over a threshold increasing the number of threads won't make much of a difference. 

[justanothercanuck]

I have LCD monitor. The refresh rate of the monitor is NOT the same as the playback frames per second. If that were the case then there would be no noticible difference between playback of a source filmed at 24fps, 30fps or 60fps.

Nvidia has something new called G-sync, it's a dynamic refresh rate that adapts to your GPU's FPS output.  Kindof expensive at the moment though.

[PinheadBE]

Because it looks better to many people. It's smoother and gives a more detailed image.

Nope!  It could appear smoother when you increase the FRAME RATE, but a more detailed image will be given by a higher DEFINITION.

Btw, ask Peter Jackson why he'd chosen to satisfy himself with a crappy 48 fps for his giant 600 M$ budget 3D blockbuster trilogy when Dave Jones can do his 2D talking head show in 60 fps.   I think I'll suit WingNut Films and New Line Cinema for a refund.... 

Come on: I love your videos, but if I want something spectacular, I'll go to the cinema!

[Monkeh]

Btw, ask Peter Jackson why he'd chosen to satisfy himself with a crappy 48 fps for his giant 600 M$ budget 3D blockbuster trilogy when Dave Jones can do his 2D talking head show in 60 fps.   I think I'll suit WingNut Films and New Line Cinema for a refund.... 

He's not doing it in 60fps, it's 50fps. 48fps is used because it's a multiple of 24, 24fps is used because.. well, no actual technical reasons exist for modern usage that I know of. Lots of reasons not to use 24fps, let alone the moronic NTSC framerates, but they still persist.

People really should stop whining about how there's no point in using higher frame rates for this sort of video and just deal with it.

[Monkeh]

He's not doing it in 60fps, it's 50fps. 48fps is used because it's a multiple of 24, 24fps is used because.. well, no actual technical reasons exist for modern usage that I know of. Lots of reasons not to use 24fps, let alone the moronic NTSC framerates, but they still persist.

People really should stop whining about how there's no point in using higher frame rates for this sort of video and just deal with it.

Between 9:15 and 9:50 Dave shows he is using 60fps.

Yeah. People should stop whining. What is the point of having a 60fps camera if you're not going to use it? If I had the free bandwidth and a fast computer I'd watch in 60fps. People will be watching the EEVBlog videos in years to come so future proofing the content is forward thinking. Just like the move from SD to HD.
I thought it was pointless at first but I have come around.

I'm sure he said before the camera only records at 50. Also, I just checked several of his previous videos, and they're 50. I have not, however, watched the video, because I have less than no interest in watching him play with encoder settings.

[Marco]

Nope!  It could appear smoother when you increase the FRAME RATE, but a more detailed image will be given by a higher DEFINITION.

That's only true statically and in motion with a true strobed display ... which even cinema hasn't been in a long long time. Cinema is tripple flashed and LCDs hold the frames in between refreshes. When your eye follows motion the extra flashes in cinema and the held frame on a LCD will smear out the detail.

[EEVblog]

People will be watching the EEVBlog videos in years to come so future proofing the content is forward thinking. Just like the move from SD to HD.
I thought it was pointless at first but I have come around.

This is the whole point of it, and why I went to HD to begin with. HD was a very painful move, but I kner I should future proof my content sooner rather than later.
And if people don't know how youtube works, they keep the original content you upload and as they improve their technology they continue to re-transcode videos in the background to suit whatever the latest technology is to display it, codecs, etc, and produce whatever the viewer chooses to watch.
It is in every youtubers best interest to upload the best quality content they can.

[wilhe_jo]

Hi there!

Back in the days when dual-CPU (not core!) systems where the very top of the roof I did some video-editing...

I'm using linux so maybe you cannot do it the same way...

As you're doing I used a 2 step aproach ... rendering and after everything looked fine transcode it to VCD

At the very beginning the raw-data was mjpeg... When I set up my rendering software to produce exactly the same format for the rendered video, every part which was not changed by overlays, ... was just copied. So basically my old IDE RAID was the bottleneck... damn I really woud have liked a bunch of those fancy SCSI disks

Some years later I used to cut and transcode movies captured from my DVB-S (some german stations gave 30(!)mbit mpeg2) card... If nothing was changed during 2 key-frames, the part was just copied as it was with the old MJPEG vids. Transcoding was a over-night job to get a 2 hour movie transcoded to xvid...

So maybe you can do similarly and save at least some rendering-time but I'm not sure if you could get this working (bloody directshow... never liked this as a programmer...).

I've some experience in GPU programming and found that using them efficiently is not very easy. The major problem is that you load your input data to your RAM, then everything is copied to the RAM of the card. After everything is computed you need to copy it back to the system RAM and save it to you HDD. Including the syncing of your "threads" on the card and the CPU this results in a huge overhead...

Actually it seems that you need special GPU codecs like the NVENC from Nvida in order to get video transcoding of mpg4 faster on a GPU than on a CPU... but that was just quick google since I was curious how this progressed the last years....

I'm sure you already checked some generic benchmarks if your system is configured correctly (dual channel ram-access, pci-e speeds correctly set, ...) ... that could also push down your rendering speed (had that on my laptop...) but I think you have to use your GPUs special rendering cores instead of some generic gpu-implementation... at least on paper the performance of your geforce sounds massive!

Cheers from Austria,
  Hans

[FrankBuss]

Dave, another idea if you really care about speed would be to use professional broadcast equipment. For example this device supports two parallel streams, up to 2048x2048 and 1920x1200 @ 60 fps video input (SDI input, which is used in broadcasting, or HDMI), and encodes it in realtime to H.264 for streaming and for recording to a harddisk. It's really expensive for EUR 4,220, but maybe there are similar cheaper special H264 encoder PCI cards or other devices with just the encoder chips, or you can get some second hand hardware.

Maybe the TV team which will visit you can tell you something about it, or they let you visit the studio to take a look at their equipment and to talk to the technicians. This would be cool for an EEVblog episode.

[DanielS]

I've some experience in GPU programming and found that using them efficiently is not very easy. The major problem is that you load your input data to your RAM, then everything is copied to the RAM of the card. After everything is computed you need to copy it back to the system RAM and save it to you HDD. Including the syncing of your "threads" on the card and the CPU this results in a huge overhead...

Copying the source data to the GPU for decoding, processing and encoding is not the bottleneck: the source data is less than 50Mbps while PCIe bandwidth is 128Gbps, a whole three orders of magnitude faster, full-duplex.

The problem with GPU encoding is that while the GPU may excel at streaming computations like convolution, modern CPUs with AVX/AVX2/HNI instruction sets are no slouches at it either. Also, this neatly serializable and parallelizable part of encode processing accounts for only a small fraction of total processing. The really tricky part is motion search and this does not scale well to hundreds of threads short of splitting the video into multiple segments for parallel processing: you can only partition screen space into so many regions before all your threads start tripping over each other and do excessive duplicate work along boundaries.

[s55]

@DanielS   You forgetting that you must first decode the video into a RAW format like NV12 before you and work with it on the GPU. This is orders of magnitude larger. So the actual data volume going back and forth is huge compared to the original stream. A lot will depend on the architecture of the app, how well it fits in and how much copying back and forth is required. May be easier for some apps to implement that others just due to their feature sets and what can run on the GPU and what can't. (i.e filters)  Some apps may be able to decode and encode all in the GPU and avoid a lot of copying, but may not be as feature packed as apps that can use the CPU also.

Your right though, Instructions such as AVX are beneficial and infact used in x264. I don't recall the exact number, but I seem to recall an 8~10% performance increase in certain x264 functions when AVX2 was implemented, but I'd need to go check that.

[Michael Rempel]

I can add a few observations Dave and others.

GPU render is for high complexity. If it is only doing some simple interpolation which there is with codec manipulation, the pipeline cost is hardly worth it. In animation rendering we sometimes run into 20mins per frame render times, so count your lucky stars.

The best answer is a NAS backing a render farm of cheap machines. I can recommend http://www.thinkboxsoftware.com/deadline/ as the best tool for the job. It will automate your entire workflow with no issues.

But seriously, why the high frame rates? Just because you can? Most people I know shoot 24fps at 1080p despite having 2k or even 4k available at higher rates. It produces as cinematic look that they love. Past 1080p you are really looking at diminishing returns, especially for a run and gun shoot like yours. Obviously you can do what you like but the investment in HFR is not giving you a lot in the end. I would invest in colour grading software (DXO Labs), perhaps a jib, and the best damn camera I can afford. Focus on colour depth most of all, not so much on frame rates or pixel counts. That might be a Nikon D810 with a Zeiss lens or two (small fortune), or a Red Dragon with a Canon Cinema lens. (big fortune. Dont choke if you look up the prices, that is what they go for. Your house might cost more, but not by much)

If you try deadline rendering and like it say Hi to Ryan for me when you buy your license. He has been coding it for years, and really knows his job.

[DanielS]

@DanielS   You forgetting that you must first decode the video into a RAW format like NV12 before you and work with it on the GPU. This is orders of magnitude larger.

Logically, you would also use the GPU for decode if the GPU supports decode acceleration for your preferred CODECs - the GPU is going grossly under-used anyway.

Even full-frame raw 4k video at 60fps at 32 bits per pixel is only 17Gbps, so x16 PCIe is fast enough for 7X real-time if the GPU and CODEC were capable of handling video encoding that fast. Dave scored less than half of real-time and we are only talking 1080p50... about 4Gbps worth of raw video.

[EEVblog]

But seriously, why the high frame rates? Just because you can?

I've explained that before/

Most people I know shoot 24fps at 1080p despite having 2k or even 4k available at higher rates. It produces as cinematic look that they love.

Great for them, not for me.

Past 1080p you are really looking at diminishing returns, especially for a run and gun shoot like yours. Obviously you can do what you like but the investment in HFR is not giving you a lot in the end.

A lot of people like it.

I would invest in colour grading software (DXO Labs)

No thanks. Last thing I want or need is another production step.

perhaps a jib

Totally inappropriate for my needs.

and the best damn camera I can afford.

The best camera is not the most expensive. It's the one that allows you to be the most productive in your environment.
There are very good reasons why I don't use my Sony NEX VG30 and prime lens as my main blogging camera, and it's the most expensive camera I have by far.

Focus on colour depth most of all, not so much on frame rates or pixel counts. That might be a Nikon D810 with a Zeiss lens or two (small fortune), or a Red Dragon with a Canon Cinema lens. (big fortune. Dont choke if you look up the prices, that is what they go for. Your house might cost more, but not by much)

FYI, I can get a RED camera (seriously I've been offered one), but I'd be a fool to use it for blogging.
Houses in my area cost $1M+ FYI

[EEVblog]

FYI, this is some info directly from the Director of Technology at Sony Creature Software (who make Vegas/Movie Studio)

There are actually three places in Movie Studio that have GPU acceleration. The first is in the video engine, using OpenCL, and includes color conversions, interlace handling, scaling, pan/crop, track motion, compositing, transitions, and effects (any of them in the “GPU Accelerated” folder in the effect chooser). This is also the GPU selected in the Preferences page that you showed in your video.
 
The second is for MainConcept AVC rendering, which you touched on briefly, using CUDA or OpenCL.
 
The third is for Sony AVC rendering, using CUDA or OpenCL. This is the area giving you trouble. The latest Maxwell-based GPUs are not being detected in that module, and we’re looking into that. Even if they were, I wouldn’t expect a massive speed-up compared to your very nice CPU since AVC compression is not one of those areas that gets amazing faster on the GPU. The machines where we saw good improvements using GPU acceleration for AVC rendering were using smaller CPUs.

[eripaha]

This episode felt like terrible disaster to me. Dave you should stick to what you know best. 

[EEVblog]

This episode felt like terrible disaster to me. Dave you should stick to what you know best. 

You should quit complaining about video you don't like, that's twice in as many posts, no one is forcing you to watch them, they are clearly titled.

[EEVblog]

Uh Oh. Dave's just noticed the new Panasonic 4K or 1080p/120fps HD  HC-WX970 and HC-VX870. Now he can up the ante on quality AND create a wifi connected smartphone picture-in-picture for mailbag close-ups.
Anyone want to participate in  a sweep on when he sucumbs to temptation?

That WiFi connected PiP feature sounds neat, gotta be useful for something. I did consider Panasonics previous dual camera head camcorder.

[levinite]

According to the Nvidia the Maxwell GPU should be able to do 1080p at 480 fps with the proper software. This does not appear to be cuda driven but uses Nvenc, Nvidia's hardware encoder. There may not be direct support in Sony's software but an intermediate step saving into another format might be all that is needed.

See the pdf here: https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&cad=rja&uact=8&ved=0CCUQFjAB&url=http%3A%2F%2Fdeveloper.download.nvidia.com%2Fcompute%2Fnvenc%2Fv4.0%2FNVENC_AppNote.pdf&ei=dparVJTWN4XegwSrjYKgAw&usg=AFQjCNG2UMxFeZcSOUWyrXKtE0K9zQwvQg