nvenc - official nvidia kepler hardware h264 encoder

[zn]

NVIDIA Releases the 301.10 WHQL Driver for the GeForce GTX 680, with support of new technology :

NVIDIA NVENC Support - adds support for the new hardware-based H.264 video encoder in GeForce GTX 680, providing up to 4x faster encoding performance while consuming less power.

[Selur]

Encoding doesn't have to get faster on gpus it has to get better quality,...

[cengizhan]

Encoding doesn't have to get faster on gpus it has to get better quality,...

which we didn't see in any of supported gpus like ati and nvidia. ati has very bad encoding quality. there is no benefit if the quality can't be compared with x264.

[mandarinka]

It also needs to consume much less power than the old shader-based stuff did, while the same utilising cpu.
And that is what these fixed-function blocks should be good at, hence all three players implementing them. BTW I've read somewhere that the VGA guys also need fast and efficient encoders for purposes of wireless display connection technology, since it might need compression at least for higher resolutions and refresh rates. (Dunno if it is just a BS or actual fact.)

[hajj_3]

info from nvidia's website:

NVENC
All Kepler GPUs also incorporate a new hardware-based H.264 video encoder, NVENC.
Prior to the introduction of Kepler, video encoding on previous GeForce products was handled by
encode software running on the GPU’s array of CUDA Cores. While the CUDA Cores were able to deliver
tremendous performance speedups compared to CPU-based encoding, one downside of using these
high-speed processor cores to process video encoding was increased power consumption.
By using specialized circuitry for H.264 encoding, the NVENC hardware encoder in Kepler is almost four
times faster than our previous CUDA-based encoder while consuming much less power.

It is important to note that an application can choose to encode using both NVENC hardware and
NVIDIA’s legacy CUDA encoder in parallel, without negatively affecting each other. However, some video
pre-processing algorithms may require CUDA, and this will result in reduced performance from the
CUDA encoder since the available CUDA Cores will be shared by the encoder and pre-processor.
NVENC provides the following:


[Can encode full HD resolution (1080p) videos up to 8x faster than real-time. For example, in high
performance mode, encoding of a 16 minute long 1080p, 30 fps video will take approximately 2
minutes.]

Support for H.264 Base, Main, and High Profile Level 4.1 (same as Blu-ray standard)

Supports MVC (Multiview Video Coding) for stereoscopic video—an extension of H.264 which is
used for Blu-ray 3D.

Up to 4096x4096 encode

We currently expose NVENC through proprietary APIs, and provide an SDK for development using
NVENC. Later this year, CUDA developers will also be able to use the high performance NVENC video
encoder. For example, you could use the compute engines for video pre-processing and then do the
actual H.264 encoding in NVENC. Alternatively, you can choose to improve overall video encoding
performance by running simultaneous parallel encoders in CUDA and NVENC, without affecting each
other’s performance.

NVENC enables a wide range of new use cases for consumers:

HD videoconferencing on mainstream notebooks

Sending the contents of the desktop to the big screen TV (gaming, video) through a wireless
connection

Authoring high quality Blu-ray discs from your HD camcorder

A beta version of Cyberlink MediaEspresso with NVENC support is now available on the GeForce GTX
680 press FTP. Support will be coming soon for Cyberlink PowerDirector and Arcsoft MediaConverter.

source: page 26 of: http://www.geforce.com/Active/en_US/en_US/pdf/GeForce-GTX-680-Whitepaper-FINAL.pdf

[Ranguvar]

This is more interesting than most GPU encoders, because it's an actual hardware chip on the GTX 680 dedicated to H.264 encoding.

[benwaggoner]

And speed versus quality can each be a fixed variable in comparisons. So one interesting question is "how does speed compare when x264 is run at settings that produce equivalent quality?"

HW can get interesting when it can be faster than even the lowest quality software settings. It can also be interesting where it doesn't use resources that can be spent on other bottlenecks, like source decode or preprocessing.

Also, fewer joules-per-minute or lower TCO-per-minute can matter for high volume facilities.

I'm joining the Amazon.com video tram as a encoding quality and workflow guru starting Monday, so these questions have rather been on my mind :)...

[zn]

Guru3D: Geforce GTX 680 review: NVENC (http://www.guru3d.com/article/geforce-gtx-680-review/6)

not interesting , but there will more article about nvenc later

[hajj_3]

yeah, having dedicated hardware in the gpu is a nice addition, hope the x264 devs add support for hardware encoding at some point in the near future. It would be nice if google hired some coders to add this support, i'm sure they would save money on encoding their youtube videos if they had a low end gpu hardware encoding some of it.

[Didée]

We'll see at some time how it fares. When the hero/ine is scrambling some dark dungeons, and you cannot reckognize anything since all is just floating mush, then speed & power savings don't count much.

[zn]

if someone who bought GTX 680 want to do nvenc test and didn't know where to get sw - send pm to me

[CruNcher]

This is more interesting than most GPU encoders, because it's an actual hardware chip on the GTX 680 dedicated to H.264 encoding.

Intel also said this still some stuff (ME) is being done on the EUs, i see those chips more as hybrids, though well see if Nvidias is also a Hybrid or a real independent Asic ;)

http://www.tomshardware.com/reviews/geforce-gtx-680-review-benchmark,3161-16.html

also this is most interesting in this Mpeg-2 test the old GTX 580 cuda cores could beat the GTX 680 encoder very strange this let me believe the Mpeg-2 Cuda fix was setting in here which was introduced to avoid a design bug in the VP4 decoder so the Mpeg-2 decoding get relayed to the CUDA cores not the DSP, though Tomshardware doesn't know that, so they must have forgotten to disable that for the VP5 decoder in the GTX 680 ;) ;)

Though most impressive for me personaly is this http://www.guru3d.com/article/geforce-gtx-680-review/4 and ill wait for a version with 1 Pin :D replacing my 2 Pin 460 GTX ;)

[zn]

laptop models also have this feature

additional h264 silicon on laptops - looks strange

[hajj_3]

many of the 600 series mobile gpu's are rebranded 500 series fermi gpu's btw, only a few will be kepler, newer models with kelper will come later: http://fudzilla.com/home/item/26501-most-geforce-600-mobile-gpus-are-still-fermi

not sure about the desktop gpu's, wouldn't mind knowing though.

[CruNcher]

zn you can have 4 H.264 decoder on Desktop/laptops internally if you want these days and the same for Encoder

1 via internal/external solutions like a Broadcom Decoder (a Spurs Encoding/Decoding card)
1 via the CPU/GPU Intel/AMD
1 via the discrete GFX AMD/Nvidia :P
1 solely on the CPU (though you have to understand how the other stuff needs cpu time when and why,to efficiently utilize it together)

plenty of crazy stuff doable with this power and Nvidia as they claim you can even use the Cuda Cores and the DSP simultaneously or if you clever enough pair the Encoders (Multithread) ;)

It's crazy to think about which workflows even on consumer systems this makes possible (Realtime) (some of those i already evaluate since some time now SB)

you can mix them in very different ways together though it's not easy to keep track of the impacts to balance it out efficiently and integrate into a Realtime workflow (you also have to take the OS into account) :D

[kieranrk]

I'm joining the Amazon.com video tram as a encoding quality and workflow guru starting Monday, so these questions have rather been on my mind :)...

Good luck with your new job. It sounds very interesting.

[CruNcher]

@ benwaggoner
oh you left/leaving Microsoft ?

[hajj_3]

maybe it is because silverlight is no more, i can't see them making a silverlight 6 due to HTML5 adding so many features that are in silverlight/flash.

[CruNcher]

still from the DRM point of view its not mature enough newest test versions of Flash even starting to avoid screen capturing now, its player surface it will just crash the flash player in browser trying to capture it, and this is generally no support problem neither anymore as the whole browser wont crash only the current player instance on the page you reload it it will work again though if you try to capture it it will crash and so on ;)

[iwod]

Encoding doesn't have to get faster on gpus it has to get better quality,...

One thing is that we could transcode High Def 1080P video to Mobile devices Real Time. In this usage scorner, ( which should be more popular later ) the faster the better.

It looks like it is 30% faster then Intel QuickSync. But Intel also promise much faster Encoding with QuickSync 2.0 in Ivy Bridge.

Let see which one is better for hardware encoding.

[hajj_3]

i wonder what difference the speed of the nvidia gpu will have on the encoding speed, maybe if intel's gpu was as fast as nvidias it could possibly be faster than the 680 at encoding?

[CruNcher]

Intels GPU is nice if they would pack some more cores or make a discrete card (wee need more then ivybridge) it would be interesting :)
the Intel Encoder still utilizes the EUs @ least on SB not sure how it will be for IB but i think not much will change here and the speedups come from other things (more EUs,Clocks) for the Motion Estimation so you have a slowing down effect their.
Im trying currently to get this as a Quicksync Result http://blip.tv/file/get/Cr4bl3r-intelhdrecordingtestx264tuned349.mp4 this is the x264 result not bad for a Intel IGP (GT1 @ stock) the record overhead is very minimal so only 1 or 2 fps get lost overall :)

[Ranguvar]

also this is most interesting in this Mpeg-2 test the old GTX 580 cuda cores could beat the GTX 680 encoder very strange this let me believe the Mpeg-2 Cuda fix was setting in here which was introduced to avoid a design bug in the VP4 decoder so the Mpeg-2 decoding get relayed to the CUDA cores not the DSP, though Tomshardware doesn't know that, so they must have forgotten to disable that for the VP5 decoder in the GTX 680 ;) ;)
It's possible, but remember that in general compute, the GTX 680 is worse than the GTX 580.

Though most impressive for me personaly is this http://www.guru3d.com/article/geforce-gtx-680-review/4 and ill wait for a version with 1 Pin :D replacing my 2 Pin 460 GTX ;)

Just ordered a GTX 680 myself, also upgrading from a 460. This will be fun.

[mandarinka]

I think it is only worse at compute if you use double-precission floats. The performance at single-precission should be increased.

[CruNcher]

That's a Nvidia thing since introduction of the Tesla Series they keep it that way, also it could be that the Performance isn't lower but a restriction either in the Firmware or on the Driver level makes it artificially slower (it is really common these days to build blocks either into the Firmware or inside the Software above (Driver), much easier to handle and create different Product lines, without needing to produce different Hardware) ;)
In earlier days you could lift these restrictions easily but be sure Nvidia learned from these System mistakes and Identification stuff becomes better, these applies to the whole usage of such artificial restrictions they also evolve with every brake, for the easy shader activation brakes (just replace the Bios with a different one) they decided to go back to the Hardware part and fix it with laser cutting the unused (or damaged) Shader impossible in the end (though it's easier todo even for multiple lines of Hardware just drive the chip to another line and cut it to what you want to be the end result) to circumvent in anyway ;)

Another good example would be Intels advancements here restricting overclocking and introducing the upgrade ability of CPUs with features with just a Code (still more a research thing then wildly used, good or bad you decide it in the end it has many cons) :)
Though i find it funny that people yet doesn't understood that overclocking is dead and it's part of every product now and that especially the younger generation really let themselves be fooled with this, it's not anymore what it used to be in my days :)

Since Software introduced the Multiple modular version system (develop the application with full features in the first place and then just leave features away and decide how to call the product that's now restricted differently, compared to the all feature version and set a different Price for it) Hardware manufactures saw the same possibility how to make use of that for their Purposes :)

Btw these system even found it's way to Games in the End (DLCs) not every DLC though is developed this way but allot are, though instead of paying a lower price you pay a upgrade price ;)
Mass Effect 3 really showed how you use this System efficiently for maximum profits :)

As Bill Gates Envisioned it everything becomes Software driven and use the same principles, though it's easy to Envision such things if you just walk into the Microsoft Research part and see how people their create such things "I have to tell you something i saw the future" is easy then and always was for him on Stage ;)

[Ranguvar]

I think it is only worse at compute if you use double-precission floats. The performance at single-precission should be increased.

Single precision is fine, yes.
http://www.brightsideofnews.com/news/2012/3/22/nvidia-gtx-680-reviewed-a-new-hope.aspx?pageid=4

My GTX 680 just arrived... fun stuff. Tweaking overclocks now. Just need to find a way to test NVENC and then I'll compare it to x264.

EDIT: Was just supplied with an NVENC-enabled build of MediaEspresso, I'll do a 'formal' test if I can get time.
EDIT 2: Not sure this is worth doing, at least at this stage -- MediaEspresso is restricted to Baseline@4.0, 25fps (with 50fps source), and CBR.
No way of seeing if these are limitations of the software, or of NVENC.
parkjoy is encoded in about 5 seconds (from a 50Mbps H.264 encode of the original so ME could read it), so twice realtime for that, which x264 can easily match.

[Mixer73]

EDIT 2: Not sure this is worth doing, at least at this stage -- MediaEspresso is restricted to Baseline@4.0, 25fps, and CBR.

Not at all surprising for a hardware encoder to be limited to CBR.

[Atak_Snajpera]

lol and no cabac obviously. typical.

[Ranguvar]

Not at all surprising for a hardware encoder to be limited to CBR.

Ah, I'm not well familiar with hardware encoders. Doesn't that pretty much destroy any chance of it even competing with x264 though?

[Dark Eiri]

I remember when I used to get super excited when those GPU H264 encoders were announced or released.
Now I just sigh.

[hajj_3]

I remember when I used to get super excited when those GPU H264 encoders were announced or released.
Now I just sigh.

why sigh, they are still great! It would be nice if x264 added support for GPU decoding then it would become amazing.

[Atak_Snajpera]

why sigh, they are still great! It would be nice if x264 added support for GPU decoding then it would become amazing.
GPU encoders still suck. Baseline profile? is this a joke? With x264 we have even access to 10bit 4:4:4. GPU encoding in x264 will probably be never implemented. To much work. VP9 is supposed to be more OpenCL friendly.

[Audionut]

GPU encoders still suck. Baseline profile? is this a joke? With x264 we have even access to 10bit 4:4:4. GPU encoding in x264 will probably be never implemented. To much work. VP9 is supposed to be more OpenCL friendly.

That's nice. But it's got nothing to do with GPU decoding support.

[Ranguvar]

x264 does have GPU decoding support.
It's called AviSynth input, where you can use whatever decoder tickles your fancy :p
Would be nice, but not high priority because of the above working solution, I assume.

[Atak_Snajpera]

indeed for decoding we have nvidia cards and quicksync from intel.

[itou]

Hello all,
I use vegas pro 11 and would like some GPU acceleration, I have to choose the 580GTX or the 670GTX for nearly the same price (+ 5% for the 670). If Vegas pro will implement the new API NVENC, I think that could be a big advantage over the 580gtx on encoding process.
But on workflow editing and preview, anyone could tell me if the 670 is better than the 580 ?
Thanks
(a trial version of vegas pro 11 is available at sony website).

[SubOne]

There's also VCE for AMD, but for whatever reason they haven't released working drivers yet, even though 7000 series has been 5 months on the market!

[littleD]

There is written in Release Notes (http://developer.amd.com/sdks/AMDAPPSDK/assets/AMD_APP_SDK_Release_Notes_Developer.pdf) of AMD APP SDK 2.7:
Additional features supported in SDK 2.7 and the Catalyst 12.4 drivers include:
• Video encode using VCE Encode (Win7)
• Open Encode update (12.4)

Looks like it is supported, It may be new MFT AMD Encoder? Wonder what is Open Encode, similar to OpenCLDecode?

[zn]

new article with nvenc testing:

http://www.hardware.fr/focus/imprimer/67/

funny thing - at first they published article with results from MediaEspresso in CUDA mode, now it is updated with nvenc mode results

[MOS-Marauder]

Some more Informations...

https://developer.nvidia.com/sites/default/files/akamai/cuda/files/CUDADownloads/NVENC_DA-06209-001_v02.pdf

Mara

[Blue_MiSfit]

Elemental's professional stuff is quite impressive, and they use nVidia GPUs on CentOS Linux. So, good quality H.264 (and MPEG-2, ProRes, and VC-1) encoding on GPUs is certainly possible.

[Filker]

There is written in Release Notes (http://developer.amd.com/sdks/AMDAPPSDK/assets/AMD_APP_SDK_Release_Notes_Developer.pdf) of AMD APP SDK 2.7:
Additional features supported in SDK 2.7 and the Catalyst 12.4 drivers include:
• Video encode using VCE Encode (Win7)
• Open Encode update (12.4)

Looks like it is supported, It may be new MFT AMD Encoder? Wonder what is Open Encode, similar to OpenCLDecode?

"Open Video Decode

This sample uses the new Open Video Decode API to read in compressed H.264 and MPEG2 elementary stream frames of video (provided) and decodes and displays them. Gaussian Blur Filter has also been implemented as a post-processing step before displaying."

http://devgurus.amd.com/thread/159235

http://developer.amd.com/tools/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/samples-demos/

"Open Video Encode

The OpenVideo Encode library provides an OpenCL API that leverages the video compression engine (VCE) on AMD platforms for H.264 encoding. This sample illustrates the use of the OpenVideo Encode library to encode video in the H.264 format. The sample takes a YUV file as input, encodes it using the OpenVideo Encode library and then saves the compressed elementary stream to disk."

http://developer.amd.com/wordpress/media/files/openEncode.zip

[Selur]

btw. is there a freely available command line encoder which uses nvenc out there?

[colinhunt]

Reviving a year-old thread for a moment... I've just tested an NVENC plug-in which works in Adobe Premiere CS6/CC and Adobe Media Encoder CS6/CC.

Installed the plug-in to AME CC, and disabled CUDA acceleration in AME so it uses NVENC only. Fed AME a 118 GB ProRes file (runtime 96 minutes) which was used for a Blu-ray master, tweaked NVENC parameters a bit and set it to work on a 1080p AVC output.

Encoding rig is Windows 7 64bit with a i7-3820 CPU and a GeForce GTX 760 GPU. Encoding was done as a single pass VBR with maximum bitrate set to 28mbps and target set to 20mbps. During the process CPU load bounced around 30%, GPU load at 4-5% and GPU's VE load at 40%.

The job was completed in 46 minutes. IQ wise the result looks more than passable, although it must be said the source was shot on Arri Alexa and is generally quite low on sensor noise. That said, I noticed the image jerks slightly every now and then, which is not in the ProRes master file. Frame rate conversion was not done so it's not the culprit. The fault may lie with PowerDVD 13 which seems to be the only player on my PC capable of playing this unmuxed, raw .m4v file.