q264 - an AVC encoder using Intel® Quick Sync Video

[Kurtnoise]

q264 is a Windows command-line program that uses Intel® Quick Sync Video hardware to encode video using the H.264 (AVC) encoding algorithm.

Features

The following are primary features of q264:
Very fast H.264 encoding using Intel® Quick Sync hardware.
Relatively low CPU load during encoding.
Reads .avi, .avs (avisynth.org), raw NV12 and YV12 files, .m2v, .mkv, .mp4, .m2ts, and many more formats.
Supports the following input color formats: RGB24 (RGB3), RGB32 (RGB4), NV12, YV12, I420, YUY2, and YUV422P.
Lets you control the low level Quick Sync parameters for flexible encoding.
This uses the FFmpeg libraries (libavformat, libavcodec, etc) under the LGPLv2.1 to read non-raw input files. FFmpeg supports a very large number of input file formats, and relatively few have been tested in q264, so they may or may not work. See ffmpeg.org for more information about the FFmpeg project.


Platform Requirements
q264 is a command line program built with the Intel® Media SDK to use the special Quick Sync hardware built into newer Intel® CPUs. Only 2nd and later generation Intel® Core architecture microprocessors (Sandy Bridge, Ivy Bridge, and Haswell) have this capability. See the Wikipedia article (http://en.wikipedia.org/wiki/Core_architecture) and the Intel® web site (http://www.intel.com/) for more information.


http://www.tetrachromesoftware.com/

http://www.tetrachromesoftware.com/Help/q264-0.4.3-full-help.html

not tried yet...

[benwaggoner]

This is probably a better link to show which processors have the required GPU level.

http://en.wikipedia.org/wiki/Intel_HD_and_Iris_Graphics

The lookahead requires at least Haswell. Which is annoying, as the readily available dual-socket workstations ideal for software encoding are still Ivy Bridge. I don't actually have any computers to run an complete speed/quality test on. I'd love to see what the quality and speed in its highest quality mode would be v. x264. It's probably most interesting for laptop use.

Anyway, it looks interesting. Trellis, a CRF equivalent, lookahead. Scene cut reducing encoding speed by 50% at 1080p is pretty striking. It'd be nice if there was a min GOP size parameter.

[NikosD]

q264 is an interesting app, as I have written elsewhere in Doom9, but QSVEncC is still the most advanced QuickSync encoder out there.

It's included in transcoding apps like Hybrid and StaxRip.

You can get it also from here:
http://rigaya34589.blog135.fc2.com/blog-category-10.html

[iSunrise]

...I'd love to see what the quality and speed in its highest quality mode would be v. x264. It's probably most interesting for laptop use.
Same here. Unfortunately there doesn't seem to be anyone interested with capable HW to compare it to x264. StaxRip is great for it, since it also has a great comparator tool included.

I would especially be interested in a comparison with several bitrates, like 5mbit, 10mbit and 20mbit for use with a live-transcoding application (which can read every input container/format/codec).

Unfortunately, I currently lack the necessary HW or I would do it myself.

[benwaggoner]

Well, my 2012 MacBook Pro's GPU has just started causing GPU panics, so It's time for me to get some new hardware anyway. I need to get a system that can play out UHD anyway.


-Ben Waggoner (via TapaTalk)

[vivan]

On i5-4670K (no OC):
q264 -i crowd_run_1080p.y4m -o q264_36.h264 -u 1 -la 100 -icq 36
22 FPS 18896 kbps
x264 crowd_run_1080p.y4m --preset medium --crf 25.1 -o x264_251.mp4
23.93 fps, 18719.52 kb/s

http://s23.postimg.org/g41t2xqex/q264_36_h264_snapshot_00_02_2015_04_26_00_45_34.png
http://s3.postimg.org/t0xki4xk1/x264_251_mp4_snapshot_00_02_2015_04_26_00_54_38.png
http://s23.postimg.org/vo96th0jd/crowd_run_1080p_y4m_snapshot_00_02_2015_04_26_0.png

q264 http://rghost.ru/private/6HTG7Dbmn/219d44e80df8535dcb9d8ea4c8731eb2
x264 http://rghost.ru/private/87B9yMCPD/40da3d3a4da58d4b39ffb5a16621dde8

Slower and worse than --preset medium. With better cpu you could even go with --preset slow at this speed.

q264 20.2 FPS 38393 kbps
http://rghost.ru/private/7vFmnLb6l/c57274f24bdaed46deefa0ce134a68b4

x264 19.58 fps, 38564.22 kb/s
http://rghost.ru/private/6Kmrdsygz/4710622b51722fffc68d2abca2cae27d
http://rghost.ru/private/7tRLwJ5Rj/dad6aedd27846838310753a69cd2d200
(sorry for 2 parts, it just refuses to store it for some reason).

I would especially be interested in a comparison with several bitrates, like 5mbit, 10mbit and 20mbit for use with a live-transcoding application (which can read every input container/format/codec).

Unfortunately, I currently lack the necessary HW or I would do it myself.Want me to encode something different?

[Nevilne]

http://www.tetrachromesoftware.com/q264Test1Analysis/q264test_1.html

[aegisofrime]

On i5-4670K (no OC):
q264 -i crowd_run_1080p.y4m -o q264_36.h264 -u 1 -la 100 -icq 36
22 FPS 18896 kbps
x264 crowd_run_1080p.y4m --preset medium --crf 25.1 -o x264_251.mp4
23.93 fps, 18719.52 kb/s

http://s23.postimg.org/g41t2xqex/q264_36_h264_snapshot_00_02_2015_04_26_00_45_34.png
http://s3.postimg.org/t0xki4xk1/x264_251_mp4_snapshot_00_02_2015_04_26_00_54_38.png
http://s23.postimg.org/vo96th0jd/crowd_run_1080p_y4m_snapshot_00_02_2015_04_26_0.png

q264 http://rghost.ru/private/6HTG7Dbmn/219d44e80df8535dcb9d8ea4c8731eb2
x264 http://rghost.ru/private/87B9yMCPD/40da3d3a4da58d4b39ffb5a16621dde8

Slower and worse than --preset medium. With better cpu you could even go with --preset slow at this speed.

q264 20.2 FPS 38393 kbps
http://rghost.ru/private/7vFmnLb6l/c57274f24bdaed46deefa0ce134a68b4

x264 19.58 fps, 38564.22 kb/s
http://rghost.ru/private/6Kmrdsygz/4710622b51722fffc68d2abca2cae27d
http://rghost.ru/private/7tRLwJ5Rj/dad6aedd27846838310753a69cd2d200
(sorry for 2 parts, it just refuses to store it for some reason).

Want me to encode something different?

Looking at the speed of your q264 encode I wonder if it's running in software mode. On QSVEnc (different software I know, but in theory they are both using QuickSync right?) I get in excess of 200 fps with those settings.

[vivan]

Nope, cpu load is ~20% (while it runs at ~2 Ghz).

I've tried QSVEnc in Hybrid (with maxing out what I could) - it was ~50 fps but quality was much worse (and I have to adjust quality to match bitrate). The resulting cli was QSVEnc --y4m -i - --input-buf 3 --slices 0 --fps 5000000/100000 --la-icq 37 --profile auto --level auto --quality best --bframes 16 --gop-len 0 --sar 1:1 --b-pyramid --scenechange --trellis all --mbbrc --extbrc --colormatrix undef

Actually it was even worse than q265 with -u 7 and without -la (which runs at ~150 fps, probably being limited by SSD speed) o_O

[aegisofrime]

Nope, cpu load is ~20% (while it runs at ~2 Ghz).

I've tried QSVEnc in Hybrid (with maxing out what I could) - it was ~50 fps but quality was much worse (and I have to adjust quality to match bitrate). The resulting cli was

Actually it was even worse than q265 with -u 7 and without -la (which runs at ~150 fps, probably being limited by SSD speed) o_O

Interesting, I should probably try out q265. Thanks for replying :)

[NikosD]

Some useful information:

QSVEncC in Hybrid is a lot slower than QSVEncC in StaxRip x86 on my system.
QSVEncC is used in a different way and with some defaults on with Hybrid that they delay the encoding.

Also, never use -u 1, it is just abnormally slow.

The command that vivan used with -u 1 and -la 100, it's like someone is trying hard to make QuickSync look as slow as possible.

I almost never use LA and if I do, I use it with the default value.

Try -u 3 or -u 4 without LA with StaxRip x86 and tell me the differences in speed and quality with your settings and app.

[aegisofrime]

I have been having some fun playing with q264, seems to have some potential. Now, if only I can figure out how to pipe Avisynth output to it. Anyone help me out? I have tried AVS2YUV but q264 seems to require an actual file for input.

[kalehrl]

I encoded a 5-minute video clip using QSVEncC in staxrip with la-icq, crf23, quality-best settings and the resulting file was almost the same size as the source file :D
Source 158mb, encode 155mb. Encoding speed 176fps.
The same file encoded using x264 with the same script, crf 23, preset slow ended with a 55,2mb file. Encoding speed 35fps.
As far as I'm concerned, HW encoding makes no sense.

[NikosD]

For ICQ encoding mode, which is close to CRF don't use LA.
Also as I said before NEVER USE BEST QUALITY (it is very slow and increases the size)

Use something around balanced (-u 4).

I transcoded a HEVC file with large bitrate to H.264 using only ICQ without LA and in balanced speed the result was HALF BITRATE with very good quality.

HW encoding is not like SW encoding.
It has its secrets. I told you some.

[aegisofrime]

For ICQ encoding mode, which is close to CRF don't use LA.
Also as I said before NEVER USE BEST QUALITY (it is very slow and increases the size)

Use something around balanced (-u 4).

I transcoded a HEVC file with large bitrate to H.264 using only ICQ without LA and in balanced speed the result was HALF BITRATE with very good quality.

HW encoding is not like SW encoding.
It has its secrets. I told you some.

Well that is interesting I will give it a go. But it's disappointing that the settings are so misleading in their use. I guess we are used to x264 like you say where typically the use of slower presets will also result in a smaller file.

[nevcairiel]

Increasing the size in best quality isn't necessarily a bad thing, if it preserves more quality in the same process. That whole statement is just misleading, and nothing else.

[vivan]

I encoded a 5-minute video clip using QSVEncC in staxrip with la-icq, crf23, quality-best settings and the resulting file was almost the same size as the source file :D
Source 158mb, encode 155mb. Encoding speed 176fps.
The same file encoded using x264 with the same script, crf 23, preset slow ended with a 55,2mb file. Encoding speed 35fps.
As far as I'm concerned, HW encoding makes no sense.Even comparing x264 with different settings makes no sense, comparing different encoders with wildly different definition of "crf" is even worse.
You have to match bitrate and compare them visually.

Well that is interesting I will give it a go. But it's disappointing that the settings are so misleading in their use. I guess we are used to x264 like you say where typically the use of slower presets will also result in a smaller file.They are not misleading, even with x264 slower preset could give larger file. See above, such comparison is wrong.

The command that vivan used with -u 1 and -la 100, it's like someone is trying hard to make QuickSync look as slow as possible.We were interested in how it compares with x264, you know.

HW encoding is not like SW encoding.
It has its secrets. I told you some.OH LOOK, FASTER PRESET GIVES FASTER ENCODING SPEED.
Thank you for sharing this secret secret.

With -u 3 (~100 fps in staxrip, ~90 fps in q264) it hardly can compare with --preset veryfast (~80 fps). With -u 4 (~120 fps in q264) it's even worse.

staxrip with --quality high --icq 27
http://rghost.ru/private/6ry2wHpVH/10a620109803ed2fe4b63b3febf22f7b

q264 -u 3 -icq 28
http://rghost.ru/private/8rY4BBRgT/e8473dcf227aa1543486de8a75a6004f

q264 -u 4 -icq 28
http://rghost.ru/private/6tTQPZrzh/850a7f871dd9ce96338f6fab40bdbba9

x264 --preset veryfast --crf 24.2
http://rghost.ru/private/6J97F46qJ/e74ceb33bc4e5e09a0a9490502275668

source http://s21.postimg.org/pkne4gkmt/crowd_run_1080p_y4m_snapshot_00_00_2015_04_26_1.png
staxrip --quality high http://s21.postimg.org/48bat1bat/crowd_run_1080p_mkv_snapshot_00_00_2015_04_26_1.png
q264 -u 3 http://s21.postimg.org/h7hp9slf9/q264_28_3_h264_snapshot_00_00_2015_04_26_19_05.png
q264 -u 4 http://s21.postimg.org/6r1l7gmet/q264_28_4_h264_snapshot_00_00_2015_04_26_19_05.png
x264 --preset veryfast http://s21.postimg.org/l017pj0xh/x264_242_mp4_snapshot_00_00_2015_04_26_19_05_36.png
x264 --preset medium http://s21.postimg.org/8b6x5uut1/x264_251_mp4_snapshot_00_00_2015_04_26_19_05_43.png

I transcoded a HEVC file with large bitrate to H.264 using only ICQ without LA and in balanced speed the result was HALF BITRATE with very good quality.Great comparison. Try encode with --preset veryfast next, and then claim how terrible slower presets are (because you got great quality and it was fast).

[NikosD]

We were interested in how it compares with x264, you know.



And who told you that in order to compare HW encoding with SW encoding you have to use the worst case scenario with HW encoding pushing the LA to max value 100 and pushing the speed parameter (-u) to its slowest value (1) ?


OH LOOK, FASTER PRESET GIVES FASTER ENCODING SPEED.
Thank you for sharing this secret secret.


Increasing the size in best quality isn't necessarily a bad thing, if it preserves more quality in the same process. That whole statement is just misleading, and nothing else.


The secret, that you didn't understand, is that balanced speed/quality of (-u 4) gives a very good quality a lot of faster than best quality (-u 1 ) and with smaller file.

So, it's not that faster preset gives faster encoding, but that faster preset gives faster encoding, smaller file and similar quality.

AVOID USING -u 1 in your comparisons with anything.


Great comparison. Try encode with --preset veryfast next, and then claim how terrible slower presets are (because you got great quality and it was fast).


Again it seems that you don't understand.
I looked at the figures again, the HEVC file was ~6.2Mbps and the similar quality H.264 file produced by -ICQ and balanced speed (-u 4) is ~4.4Mbps (not half bitrate actually but smaller).

[kalehrl]

For ICQ encoding mode, which is close to CRF don't use LA.
Encoded the same file with the same script using just ICQ, crf 23, best quality and the encoded file is 81,2mb and the bitrate is half of that produced by LA-ICQ.
The speed was around 205fps, so just a little faster.
I'll experiment with other quality settings.

[aegisofrime]

Encoded the same file with the same script using just ICQ, crf 23, best quality and the encoded file is 81,2mb and the bitrate is half of that produced by LA-ICQ.
The speed was around 205fps, so just a little faster.
I'll experiment with other quality settings.

In my own tests the quality produced by ICQ is inferior to LA-ICQ (tons of blocking!).

I think Quick Sync has potential but a lot of work needs to be done to drill down on good settings.

[Selur]

seems like the project died,..