h264 encoding challenge [Archive]

deadrats

8th February 2011, 00:16

ok folks, about 2 weeks ago i was laid off and thus have way too much time on my hands, thus i have been doing a ton of test encodes, trying out numerous video editing software and techniques, some coding, anything to keep me from losing my mind.

i just did 2 test encodes with the demo for the latest tmpg, the source is a 2 minute mkv that i clipped from an adult blu-ray i own, it's 1920x1080, 29.97 fps 23.2 mb/s, avc with ac3 audio, very high quality, it actually surpasses some main stream blu-rays and it's a very tough source to work with because it's MBAFF, which means that each frame is encoded partly interlaced and partly progressive.

because of this i disabled tmpg's de-interlace filter and did test encodes with the encoder set to "interlaced", the target was set as 1280x720, 4 mb/s, 2 channel ac3.

for the x264 encodes i disabled cuda completely and used the software decoder as well as software resizing.

for the cuda encode i went cuda all the way and used the cuda decode, cuda encode and cuda resizing.

in the case of x264 i chose the "fastest" setting and in both cases the gop length was set to 18 with 2 b frames.

here are the samples:

http://rapidshare.com/files/446757824/Tia_Tanaka_-_Asian_Adventure_2.mkv

http://rapidshare.com/files/446757825/Tia_Tanaka_cuda_encode_decode_resizing_interlace.mkv

http://rapidshare.com/files/446757826/Tia_Tanaka_software_decode_and_resizing_x264_encode_interlaced.mkv

now mind you, this is what i'm talking about when i go on against "bit rate starving" an encode, i consider this type of thing idiotic but it does seem to be what many think is perfectly acceptable, taking a 1920x1080 23 mb/s source and transcoding it to a 4 mb/s 1280x720, so i thought i would simulate a common encoding scenario.

as for encoding speeds, the source is exactly 2 minutes long, the x264 encode took 6 minutes and the cuda encode took 4:44.

these results are pretty indicative of what i saw with all the encoding tests i did, i'm looking forward to eventually adding SB encoding times to these results.

what i would like for those that wish to participate is for you guys to download the samples, take the source and transcode it to 1280x720 4 mb/s h264 with 128 kb/s ac3, you can use any app you desire but there 2 stipulations:

1) you must try to beat the cuda time of 4:44

2) try and surpass the quality of my test encodes.

also, in the interest of fairness if you demux the source, decompress the video, encode to h264 and the remux everything you must count the total processing time (demux, remux, transcoding audio and video) as the total encode time and report accordingly.

and obviously, list your system specs as well as the procedure you used to obtain the results.

*my system specs are a phenom 2 x4 620, 4 gigs ddr2 800 and a gts 250 1 gig gddr3.

thanks in advance for your participation.

kolak

8th February 2011, 00:49

poisondeathray

8th February 2011, 00:53

kolak

8th February 2011, 00:56

He didn't deinterlaced source- just resized.

Andrew

poisondeathray

8th February 2011, 00:59

He didn't deinterlaced source- just resized.

Andrew

OK is see, but he's encoding interlaced and resized without deinterlacing? So it' s an interlace aware resize? or is he mashing fields ? Or is this 1280x720i29.97 ?

i disabled tmpg's de-interlace filter and did test encodes with the encoder set to "interlaced",

kolak

8th February 2011, 01:05

It looks like it's 59.94, so I think he is a bit lost on his test :)
It looks progressive.

Andrew

deadrats

8th February 2011, 01:07

Did you use TMPEG 5?

Some quick tests, which I've done show that it's few times slower (for some reason) than x264 in CLI mode (same settings).

Was it 1pass in both cases?
Does CUDA support 2pass?

Andrew

yes, latest tmpg, you're free to use any method you want, so long as you are fair in your reporting of encode times; if you demux, use x264cli, a separate app for ac3 and then mux everything together you must account for the total processing time, not just the encoding of the video stream via cli.

all test encodes were done 1 pass vbr, this implementation of cuda does not support 2 pass though for some reason xillisoft ships with a version where 2 pass is possible (but it takes a lot of configuring and lots of bit rate to get really good results.

kolak

8th February 2011, 01:15

deadrats

8th February 2011, 01:18

Is this an encoding challenge? or a deinterlacing, resizing , encoding challenge? (i.e a specific workflow challenge?)

Why not use a progressive source and progressive output - To test encoding? Or interlaced to interlaced to test interlaced encoding specifically ?

To reduce the effects of using various decoders, use a lossless format where both have to use the same decoder

Why not test 1 variable at a time? Like deinterlacing speed , quality etc.... in a different test ? Or quality/speed of resizing algorithm in a different test etc... ?

because no one in the real world ever encodes "1 variable at a time". no one outside of a movie studio has access to uncompressed sources, no consumer level, or prosumer for that matter, camera that i know of records to an uncompressed format.

furthermore, taking a previously compressed source and decompressing it then running a test encode isn't really fair as you should really be counting the total processing time, work was done to decompress, that must be counted.

it's kind of like when muscle car magazine would take a gt 5.0 with 225hp and 300lb-ft torque and get acceleration figures that no one else could replicate, as low as high 13's in the quarter mile when everyone else was seeing mid 14's to low 15's.

what they were doing was taking out the back seat, reducing the tire pressure to 20 psi (to get better launch traction), they would use dry ice to cool off the intake, power shift every upshift and side step the clutch on take off.

that't not a realistic representation of how the average owner was going to be driving his car.

same thing here, the average user isn't going to have access to an uncompressed source, what they are going to do is "back up" a blu-ray to avchd.

as for the interlace issue, MBAFF is one of the more advanced features of h264 that result in greater quality, both progressive and interlaced have their drawbacks, this aims to get the best of both worlds.

as far as i'm concerned all blu-ray should be encoded as MBAFF.

deadrats

8th February 2011, 01:20

It looks like it's 59.94, so I think he is a bit lost on his test :)
It looks progressive.

Andrew

i just checked, it looks like i messed up with the cuda settings, for some reason i must have clicked on 59.94 fps, i will redo with 29.97 and re-up the results.

thanks for pointing it out.

poisondeathray

8th February 2011, 01:27

because no one in the real world ever encodes "1 variable at a time". no one outside of a movie studio has access to uncompressed sources, no consumer level, or prosumer for that matter, camera that i know of records to an uncompressed format.

furthermore, taking a previously compressed source and decompressing it then running a test encode isn't really fair as you should really be counting the total processing time, work was done to decompress, that must be counted.

it's kind of like when muscle car magazine would take a gt 5.0 with 225hp and 300lb-ft torque and get acceleration figures that no one else could replicate, as low as high 13's in the quarter mile when everyone else was seeing mid 14's to low 15's.

what they were doing was taking out the back seat, reducing the tire pressure to 20 psi (to get better launch traction), they would use dry ice to cool off the intake, power shift every upshift and side step the clutch on take off.

that't not a realistic representation of how the average owner was going to be driving his car.

same thing here, the average user isn't going to have access to an uncompressed source, what they are going to do is "back up" a blu-ray to avchd.

as for the interlace issue, MBAFF is one of the more advanced features of h264 that result in greater quality, both progressive and interlaced have their drawbacks, this aims to get the best of both worlds.

.

Ok ...I was just asking for clarification. There were a lot of inconsistencies in your 1st post. You didn't specify interlaced or progressive. You implied interlaced, but encoded progressive??

So you're testing a workflow , what a "typical" user would use to encode interlaced, using an interlaced resize? Correct?

I just want clarification of what you're doing or set out to test.

as far as i'm concerned all blu-ray should be encoded as MBAFF

Considering Hollywood movies are usually shot on film (or digital cinema equivalent like Red), this makes zero sense...

deadrats

8th February 2011, 01:30

OK is see, but he's encoding interlaced and resized without deinterlacing? So it' s an interlace aware resize? or is he mashing fields ? Or is this 1280x720i29.97 ?

i don't know how one goes about de-interlacing MBAFF and to be honest i'm not sure that it's wise to do so, in a few tests that i did trying to de-interlace, no matter what i tried the resulting file looked like crap, this is true for both x264 and cuda.

as for whether the resize filter is interlace aware, i used lancsoz-3, so you tell me, is it interlace aware?

edit: i just redid the cuda encode and despite setting the frame rate to 29.97 the resulting file was again 59.97, anyone have any idea why that would be?

kolak

8th February 2011, 01:33

It may be because you use 720p, which is (by standard) either 50p or 59.94p.

Andrew

deadrats

8th February 2011, 01:34

Considering Hollywood movies are usually shot on film (or digital cinema equivalent like Red), this makes zero sense...

all i know is that to my eyes, the best blu-ray encodes i have come across are all MBAFF, just going with my own personal experiences.

kolak

8th February 2011, 01:35

Only 50i, 60i BD discs are encoded with MBAFF- they make maybe 5-10% of all BD discs (maybe less).
Quality has nothing to do with MBAFF- if your source is 50i or 60i every pro encoder encodes it with MBAFF, but it does not mean that quality is better than other 24p disc.

Andrew

poisondeathray

8th February 2011, 01:36

If you're looking for fast AVC encoding than check FireCoder Blu card from GV.
TMPEG 5 does support it- it's Spurs Engine- speed is very good, but quality only okish (but read some reports that x264 can't match quality/speed of FCB).
Speed is about 2 times faster than RT for full HD 60i.

Andrew

Is this a new version of firecoder blu card? Spurs Engine? or the same one that came out earlier about a year ago? The reviews I saw of when it came out were pitiful.

kolak

8th February 2011, 01:40

Same, but problem was with implementation (software part), not with actual hardware.
TMPEG 5 seams to expand its possibilities.

Andrew

deadrats

8th February 2011, 01:46

It may be because you use 720p, which is (by standard) either 50p or 59.94p.

actually tmpg allows you to set resolution independently of interlacing and it normally allows you to choose any fps you want, also it doesn't have a problem when x264 is set as the encoder.

i just tried a bunch of other resolutions and each time the cuda encoder wants to encode as 59.94, very odd.

kolak

8th February 2011, 01:48

So, it's a bug :)

Andrew

TheFluff

8th February 2011, 02:22

in the case of x264 i chose the "fastest" setting and in both cases the gop length was set to 18 with 2 b frames.

Disregarding everything else that is bizarre about your post (like the confusion about interlaced vs progressive) as well as the "test" (your chosen test parameters make it about as meaningful as trying to benchmark HDD I/O performance by browsing youtube and measuring how long it takes to load a video) itself, setting the GOP length to 18 is rather nonsensical, wouldn't you say?

I know you're trying to prove a point (more specifically, the point "zomg gpu accelerated stuff is the best thing since sliced bread"), and I'm not gonna say anything about that, but you could at least try to be intellectually honest about it.

TheRyuu

8th February 2011, 02:43

http://puu.sh/TSf

Use a better sharing site if you want us to take the time to actually look at the stuff.

protip: mediafire or speedyshare

mariush

8th February 2011, 02:44

Here's the source as a direct link, without loading time, at the maximum speed... http://rapidshare.com/files/446773538/Tia_Tanaka_-_Asian_Adventure_2.mkv

Another direct link but may not be fast for US as the server is in Holland, Europe: http://mplayer.savedonthe.net/test_files/ttaa2.mkv

If you'll wait about 25 minutes, I'll edit and post mediafire links here... if I'll still be able to.

For some reason, VLC reports this "sample" as 1000fps and MPC-HC won't even play it, and DirectShowSource says "render graph doesn't want to speak to me" or something similar as error.

I'll have to investigate this further, but anyway, the source is progressive, doesn't make any sense to talk about mbaff and interlaced and all that crap.

deadrats

8th February 2011, 02:50

I know you're trying to prove a point (more specifically, the point "zomg gpu accelerated stuff is the best thing since sliced bread"), and I'm not gonna say anything about that, but you could at least try to be intellectually honest about it.

on the contrary, i really wanted to see what kind of encoding speeds other users with different setups could get while achieving similar or better visual quality.

as for the gop length and b frame count, if i remember correctly dvd spec ntsc mpeg-2 used 18 frames per gop and 15 for pal, i was always of the school of thought that gop length should be the same for avc, i don't believe in gop lengths in the hundreds of pictures nor do i believe in too many b frames (that's only for people that get off on using as little bit rate as possible).

if people want to participate fine, if people view this as something they want no part of fine as well.

deadrats

8th February 2011, 02:51

Disregarding everything else that is bizarre about your post (like the confusion about interlaced vs progressive)

what "confusion" are you talking about?

deadrats

8th February 2011, 02:55

or some reason, VLC reports this "sample" as 1000fps and MPC-HC won't even play it, and DirectShowSource says "render graph doesn't want to speak to me" or something similar as error.

I'll have to investigate this further, but anyway, the source is progressive, doesn't make any sense to talk about mbaff and interlaced and all that crap.

not sure what you're talking about but i just tried it with media player classic home cinema x64 and it plays fine and media info has this to say:

General
Unique ID : 233863017932456092869136983601553855044 (0xAFF0610061F4BA02FF06AAA6FE9FD244)
Complete name : C:\Users\deadrats\Desktop\Tia Tanaka - Asian Adventure 2.mkv
Format : Matroska
File size : 345 MiB
Duration : 2mn 0s
Overall bit rate : 24.1 Mbps
Writing application : Lavf52.93.0
Writing library : Lavf52.93.0

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L4.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 2mn 0s
Bit rate mode : Variable
Bit rate : 23.2 Mbps
Maximum bit rate : 30.0 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 1 000.000 fps
Original frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : MBAFF
Bits/(Pixel*Frame) : 0.011
Stream size : 332 MiB (96%)
Language : English
Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177
Transfer characteristics : BT.709-5, BT.1361
Matrix coefficients : BT.709-5, BT.1361, IEC 61966-2-4 709, SMPTE RP177

Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Codec ID : A_AC3
Duration : 2mn 0s
Bit rate mode : Constant
Bit rate : 448 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 6.42 MiB (2%)
Language : English

note the scan type, MBAFF, i didn't pull this out of thin air.

TheRyuu

8th February 2011, 02:56

on the contrary, i really wanted to see what kind of encoding speeds other users with different setups could get while achieving similar or better visual quality.

as for the gop length and b frame count, if i remember correctly dvd spec ntsc mpeg-2 used 18 frames per gop and 15 for pal, i was always of the school of thought that gop length should be the same for avc, i don't believe in gop lengths in the hundreds of pictures nor do i believe in too many b frames (that's only for people that get off on using as little bit rate as possible).

if people want to participate fine, if people view this as something they want no part of fine as well.

There are these things called levels and profiles. If you're targeting a specific device pick one, if not I should be free to use whatever I like.

http://forum.doom9.org/showthread.php?t=154533

Blue_MiSfit

8th February 2011, 03:04

I like the idea behind this test. We need to work out some kinks in the concept though.

1) It seems like TMPGEnc will only let you output 720p60 from 1080i60 when using the CUDA encoder, or maybe 720i60? I'm not clear, but let's assume the former, since it's actually AVCHD compatible.
2) Resizing without regard for the interlacing will obviously destroy things. It probably bobs first, and then scales to 720p. We need to verify this somehow.
3) We need figures for vbv-maxrate and vbv-bufsize
4) 18 frame GOP is silly. I believe 1 full second is ok per the AVCHD spec?
5) 128kbps AC3 is a terrible idea. It will lowpass away everything. 192 kbps please, if we're using AC3.
6) Oh, no standardization on what type of hardware we're running on here!

Since speed is the goal, we should probably do the following:

1) Decode source using DGDecNV, along with its CUDA bobber and scaler to 720p60
2) Encode at ultrafast and get a baseline "max performance" number for hardware decode/scale. DGDecNV will likely bottleneck things, as its sweet spot is usually in the middle.
3) Replace DGDecNV with ffmpeg-mt or other fast software decoder. Replace processing steps with MT'd YADIF and BicubicResize. Again, encode at ultrafast to see "max performance" for software decode/scale.
4) Maybe try some other software processing options. I'm open to ideas ;)
5) At some point, x264 should easily match or exceed the speed provided by the CUDA encoder
6) Dial down settings to match speed, and then start looking at quality

Also, to avoid nerdrage, please avoid RapidShare ;)

I'll be playing on my 1.8GHz mobile i7 quad...

Thanks,
Derek

mariush

8th February 2011, 03:10

Maybe the upload was corrupted?

http://savedonthe.net/image/856/100fps.png

Actually look again in your own text paste, it says 1000 fps in your text also.

TheRyuu

8th February 2011, 03:12

Works for me. 29.97fps progressive says ffms2 and my eyes.

Since speed is the goal, we should probably do the following:

1) Decode source using DGDecNV, along with its CUDA bobber and scaler to 720p60
3) Replace DGDecNV with ffmpeg-mt or other fast software decoder. Replace processing steps with MT'd YADIF and BicubicResize. Again, encode at ultrafast to see "max performance" for software decode/scale.

The source is progressive, no need for any bobbing or deinterlacing.

TheFluff

8th February 2011, 03:14

what "confusion" are you talking about?

You do not seem to be aware of the nature of your content, only of its coding type (and that doesn't mean anything at all). Furthermore, you do not seem aware of what interlacing actually means, nor what the possible correct ways of handling interlaced content are, nor what a resampling filter might do to interlaced content, nor how interlacing affects encoding or decoding. In short, confusion.

on the contrary, i really wanted to see what kind of encoding speeds other users with different setups could get while achieving similar or better visual quality.

What are you trying to measure, exactly? There are so many uncertain factors and so many variables in this "test" that any data generated by it is essentially meaningless. Zed Shaw might be an asshole, but I strongly recommend his essay (http://www.zedshaw.com/essays/programmer_stats.html) about programming and statistics. It applies to encoder tests as well; see especially the section about confounding.

as for the gop length and b frame count, if i remember correctly dvd spec ntsc mpeg-2 used 18 frames per gop and 15 for pal, i was always of the school of thought that gop length should be the same for avc, i don't believe in gop lengths in the hundreds of pictures nor do i believe in too many b frames (that's only for people that get off on using as little bit rate as possible)

That's an interesting position to say the least. Would you perchance care to elaborate on your reasoning behind it, especially the GOP size? Have you done any tests that indicates it is beneficial? If so, in what way is it beneficial?

mariush

8th February 2011, 03:31

Yeah well, I used mkvextract to extract the video to a raw h264 stream, them used mkvtoolnix to create a mkv mentioning fps 29.97

T:\>x264.exe --bitrate 4096 --preset veryfast --no-interlaced --tune film --vide
o-filter resize:1280,720 -o t:\a.mkv "t:\testing.mkv"
ffms [info]: 1920x1080i 1:1 @ 30000/1001 fps (vfr)
resize [info]: resizing to 1280x720
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.1
x264 [info]: frame I:55 Avg QP:14.79 size: 50432
x264 [info]: frame P:2762 Avg QP:18.07 size: 18890
x264 [info]: frame B:783 Avg QP:19.07 size: 10281
x264 [info]: consecutive B-frames: 63.5% 21.6% 2.6% 12.3%
x264 [info]: mb I I16..4: 37.6% 48.8% 13.6%
x264 [info]: mb P I16..4: 24.8% 15.6% 0.4% P16..4: 29.8% 12.3% 5.6% 0.0% 0
.0% skip:11.6%
x264 [info]: mb B I16..4: 2.9% 1.5% 0.0% B16..8: 27.2% 9.2% 0.8% direct:
21.0% skip:37.4% L0:31.9% L1:45.9% BI:22.2%
x264 [info]: final ratefactor: 17.48
x264 [info]: 8x8 transform intra:38.5% inter:38.6%
x264 [info]: coded y,uvDC,uvAC intra: 47.7% 44.8% 7.5% inter: 22.8% 25.5% 0.7%
x264 [info]: i16 v,h,dc,p: 43% 20% 27% 9%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 20% 11% 50% 2% 4% 3% 3% 3% 3%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 31% 15% 21% 3% 8% 6% 5% 6% 5%
x264 [info]: i8c dc,h,v,p: 62% 16% 19% 2%
x264 [info]: Weighted P-Frames: Y:2.9% UV:1.6%
x264 [info]: kb/s:4195.64

encoded 3600 frames, 22.04 fps, 4195.68 kb/s

So it looks like plenty of room to get everything within 4:40. CPU wasn't even used much, it was stuck at around 70% on all four cores (q6600, 3.02 Ghz, 4GB ddr 2).. while watching a 720*576 h264 mkv on the second monitor.

Blue_MiSfit

8th February 2011, 03:51

Yes, the source is indeed progressive. Sure, it's encoded at 1080i60 with MBAFF, but the content is progressive. That means no deinterlace necessary! Sweet ;)

Also, the source levels have been crushed (i.e. instead of proper 16-235 it's actually roughly 32-215). But, whatever. It's porn, and fixing stuff like that is not within the scope of this test.

Derek

Biggiesized

8th February 2011, 03:57

mariush

8th February 2011, 04:08

Which one... the first is my own rapidshare premium account.

With a premium account, after uploading file, you can go in the File Manager and select Trafficshare and link will become direct (sort of, actually it's a redirect after clicking but same thing). You have a bandwidth amount and the traffic will be deducted from your monthly limit but I have about 50 TB of bandwidth saved up from months ago so it's not a problem.

The second is my own dedicated server...

poisondeathray

8th February 2011, 04:21

Besides the screwed up levels, patches of textures missing , there is aliasing everywhere (I suspect it was shot with low quality 60i HDV cam, then drop field deinterlaced), chromatic aberration from low quality optics, chroma noise. What a mess.

Are you sure this is original blu-ray?

all i know is that to my eyes, the best blu-ray encodes i have come across are all MBAFF, just going with my own personal experiences.

And considering your big stash of pr0n , I'm not so sure about the quality of your eyesight... :)

aegisofrime

8th February 2011, 04:39

I wonder how many people actually downloaded the file for the test rather than the content? ;)

Anyway, I sure hope somebody with an actual Sandy Bridge CPU could give Quick Sync a whiz. I recall Cruncher having one?

deadrats

8th February 2011, 04:55

That's an interesting position to say the least. Would you perchance care to elaborate on your reasoning behind it, especially the GOP size? Have you done any tests that indicates it is beneficial? If so, in what way is it beneficial?

after numerous encoding tests i arrived at the conclusion that too many b frames resulted in reduced over all quality, contributing to complaints of "frame beating" from many users of many codecs.

note i'm doing this from memory and considering how many ice cold ones i've sucked down i'm not really up to researching this to make sure it's 100 percent accurate:

i thought about it from an mpeg-2 standpoint and realized the following:

1) I frames are encoded using a compression scheme identical to jpeg/mjpeg and they contain all the data about a particular frame.

2) P frames are predictive frames and discard any data that is the same as the frame that came before it (or is it after it?).

3) B frames are bi-directional frames and only contain the difference between frames before and aft.

it became obvious to me that for maximum quality the closer you got to all the data the better, thus in an ideal world a video file would be solely I frames and lots of bit rate. unfortunately size constraints of various media, such as dvd's, necessitate the use of frame types where less bit rate can be used.

i then applied this reasoning to avc encoding and reasoned that if you were inclined to bit rate starve an encode then using a ton of b frames is the way to go since you would be keeping less of the original data.

conversely, if you want the maximum quality then you want to minimize the number of consecutive B frames and maximize the number of I frames.

since the data within a gop is derived from the I frame and processed from there, it made sense to me to stick with a dvd spec gop length for maximum quality.

using this approach, i've been able to avoid the dreaded "frame beating" with my cuda encodes (at least i don't notice them).

does this make sense?

mariush

8th February 2011, 05:06

No, because you're assuming h264 is as stupid as mpeg2 and you're not considering the advances in technology and algorithms implemented in a new compression system when you're making up limitations and restrictions and other rules.

What would starve mpeg2 may not starve h264 at all.h264 uses bitrate more intelligently, it needs less bits to store iframes, therefore it may be able to afford to spend more bits on b-frames or p-frames or even "upgrade" b-frames to iframes when it feels like it helps.

There's more than i/p/b in h264 by the way: http://en.wikipedia.org/wiki/Video_compression_picture_types

And read especially the part about differences between b-frames in MPEG 2 and b-frames in h264.

ps. You can see in my previous post how x264 used the b-frames:

x264 [info]: frame I:55 Avg QP:14.79 size: 50432
x264 [info]: frame P:2762 Avg QP:18.07 size: 18890
x264 [info]: frame B:783 Avg QP:19.07 size: 10281
x264 [info]: consecutive B-frames: 63.5% 21.6% 2.6% 12.3%
x264 [info]: mb I I16..4: 37.6% 48.8% 13.6%
x264 [info]: mb P I16..4: 24.8% 15.6% 0.4% P16..4: 29.8% 12.3% 5.6% 0.0% 0
.0% skip:11.6%
x264 [info]: mb B I16..4: 2.9% 1.5% 0.0% B16..8: 27.2% 9.2% 0.8% direct:
21.0% skip:37.4% L0:31.9% L1:45.9% BI:22.2%
x264 [info]: final ratefactor: 17.48

See this page which explains how to read that data: http://mewiki.project357.com/wiki/X264_Stats_Output

And this was for veryfast - for slow or veryslow presets I'm sure it would change.

Blue_MiSfit

8th February 2011, 05:07

does this make sense?

No.

P and B frames to a greater extent can be smaller than I frames, and deliver equivalent quality. Keyframe pulsing as you describe it is often attributed to a GOP that is too short. If you look at bitrate graphs for a video that has keyframe pulsing, you'll see big spikes for each I-Frames, since they have to be enormous to look good. Then (more importantly), you'll see the resulting P and B frames have very low bitrate, as the whole encode is starved by having to deal with lots of big I frames.

Long GOPs are good, lots of consecutive B frames are also good (to a point, for film content x264 will rarely use more than 4-5 consecutive). This is only really true if you have adaptive GOP, which x264 does a very good job of.

I'm still running numbers.

Derek

poisondeathray

8th February 2011, 05:14

If you set out to test what a "typical" user would use, why would you even adjust those settings?

Wouldn't the simulation be more realistic if they used default presets like "quality preset" or "speed preset" or whatever TMPGEnc has?

"Joe Public" would just pop the blu-ray in and wouldn't have a clue what MBAFF, interlaced, or I-frame is. They'd just push the button

Blue_MiSfit

8th February 2011, 05:22

Another word on consecutive b-frames, x264 decided (on fast settings) that the following was optimal b-frame placement:

x264 [info]: consecutive B-frames: 65.6% 20.6% 2.6% 11.2%

Those percentages refer to the number of consecutive b-frames, starting with 0, running through 3. x264 probably would have used more than 3 quite a bit, if we hadn't restricted it to 3 for AVCHD compliance.

Derek

deadrats

8th February 2011, 05:38

alright folks, because people are complaining about the original test source and even i had a few problems with it, i decided to up a different clip that should be easier to work with:

this source is from a web site, again legally purchased, it's 1080p at 8 mb/s, so there not a lot of margin for error when transcoding this.

a bit of a warning, if you have a problem with a hot chick in a sexy bikini teasing you, then don't download the sample, i'm fairly certain it's within the rules of this forum, though it may come too close to breaking them for some peoples tastes. if this does violate the rules, then just let me know and i will find something a bit more sanitized.

if this is to everyone's liking, we can set some test parameters, say going down to 720p at 4 mb/s with 192 kb/s audio?

my test encode used cuda resizing, decode and encode, ac3 audio at 192 kbs 44 hz, it took 1:06 to convert, source is 49 seconds. note that the audio is being transcoded as well from aac to ac3, again i wanted to simulate a "real world" task, something some people may actually do.

i also did a test encode with cuda doing the resizing and decoding and x264 set to fastest doing the encoding, it took 1:12 and i couldn't tell the difference between the cuda encode and the x264 encode.

disabling cuda completely and doing a software decode/resize with a x264 encode took 1:39 and from a quality standpoint it would be nitpicking to try and pick a winner.

as far as i'm concerned it would be silly to try and transcode this to 1080p at a lower bit rate, hell i don't see the point of paying for 1080p and then purposely going lower but this is just for testing purposes, normally i'd be inclined to tell people to just buy another hdd.

source:

http://rapidshare.com/files/446787690/Ashli_Orion_-_Elegant_Angel.mp4

test encode:

http://rapidshare.com/files/446788432/Ashli_Orion_cuda_resizing_decode_encode.mkv

Blue_MiSfit

8th February 2011, 05:57

JUST REALIZED MY SETTINGS WERE SLOWER THAN THEY NEEDED TO BE!!! I WAS FORCING 6 REFS. THESE TESTS ARE ARTIFICIALLY SLOW Please disregard these numbers and look at my next batch of tests.

OK here are some numbers from my wimpy little laptop.

Let's consider the following:

1) My system is a 1.73 GHz Core i7 Q820 quad-core (with HT) laptop. It has 4 GB of DDR3, A QuadroFX 2800M GPU, and runs Windows 7 x64. This should be comparable to deadrats' phenom, probably slower though I'm not sure.

2) Demuxing the source, transcoding the audio, and remuxing this finished audio with the finished encode took me a grand total of 30 seconds. Let's call it 44 seconds, so we have an even 4 minutes to transcode. This means that we must run at least 15fps for the speed to match the CUDA encoder.

3) CUDA tests below use DGDecNV for decode and scale.

4) Here's my example command line - which is the same in all cases, only adjusting the preset. This was taken from the x264 bluray encode guide and tweaked a bit:

c:\x264.exe test2.avs --preset ultrafast --tune film --bitrate 4000
--vbv-maxrate 40000 --vbv-bufsize 30000 --keyint 30 --level 41 --b-pyramid strict
--slices 4 --ref 6 --aud --pulldown double --sar 1:1 --nal-hrd vbr

By the way, 4mbps for this encode at 720p nets average QPs of roughly 15/17/20 (I/P/B). This is a piss poor measure of quality, but I usually don't worry until I see things in the mid 20s for P-Frames. It's a meaningless measure, but I would hardly consider this encode "bit starved". It's very simple content.

CUDA Decode and scale, ultrafast:
10% utilization
32 fps

CUDA Decode and scale, superfast:
20% utilization
32 fps

CUDA Decode and scale, veryfast:
40% utilization
32 fps

CUDA Decode and scale, faster:
100% utilization
28 fps

As you can see, DGDecNV is the bottleneck until we start using the "faster" preset. At this point, my CPU is fully saturated, and x264 becomes the bottleneck. At this point, however, we are still seeing 28fps.

CUDA Decode and scale, fast:
100% utilization
15.6 fps

OK, here's where I would call it even. 15.6 fps beats the CUDA encoder. x264 on --preset fast is really really good.

Now then, let's take a look at extreme cases, since CUDA bottlenecks us for very fast settings:

Switching DGDecNV out for ffdshow(ffmpeg-mt) decoding and MT-AviSynth bilinear resizing (for max possible speed) we see the following:

Software Decode, ultrafast:
100% utilization
55.6 fps

Software Decode, superfast:
100% utilization
44.7 fps

Software Decode, veryfast:
100% utilization
29.7 fps

OK at this point there is an advantage with CUDA decoding. That's the "sweet spot in the middle" I was talking about. All software gets us 29.7fps at "veryfast", while CUDA decode/scale gets us 32fps at the same x264 settings.

Still, consider that on a (fairly powerful, I'll admit) laptop, I can do 1080p30 to 720p30 at nearly 2x realtime using only software. Sure ultrafast preset is pretty ugly, but still! If I didn't have to decode a BluRay stream, things would be even happier!

The only thing that I think TMPGEnc could possibly offer over the traditional open-source workflow is a different filter chain. Maybe their CUDA scalers are much faster than AviSynth's. I doubt it though.

I'll submit the encode generated with the "fast" preset using CUDA decode and scaling for consideration, since it basically hits the target.

Derek

Blue_MiSfit

8th February 2011, 06:01

LOL just as I finish all that work to compare with your original example :devil:

Here's the link I promised, if anyone cares. Again, this is encoded with --preset fast, and matches your CUDA encode in speed.
http://www.mediafire.com/?d9bket7e6sklefa

I'll do more testing with your new sample. I'm genuinely curious as always.

Mind posting it on mediafire or somewhere other than rapidshit? I'm unavailable for a bit...

Derek

Blue_MiSfit

8th February 2011, 06:48

OK OK, back. God damn it I hate rapidshare.

http://i.imgur.com/5sS8C.png

I got the source at least.

I'm thinking this will definitely be transparent at 4mbps for 720p... There's like no detail here.

burfadel

8th February 2011, 07:01

Its a shame the compliance didn't allow for 5 b-frames, as that seems to be the typical number where the percentage is still high I have found when using --b-adapt 2. Higher than this the number drops off such as there may be only a fraction of a percent.

Keep in mind that if you were to have the possibility of 9 b-frames in a row, essentially you will have 3 consectuive b-frames, then a p-frame, then another 3 consecutive b-frames when set for compliance. Thats over-simplifying it a little, but the principle is there, in that the efficiency drop isn't as high as one may think. Keep in mind that in the 9 frame sequence above, with no b-frames there are 9 p-frames, with 3 consecutive b-frames, there are 2 lots of 4 b-frames and a p-frame, against having 8 consecutive b-frames which would allow for 8 9 b-frames. Having that p-frame in the middle does reduce efficiency slightly, however since they are in themselves a frame that represents changes, they aren't too bad size wise. Remember, having a large number of consecutive b-frames is unlikely anyway.

An issue with the above example is its more likely that you will have the need for say, 4 consecutive b-frames. In that scenario, the placement of the p-frames means that there may be few consecutive b-frames to the left or right of that p-frame, so the ratio of b-frames to p-frames increases for those sequences.

Problems with b-frames analysis in x264:
* --b-adapt 1 is the standard for most typical modes. This 'çlassic' x264 mode only works to a few b-frames, it supposedly misses optimal placement and use of b-frames
* --b-adapt 2 is the optimal method for b-frame decision. It uses an active method for finding placement, resulting in more efficient use and placement of b-frames. The problem with --b-adapt 2 is for each consecutive b-frame higher that is set, the slower it is due to the active method. At 3 b-frames, the search doesn't really affect performance and the results can be worthwhile. At 5 b-frames, a slight drop in performance can be noticed, however 4 and 5 consecutive b-frames can be signicantly better utilised. Any more than 5 b-frames, the consecutive b-frame number is very minimal and the slowness of the search isn't worth it for the average source.

In my opinion, --b-adapt 2 should be the default method, and be used under 5 b-frames. For over 5 b-frames, the 'classic' mode should be used. I'm unsure of the possibility of having such a hybrid mode, but if it were possible it would surely allay peoples hesitance to use it. So, for defualt settings you get the benefit of the optimal method, and for high b-frame numbers you get the perceived benefit after 5 b-frames of the faster 'classic' mode. In reality, the hybrid mode would rarely result in use of a b-frame, since even on optimal method more than 5 are rare, but if people want to set it to 16 b-frames, they're quite welcome to in that case. In 'classic' mode, despite the ability to set 16 b-frames, its very rare for more than 3 to be used. Remember, a consecutive percentage of 0.2% isn't really consequential.

Consecutive b-frames means the number of b-frames after the first, such that 2 consecutive b-frames means two after the first! Its why the first number in the stats is zero, as the stats actually refer to b-frame sequence presence. The first number means there's no b-frames to the left or right of that b-frame.

Blue_MiSfit

8th February 2011, 07:46

Ok, so here are my impressions on this new source.

1) It was probably encoded by something other than x264 (guessing Apple Compressor), at 8mbps using Baseline profile. This makes transcoding very interesting because 8mbps without CABAC decodes a whole shitload faster than 25mbps with CABAC.

2) It is extremely soft and has basically no detail

3) Scaling down to 720p and scaling back up to 1080p looks no different than the source. My bet is that this was shot on an HDV camera (1440x1080i native), then (poorly) deinterlaced and scaled to 1920x1080p30. Yuck.

4) All in all, I think that 720p at 4mbps is a cakewalk for this source. To really illustrate differences between encoders, I'd push this to 2mbps, but that's just me :devil:. In production, I would probably settle on ~4mbps.

Not a nice source by any means, but simple enough. The low bitrate CAVLC part is kind of fun too, because we can get really big transcode fps :D

Now, about my testing.

1) I'm on my desktop now, a rather long-in-the-tooth by today's standards, bone stock Intel Q6600 CPU running at 2.4 GHz. I've got 8GB of RAM and an nVidia GeForce GTX 460, whee! CPU performance is quite similar to my laptop in most cases. Oh, and Windows 7 x64 of course.

2) Let's establish a baseline for CUDA decode versus software decode. Simple enough:

I'm using the same x264 command line from above, minus --ref 6! Whoops!!!

x264.exe --tune film --bitrate 4000 --vbv-maxrate 40000 --vbv-bufsize 30000
--keyint 30 --level 41 --b-pyramid strict --slices 4 --aud --pulldown double --sar 1:1
--nal-hrd vbr --preset medium

DGDecNV ultrafast = 110 fps (50% usage)

DGSource(..., resize_w=1280, resize_h=720)

ffdshow ultrafast = 70.6 fps (100% usage)

dss2(...)
bilinearresize(1280,720)

So, we see a big win for CUDA decode on this very simple content. Keep in mind, CUDA decoding doesn't actually run on the GPU itself - it's the nVidia PureVideo ASIC. My GTX460 happens to have the latest version: VP4. Reference: http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD.29_GPUs

That's pretty smoking!

Here's the speed breakdown:

DG superfast = 84.7 fps
DG veryfast = 47.2 fps
DG faster = 30.8 fps
DG fast = 21.64 fps
DG medium = 18.5 fps

Here's the two encodes I think are most interesting:
x264 medium: http://www.mediafire.com/?3yglab8daed17vd
x264 superfast: http://www.mediafire.com/?md4cwhdxix8uaud

OK, so we've got a nice spread of results, ranging from 3.67x RT (for ultrafast) to .62x RT (for medium).

You indicated that your TMPGenc CUDA encode took 106 seconds total. Let's subtract 20 seconds for audio processing / mux. Realistically you could do it much faster than that, but let's bias in favor of the newcomer.

So, I have 86 seconds to encode a 49.883 second video. Let's split the difference and call it 50 seconds. This implies that we must transcode at or faster than ~.58x RT. Let's just call that .6x RT, or 18fps

In other words, my --preset medium encode qualifies as being "as fast as" the CUDA encode provided.

Let's do some visual comparison.

Starting with the CUDA encode on my 50" 1080p plasma, the first thing that stood out at me in motion was the subtle but consistent blocking on the girl's torso as she struts her stuff. This is also visible on the background. It's tough to see in a screenshot, but it's easily visible if you watch the source in motion. The second thing that I noticed right away was the ugly, blocky fades. Not end-of-the-world bad, but enough to make me blow a fuse.

To be fair, the CUDA encode had to deal with the TMPGEnc watermark, so that's no good. I'll ignore scenes where the watermark is visible to minimize the impact.

So the problems with the CUDA encode:
1) Fairly blocky girl / background
2) Fail fades

I checked the source, and though I expressed my dislike for this source, it's not horrible in these regards - mainly just soft. There is some blocking and problems in fades, but nothing like the CUDA encode.

So, let's see how x264 does on --preset medium, which in my case matched the performance of your GTS250 in CUDA. Actually, naaah let's really bias this in favor of CUDA by looking at the x264 superfast encode. Remember, this encode ran at 84.7 fps, which equals ~2.8x RT, which is about 5 times faster than the CUDA encoder.

Please, everyone be your own judge, and watch the videos. Screenshots are only here to give you a quick peek.

CUDA Static 1: http://i.imgur.com/xMAwa.jpg
x264 Static 1: http://i.imgur.com/jkcaU.jpg
CUDA Fade 1: http://i.imgur.com/wEHx8.jpg
x264 Fade 1: http://i.imgur.com/sdJb6.jpg
CUDA Static 2: http://i.imgur.com/o7eif.jpg
x264 Static 2: http://i.imgur.com/RLBbs.jpg

I think that makes the CUDA encoder look pretty damn bad, personally. It's not end of the world bad like some CUDA stuff I've seen, no epic fail, but nothing impressive, especially from the speed perspective.

The key bits here (for me) are that A) x264 performs HUGELY better on fades, and B) x264 retains more detail in static scenes, and tends to block less. And, in case you've forgotten, it encoded 5 times faster...

I'm getting this level of encoding performance from a 4 year old CPU, too. Sure, I'm helped out by CUDA decode, but a $40 GPU would be no different from my GTX 460 in this case.

Still, QuickSync is called QuickSync for a reason. It's for SYNC, where the goal is to transcode OMGFAST with reasonable quality. I'd be interested if (for example) my GTX 460 running a CUDA encoder could transcode this 8mbps 1080p sample to iPhone 4 / iPad compatible 720p at 10x realtime. I don't even care about the bitrate, I just want it to run THAT FAST, jive with iTunes, sync across to my device without issues, and look as close to the source as possible.

We're not there yet, with CUDA or with x264, at least not on consumer hardware.

YET

:devil:

I'm interested in pursuing this further though... I'm downloading the trial of TMPGEnc Video Mastering Works 5 now.

Derek

Blue_MiSfit

8th February 2011, 09:13

aegisofrime

8th February 2011, 13:21

One last bit...

Same tests, but at 2mbps:

CUDA (same speed as the 4mbps version): http://www.mediafire.com/?pgdx5826n0j6sl0
x264 superfast (98fps, or 5.4x faster than CUDA): http://www.mediafire.com/?8hdytwg33t4owa4

Yikes.

Very interesting! I think you can pretty much call this definitive. There's no reason to use CUDA, except in extreme situations like if you are running a GTX 580 on an Intel Atom system :)

Sharktooth

8th February 2011, 14:03

deadrats

8th February 2011, 15:16

finally we can end this discussion with a conclusion: GPU encoding sux b@ll$.
oh, wait, wasnt it already known? whatever... seriously, let's stick the tests so no more CUDA/GPU fanboys will make ppl waste their time...

2 things:

1) no one is twisting your arm to participate and i am certainly not a "fan boy", more like an A/C man.

2) i fail to see any evidence to support the claim of "gpu encoding sucking balls", i think most of the tests show comparable visual quality across the board.

3) some of the encoding speeds for x264 seem way to high and then i realized a couple of things: a) it seems those participants use intel cpu's and 2) they are all using cli versions of x264.

i'm wondering if this is skewing the results, if either intel cpu's have a superior SSE engine or if the x264cli versions they're using have performance patches and/or very aggressive compilation parameters.

i'd like that info from those that participated and used a cli version: what build is it, where did you get it, how was it compiled (compiler version, options, etc).

if they're using custom builds that certainly skews the results.

Sharktooth

8th February 2011, 15:49

1) clogging the forums or even hijaking discussions with your CUDA/GPU encoding very questionable theories is a way to piss me off (if you havent already noticed it, today im not in a good mood...)
2) no evidence? are you still talking? 5 times faster encoding with a 1.8GHz CPU and x264 has still BETTER quality... watch your mounth, coz you're trolling here...
3) there is no other official versions other than CLI and libx264. also x264 is well optimized for AMD cpus.
there are no compilation parameters that influence x264 speed so much since most (if not all) of the relevant code is written in assembly and compiler optimizations will result in less than 2% difference.
now, just accept the fact that you werent able to set up x264 correctly (also, as i said, CLI is the "official" encoding frontend) and GPU encoding sux.

Didée

8th February 2011, 16:03

There are no "magic speed tweaks". Most of the speed relevant parts are inline ASM anyway.

Perhaps you're posing the wrong question. Instead of asking "why is CLI encoding with x264 so fast", perhaps you should rather ask "why is x264 encoding so slow in TMpegEnc" ...

2) i fail to see any evidence to support the claim of "gpu encoding sucking balls", i think most of the tests show comparable visual quality across the board.
Might be related to the testing material. I've seen 4mbps rips that look better after encoding, than your source material before encoding ...

Or, perhaps it's just a matter of personal perception. Know this from my wife ... as long as you can tell apart George Clooney from Brad Pitt, the quality is good.

Motenai Yoda

8th February 2011, 16:03

only for replying..
with
mencoder.exe %1 -noskip -nosub -lavdopts threads=2:idct=3 -o %1_.mkv -of lavf
-lavfopts format=matroska -forceidx -ovc x264 -oac lavc -lavcopts acodec=ac3:abitrate=192
-vf scale=1280:720 -sws 0 -x264encopts frameref=1:bframes=0:deblock=false:cabac=false:weight_b=false:partitions=none
:8x8dct=false:me=dia:me_range=4:subq=0:trellis=0:aq_mode=0:chroma_me=false
:mixed_refs=false:direct_pred=none:b_adapt=false:b_pyramid=0 -channels 6 -af pan=2:1:0:0:1:-0.866:0.5:-0.5:0.866:0.707:0.707:0:0
1m07s
while with default (mencoder's)
mencoder.exe %1 -lavdopts threads=2:idct=3 -o %1_.mkv
-of lavf -lavfopts format=matroska -ovc x264 -oac lavc
-lavcopts acodec=ac3:abitrate=192 -vf scale=1280:720
1m52s
spec i7-920@stock, 6gb ddr3@1333, hd4650 1gb ddr2

some times ago I've tested mediaexpresso.. it's faster than x264 but with a low quality results... both software and GPU encoding. (ME Gpu 2m55s@24.6drf vs x264 3m50s@20.8drf)

mariush

8th February 2011, 16:07

He always fails to see any evidence the love of his life (cuda) sucks. I wouldn't be suprised by now to hear that he's actually color blind.
In addition, in ALL his tests we found much later that he actually used custom settings, different on Cuda and the x264, so it makes his tests pointless. The source material is also trash, a poor benchmarking one.

I could provide you with a test file that would stress both x264 and especially cuda if you want but to be honest, I don't see the point if he's not going to admit that cuda has lower quality for just a bit, if any, speed improvement.

Sharktooth

8th February 2011, 16:13

are you kidding too? x264 was able to outperform CUDA encoder speed by 5 times and still produced a better quality... on a 1.8Ghz CPU.

8th February 2011, 16:24

only for replying..
with
mencoder.exe %1 -noskip -nosub -lavdopts threads=2:idct=3 -o %1_.mkv -of lavf
-lavfopts format=matroska -forceidx -ovc x264 -oac lavc -lavcopts acodec=ac3:abitrate=192
-vf scale=1280:720 -sws 0 -x264encopts frameref=1:bframes=0:deblock=false:cabac=false:weight_b=false:partitions=none
:8x8dct=false:me=dia:me_range=4:subq=0:trellis=0:aq_mode=0:chroma_me=false
:mixed_refs=false:direct_pred=none:b_adapt=false:b_pyramid=0 -channels 6 -af pan=2:1:0:0:1:-0.866:0.5:-0.5:0.866:0.707:0.707:0:0
1m07s

Decoding speed is a bottleneck here. Try -lavdopts threads=8 and make sure your MEncoder is linked against ffmpeg-mt.

Why are you setting idct=3? Doesn't sound like a good idea to me.

And how about using presets instead of custom settings? MEncoder supports this now: -x264encopts preset=superfast
I wouldn't use ultrafast because it's sometimes worse than nvcuenc.

Motenai Yoda

8th February 2011, 16:43

Decoding speed is a bottleneck here. Try -lavdopts threads=8 and make sure your MEncoder is linked against ffmpeg-mt.

Why are you setting idct=3? Doesn't sound like a good idea to me.

my hd is a bottleneck, with high bitrate source, increase decoding threads don't increase speed...
edit:- it's increased a lot (~10fps)
also idct=3 is still IEEE-1180 compliant, which should I use?
(I use this batch for reencode avc fansubs to sap compatible avi, I do not care reach the highest quality)

And how about using presets instead of custom settings? MEncoder supports this now
on the man page isn't reported.

8th February 2011, 16:48

my hd is a bottleneck, with high bitrate source, increase decoding threads don't increase speed...

HDD might become a bottleneck for 25 Mbps video at 20x realtime decoding speeds, not 4x.
Are you sure the decoder is ffmpeg-mt? Which MEncoder build are you using?

also idct=3 is still IEEE-1180 compliant, which should I use?

I don't think the idct parameter is even used in the H.264 decoder; only MPEG-4 ASP. Just don't set it at all.

Sharktooth

8th February 2011, 16:50

leave the idct alone and use presets. even if it is not documented they're in. also, check if your mencoder is linked against ffmpeg-mt as nm suggested coz i really doubt your HDD is the bottleneck...

Didée

8th February 2011, 16:51

are you kidding too? x264 was able to outperform CUDA encoder speed by 5 times and still produced a better quality...
Better don't get hooked to that 5 times number. I cannot imagine THAT, something must've been mixed up. Back when I did some 720p comparisons with Nvidia's vanilla CUDA SDK encoder, I've had x264 (veryfast/superfast, not sure ATM) slightly faster than CUDA: CUDA was 94fps, x264 was 102 fps. That was on an i7-860 with an GT240, read: strong CPU, weak GPU. I'd rather rate them as ~roughly~ the same speed.

Sharktooth

8th February 2011, 17:00

probably TMpegEnc uses a different encoder.

poisondeathray

8th February 2011, 17:01

Yes, something is weird here.... it should be closer in speed (not 5x faster)

Kolak mentioned something about TMPG's x264 implementation, maybe it's buggered or needs a patch, maybe it's other encoders need fixing too

Thanks for the test results Blue_Misfit, I would like to see your results on TMPG as well - this would provide more information if it's an AMD/Intel issue or if TMPG screwed up that release

Did you use TMPEG 5?

Some quick tests, which I've done show that it's few times slower (for some reason) than x264 in CLI mode (same settings).

Motenai Yoda

8th February 2011, 17:17

it's the sherpya's p4-mt build
- audio=copy +ultrafast : decoding threads=8 => 86.18 | decoding threads=4 => 80.26 | decoding threads=2 => 54.93
- audio=copy +medium : decoding threads=8 => 34.99 | decoding threads=4 => 34.82 | decoding threads=2 => 33.99

my hdd's speed on long time sequenzial read/write is ~30MBps
it's a 24.1Mbps = 3MBps so it's shoud go at 10x ≈ 300fps (ignoring fragmentation and access&seek time)

Blue_MiSfit

8th February 2011, 21:05

I'll give TMPGEnc more work tonight.

With its CUDA encoder on my GTX 460, at both 2mbps and 4mbps for the second source file, I had total encode times of 1m22s, including the audio, mux etc. That's just piss poor.

I'll try its x264 mode tonight. As for the incredibad performance in this department within TMPGEnc, maybe their libx264 wasn't compiled with asm? :devil:That's one thing that I'd think could cause such a massive slowdown versus plain CLI.

The 5x faster number is pretty damning. Remember though, as I stated on my previous post - this was on my desktop, a 2.4 GHz Intel Core 2 Quad Q6600. Its performance in encoding has been shown to be quite similar to my 1.8 GHz i7 laptop though. The CUDA decode really helps a lot in cases like these.

Derek

InsulinJunkie

9th February 2011, 03:38

Is there a working source link (the ones he linked earlier are dead)?

Grabbed the MediaConverter 7 demo (although it had to download several auto-updates to get to the version that had QuickSync enabled), and I'll probably grab the TMPGEnc demo. I don't believe the version of DVRMSToolbox with QuickSync has been released for public consumption yet.

Blue_MiSfit

9th February 2011, 03:42

I'll push one up later tonight.

InsulinJunkie

9th February 2011, 06:02

I'll push one up later tonight.

Sounds good.

Tried a 5 minute snippet of a 720p OTA recording with MediaConverter to try and get a feel for the settings (and it's sort of limited for Intel QuickSync, which is no surprise given the intended audience).

aegisofrime

9th February 2011, 06:23

While everyone is comparing x264,and CUDA, I did a comparison of CUDA and Intel Media SDK.

Quick first impressions was that Intel Media SDK looked much better than CUDA at the same bitrate, however it was much slower. However that is mostly probably because I don't have a Sandy Bridge CPU. Does anyone know if the output would be the same, if it was done with a AMD CPU and a Sandy Bridge CPU?

Also, I was pleasantly surprised that TMPGEnc Mastering Works supports avisynth input. If I were to get a Sandy Bridge CPU that might replace some of my current workflows :)

InsulinJunkie

9th February 2011, 07:24

While everyone is comparing x264,and CUDA, I did a comparison of CUDA and Intel Media SDK.

Quick first impressions was that Intel Media SDK looked much better than CUDA at the same bitrate, however it was much slower.

I haven't gotten around to putting my GT 240 back in (using the IGP of the 2500K at the moment), but I was impressed with my quick test of QuickSync, considering my low expectations.

Took the first five minutes of DETROIT 1-8-7 (OTA recording, 720p60, MPEG2 video bitrate of ~16.3), saved it as an MPEG, and threw it at Media Converter. Not a lot of customising is possible (can't set a bitrate, just a constant quant, but it doesn't seem to matter what you enter anyways) - it spit out a file with a video bitrate of ~5 in 1:45, which works out to about 172fps.

Will do more thorough testing later (tomorrow or later in the week), but did feed the MPEG straight to r1884 x64 with --preset fast --tune film --crf 20, since I usually encode HD with CRF 20 or 21 and wanted to get a rough ballpark idea of the bitrate for comparison with QuickSync, and got a bitrate of 5785 and 46.87fps. --preset medium, bitrate of 5025 and 40.03 fps.

For watch-once transcodes (with really low power consumption), QuickSync doesn't seem so bad.

woah!

9th February 2011, 07:36

for me using my weapons of choice, i get a muxed mkv file after 1min 44secs using the x264 profile of medium. i would like to see the cuda result in the first post to compare but its not there any more.
i can post the file if needed, heres a screen shot of the encode window with stopwatch.

http://i.imgur.com/pqkOe.jpg

Blue_MiSfit

9th February 2011, 07:42

Here's the second porn source that deadrats provided:

http://www.mediafire.com/?cp36l1x51varm24

Disclaimer: there's some upper frontal female nudity here, so if you're offended by that sort of thing... well... don't download it :)

Now, on to comparison between TMPGEnc 5's built in x264, and x264 cli.

A few things
1) The TMPGenc version doesn't support one pass VBR, which is probably just as well. It does support one pass CBR, so that's what we'll test here

2) It's tough to know which options in the TMPGEnc GUI map to the x264 cli arcuments. Since we're going for max possible speed here, I tried my best to match x264 cli's --preset ultrafast

1280x720p29.97, BP@L4, 1:1 PAR, single pass CBR, 4mbps avg/max bitrate, automatic buffer size, CAVLC, "fastest" performance preset", GOP limited to 30 frames, 1 ref, 0 b-frames (auto-set by baseline profile), no scene change detection

These settings made an output in 1m 23s.

TMPGEnc reports that the CPU was used for 72.6% of the work, and CUDA was used for 27.4% of the work, likely for decode and scaling, IMO. During the encode, I saw about 60% CPU utilization.Disabling CUDA brought CPU usage up to an average of maybe 70%, but total encode time increased to 1m27s.

For reference, x264 cli set to CBR mode and ultrafast settings was able to push 111fps with roughly the same CPU utilization.

So then, TMPGEnc spent (let's subtract 23 seconds for the audio transcode and mux) about one minute on the encode. That means it ran at about 25fps.

25fps vs 111fps..... same CPU usage.....I think somebody either totally broke something, or compiled libx264 without ASM... yikes.

Derek

woah!

9th February 2011, 07:59

i'll suffer tho it... i do this for the good of this forum...

InsulinJunkie

9th February 2011, 08:05

I figured out MediaConverter a bit more - if you choose a resolution it allows you to set the bitrate.

Resizing to 1280x720, bitrate of 4 (actually came out ~3715), converting to MP3 (it doesn't seem to let you keep the audio as-is), and spitting out a MKV took 9 seconds. 1496 frames, so ~166 fps using QuickSync on a 2500K.

QuickSync test: http://www.mediafire.com/?nln6tb4dxcdt52r

woah!

9th February 2011, 08:23

ok with new source:

DG ultrafast = 110.56 fps
DG superfast = 110.43 fps
DG veryfast = 93.78 fps
DG faster = 71.13 fps
DG fast = 44.41 fps
DG medium = 42.80 fps

heres the Screens.

http://i.imgur.com/T5kro.jpg

http://i.imgur.com/JJ3p7.jpg

woah!

9th February 2011, 08:43

GodofaGap

9th February 2011, 10:35

@Blue_Misfit:

Without wanting to go into details, deadrats is indeed suspended?

7ekno

9th February 2011, 12:09

2) i fail to see any evidence to support the claim of "gpu encoding sucking balls", i think most of the tests show comparable visual quality across the board.

Seriously?!? You can't see "the blocks dancing" in the fades?!? You can't see the "blocks dancing" on flat backgrounds?!?

Yikes,
7ek

kolak

9th February 2011, 12:18

So then, TMPGEnc spent (let's subtract 23 seconds for the audio transcode and mux) about one minute on the encode. That means it ran at about 25fps.

25fps vs 111fps..... same CPU usage.....I think somebody either totally broke something, or compiled libx264 without ASM... yikes.

Derek

Yes- about 4x slower. Something is wrong with TMPEG 5.

Andrew

InsulinJunkie

9th February 2011, 23:01

Yes- about 4x slower. Something is wrong with TMPEG 5.

When I tried TMPGEnc after running MediaConverter 7, it was much slower than MediaConverter 7 even using hardware (Intel QuickSync) - about 35 seconds to MediaConverter's 9 seconds.

aegisofrime

10th February 2011, 02:48

Hmmm if everything is slower on TMPGEnc 5, could it be a trialware limitation perhaps? Just guessing.

Interestingly, when I encode with Intel Media SDK on my Phenom rig it says that it's using CUDA, despite me not having any filters on. Hmmm...

10th February 2011, 10:44

Interestingly, when I encode with Intel Media SDK on my Phenom rig it says that it's using CUDA, despite me not having any filters on. Hmmm...

Maybe it's using nvcuvid for hardware decoding.

LoRd_MuldeR

10th February 2011, 13:31

Hmmm if everything is slower on TMPGEnc 5, could it be a trialware limitation perhaps? Just guessing.

With a trial version you usually want to convince your potential customers to buy the full version. You don't want to scare them away :p

aegisofrime

10th February 2011, 16:51

With a trial version you usually want to convince your potential customers to buy the full version. You don't want to scare them away :p

Sometimes companies do the darnest things. It's one explanation I can think of for both TMPGEnc Quick Sync and x264 being slower than other implementations though.

Maybe it's using nvcuvid for hardware decoding.

I think I will give it a shot with a format that I know Purevideo doesn't support...

Blue_MiSfit

10th February 2011, 22:35

Could be the scaling. Anyone try feeding TMPGEnc an AviSynth script, pre-scaled?

Derek

kolak

10th February 2011, 23:01

My test was pure encode- no processing at all.
There is something wrong with TMPEG 5.

Andrew

InsulinJunkie

10th February 2011, 23:44

Just feeding both the 5-minute MPEG snippet of a 720p60 OTA recording, using QuickSync hardware transcoding to CBR 5000, it was much closer for the video transcode/audio encode/mux.

1:42 for Media Converter 7 trial
2:40 for TMPEG 5 trial.

CruNcher

12th February 2011, 19:46

Hi its not the best evaluation but its the only one that has samples available for all the top tier ISV Encoding applications (Cyberlink,Arcsoft,Elemental) and modes (including originals), please be aware that all the Applications use different Frameworks and for some GPU stuff own Encoder are used (especially you have to look out for Arcsoft GPU results they use their own Encoder Core (APP/CUDA) like Badaboom does for CUDA as well and their APP Encoder is currently totally borked (also their CUDA Encoder is not really working perfect they use a modified X264 with GPU support though it fails fast on high quantizers creating strange effects), so the ATI results inside MediaConverter 7 are currently the worst quality wise, seems to be a very early in Dev APP Encoder, that they always release such Alpha stuff out of their Labs into their Applications that get sold really surprises me).
QuickSync results are consistent throughout all ISV Applications (no surprise here).
Cyberlink uses the Default supplied Nvidia Encoder (inside the driver) but not the best tweaking for the profiles, and a at least stable APP Encoder compared to Arcsofts.
Elementals Badaboom 2.0 Alpha uses their own Cuda Encoder as well like Arcsoft and Mainconcept do it, its a more recent code version from their Professional Elemental Encoder line (Blue_MiSfit has some insights on it out of real life experience), so much better results then the old consumer Core we have plenty results of here on Doom9 from it.

http://www.tomshardware.com/reviews/video-transcoding-amd-app-nvidia-cuda-intel-quicksync,2839.html

Quick Sync shows that it has a much more efficient Motion Search where Nvidias Diamond search is often failing in more complex scenes Intels Quick Sync survives it but also Badaboom 2.0 Alpha has a better Motion Search for CUDA then Nvidias own Nvcuvenc now, but stability wise it's not up to Quick Sync, it comes close though imho :)

This is no scientific compare in any way, but we can surely say that at least Quick Sync has better Quality then Nvidias Nvcuvenc @ faster speeds, my own compare also with a well Enhanced Cuda Framework is still in the making :)

Also be careful not every sample from the THG test is usable or comparable as the ISV application use sometimes very strange profile settings for Devices and some samples are Baseline some are Main different levels it's a total mess to interpret ;)

Though comparing the samples between each ISV application is not really a good way either as the Frameworks (especially scaling in this case) can be completely different so the THG test is more a comparison between Frameworks and final results (of the individual ISV applications) then a Encoder Compare :)

So just from looking @ this even with all quirks i would say that

1st place = Quick Sync (not important in which Application all are Media SDK 2.0 based, though restricted to Vista/7 DXVA2, also output restrictions and currently chipset restrictions apply not very nice the whole environment it operates in currently)
2nd place = Badabom 2.0 Alpha CUDA/Nvidia CUDA (WinXP,Vista/7)
3rd place = Arcsoft CUDA (WinXP,Vista/7) (x264 core based, with some bugs @ high quantizers)
4th place = Cyberlink APP (WinXP,Vista/7) (quality is visually worse, needs quality improvements)
5th place = Arcsoft APP (WinXP,Vista/7) (a visual mess that needs heavy work, lots of bugs)

though a well tweaked x264 will beat all of them quality and most probably speed wise on Sandy Bridge especially using GPU Decoding via Intels IGP, so we just need DGMXFdec now, though would be Vista/7 only then ;)

This also shows that AMDs APP Encoder are not up yet to compete with either Intel, Nvidia, Elemental or Mainconcept (Quality comparable to Nvidias Encoder) all available AMD APP implementations tested are weak in comparison (Visual Quality lacks, have severe bugs, no surprising result either (except Arcsofts own APP Encoder results) seeing all the Doom9 tests done with AMDs GPU Encoder in the past and those results, also AMDs own H.264 Software Research isn't very advanced see MSU tests compared to Intel).

Also i would like to quote and comment something from the THG test

Another person concurred, saying, "give them time and they will get quality down." Both individuals have a fair point. Indeed, Sam Blackman, Elemental's CEO, is insistent that hardware-accelerated encoders will be just as good as their CPU counterparts given time. He further stated, "if you look at where we were with Badaboom two years ago versus where we are now, the amount of progress is so significant that its pretty clear that the trajectory of GPGPU encoders is one that is going to surpass CPU only in the very near future, if it hasn't already."

We will see improvements though till GPGPU Encoders reach X264 quality we most probably will be deep into X265/VP9 already ;)
And @ that time we gonna see if all the done research can be easily applied and taken on to the same level for GPGPU (or if H.265/VP9 will be even designed partly for it) if that happens we can say it makes no sense anymore to continue the CPU Software part if consumers could have this quality then available @ roughly the same timeframe in GPU Hardware inside the CPU :)
And yes it's exciting to see how that Develops in the Future :)

dansus

25th February 2011, 04:26

Are there any interesting projects that use Quick Sync yet? (apart from the usual big name brands which are typically useless)

Oh and Badaboom is now at 2.0 and Quick Sync enabled.

aegisofrime

25th February 2011, 04:53

Yes I just downloaded Badaboom 2.0.

My main beef with Badaboom 1.x, which I see they have not fixed in 2.0, is the lack of a "as source" resolution setting. I mean, in the immortal words of Jeremy Clarkson, how hard can it be?

In any case, stupidity aside I will be grabbing a few lossless clips and giving it a whirl.

However, so far I'm really giving the edge to TMPGEnc Mastering Works 5, because it supports Avisynth input and it's not "idiot-proofed" like Badaboom, trying to hold my hand by restricting the options that I have.

dansus

25th February 2011, 14:20

If someone with Quick Sync like to do a comparison of available tools, that would be useful.

pascalwil

26th March 2011, 19:52

What is --no-interlaced for?
Is it for Progressive?
If so is --interlaced correct for Interlaced?

Thanks

sneaker_ger

26th March 2011, 22:21

"--no-interlaced" is indeed for forcing progressive in case x264 misidentifies the content.
Use "--tff" or "--bff" for interlaced. (top field first/bottom field first)

pwnsweet

31st March 2011, 05:28

However, so far I'm really giving the edge to TMPGEnc Mastering Works 5, because it supports Avisynth input and it's not "idiot-proofed" like Badaboom, trying to hold my hand by restricting the options that I have.

Have you by any chance managed to get b-pyramids working in TMPGEnc Video Mastering Works 5? All the encoding tests I've performed in TMPGEnc have b-pyramid=0...

ilovejedd

20th April 2011, 20:43

Do we have PQ comparisons or even screenshots of 1080p videos encoded with Quick Sync and with x264? My search-fu is failing me...

benwaggoner

21st April 2011, 20:08

1st place = Quick Sync (not important in which Application all are Media SDK 2.0 based, though restricted to Vista/7 DXVA2, also output restrictions and currently chipset restrictions apply not very nice the whole environment it operates in currently)
2nd place = Badabom 2.0 Alpha CUDA/Nvidia CUDA (WinXP,Vista/7)
3rd place = Arcsoft CUDA (WinXP,Vista/7) (x264 core based, with some bugs @ high quantizers)
4th place = Cyberlink APP (WinXP,Vista/7) (quality is visually worse, needs quality improvements)
5th place = Arcsoft APP (WinXP,Vista/7) (a visual mess that needs heavy work, lots of bugs)
Have you looked at Main Concept's CUDA implementation yet? Any idea where it would rank? It's implemented in Expression Encoder 4 SP1. That drop was fast but definitely had lower compression efficiency compared to a dialed-up pure software encode. Main Concept CUDA doesn't do adaptive or reference B-frames, among other limitations. But they're working hard to improve it.

I'm personally still agnostic as to how useful a GPU codec implementation would be. The low-hanging fruit for GPU acceleration of compression is definitely in source decode and preprocessing. A TDeint+EDI implementation on GPU would probably be easier than doing a full codec, show a bigger performance gain, and not have any quality regressions. GPU is great for "embarassingly parallel" but an actual video encoder has a whole lot of dependiences on what's happening in past frames and other parts of the current frame.

There's been some interesting talk about using the GPU for an initial coarse motion estimation, and then using the CPU to do the actual refinement. This would be particularly useful in multibitrate encoding where 10 different encoder instances may be running at once, and so only doing motion estimation between areas already flagged as having matching could save a lot in CPU time and by loading fewer pixels into the memory cache per instance.

In the VC-1 Smooth Streaming encoder, we saved a bunch of encoding time by only needing a single encoder instance for the first pass, which could be used by an arbitrary number of second passe bitstreams at different bitrates and frame sizes. That's something that could probably be done entirely in GPU.