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

0 Members and 1 Guest are viewing this topic.

Offline free_electron

  • Super Contributor
  • ***
  • Posts: 8515
  • Country: us
    • SiliconValleyGarage
Re: EEVblog #698 - GPU Video Rendering
« Reply #50 on: January 02, 2015, 03:07:07 pm »
Stuff to ponder about

How much transcoding do you do ?
'Rendering' is the terminology used when you create animated overlays like tickerbars, greenscreen effects , crossfades etc. you don't seem to be doing any of that in your movies. Render operations are doing pixel operations for which the gpukicks in.

What you are doing is transcoding. Take a chunk of video recorded in format x, and spit it out in format y.

Your camera films in format x. Your output is a different format ? What if you keep the format the same (input and output for,at identical) then the encoding only happens at the intersection of two clips. Most of the other data is simply copied over. Like merging two files.  There may be a tweak where you can tell the editing tool to adjust your cut points so they always coincide with an i frame. In that case there is no rendering involved at the handover point as a frame sequence always has to start with an i frame.

Do you know what the gop format looks like for your input format and output format ? If the gop lengths are different then encoding becomes time consuming.

What other effects are you running ? Color correction ? Audio leveling ?

Here's another thing to think about. If you watch commercial broadcast in HD. Let's say a news channel. They have the live studio feed, overlay a titlebar, have an animated scroller at the bottom , may inject an animated background and when interviewing a live reporter do picture in picture.
This is all done by a single computer , in realtime.

How do they pull that off ? By skipping decoding/encoding.

The live video comes in as an uncompressed format so the computer does not have to waste time expanding the stream and then re compressing it. The datarates are not that high for a modern computer. Overlays (tickerbar etc )are run on the gpu. Assembling the output video is a chunk of or operations using masks take live feed, apply mask (set certain areas to black). Then take overlay anything that is not black in overlay gets copied over to anything that is black in stream. Done.
Very simp,e bitswap operations.

When the final video is ready , then does it get encoded , once in the desired transmit 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.

That may edit much faster than the native format from the camera. Edit in vegas, save as uncompressed , and let handbrake do the encoding .

Something worth a try.

My gut says the computer is spending al its time decoding/reencoding.

« Last Edit: January 02, 2015, 03:30:40 pm by free_electron »
Professional Electron Wrangler.
Any comments, or points of view expressed, are my own and not endorsed , induced or compensated by my employer(s).
 

Offline JoeO

  • Frequent Contributor
  • **
  • Posts: 527
  • Country: us
  • I admit to being deplorable
Re: EEVblog #698 - GPU Video Rendering
« Reply #51 on: January 02, 2015, 03:12:39 pm »
Dave:

Why don't you post a video that readers can download and specify what you want as an output.  Also post your rendering time.

Then let the EEVBlog users experiment with their own systems and software with a goal of the least amount of time to render.

They can then post their results here along with their software/hardware/settings.
The day Al Gore was born there were 7,000 polar bears on Earth.
Today, only 26,000 remain.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: EEVblog #698 - GPU Video Rendering
« Reply #52 on: January 02, 2015, 03:15:21 pm »
Why don't you do 4k at 60fps?*





(*=joke)
 

Offline rw

  • Newbie
  • Posts: 2
Re: EEVblog #698 - GPU Video Rendering
« Reply #53 on: January 02, 2015, 03:29:10 pm »
I have had similar issues with NVidia GTX-970 card and several pieces of software not seeing CUDA as available. An interesting bit of information, which might possibly be gleaned from the DVDFAB DeCrypter forums: it was suggested that the new Maxwell architecture used in the current NVidia products also came with a change in the driver architecture. It was suggested that after some rewriting, CUDA can again be used. The people at DVDFab have said that in current versions they do support the newest NVidia chipsets. Unfortuantly for other reasons, I have not been able to test this statement, but my take away, is that if you are willing to wait, perhaps for quite a long time (based on the face that Maxwell GPUs were relased in the GTX 870 and 880 as well), the newer chips will be supported.
 

Offline hikariuk

  • Supporter
  • ****
  • Posts: 206
  • Country: gb
Re: EEVblog #698 - GPU Video Rendering
« Reply #54 on: January 02, 2015, 03:46:37 pm »
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.

60 fps recordings are pretty common place in the PC gaming crowd and their associated YouTube channels.  PC gamers, at least, prefer higher frame rates to higher resolutions.
I write software.  I'd far rather be doing something else.
 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: EEVblog #698 - GPU Video Rendering
« Reply #55 on: January 02, 2015, 04:50:08 pm »
Given the choice, and knowing how long the transcoding and rendering can take, personally I'd prefer the time to be spent on content rather than fannying around producing a 60fps rate. The frame rates on broadcast full HD TV is still 1080i at 25/30 frames/sec, perhaps I'm living under a rock, but I don't see many complaints about that.
 

Offline Flump

  • Frequent Contributor
  • **
  • Posts: 520
  • Country: gb
Re: EEVblog #698 - GPU Video Rendering
« Reply #56 on: January 02, 2015, 04:55:15 pm »
should have left things as they were dave, all you have done is create problems for yourself,
increased rendering time and bigger file sizes and such.
And there are people that cant watch 1080p60 anyway (like myself) as it just jerks and stutters,
and when i swap between 720p60 and 1080p60 i cant see any difference at all
(apart from the stuttering)

hope you get it sorted out without spending anymore money

 

Offline ovnr

  • Frequent Contributor
  • **
  • Posts: 658
  • Country: no
  • Lurker
Re: EEVblog #698 - GPU Video Rendering
« Reply #57 on: January 02, 2015, 04:57:01 pm »
PC gamers, at least, prefer higher frame rates to higher resolutions.

Some of them anyway; I decided I was happier with Nvidia's DSR rendering at ~4k and downsampling to 2560x1440 @ 30fps than 1080p @ 60fps.
 

Offline IanJ

  • Supporter
  • ****
  • Posts: 1580
  • Country: scotland
  • Full time EE biz & Youtuber
    • IanJohnston.com
Re: EEVblog #698 - GPU Video Rendering
« Reply #58 on: January 02, 2015, 06:23:29 pm »
and when i swap between 720p60 and 1080p60 i cant see any difference at all
(apart from the stuttering)

That's one reason why I mentioned it in my post below, but don't get me wrong......IMO it still needs some testing to see if 720p50/60 is acceptable, and/or whether 1080p50/60 is worth the extra time to encode. Personally, at the moment I don't watch YT vids full screen, so 1080 has no real advantage over 720, and I'd prefer the 50/60fps all day over 25/30.

https://www.eevblog.com/forum/blog/eevblog-698-gpu-video-rendering/msg579014/#msg579014

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 cmpxchg

  • Contributor
  • Posts: 13
  • Country: de
Re: EEVblog #698 - GPU Video Rendering
« Reply #59 on: January 02, 2015, 06:45:36 pm »
Frankly, it seems like we are missing the point here. Dave said that he does his actual encoding in Handbrake. So ideally, you would not want that Sony tool to do any *coding* whatsoever! Doing two separate lossy encoding steps is a no-no for quality, and as shown here, it hurts encoding time, too.

Is there a lossless codec available in Sony, ideally with no time-consuming compression at all? Sure, the resulting file will be massive, but that's only an intermediate step for Handbrake to work on. Then you have Sony do the *composition* and Handbrake do the *encoding*. These are separate processes. With a proper lossless codec on low compression, you'll probably be limited by hard disk throughput for encoding, so it'll be much faster than realtime.
 

Offline lightman

  • Newbie
  • Posts: 8
Re: EEVblog #698 - GPU Video Rendering
« Reply #60 on: January 02, 2015, 07:35:40 pm »
This thread is priceless, it has so much info!.

So far, in my experience encoding video (15 yrs), the most important thing are:
1- Number of CPU cores / Number of processors
2- L3 cache

Usually you will not notice much difference between i7 top of the line and Xeon processors.

I think the best thing you can do is to purchase a dual or quad processor eATX board, but not sure if there is such a solution for i7 , i used a couple of dual processor boards for AMD processors in the past.

I have a couple of servers here with single and dual xeons so I can do some tests if you like, they are not the most newer ones, but enough to see the difference between single and dual processor.

BTW: someone comment about the results of using mainconcepts encoder with cuda!, VERY interesting! I will test it as soon as I can free a maxwell card.
« Last Edit: January 02, 2015, 07:58:10 pm by lightman »
 

Offline rollatorwieltje

  • Supporter
  • ****
  • Posts: 571
  • Country: nl
  • I brick your boards.
Re: EEVblog #698 - GPU Video Rendering
« Reply #61 on: January 02, 2015, 08:00:53 pm »
Frankly, it seems like we are missing the point here. Dave said that he does his actual encoding in Handbrake. So ideally, you would not want that Sony tool to do any *coding* whatsoever! Doing two separate lossy encoding steps is a no-no for quality, and as shown here, it hurts encoding time, too.

Is there a lossless codec available in Sony, ideally with no time-consuming compression at all? Sure, the resulting file will be massive, but that's only an intermediate step for Handbrake to work on. Then you have Sony do the *composition* and Handbrake do the *encoding*. These are separate processes. With a proper lossless codec on low compression, you'll probably be limited by hard disk throughput for encoding, so it'll be much faster than realtime.
It can do lossless as in no compression at all, but it still takes quite long and the file will be like 12GB per minute or so (using Video for Windows -> create a lossless template). There doesn't seem to be some useful intermediate codec with at least a minimal amount of compression.

I don't get the extra Handbrake step either, but I have no real experience in this. Youtube accepts the output AVC from Movie Studio directly. If that file is too big, why not lower the bitrate in Movie Studio instead of compressing it again?
 

Offline Rutger

  • Regular Contributor
  • *
  • Posts: 210
  • Country: us
Re: EEVblog #698 - GPU Video Rendering
« Reply #62 on: January 02, 2015, 08:28:56 pm »
If you aren't using an SSD you are not going to be able to write at 25MB/s.
 

Offline Marco

  • Super Contributor
  • ***
  • Posts: 6694
  • Country: nl
Re: EEVblog #698 - GPU Video Rendering
« Reply #63 on: January 02, 2015, 08:43:43 pm »
By and large encoding is not an embarrassingly parallel problem ... everything is super-branchy and interconnected, not suited to GPUs at all. For a few limited parts of the encoder (motion estimation foremost) you could do a GPU version which eekes out a bit more compression, but that's about it.
 

Offline rollatorwieltje

  • Supporter
  • ****
  • Posts: 571
  • Country: nl
  • I brick your boards.
Re: EEVblog #698 - GPU Video Rendering
« Reply #64 on: January 02, 2015, 08:49:36 pm »
If you aren't using an SSD you are not going to be able to write at 25MB/s.

That would be quite a poor harddrive... Even to my NAS I can write with more than twice that speed.
It has a WD Green 2TB, not even a performance disk.
 

Offline mariush

  • Super Contributor
  • ***
  • Posts: 4983
  • Country: ro
  • .
Re: EEVblog #698 - GPU Video Rendering
« Reply #65 on: January 02, 2015, 08:51:03 pm »
My 4 TB Hitachi NAS series drive can do 80 MB/s sustained at any point on the surface... starts at around 160 MB/s and goes down as the heads move towards the other side of the platters. Saving videos encoded with lossless codecs like MagicYUV is really not a problem.

No need for a SSD unless you work with multiple video and audio tracks and you do a lot of cuts and add lots of effects/transitions

Dave only has one video track and his video consists mostly of sticking segments together and cutting out parts he doesn't want anymore.  So Sony software buffers a whole bunch of data from the input video file, then writes data from video codec to disc.
There's minimum read/write access so the negative points of regular hard drives (long access time, having to move heads between read and write operations) are not causing any issues here.

 

Offline Howardlong

  • Super Contributor
  • ***
  • Posts: 5315
  • Country: gb
Re: EEVblog #698 - GPU Video Rendering
« Reply #66 on: January 02, 2015, 10:24:35 pm »
Even five years ago when I last did HD video my sustained bulk (ie not cached) hard drive throughput was 80MB/s. Not sure where 25MB/s comes from, maybe an order or magnitude out?
« Last Edit: January 02, 2015, 11:39:07 pm by Howardlong »
 

Offline cmpxchg

  • Contributor
  • Posts: 13
  • Country: de
Re: EEVblog #698 - GPU Video Rendering
« Reply #67 on: January 02, 2015, 11:08:52 pm »
Frankly, it seems like we are missing the point here. Dave said that he does his actual encoding in Handbrake. So ideally, you would not want that Sony tool to do any *coding* whatsoever! Doing two separate lossy encoding steps is a no-no for quality, and as shown here, it hurts encoding time, too.

Is there a lossless codec available in Sony, ideally with no time-consuming compression at all? Sure, the resulting file will be massive, but that's only an intermediate step for Handbrake to work on. Then you have Sony do the *composition* and Handbrake do the *encoding*. These are separate processes. With a proper lossless codec on low compression, you'll probably be limited by hard disk throughput for encoding, so it'll be much faster than realtime.
It can do lossless as in no compression at all, but it still takes quite long and the file will be like 12GB per minute or so (using Video for Windows -> create a lossless template). There doesn't seem to be some useful intermediate codec with at least a minimal amount of compression.

I don't get the extra Handbrake step either, but I have no real experience in this. Youtube accepts the output AVC from Movie Studio directly. If that file is too big, why not lower the bitrate in Movie Studio instead of compressing it again?

At 12GiB/minute, Daves camera must be a real monster to sustain 200MiB/s and do all the video camera stuff simultaneously. You can of course do lossless and have compression; that's what WinRAR and ZIP are for, and I'm sure video codecs exist for "lossless, but compressed" too, there are certainly audio codecs for that. So the output size of such a codec would either be the same as the original camera data, and clearly the i7 has the camera beat on performance, or most likely, it would be considerably less as you can use the i7 to do compression.
 

Online EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37663
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #68 on: January 02, 2015, 11:25:59 pm »
Frankly, it seems like we are missing the point here. Dave said that he does his actual encoding in Handbrake. So ideally, you would not want that Sony tool to do any *coding* whatsoever! Doing two separate lossy encoding steps is a no-no for quality, and as shown here, it hurts encoding time, too.
Is there a lossless codec available in Sony, ideally with no time-consuming compression at all?

Not that supports 50/60fps that I am aware of. Unless there is a plugin one of some sort.
Yes, Sony is only used to produce an intermediate file that goes to Handbrake and is then deleted.
 

Online EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37663
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #69 on: January 02, 2015, 11:32:33 pm »
I don't get the extra Handbrake step either, but I have no real experience in this. Youtube accepts the output AVC from Movie Studio directly. If that file is too big, why not lower the bitrate in Movie Studio instead of compressing it again?

Because Handbrake (actually x264 codec, Handbrake is just the shell) is superb at what it does. It has a single pass "constant quality" mode that ensures optimal picture quality for every frame. Instead of picking a target bit rate you pick a target "quality" rate.
So no matter what type of video I produce, be it outdoors motion with tons of detail, a talking head, or a screen capture tutorial, Handbrake does the best job every time without me having to think about and dick around with it.
An outdoor motion video will be huge in file, and screen capture will be insanely small in size, all with the same consistent quality.
 

Online EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37663
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #70 on: January 02, 2015, 11:33:51 pm »
I think the best thing you can do is to purchase a dual or quad processor eATX board, but not sure if there is such a solution for i7 , i used a couple of dual processor boards for AMD processors in the past.

I thought only Xeon allowed multiple processors?
 

Offline wholder

  • Regular Contributor
  • *
  • Posts: 72
  • Country: us
    • Wayne's Tinkering Page
Re: EEVblog #698 - GPU Video Rendering
« Reply #71 on: January 02, 2015, 11:35:03 pm »
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
 

Online EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37663
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #72 on: January 02, 2015, 11:40:44 pm »
'Rendering' is the terminology used when you create animated overlays like tickerbars, greenscreen effects , crossfades etc. you don't seem to be doing any of that in your movies. Render operations are doing pixel operations for which the gpukicks in.
What you are doing is transcoding.

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.

Quote
Your camera films in format x. Your output is a different format ? What if you keep the format the same (input and output for,at identical) then the encoding only happens at the intersection of two clips. Most of the other data is simply copied over. Like merging two files.  There may be a tweak where you can tell the editing tool to adjust your cut points so they always coincide with an i frame. In that case there is no rendering involved at the handover point as a frame sequence always has to start with an i frame.

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

Quote
What other effects are you running ? Color correction ? Audio leveling ?

None. Just some fades, text and occasional dual video overlays.

Quote
The live video comes in as an uncompressed format so the computer does not have to waste time expanding the stream and then re compressing it. The datarates are not that high for a modern computer. Overlays (tickerbar etc )are run on the gpu. Assembling the output video is a chunk of or operations using masks take live feed, apply mask (set certain areas to black). Then take overlay anything that is not black in overlay gets copied over to anything that is black in stream. Done.
Very simp,e bitswap operations.

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.

Quote
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.

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.

Quote
My gut says the computer is spending al its time decoding/reencoding.

Of course it is.
 

Online EEVblogTopic starter

  • Administrator
  • *****
  • Posts: 37663
  • Country: au
    • EEVblog
Re: EEVblog #698 - GPU Video Rendering
« Reply #73 on: January 02, 2015, 11:44:40 pm »
I'm wondering if a bit of crowd sourcing could help, here.

I know the result. I'd end up with a 1000 different opinions on why their way/program is the best.

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.
I did try Frameserver at one point, which in theory is supposed to render the quickest because it's a raw output, but it was messy and didn't work right.
 

Offline warp_foo

  • Supporter
  • ****
  • Posts: 117
  • Country: us
Re: EEVblog #698 - GPU Video Rendering
« Reply #74 on: January 03, 2015, 12:02:12 am »
I have had similar issues with NVidia GTX-970 card and several pieces of software not seeing CUDA as available. An interesting bit of information, which might possibly be gleaned from the DVDFAB DeCrypter forums: it was suggested that the new Maxwell architecture used in the current NVidia products also came with a change in the driver architecture. It was suggested that after some rewriting, CUDA can again be used. The people at DVDFab have said that in current versions they do support the newest NVidia chipsets. Unfortuantly for other reasons, I have not been able to test this statement, but my take away, is that if you are willing to wait, perhaps for quite a long time (based on the face that Maxwell GPUs were relased in the GTX 870 and 880 as well), the newer chips will be supported.

If the above is correct - Maxwell architecture impacts CUDA processing - if possible, try borrowing a GTX 770. It's a Kepler based GPU.

m

ETA: If you want to, that is.  :)
« Last Edit: January 03, 2015, 12:05:16 am by warp_foo »
Where are we going, and why are we in a handbasket?
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf