h264 encoding challenge

[deadrats]

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]

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

[poisondeathray]

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... ?

[kolak]

He didn't deinterlaced source- just resized.

Andrew

[poisondeathray]

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]

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

Andrew

[deadrats]

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]

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

[deadrats]

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]

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]

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]

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]

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


Andrew

[deadrats]

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]

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]

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]

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


Andrew

[deadrats]

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]

So, it's a bug :)


Andrew

[TheFluff]

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]

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]

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]

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]

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

what "confusion" are you talking about?

[deadrats]

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]

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]

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]

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]

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]

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]

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]

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]

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.

How'd you pull that direct link?

[mariush]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[aegisofrime]

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]

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...