video encoder usage 2015

[stax76]

What's your primary video encoder this year?

[feisty2]

FFMPEG (uncompressed raw video)
ImageMagick (uncompressed CIE Lab TIFF sequence)

[Sparktank]

NVidia and Intel requires more clarity.

I know Nvidia has their encoders (and variants).
The only Intel encoders I know are the standard, unoptimized builds from their SDK.

I don't use GUI's or anything. It's all scripts.
I don't know what GUI's use when they limit to only Intel and not Nvidia.

But, I use x264 8bit but Komisar's builds. (kMod)
With --opencl on Nvidia.

[Asmodian]

x264 10-bit for me. :)

I target PC only encodes at bitrates that are transparent compared to the bluray.

[stax76]

NVidia and Intel requires more clarity.

I know Nvidia has their encoders (and variants).
The only Intel encoders I know are the standard, unoptimized builds from their SDK.

I don't use GUI's or anything. It's all scripts.
I don't know what GUI's use when they limit to only Intel and not Nvidia.

But, I use x264 8bit but Komisar's builds. (kMod)
With --opencl on Nvidia.

There is currently a lot interest in hardware encoding and there are people (me included) that believe hardware decoding and encoding will get much more popular. x265 is slow and blurry, 4K is very hard to decode and encode, GTX 960 already does H265 encoding but the quality isn't very good, Intel's Skylake platform released later this year should have a better H265 encoder.

Tools I know for decoding:


DirectShowSource with LAV filters using either DXVA copy back, Intel Quick Sync or NVIDIA CUVID, this can work well and people actually use it
DGDecNV and DGDecIM, I've very good experience with DGDecNV so absolutely recommend it, especially dealing with TS


For encoding there are two solid CLI tools from a Japanese programmer called rigaya, NVEncC and QSEncC:


StaxRip has a GUI for both (Nikos D was and still is a great help improving everything hardware related in StaxRip)
Selur's Hybrid also supports both (long before StaxRip I believe)
Handbrake has a own Intel Quick Sync implementation


DGDecNV and QSEncC can also resize and deinterlace with hardware.

While hardware encoding has still room for quality improvements it's worth to test it just like x265, in StaxRip there is currently a codec comparison tool in development, the latest beta is the first release that includes it.

[Kurtnoise]

There is currently a lot interest in hardware encoding and there are people (me included) that believe hardware decoding and encoding will get much more popular.
Any proof of that ?

[detmek]

I use x264 8bit for hardware compatibility. And because my encodings are done in 480p or 720p resolution x265 does not give me much improvement while I lose compatibility and encoding speed.

I testet Intel's QS encoder in VidCoder last year but i wasn't impressed with quality. Though, speed was amazing as I have dual core Pentium.

In a following days I will test StaxRip version as it seams it has more options to tweak, presets to choose. Maybe I can get a bit more quality compared to VidCoder/Handbrake. With x264 I use --preset medium --crf 18 to 20 --me umh --badapt 2 --direct auto --deblock -1:-1.

[stax76]

Any proof of that ?

You can find proof at doom9 and videohelp forums if you watch out, working on StaxRip anything hardware related is taken absolutely serious, 64-Bit StaxRip starts with the next release.

[huhn]

You can find proof at doom9 and videohelp forums if you watch out, working on StaxRip anything hardware related is taken absolutely serious, 64-Bit StaxRip starts with the next release.

HEVC 8/10 bit and AVC 10/8 bit is already tehre so noone is asking about these encoder leaving only stuff that doesn't really exist yet. the hardware encoder.

that doesn't mean it is popular...

[stax76]

I didn't say that it is popular, I said that there are people that believe it will get much more popular and that there is a lot interest currently which I judge from StaxRip feedback I get in forums and mail and from topics on other hardware related tools.

[NikosD]

HW encoding of H.264 on Intel Haswell is a great experience for 8bit clips.

It's not only extremely fast, but with great quality too using some of the latest encoding modes like ICQ or LA-ICQ.

I'm about to do an exhaustive test on various HW encoding modes of Haswell's QuickSync probably vs x264.

[Motenai Yoda]

actually x264-8bit and few things with x265-8bit, at least until hevc 10bit hw decoding will widespread.

[Kurtnoise]

You can find proof at doom9 and videohelp forums if you watch out, working on StaxRip anything hardware related is taken absolutely serious, 64-Bit StaxRip starts with the next release.
have a look at your poll result and tell me what do you see...

Hardware decoding is much more useful imo.

[stax76]

It's not looking good for HW encoding and x265 did also very poor, there is still interest for both. It would be very interesting to see a comparison between x264, x265 and Quick Sync on Haswell, unfortunately I don't have Haswell, I wait for Skylake.

[huhn]

It's not looking good for HW encoding and x265 did also very poor, there is still interest for both. It would be very interesting to see a comparison between x264, x265 and Quick Sync on Haswell, unfortunately I don't have Haswell, I wait for Skylake.

i ivy, haswell, nvenc (kampler) and AMD VCE 1.0 access here.

and i did some pretty bad comparison using OBS here on the forum.

you can leave IVY out of the comparison it's so so bad.

[NikosD]

SW encoding of H.265 is painfully slow.

If Skylake has fast and in good quality HW encoding of H.265, you will see the popularity of HW encoding rising a lot.

Because for H.264 HW encoding Intel made a lot of mistakes in the beginning.

[nevcairiel]

Unfortunately, none of the HW encoders available to consumers can even come close to the quality of x264. They are faster, and at matched speed (ie. x264 at ultrafast) may even match x264 in quality, but if you want higher quality, you can just make x264 run slower and get much better quality - an option the HW encoders do not have.
IMHO, HW encoders are fine for streaming purposes, ie. real-time encoding for streaming to a mobile device or your TV for example, but encoding something for storage purposes, I will strongly favor the increased quality of x264 in a slower/higher quality preset.

I don't expect this to be different for HEVC/H.265.

[NikosD]

With a little higher bitrate than x264, Haswell can do HW encoding in a quality that can not be easily distinguished by SW encoding and a lot faster.

[Atak_Snajpera]

Define 'a little bit higher bitrate' ? 10%,20% or more?

[huhn]

does these HW encoder have something like CRF?
speed is so unimportant for encoding...

the most advanced encoder here are limited by avisynth/vapoursynth not the encode it self.

even for live streaming using OBS i can use preset medium that's very hard to beat for HW encoder.

[NikosD]

About bitrate I couldn't say exactly because of two reasons:

a) It obviously depends on the source
b) I'm not an expert on encoding and especially SW encoding I only use presets of x264/x265.

The comparison may not be fair.

The ICQ encoding mode is like CRF and speed always play a significant role.

I read about 1 or 2 days encodings of SW H.265 and I think someone is joking, but unfortunately they don't.
They mean it literally that they leave their PCs for 2 days for encoding using 100% CPU and not doing anything else.

Because one more important parameter for me, is the ability of HW encoding to let you do other things with your CPU at the same time.

[huhn]

if someone is willing to spend 2 days encoding they want quality so an HW encoder is no option for this person. the person could have taken x264 but he didn't so there is a reason he needs the extra compression ability from x265. so where does a HW encoder help in this case?
and there is still the possibility the filter where the issue not the encode it self.

if you just want to convert a video fast in something that runs on any other device than there is nothing wrong with using HW encoder but if you want quality a HW encoder is simply not the best way.

[stax76]

extra compression ability from x265

Are you sure this isn't a myth?

[huhn]

Are you sure this isn't a myth?

not anymore. was only a question of time anyway.

[stax76]

not anymore. was only a question of time anyway.

Can you give a few numbers like image size, bitrate and compression ratio, the difference I saw in my recent comparison wasn't in favor of x265, I used 1920x1080 at 1000 Kbps.

[huhn]

i follow like you this thread: http://forum.doom9.org/showthread.php?t=170986

and i saw your post about 720p too:
http://forum.doom9.org/showthread.php?t=170986&page=9
and can't disagree. x264 wins in this test clearly all other encodes doesn't have a proper door.

but there are no settings and stuff like this.

in general x265 does pretty well for high resolutions. the last huge problem is or was grain.

[Atak_Snajpera]

About bitrate I couldn't say exactly because of two reasons:

a) It obviously depends on the source
b) I'm not an expert on encoding and especially SW encoding I only use presets of x264/x265.


So your a "little bit higher" may end up even at 50%. Another question. How good are AQ and Psy algos in those hardware encoders? Do they even exist there?

[NikosD]

So your a "little bit higher" may end up even at 50%.


No it can't.


Another question. How good are AQ and Psy algos in those hardware encoders? Do they even exist there?

Most of the tests I have seen are using "objective" metrics.

Take a look with a Google search to missingremote.com and q264 HW encoder site they have both x264 vs HW Haswell encoding tests.

[Atak_Snajpera]

No it can't.
Even in parkjoy sample or any other extreme case?

[huhn]

Most of the tests I have seen are using "objective" metrics.

and it's a fact that encodes without aiming at these "objective" metrics results in visible better results.

so if you do test post the clips and screens so people can argue over it.

better SSIM or PSNR is pretty much worthless.

[foxyshadis]

does these HW encoder have something like CRF?
speed is so unimportant for encoding...

the most advanced encoder here are limited by avisynth/vapoursynth not the encode it self.

even for live streaming using OBS i can use preset medium that's very hard to beat for HW encoder.

if you just want to convert a video fast in something that runs on any other device than there is nothing wrong with using HW encoder but if you want quality a HW encoder is simply not the best way.

That's getting less true with every hardware & driver generation. NVidia ShadowPlay has a way to go, though it's getting better, but Quicksync is quite good quality while allowing you to encode & play together. Hardware encoding basically enables an entirely new level of streaming that simply wasn't ever available to most people before; you used to need a separate encoding box just to stream in HD. If all you want is SD, software works fine.

[huhn]

nothing wrong with using it for real time situation but still. is it better than faster x264?

of course if you can't use your CPU for it you can use something like this.

nvenc and haswell are definitely not bad for 3000-3500 kbit CBR encodes for 720p30 720p60 and maybe even 1080p60 if the game isn't to demanding.

i don't say there are totally useless but for storage encoding i highly prefer quality encodes.

[NikosD]

You can't put in the same sentence, NVenc and Haswell's QuickSync.

The differences in quality are huge.

Nvidia's encoding quality is on par with Sandy/ Ivybridge.

The encoding modes of Haswell are more than 10, they are not limited to CBR, VBR, AVBR, CQP like Nvidia and Sandy/Ivybridge.

I have already replied above that supports Look-ahead (LA) and even a CRF-like mode called ICQ.

[huhn]

NVenc counts as one of the better ones in the OBS forum.
it can even record in 4:4:4

i used the 1.0 SDK back in the time it has a hole setting file to play around.
and i don't know if it is still ok. but when i compared it to my i7 3770k it clearly won.