Affordable transcode options with OpenCL / GPU support?

[deadrats]

@Darrells:

would you be offended if i ask you wtf you're smoking? you're encoding a 4k file with less than 4mb/s and you're complaining about the quality?

and with the software based encoders you use less than 500kb/s and you think the results are great?!? have you considered getting that cataract surgery you so obviously need?

[poisondeathray]

you're encoding a 4k file with less than 4mb/s and you're complaining about the quality?

and with the software based encoders you use less than 500kb/s and you think the results are great?!? have you considered getting that cataract surgery you so obviously need?

It's not typical 4k content. White cyc background - easy to compress. It's not really "full resolution" - in the sense that all the pixels aren't really being used or being "changed" from frame to frame. At least that' s what I'm inferring the clip to be . For example, If she dances around , flashes her "tatas" - that would be much harder to compress than if she just stands there idly. The content very much determines how much bitrate is required to attain certain level of "quality"

Anyways, I think he's just sharing some results that some software encoders were able to get decent results at lower bitrates in this specific test scenario



@DarrellS - Any reason why the Cuda run was missing a frame as well?

The other ones were 375

INFO: Number of Coded Frames : 374

[hello_hello]

@hello_hello

could you upload the test avi you used, i'd like to try it out myself, also what bit rate did x264 crf 18 give you and what preset did you use?

and yes, the drivers do make a difference, it's been my experience that some driver revisions seem to kill quality, usually when Nvidia is trying to improve overall performance (the latest beta drivers improved performance considerably but definitely had a quality effect with some encoders).

I'd already deleted the test encodes so I ran a few again, this time just on 30 seconds of the AVI. My upload speed is very slow so it'd take a while to upload much more.
I used the default MediaCoder settings for both x264 and CUDA. The only thing I changed was the CRF value/bitrate. Changing the CRF value for CUDA seems to make no difference. I don't know if it's a limitation of the encoder or whether MediaiCoder is broken in that respect.
The x264 CRF18 encode produced a bitrate of 682kbps. For CUDA it was 389kbps. The second CUDA encode when setting an average bitrate of 700kbps looked much better, but there still seems to be a bit of keyframe pumping. Because the first part of the video contains still pictures, you can see the picture "wobble". It's fairly obvious looking at the quality based encode.
The original isn't great quality to begin with, but when encoding a high quality video the result of CUDA encoding is even more obvious.

Seeing as I'd gone that far, I uninstalled the Nvidia drivers and installed the latest, then tried again. I'd been running version 295.73 of the drivers, which are a couple of years old, so I installed version 335.28. It didn't seem to make any difference. The row of pixels down the side was still there and the result of a CUDA quality based encode didn't change. In fact the bitrate dropped by about 10kbps.

Anyway..... all that was a perfect reminder as to why I never update anything unless I absolutely have to. The latest Nvidia drivers seem to be making a mess of the luminance levels, at least for the TV. For some reason they seem okay for the CRT monitor. The only way I seem to be able to get the correct levels for the TV is to set both the video card and TV to expand them to PC levels (ie set the TV to expect TV levels). When the levels "match" I end up with washed out video and even trying to correct them with a pixel shader doesn't work. That gives me crushed blacks, except they not black, they're still dark grey. ^%&&% Nvidia.......

30 seconds of the original AVI is included in the zip file.

[hello_hello]

MediaCoder does my head in at times. What is it about these settings:



Which would take a mod16 video with square pixels like this:



And give me an encode with an aspect ratio like this?



The only way I could get "704x384 in" and "704x384 out" was to manually set the PAR to 1:1.
And that Auto-level option under effects should be hidden away behind a tab nobody will ever look at and where it will never be checked, whether it's deliberately or by accident.

[deadrats]

@pdr:

i understand what you're saying but this guy does this all the time, he makes all sorts of claims about encoding speed (i think he's the guy that claimed he was getting 100fps with x265 at 1080p), he claims that x264/x265/divx265 is producing some phenomenal looking HD video at bit rates that would typically be used for high quality dts audio and he never provides the source and a full video clip sample of the output so we can see if for ourselves, he just posts a screenshot that tells us nothing and some text that supposedly shows the encoding characteristics of the final encodes.

for the love of God, if someone's going to make completely insane claims then at least provide the source and the final result so that we can examine it for ourselves.

an lastly, it's already been established that software encoders blur pictures way more than hardware encoders by design, so yes at a stupid low bit rate the software encoders will walk all over the any hardware encoder. crank up x264's deblocking filter and psy-rd. drop the bit rate through the floor and you'll get a video with no artifacts, no macroblocking, but also no detail because they'll all be washed out, the hardware encoders will fall about with artifacts all over the place because they're not capable of deblocking to that level and they're not designed to intelligently drop fine details.

for a proper test, one should take a 4k source (for instance the ToS 6gb file) and create a blu-ray complaint 1080p file, at proper blu-ray bit rates and compare those results and the encoding time with comparably classed hardware (i.e. don't compare an 3770k to a gt610 and conclude that x264 is faster).

@hello_hello:

maybe i've been using media coder for too long but the settings make perfect sense to me. 704x384 is an odd ball resolution (how did you come up with that anyway, (crop the crap out of 720x480 and why?), so obviously you're going to have to specify what the pixel aspect ratio is, i normally do it no matter what the resolution is and have been doing it for years, to me it's part of a normal encode setup.

as for the aspect ratio, if you had paid attention in grammar school when they first taught you fractions way back in what was it5th grade or so, you would realize that 704x384 has an aspect ratio of 1.83~ (it's a repeating decimal) and as a fractional representation of said ratio you would use something like 37/20=1.85 or 355/192=1.8489583~ (repeating decimal again) which gets rounded up to 1.85.

media coder didn't do anything to your aspect ratio, you chose that aspect ratio when you decided to butcher your source file by cropping away the black borders, the only difference between what it was and what it is in terms of aspect ratio is that media coder, or more accurately the h264 encoder wrote that information into the header and no windows reads that info and displays it, nothing has changed, you're just being slapped in the face with the choices you made whereas before you were in blissful ignorance.

i hope the above doesn't come off overly harsh but it drives me up the wall the things that some people do to their encodes.

[jagabo]

it's already been established that software encoders blur pictures way more than hardware encoders by design

That's exactly the opposite of what I've seen. Look at the encodes in post #33. In the CUDA encodes all the fine detail is gone on anything that moves. Even in the still sequences some of it is gone. x264 veryfast at CRF 18 was much closer to the source.

[poisondeathray]

an lastly, it's already been established that software encoders blur pictures way more than hardware encoders by design, so yes at a stupid low bit rate the software encoders will walk all over the any hardware encoder. crank up x264's deblocking filter and psy-rd. drop the bit rate through the floor and you'll get a video with no artifacts, no macroblocking, but also no detail because they'll all be washed out, the hardware encoders will fall about with artifacts all over the place because they're not capable of deblocking to that level and they're not designed to intelligently drop fine details.

You have the option to change whatever setting you want to get the desired end result to fit that specific scenario.

That's sort of the whole point of a "test" isnt it?

Let's see, why not deactivate a few cylinders to see how fast a car can go ? Throw in a few flat tires while you're at it

Wait .... CPU's can't massively parallelize on the scale of GPU's. Why not reduce the GPU units by 90% then test it? - do you see how absurd and convoluted your notion is ?



The current crop CPU encoders (easily accessible by consumers and costing < $20K) do walk over GPU encoders - at least in terms of quality/compression ratio - that's part of the point of the discussion. But speedwise is faster with Intel QS (at least on Haswell), but quality appears to have dropped compared to IB QS (at least according to some tests) . So the tradeoff in increased speed is lower quality
http://www.anandtech.com/show/7007/intels-haswell-an-htpc-perspective/8

for a proper test, one should take a 4k source (for instance the ToS 6gb file) and create a blu-ray complaint 1080p file, at proper blu-ray bit rates and compare those results and the encoding time with comparably classed hardware (i.e. don't compare an 3770k to a gt610 and conclude that x264 is faster).

That might be a proper test for 1 scenario . But you do realize there are multiple scenarios and bitrate levels. Blu-ray is just a small fraction of those possible scenarios. Content distribution also includes online/web. Think youtube, netflix. Portable devices, handhelds (Ipads, ipods, blackberry's etc..)

The whole point of video "compression" is to reduce the filesize, hopefully with maintaining a certain level of quality. If you can maintain a certain level of quality at a lower bitrate - that implies "better compression"

It's absurd to test only 25-35Mb/s for 1080p24 . You want to look at how the encoder functions in all scenarios, not just a tiny subset

So the "proper" test is to encode a variety of sources, a variety of scenarios at different bitrates to generate compression curves . Not just look at one high range or one low range . You want to look at objective and subjective measures

[hello_hello]

maybe i've been using media coder for too long but the settings make perfect sense to me. 704x384 is an odd ball resolution (how did you come up with that anyway, (crop the crap out of 720x480 and why?), so obviously you're going to have to specify what the pixel aspect ratio is, i normally do it no matter what the resolution is and have been doing it for years, to me it's part of a normal encode setup.

I didn't encode it, but had I encoded it, and had the source been a DVD, then I probably would have cropped and resized it to square pixels just as that AVI was cropped and resized. Have you never converted a DVD to an AVI before? Why are you asking such silly questions? Did you only encode your first video ten minutes ago?

as for the aspect ratio, if you had paid attention in grammar school when they first taught you fractions way back in what was it5th grade or so, you would realize that 704x384 has an aspect ratio of 1.83~ (it's a repeating decimal) and as a fractional representation of said ratio you would use something like 37/20=1.85 or 355/192=1.8489583~ (repeating decimal again) which gets rounded up to 1.85.

Seriously?? You're defending a change of aspect ratio when the setting specifically says "keep display aspect ratio"? Because that's what it says. It doesn't say "rounded aspect ratio" or "similar aspect ratio" it says "keep display aspect ratio", and the aspect ratio was 704:384, not some rounded, bad attempt at justifying, non-repeating decimal ratio, it was 1.8333333333333333. The program can output the same resolution and aspect ratio if I specifically tell it I want square pixels, but if I don't crop and resize it can't keep the original aspect ratio according to it's "keep display aspect ratio" setting?? Give me a break......
All MediaCoder had to do was set the SAR to 1:1. Obviously it didn't. Even the "keep PAR" setting fudged the aspect ratio. Got some irrelevant math which explains why a PAR of 1:1 is changed when the "keep PAR" setting is selected?

media coder didn't do anything to your aspect ratio, you chose that aspect ratio when you decided to butcher your source file by cropping away the black borders, the only difference between what it was and what it is in terms of aspect ratio is that media coder, or more accurately the h264 encoder wrote that information into the header and no windows reads that info and displays it, nothing has changed, you're just being slapped in the face with the choices you made whereas before you were in blissful ignorance.

i hope the above doesn't come off overly harsh but it drives me up the wall the things that some people do to their encodes.

What a load of twaddle. Of course something changed when the video was encoded. The source had a 704x384 resolution with an identical aspect ratio. The encoded version didn't. MediaCoder did that. How and why that 704x384 AVI came into existence is irrelevant. That's what it was, yet the output wasn't.

The only choice I'm being slapped in the face with was the one which resulted in me installing MediaCoder again. I could open the same AVI for encoding in any other GUI and without any resizing and cropping I could expect the output video to be 704x384 with exactly the same aspect ratio as the source and my expectation would be met each and every time.
I hope this doesn't come off overly harsh, but show me one other encoder GUI that changes the aspect ratio as MediaCoder does, because until then I'll be assuming you're a nutter trying to defend the indefensible.

Edit: For the record, I encoded a 4:3 video as a test (960x720) and correct me if I'm wrong, but there's lots of recurring there too. 1.333333333. For some reason though, MediaCoder decided that was an aspect ratio worth keeping when "keep display aspect ratio" was selected, and didn't feel obliged to round it to something else. Is there a list somewhere which specifies which aspect ratios the "keep aspect ratio" setting errrrr.... keeps?

[hello_hello]

it's already been established that software encoders blur pictures way more than hardware encoders by design

That's exactly the opposite of what I've seen. Look at the encodes in post #33. In the CUDA encodes all the fine detail is gone on anything that moves. Even in the still sequences some of it is gone. x264 veryfast at CRF 18 was much closer to the source.

I tried another video I was working with today (720p). After re-encoding with x264 (CRF17) the final average bitrate was around 3500kbps. So I encoded the first minute or so use MediaCoder/Cuda as there's a reasonable amount of fine detail. I took it up to 16000kbps as that's the maximum MediaCoder will let me and CUDA still wasn't encoding the opening scene as well as x264. I was still losing some fine detail in motion areas (I disabled de-interlacing to make sure it wasn't the culprit as it's set to "auto" by default).

deadrats should show us a hardware based encode which matches x264 for quality rather than expect us to keep providing examples of hardware based encodes which don't. It shouldn't be hard, if anything he says is true......

[deadrats]

I hope this doesn't come off overly harsh, but show me one other encoder GUI that changes the aspect ratio as MediaCoder does, because until then I'll be assuming you're a nutter trying to defend the indefensible.

this is a serious question, are you sober right now? do you want to set up an intervention for all the crack you're smoking?

you're own screenshots show that the input file was 704x384 with square pixels for an aspect ratio of 1.8333... and the output was likewise 704x384 with square pixels for an aspect ratio of 1.8333... and just to be certain i ran my own test with media coder 64bit and your sample and nothing was changed, for some reason windows is reporting the aspect ratio of the final encode as a fraction, not a decimal and using a fractional representation of the aspect ratio. just to be sure i confirmed it with media info, nothing has changed, zip, zilcho, nada, nothing.

in fact, i checked all the samples you provided with media info and they all show the exact same resolution and aspect ratio.

[DarrellS]

@pdr:

i understand what you're saying but this guy does this all the time, he makes all sorts of claims about encoding speed (i think he's the guy that claimed he was getting 100fps with x265 at 1080p), he claims that x264/x265/divx265 is producing some phenomenal looking HD video at bit rates that would typically be used for high quality dts audio and he never provides the source and a full video clip sample of the output so we can see if for ourselves, he just posts a screenshot that tells us nothing and some text that supposedly shows the encoding characteristics of the final encodes.

for the love of God, if someone's going to make completely insane claims then at least provide the source and the final result so that we can examine it for ourselves.

an lastly, it's already been established that software encoders blur pictures way more than hardware encoders by design, so yes at a stupid low bit rate the software encoders will walk all over the any hardware encoder. crank up x264's deblocking filter and psy-rd. drop the bit rate through the floor and you'll get a video with no artifacts, no macroblocking, but also no detail because they'll all be washed out, the hardware encoders will fall about with artifacts all over the place because they're not capable of deblocking to that level and they're not designed to intelligently drop fine details.

for a proper test, one should take a 4k source (for instance the ToS 6gb file) and create a blu-ray complaint 1080p file, at proper blu-ray bit rates and compare those results and the encoding time with comparably classed hardware (i.e. don't compare an 3770k to a gt610 and conclude that x264 is faster).

You're full of shit as usual. I've never made claims that x265 or DivX265 could encode anything at 100fps. you're the one that goes on full page rants if someone disagrees with your opinion. It's your prerogative to believe or not believe the numbers and individual frames that I post (not screenshots but actual frames from the clip) or anyone else posts for that matter since it's been proven by a lot more people than myself that cuda h264 needs two or three times the bitrate as x264 to produce the same quality. I could care less how fast Cuda supposedly is if the video looks like crap.

The whole point of video "compression" is to reduce the filesize, hopefully with maintaining a certain level of quality. If you can maintain a certain level of quality at a lower bitrate - that implies "better compression"

Exactly!

[jagabo]

Anyway......... I ran an x264 CRF18 encode (default settings) on an AVI I had handy. This old E6750 CPU managed about 45fps. Using the default MediaCoder/CUDA settings I was encoding at over 100fps

By the way, on my i5 2500K I got over 600 fps encoding your AVI file from post #33 with x264 at preset=veryfast, CRF=18. Using MediaInfo and CUDA on my old Nvidia GTX 460 I got around 200 fps and a lot better quality at the same ~700 kbps as your encode.

[DarrellS]

Cuda H264 --resolution %(width)x%(height) --input - --sar 1x1 --format IYUV --control_mode cbr --bitrate 20000 --bitrate_peak 32000 --fps 24000/1000 --profile high --level auto --offload partial --measure FPS --showFrameStats 100 --deinterlace false --frame_typ frame --pframe_dist 1 --gop_max 250 --dynamicGOP true --pquant_min 18 --bquant_min 20 --iquant_min 16 --deblock true --cavlc false --nal_typ auto --sps_pps false --slices auto --output "%(tempvideofile)"

[*] Beginning dub operation.
[i] Dub: Input (decompression) format is: RGB888.
[i] Dub: Output (compression) format is: YUV420.
[i] VideoEnc: SETTING colorformat --format: IYUV
[i] VideoEnc: fieldMode: 0dieMode: 0currentProfile: highINFO: Reading input from stdIn,...
[i] VideoEnc: INFO: Create the timer for frame time measurement,..
[i] VideoEnc: INFO: Creating encoder api interface,..
[i] VideoEnc: INFO: Created a NVEncoder instance,..
[i] VideoEnc: INFO: Using H.264 encoder,...
[i] VideoEnc: INFO: Detected 1 GPU(s) capable of GPU Encoding.
[i] VideoEnc: INFO: GPU Device 0: GeForce GTS 450
[i] VideoEnc: INFO: Compute Capability = SM 2.1
[i] VideoEnc: INFO: Total Memory = 1024 MBytes
[i] VideoEnc: INFO: GPU Clock = 1764000 Hz
[i] VideoEnc: INFO: Multiprocessors = 4
[i] VideoEnc: INFO: GPU Encoding Mode:
[i] VideoEnc: INFO: CPU: Entropy Encoding
[i] VideoEnc: INFO: GPU: Full Offload of Encoding
[i] VideoEnc: INFO: Using device with index 0,...
[i] VideoEnc: PARAM: NVVE_GPU_OFFLOAD_LEVEL 8
[i] VideoEnc: PARAM: NVVE_OUT_SIZE 1920 1200
[i] VideoEnc: PARAM: NVVE_ASPECT_RATIO 1 1 1
[i] VideoEnc: PARAM: NVVE_FIELD_ENC_MODE 0
[i] VideoEnc: PARAM: NVVE_P_INTERVAL 1
[i] VideoEnc: PARAM: NVVE_IDR_PERIOD 250
[i] VideoEnc: PARAM: NVVE_DYNAMIC_GOP 1
[i] VideoEnc: PARAM: NVVE_RC_TYPE 2
[i] VideoEnc: PARAM: NVVE_AVG_BITRATE 20000000
[i] VideoEnc: PARAM: NVVE_PEAK_BITRATE 32000000
[i] VideoEnc: PARAM: NVVE_QP_LEVEL_INTRA 16
[i] VideoEnc: PARAM: NVVE_QP_LEVEL_INTER_P 18
[i] VideoEnc: PARAM: NVVE_QP_LEVEL_INTER_B 20
[i] VideoEnc: PARAM: NVVE_FRAME_RATE 24000 1000
[i] VideoEnc: PARAM: NVVE_DEBLOCK_MODE 1
[i] VideoEnc: PARAM: NVVE_PROFILE_LEVEL 65380
[i] VideoEnc: PARAM: NVVE_SET_DEINTERLACE 0
[i] VideoEnc: PARAM: NVVE_DISABLE_CABAC 0
[i] VideoEnc: PARAM: NVVE_CONFIGURE_NALU_FRAMING_TYPE 0
[i] VideoEnc: PARAM: NVVE_DISABLE_SPS_PPS 0
[i] VideoEnc: PARAM: NVVE_SLICE_COUNT 0
[i] VideoEnc: INFO: Register the callback structure,...
[i] VideoEnc: INFO: Create the hw resources for encoding..
[i] VideoEnc: INFO: Starting encoding,...
[i] VideoEnc: INFO: Colorspace: IYUV
[i] VideoEnc: INFO: measuring FPS: true
[i] VideoEnc: INFO: showFramestats: 100
[i] VideoEnc: Starting the encoding,...
[i] VideoEnc: [Frame: 100, 31.9081 fps, frame time: 31.34 (ms)]
[i] VideoEnc: Finished encoding,...
[i] VideoEnc: INFO: Number of Coded Frames : 107
[i] VideoEnc: INFO: Elapsed time : 3478 ms
[i] VideoEnc: INFO: End to End FPS : 30.7648
[i] VideoEnc: INFO: CPU utilization : 46.5357
[i] VideoEnc: (user: 17.1341%, kernel: 14.8017%) / 4 cores
[i] VideoEnc: Closing cuda,...
[i] VideoEnc: INFO: Encoder handler exited with 0
[i] VideoEnc: INFO: Closing cuda,...
[i] VideoEnc: INFO: Closing input file reader,...
[i] VideoEnc: INFO: Destroying cuda encoder,...
[i] VideoEnc: INFO: Closing output file writer,...
[i] VideoEnc: INFO: Freeing file buffer one,...
[i] VideoEnc: INFO: Freeing file buffer two,...
[i] VideoEnc: INFO: Freeing char buffer,...
[i] VideoEnc: Cuda returned with return value: 0
[i] Mux: mkvmerge v6.8.0 ('Theme for Great Cities') 64bit built on Mar 2 2014
21:34:26
[i] Mux: 'F:\My Recordings\01\MP4\GunnerGirls-001-cuda-20000.mkv.264': Using
the demultiplexer for the format 'AVC/h.264'.
[i] Mux: 'F:\My Recordings\01\MP4\GunnerGirls-001-cuda-20000.mkv.264' track 0:
Using the output module for the format 'AVC/h.264 (unframed)'.
[i] Mux: The file 'GunnerGirls-001-cuda-20000.mkv' has been opened for
writing.
[i] Mux: 'F:\My Recordings\01\MP4\GunnerGirls-001-cuda-20000.mkv.264' track 0:
Extracted the aspect ratio information from the MPEG-4 layer 10 (AVC)
video data and set the display dimensions to 1920/1200.
[i] Mux: Progress: 8%
[i] Mux: Progress: 100%
[i] Mux: Progress: 100%
[i] Mux: The cue entries (the index) are being written...
[i] Mux: Muxing took 0 seconds.[*] Ending operation.

General
Unique ID : 173990919848621450196444105879058941561 (0x82E56EA883276EB09DA3A7E6F6C88679)
Complete name : F:\My Recordings\01\MP4\GunnerGirls-001-cuda-20000.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 11.4 MiB
Duration : 4s 459ms
Overall bit rate mode : Constant
Overall bit rate : 21.5 Mbps
Encoded date : UTC 2014-04-15 17:38:10
Writing application : mkvmerge v6.8.0 ('Theme for Great Cities') 64bit built on Mar 2 2014 21:34:26
Writing library : libebml v1.3.0 + libmatroska v1.4.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.0
Format settings, CABAC : Yes
Format settings, ReFrames : 1 frame
Format settings, GOP : N=1
Codec ID : V_MPEG4/ISO/AVC
Duration : 4s 458ms
Bit rate mode : Constant
Bit rate : 20.0 Mbps
Width : 1 920 pixels
Height : 1 200 pixels
Display aspect ratio : 16:10
Frame rate mode : Constant
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.362
Stream size : 11.2 MiB (98%)
Default : Yes
Forced : No

[poisondeathray]

it's been proven by a lot more people than myself that cuda h264 needs two or three times the bitrate as x264 to produce the same quality. I could care less how fast Cuda supposedly is if the video looks like crap.

To be fair, this is only true at the lower bitrate ranges relative to content complexity . At mid to higher bitrate ranges (again relative to content complexity) it might only need 1.5-2x the bitrate . The compression curves never coincide untill you get to very high bitrates .

But CUDA does seem to be worse than other GPU implementations, especially QS (both in terms of speed an quality). I think everyone will agree on that

Another worrisome thing is many GPU implementations seem to produce random corrupt frames, dropped frames, levels issues. eg. on DarrelS's run there was a dropped frame. Even QS has these issues. Some of these might be driver related, or it might just be laziness or lack of competence from the programmers but we shouldn't be seeing major issues like that since they've been around for a few years now and have had plenty of time to mature

We can get a rough idea of MC's OpenCL and CUDA implementation by looking at the MSU comparisons , at least in terms of speed. Download the pdf and look at the charts. For those that are too lazy, they are about 1.5x -1.8x slower than IB QS on the high quality preset, 1-1.2x slower on the speed preset. Quality is always worse (at least in terms of SSIM), requiring about 1.2-1.5x more bitrate on all presets . Keep in mind Haswell QS is about 20-25% faster than IB QS, and 75-70% faster than SB QS - but quality seems to be lower than previous Intel generations even on the high quality preset(at least according to some reviews)

I'm interested in seeing how the x265 GPU implementation pans out.

[DarrellS]

x264 --crf 17 --preset superfast --tune animation --demuxer raw --input-csp i420 --input-res %(width)x%(height) --fps %(fpsnum)/%(fpsden) -o "%(tempvideofile)" -

[i] VideoEnc: raw [info]: 1920x1200p 0:0 @ 24/1 fps (cfr)
[i] VideoEnc: x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64 SlowShuffle
[i] VideoEnc: x264 [info]: profile High, level 5.0
[i] VideoEnc:
[i] VideoEnc: x264 [info]: frame I:1 Avg QP:14.03 size:407389
[i] VideoEnc: x264 [info]: frame P:35 Avg QP:14.72 size:108242
[i] VideoEnc: x264 [info]: frame B:72 Avg QP:16.75 size: 1443
[i] VideoEnc: x264 [info]: consecutive B-frames: 16.7% 0.0% 0.0% 0.0% 83.3%0.0%
[i] VideoEnc: x264 [info]: mb I I16..4: 3.1% 14.9% 82.0%
[i] VideoEnc: x264 [info]: mb P I16..4: 1.0% 0.9% 1.7% P16..4: 84.4% 0.0% 0.0% 0.0% 0.0% skip:12.0%
[i] VideoEnc: x264 [info]: mb B I16..4: 0.0% 0.0% 0.0% B16..8: 4.0% 0.0% 0.0% direct: 5.9% skip:90.1% L0: 5.4% L1:94.5% BI: 0.0%
[i] VideoEnc: x264 [info]: 8x8 transform intra:20.0% inter:41.0%
[i] VideoEnc: x264 [info]: coded y,uvDC,uvAC intra: 80.0% 94.8% 87.9% inter: 17.4% 18.0% 4.0%
[i] VideoEnc: x264 [info]: i16 v,h,dc,p: 51% 21% 24% 4%
[i] VideoEnc: x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 21% 25% 6% 6% 5% 7% 6% 10%
[i] VideoEnc: x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 18% 19% 8% 9% 8% 8% 8% 9% 13%
[i] VideoEnc: x264 [info]: i8c dc,h,v,p: 31% 26% 23% 20%
[i] VideoEnc: x264 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
[i] VideoEnc: x264 [info]: kb/s:7643.96
[i] VideoEnc: encoded 108 frames, 30.05 fps, 7643.96 kb/s

General
Unique ID : 216300168945569672788984265450244005885 (0xA2B9E5B12E87B235BD333C8F334BDFFD)
Complete name : F:\My Recordings\01\MP4\GunnerGirls-002-x264.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 4.11 MiB
Duration : 4s 500ms
Overall bit rate : 7 655 Kbps
Encoded date : UTC 2014-04-15 16:43:51
Writing application : mkvmerge v6.8.0 ('Theme for Great Cities') 64bit built on Mar 2 2014 21:34:26
Writing library : libebml v1.3.0 + libmatroska v1.4.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 4s 500ms
Bit rate : 7 503 Kbps
Width : 1 920 pixels
Height : 1 200 pixels
Display aspect ratio : 16:10
Frame rate mode : Constant
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.136
Stream size : 4.02 MiB (98%)
Writing library : x264 core 140 r2377 1ca7bb9
Encoding settings : cabac=1 / ref=1 / deblock=1:1:1 / analyse=0x3:0x3 / me=dia / subme=1 / psy=1 / psy_rd=0.40:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=5 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=24 / scenecut=40 / intra_refresh=0 / rc=crf / mbtree=0 / crf=17.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:0.60
Default : Yes
Forced : No

[hello_hello]

you're own screenshots show that the input file was 704x384 with square pixels for an aspect ratio of 1.8333... and the output was likewise 704x384 with square pixels for an aspect ratio of 1.8333...

So all your silly aspect ratio rounding due to recurring decimals nonsense just went out the window by your own admission?? Pity you're wrong though....

My two screenshots show the original video has a resolution of 704x384 with no additional aspect ratio information. The encode (second screeshot) has a resolution/aspect ratio of 704x384 (AR 355:192). It's right there in the picture, FFS. Next to where it says "Video size". Can you see it yet?
First you defend the change of aspect ratio with some mathematical nonsense trying to prove it's expected behaviour, and now you claim there isn't any change. I'd at least have hoped you'd refrain from the smoking crack accusations given you can't make up your mind.

in fact, i checked all the samples you provided with media info and they all show the exact same resolution and aspect ratio.

MediaInfo does a whole lot of rounding with aspect ratios in it's GUI. I hope you're not checking that way as it'll be reporting 1.85 yet you've already claimed the aspect ratio remained unchanged at 1.83333. How are you checking the aspect ratios exactly?
I don't know what basis you have for saying I'm getting the aspect ratio from Windows. I'm getting it from MPC-HC's File/Properties menu. I've never known it not to be accurate. FFS, if I open one of the encodes in one instance of MPC-HC and the original AVI in another, I can see their display widths are different. That's what got me checking the aspect ratios in the first place. I even double checked by opening both the original AVI and the encoded version with MeGUI to see what it displayed as the aspect ratio for each and it confirmed they're different.

[hello_hello]

Using MediaInfo and CUDA on my old Nvidia GTX 460 I got around 200 fps and a lot better quality at the same ~700 kbps as your encode.

So the logical conclusion is not all hardware encoders are created equally? ie CUDA at "x" kbps will produce different quality according to which flavour of Nvidia card you have installed? Did you have the same problem with the "odd" few rows of pixels down the left side, or is that something unique to my video card?
What about quality based CUDA encoding? Do you know if changing the quality setting in MediaCoder has any effect? It didn't for me.

If the video card makes a difference, I guess you'd want a fairly recent one in order to obtain a quality encode. As far as I know the same can't be said for x264. To the best of my knowledge the quality doesn't change according to the type of CPU you're using.

[poisondeathray]

"GunnerGirls-001-cuda-20000.mkv" was encoded intra-only (All I frames) . That's going to severely limit the compression especially since that clip isn't "full motion" (there are lot of duplicate frames) . An "Apples to apples" comparison would use better or at least comparible settings . Now certain very early revisions of some CUDA implementations didn't allow for b-frames, but both p and b frames are possible in newer CUDA implementations

hello_hello - it might be that difference in drivers are accounting for at least some of your differences as well

[DarrellS]

"GunnerGirls-001-cuda-20000.mkv" was encoded intra-only (All I frames) . That's going to severely limit the compression especially since that clip isn't "full motion" (there are lot of duplicate frames) . An "Apples to apples" comparison would use better or at least comparible settings . Now certain very early revisions of some CUDA implementations didn't allow for b-frames, but both p and b frames are possible in newer CUDA implementations

hello_hello - it might be that difference in drivers are accounting for at least some of your differences as well

I used the command line that Selur gave me when I first started playing with Cuda. I just raised the bitrate to produce the same quality that x264 produced. I'm not sure exactly at what bitrate that the macroblocking stopped with the Cuda encoder but it was still pretty noticable at 12000. 20000 looked pretty close to the x265 superfast clip at crf 17, 7500 Kbps.

What command line would you suggest?

EDIT: It doesn't look too bad at 15000Kbps (twice as much bitrate and filesize is over twice as big as x264). Bitrate is the only settings that I chose. All other settings are default...

Cuda --resolution %(width)x%(height) --input - --sar 1x1 --format IYUV --control_mode cbr --bitrate 15000 --bitrate_peak 25000 --fps 24000/1000 --profile high --level auto --output "%(tempvideofile)"

[*] Beginning dub operation.
[i] Dub: Input (decompression) format is: RGB888.
[i] Dub: Output (compression) format is: YUV420.
[i] VideoEnc: SETTING colorformat --format: IYUV
[i] VideoEnc: fieldMode: 0dieMode: 0currentProfile: highINFO: Reading input
from stdIn,...
[i] VideoEnc: INFO: Create the timer for frame time measurement,..
[i] VideoEnc: INFO: Creating encoder api interface,..
[i] VideoEnc: INFO: Created a NVEncoder instance,..
[i] VideoEnc: INFO: Using H.264 encoder,...
[i] VideoEnc: INFO: Detected 1 GPU(s) capable of GPU Encoding.
[i] VideoEnc: INFO: GPU Device 0 : GeForce GTS 450
[i] VideoEnc: INFO: Compute Capability = SM 2.1
[i] VideoEnc: INFO: Total Memory = 1024 MBytes
[i] VideoEnc: INFO: GPU Clock = 1764000 Hz
[i] VideoEnc: INFO: Multiprocessors = 4
[i] VideoEnc: INFO: GPU Encoding Mode:
[i] VideoEnc: INFO: CPU: Entropy Encoding
[i] VideoEnc: INFO: GPU: Full Offload of Encoding
[i] VideoEnc: INFO: Using device with index 0,...
[i] VideoEnc: PARAM: NVVE_GPU_OFFLOAD_LEVEL 8
[i] VideoEnc: PARAM: NVVE_OUT_SIZE 1920 1200
[i] VideoEnc: PARAM: NVVE_ASPECT_RATIO 1 1 1
[i] VideoEnc: PARAM: NVVE_FIELD_ENC_MODE 0
[i] VideoEnc: PARAM: NVVE_P_INTERVAL 1
[i] VideoEnc: PARAM: NVVE_IDR_PERIOD 250
[i] VideoEnc: PARAM: NVVE_DYNAMIC_GOP 1
[i] VideoEnc: PARAM: NVVE_RC_TYPE 2
[i] VideoEnc: PARAM: NVVE_AVG_BITRATE 15000000
[i] VideoEnc: PARAM: NVVE_PEAK_BITRATE 25000000
[i] VideoEnc: PARAM: NVVE_QP_LEVEL_INTRA 10
[i] VideoEnc: PARAM: NVVE_QP_LEVEL_INTER_P 12
[i] VideoEnc: PARAM: NVVE_QP_LEVEL_INTER_B 15
[i] VideoEnc: PARAM: NVVE_FRAME_RATE 24000 1000
[i] VideoEnc: PARAM: NVVE_DEBLOCK_MODE 1
[i] VideoEnc: PARAM: NVVE_PROFILE_LEVEL 65380
[i] VideoEnc: PARAM: NVVE_SET_DEINTERLACE 0
[i] VideoEnc: PARAM: NVVE_DISABLE_CABAC 0
[i] VideoEnc: PARAM: NVVE_CONFIGURE_NALU_FRAMING_TYPE 0
[i] VideoEnc: PARAM: NVVE_DISABLE_SPS_PPS 0
[i] VideoEnc: PARAM: NVVE_SLICE_COUNT 0
[i] VideoEnc: INFO: Register the callback structure,...
[i] VideoEnc: INFO: Create the hw resources for encoding..
[i] VideoEnc: INFO: Starting encoding,...
[i] VideoEnc: INFO: Colorspace: IYUV
[i] VideoEnc: INFO: measuring FPS: true
[i] VideoEnc: INFO: showFramestats: 0
[i] VideoEnc: Starting the encoding,...
[i] VideoEnc: Finished encoding,...
[i] VideoEnc: INFO: Number of Coded Frames : 107
[i] VideoEnc: INFO: Elapsed time : 3345 ms
[i] VideoEnc: INFO: End to End FPS : 31.988
[i] VideoEnc: INFO: CPU utilization : 45.1214
[i] VideoEnc: (user: 16.7427%, kernel: 13.0584%) / 4 cores

General
Unique ID : 177712113717232080555761450805107794127 (0x85B21BAE54D95829A8CFB100782EA0CF)
Complete name : F:\My Recordings\01\MP4\new-cuda-2.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 8.97 MiB
Duration : 4s 459ms
Overall bit rate mode : Constant
Overall bit rate : 16.9 Mbps
Encoded date : UTC 2014-04-15 21:29:39
Writing application : mkvmerge v6.8.0 ('Theme for Great Cities') 64bit built on Mar 2 2014 21:34:26
Writing library : libebml v1.3.0 + libmatroska v1.4.1

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.0
Format settings, CABAC : Yes
Format settings, ReFrames : 1 frame
Format settings, GOP : N=1
Codec ID : V_MPEG4/ISO/AVC
Duration : 4s 458ms
Bit rate mode : Constant
Bit rate : 16.5 Mbps
Nominal bit rate : 15.0 Mbps
Width : 1 920 pixels
Height : 1 200 pixels
Display aspect ratio : 16:10
Frame rate mode : Constant
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.299
Stream size : 8.79 MiB (98%)
Default : Yes
Forced : No

[poisondeathray]

@DarrelS
I'm not that familiar with the cuda switches. Which version or exe are you using ? or can you post -help . Hello_hello's cuda encode using media coder (I think it uses cudaH264Enc.exe) uses b-frames and long GOP

But you need to use comparable settings, and enable long GOP . Right now you're using a GOP size of 1 (intra only).

x264 looks like crap with intra encoding at low bitrates too. x264's biggest strength for compression is it's b-frames . Disable B and P frames - and you need about double the bitrate right off the bat in most scenarios . In low bitrate scenarios the penalty is even worse


Hahaha get a kick out of the log in post #43

[i] VideoEnc: INFO: Closing cuda,...
[i] VideoEnc: INFO: Closing input file reader,...
[i] VideoEnc: INFO: Destroying cuda encoder,...
[i] VideoEnc: INFO: Closing output file writer,...

LOL Maybe it's "destroyed" from the last run

[deadrats]

ok people, i just ran a number of gpu powered encoding tests. for source i used the 4k Tears of Steel movie:

http://ftp.nluug.nl/pub/graphics/blender/demo/movies/ToS/

the source is 3840x1714 at 24fps, for an aspect ratio of 2.25:1.

as a reference point i also downloaded the 720p file that they created, interestingly enough that file was 1280x534 for an aspect ratio of 2.40 and the settings they used for x264 are odd as well, cbr, 4mb/s, dia, sub me 6, you guys can download the file and see for yourselves.

i used the latest Sony Movie Studio Platinum 13 demo and i created 3 different files using main concept's cuda encoder, main concept's ocl encoder and sony's cuda encoder and i verified that the gpu was being used via gpu-z. attached you can see the test encodes. the Sony gpu encoder had a bit of trouble hitting the target bit rate but to my eyes all the encodes beat the x264 encode offered by the ToS team.

of course, the settings they used for x264 are nowhere near ideal and i'm sure you guys could produce a better x264 result, still i don't think anyone would be able to produce an x264 encode at 4mb/s that beat any of the encodes i'm uploading.

feel free to try, just upload your encodes for comparison.

[jagabo]

i used the 4k Tears of Steel movie:

http://ftp.nluug.nl/pub/graphics/blender/demo/movies/ToS/

There are more than one 4K versions there. Which one did you start with?

[vhelp]

and also, please include the param setup for both (all) encoders.

and, can someone create a x264 encoded lossless version of ToS that can be D/L'ed----that should be much smaller than the png's unless i'm wrong, thanks.

[deadrats]

there's only one that truly 4k, namely the 6.3gb file, the other is a 1080p created from the 4k, basically these guys have created a bunch of 1st and 2nd generation 1080p files from different 4k sources.

http://ftp.nluug.nl/pub/graphics/blender/demo/movies/ToS/

file name "tearsofsteel_4k.mov"

i was almost tempted to download the 4k DCP files or the TIFF and they used to have a massive ~60gb 4k source but i figured the 6gb x264 4k render would be good enough as a test source.

[hello_hello]

of course, the settings they used for x264 are nowhere near ideal and i'm sure you guys could produce a better x264 result, still i don't think anyone would be able to produce an x264 encode at 4mb/s that beat any of the encodes i'm uploading.

feel free to try, just upload your encodes for comparison.

What for??

Main Concept CUDA 1 pass cbr,
Main Concept OCL 1 pass cbr,
Sony AVC GPU

Who'd encode using a constant bitrate, assuming that's what CBR refers to?? How's the third one encoded?
CBR encoding? I thought my days of taking a guess at an average bitrate died with Xvid, but CBR......

I assume you're just going to ignore my previous post regarding the encode apsect ratios and pretend you weren't wrong? No apology for the childish remarks so I might consider taking seriously anything else you might post from now on?

[poisondeathray]

@deadrats -

Some issues with your "test"

What resizing method did you use ? For example , if someone used a sharper or less sharp kernal it will look different . You should attempt to reduce the variables when doing testing

Did you intend to pillar box it to screw with the AR ? For example, the original 16bit 4k TIFF's were not pillarboxed. I didn't download the MOV, but I suspect it wasn't either

[poisondeathray]

the source is 3840x1714 at 24fps, for an aspect ratio of 2.25:1.

So are you saying this MOV version is cropped and has pillarboxing ? Or was that some mistake you made ? I haven't downloaded the MOV version, just one of your encodes.

For reference, the original TIFFs were 4096x1714 (AR ~2.389) . It was "real" cinema 4K or 4096 width, not "UHDTV" or 3840 width

[deadrats]

and also, please include the param setup for both (all) encoders.

and, can someone create a x264 encoded lossless version of ToS that can be D/L'ed----that should be much smaller than the png's unless i'm wrong, thanks.

i did not download the massive PNG source, i downloaded the 6.3gb x264 encode they created, i figured that's high quality enough for a test source.

media info for the source:

Complete name : H:\Temp\tearsofsteel_4k.mov
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt
File size : 6.27 GiB
Duration : 12mn 14s
Overall bit rate mode : Variable
Overall bit rate : 73.4 Mbps
Writing application : Lavf54.29.104

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L5.1
Format settings, CABAC : No
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 12mn 14s
Bit rate : 73.2 Mbps
Nominal bit rate : 100.0 Mbps
Width : 3 840 pixels
Height : 1 714 pixels
Display aspect ratio : 2.25:1
Frame rate mode : Constant
Frame rate : 24.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.464
Stream size : 6.26 GiB (100%)
Writing library : x264 core 118
Encoding settings : cabac=0 / ref=2 / deblock=1:0:0 / analyse=0x3:0x113 / me=dia / subme=6 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=1 / weightp=2 / keyint=18 / keyint_min=10 / scenecut=40 / intra_refresh=0 / rc_lookahead=18 / rc=cbr / mbtree=1 / bitrate=100000 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / vbv_maxrate=100000 / vbv_bufsize=4166 / nal_hrd=none / ip_ratio=1.40 / aq=1:1.00
Language : English

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 12mn 13s
Bit rate mode : Variable
Bit rate : 183 Kbps
Maximum bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 44.1 KHz
Compression mode : Lossy
Delay relative to video : 83ms
Stream size : 16.0 MiB (0%)
Language : English


also i had to remux the mov file to mp4 because sony's software wanted me to install apple's official quick time in order to open the .mov and i refuse to install that garbage on my system.

the settings for the gpu encoders are as follows:

Sony Movie Studio Platinum 64 bit build 879

for main concept avc i used 4 reference frames (if i tried to use more the encoder crashed with an error message that there wasn't enough available ram, with smaller sources i have used up to 16 reference frames), slices was set to 1, cbr 4mb/s (does support vbr and 2 pass if so desired), under "project" video rendering quality was set to "best", progressive download was disabled, "allow source to change frame rate" was unchecked, under encode mode i used both "render using ocl if available" and "render using cuda if available", i confirmed with gpu-z that the 9600gso was being used in both cases.

for sony avc the same settings applied, only there is no option for cbr or 2 pass, no option for number of reference frames, main profile was used for all encodes, and the rest was as above.

[deadrats]

Who'd encode using a constant bitrate,

the people that created Tears of Steel for one, check out their 4k encode.

I assume you're just going to ignore my previous post regarding the encode aspect ratios and pretend you weren't wrong?

in what way was i wrong? you still believe a patently false premise, one that your own screenshots show is wrong.

you want an apology? sure, here goes: i'm sorry you don't know what you're doing.

[poisondeathray]

According to mediainfo it looks like they converted from 4K , but is it really pillarboxed ?? Can you open the MOV (or remuxed MP4) , in something like vdub or avidemux and take a 1:1 screenshot from somewhere in the middle . A lossy jpg will do (I'm just checking the AR)