Batman Arkham Asylum Quality Test

2010-10-31 11:53:13 pm

The Dork Knight himself.

I'm currently working on a segmented run for Arkham Asylum and need to know if I'm using good quality settings.

Program: Avidemux
Video: x264, 2-pass, Avg Bitrate = 10,000, 1280x720 res, 60fps
Audio: AAC

Nightmare Sequence 1

I'm thinking that 10,000 avg bitrate might be going a little too low, possibly bumping to 15,000-20,000 for other segments (especially ones with more action).

Thread title:

Mystery

2010-11-05 07:42:20 am

When capturing, you should use lossless. When submitting, you should use SDA profiles.
10 mbps should be more than enough for 720p, but nevertheless, it's not a good idea.
Firstly, you should be capturing lossless if possible.
Secondly, you should be using CRF when compressing otherwise. 17 or lower CRF will provide excellent quality for any video.

honorableJay

Edit history:

honorableJay: 2010-11-05 02:15:29 pm

2010-11-05 01:24:17 pm

The Dork Knight himself.

Well this is the pc game, so I have to capture with Fraps (which rules out capturing lossless). As for using CRF, Avidemux implements it slightly different. When I try using it, I have to adjust a quality slidebar from 0 (worst) to 100% (best). I'm assuming when you say use 17 or lower means to use 70% or higher for me. But I'd prefer not to use that method since the videos I get seem to lose a lot of crispness. ***Edit*** Whoops, just checked it again, the slider is reversed. 0 is best, 100 is worst. DOH!!!

In case anyone is wondering, yes I do have anri-chan. Yes I do know how to use it. The problem I have is the glacial pace at which it encodes. I've found that I can encode videos 2-3 times faster with Avidemux while getting the same quality. I'm not sure why, but anri refuses to max out my proc (35% usage on a 3.2ghz Q6600) and does both the first and second passes at only 16.88fps. Rendering a 5 minute clip takes almost 4 hours for both passes to complete, yet is done in just shy of 40 mins in Avidemux (maxes out my proc, renders at about 30fps). If there's a hidden setting in anri-chan or some way to get it to max out my proc to save render times please let me know (would make encoding so much easier). If there is no way, could someone list the specific rendering options that anri-chan uses for x264 so I can make an Avidemux profile? Both would save tons of time and headaches.

Well this is the pc game, so I have to capture with Fraps (which rules out capturing lossless). As for using CRF, Avidemux implements it slightly different. When I try using it, I have to adjust a quality slidebar from 0 (worst) to 100% (best). I'm assuming when you say use 17 or lower means to use 70% or higher for me. But I'd prefer not to use that method since the videos I get seem to lose a lot of crispness. ***Edit*** Whoops, just checked it again, the slider is reversed. 0 is best, 100 is worst. DOH!!!

In case anyone is wondering, yes I do have anri-chan. Yes I do know how to use it. The problem I have is the glacial pace at which it encodes. I've found that I can encode videos 2-3 times faster with Avidemux while getting the same quality. I'm not sure why, but anri refuses to max out my proc (35% usage on a 3.2ghz Q6600) and does both the first and second passes at only 16.88fps. Rendering a 5 minute clip takes almost 4 hours for both passes to complete, yet is done in just shy of 40 mins in Avidemux (maxes out my proc, renders at about 30fps). If there's a hidden setting in anri-chan or some way to get it to max out my proc to save render times please let me know (would make encoding so much easier). If there is no way, could someone list the specific rendering options that anri-chan uses for x264 so I can make an Avidemux profile? Both would save tons of time and headaches.

Mystery

2010-11-05 01:31:22 pm

You would use the constant rate factor setting in Avidemux. It allows you to choose a number.
But the encoding settings aren't everything. Anri also handles things such as deinterlacing. I definitely cannot help you on that, but ballofsnow might help you with settings and anri-specific stuff.

nate

2010-11-05 05:17:19 pm

are you using nmf in anri?

Aftermath

Edit history:

Aftermath: 2010-11-05 07:15:35 pm

2010-11-05 07:11:23 pm

Quits halfway

I don't see why deinterlacing would be an issue, his source is progressive. I just tested it with a 720p capture, and get the same problem. It seems likely that at lower qualities, the resizing thing can only use one core, so it doesn't use anything more than that. At higher qualities, it's limiting it to two cores for some reason, which I don't seem to remember happening with nmf'd 480i/1080i sources. Weirdly enough, processing the 720p video as a console recording made it go about 30% faster compared to saying it was a screen capture.

Maybe you could give meGUI a try? I know that it always maxed my cpu (unless I was resizing or something), and you'd be sure to get the correct profiles for SDA (and the results looks good). Here are the SDA profiles if you want to look at or use them.

honorableJay

2010-11-05 08:00:30 pm

The Dork Knight himself.

Quote from nate:

are you using nmf in anri?

I thought by default anri uses nmf? If not, how do I enable it? Unless I missed it, there was no question asking if I wanted to use nmf at all. The last version of anri was much faster with lower quality encodes (I believe it was 3.1, maxed out my cpu) but only when it hit HQ did things slow down (which didn't have to resize oddly enough).

Quote from Aftermath:

It seems likely that at lower qualities, the resizing thing can only use one core, so it doesn't use anything more than that. At higher qualities, it's limiting it to two cores for some reason....

Not sure if that's the case. For me, it was using all 4 of my cores, just not really tapping them fully. Rather than having 1 core at about 80% usage and the others idle, all 4 were at 35% usage. I'm gonna load up meGUI and see if I get any better results. The latest encode that I started last night took way too long so I must have something messed up. Using 229Gb of raw Fraps avi's (69 files in total, all of em 1280x720@60fps) took a total of about 13-ish hours for a lq encode. Half of that was on the first pass, the other on the second. Now normally I wouldn't think anything was wrong seeing how it was chugging through 2 hours of video, but again it barely touched my cpu and when it started with a mq encode it had to do the first pass over again (which is when I shut it down seeing another 6 hours for the first pass). I thought the first pass was to analyze the original video for better compression during the second pass. If so, why require the encoder to do the first pass again when making multiple encodes in one sitting?

Another thing I was wondering: is nmf really necessary if the user is processing Fraps recordings? According to the KB the nmf is saved losslessly with a huge bitrate, essentially the same thing that a Fraps video is captured at. Does the "light" compression Fraps uses during capture play havoc with the encoder? If nmf isn't needed, maybe the user should be prompted with a "Is the source Fraps," have one of the source vids scanned for dimensions/aspect ratio to skip the widescreen question, and go straight to the questions relating to which qualities to encode.

I've also attached the avs/logs from the 13 hour encode, hopefully someone can make sense out of them.

[quote="nate"]are you using nmf in anri?[/quote]

I thought by default anri uses nmf? If not, how do I enable it? Unless I missed it, there was no question asking if I wanted to use nmf at all. The last version of anri was much faster with lower quality encodes (I believe it was 3.1, maxed out my cpu) but only when it hit HQ did things slow down (which didn't have to resize oddly enough).

[quote="Aftermath"]It seems likely that at lower qualities, the resizing thing can only use one core, so it doesn't use anything more than that. At higher qualities, it's limiting it to two cores for some reason....[/quote]

Not sure if that's the case. For me, it was using all 4 of my cores, just not really tapping them fully. Rather than having 1 core at about 80% usage and the others idle, all 4 were at 35% usage. I'm gonna load up meGUI and see if I get any better results. The latest encode that I started last night took way too long so I must have something messed up. Using 229Gb of raw Fraps avi's (69 files in total, all of em 1280x720@60fps) took a total of about 13-ish hours for a lq encode. Half of that was on the first pass, the other on the second. Now normally I wouldn't think anything was wrong seeing how it was chugging through 2 hours of video, but again it barely touched my cpu and when it started with a mq encode it had to do the first pass over again (which is when I shut it down seeing another 6 hours for the first pass). I thought the first pass was to analyze the original video for better compression during the second pass. If so, why require the encoder to do the first pass again when making multiple encodes in one sitting?

Another thing I was wondering: is nmf really necessary if the user is processing Fraps recordings? According to the KB the nmf is saved losslessly with a huge bitrate, essentially the same thing that a Fraps video is captured at. Does the "light" compression Fraps uses during capture play havoc with the encoder? If nmf isn't needed, maybe the user should be prompted with a "Is the source Fraps," have one of the source vids scanned for dimensions/aspect ratio to skip the widescreen question, and go straight to the questions relating to which qualities to encode.

I've also attached the avs/logs from the 13 hour encode, hopefully someone can make sense out of them.

Attachment:

baa-testrun-avslogs.zip

honorableJay

2010-11-05 11:43:14 pm

The Dork Knight himself.

Just did a quick encode test comparing anri-chan 3.2 to Avidemux. Total video playtime is 1:15. Source file is 1280x720@60fps.

anri-chan: hq settings (two-pass, 2048 bitrate, res 856x480, 60fps)
encode rate: avg 23fps
total time: roughly 5 minutes

Avidemux: sda hq settings (two-pass, 2048 bitrate, res 852x480, 60fps)
encode rate: avg 46fps
total time: roughly 2 minutes

The resolutions were supposed to match up, but I couldn't get 856x480 in Avidemux until I unlocked the pixel ratio before resizing. Anri-chan used up a bit more cpu power during the first pass, and maxed it out during the second pass. However the encoding frame rate was still only 23fps. The only changes from the last encode were: changed the base project home to my secondary drive, answered no to the widescreen question, and chose HQ over LQ. Doing a side by side playback of the videos doesn't show why the Avidemux video rendered twice as fast since they both look practically identical (the only noticeable difference is I increased the brightness a little for the Avidemux encode). Also, the file sizes are almost the same (anri = 20538152 bytes, avidemux = 20594994 bytes). Both vids can be found here for comparison. I'm attaching another zip file to the post showing all of the video settings the x264 encoder is using in Avidemux.

Just did a quick encode test comparing anri-chan 3.2 to Avidemux. Total video playtime is 1:15. Source file is 1280x720@60fps.

anri-chan: hq settings (two-pass, 2048 bitrate, res 856x480, 60fps)
encode rate: avg 23fps
total time: roughly 5 minutes

Avidemux: sda hq settings (two-pass, 2048 bitrate, res 852x480, 60fps)
encode rate: avg 46fps
total time: roughly 2 minutes

The resolutions were supposed to match up, but I couldn't get 856x480 in Avidemux until I unlocked the pixel ratio before resizing. Anri-chan used up a bit more cpu power during the first pass, and maxed it out during the second pass. However the encoding frame rate was still only 23fps. The only changes from the last encode were: changed the base project home to my secondary drive, answered no to the widescreen question, and chose HQ over LQ. Doing a side by side playback of the videos doesn't show why the Avidemux video rendered twice as fast since they both look practically identical (the only noticeable difference is I increased the brightness a little for the Avidemux encode). Also, the file sizes are almost the same (anri = 20538152 bytes, avidemux = 20594994 bytes). Both vids can be found [url=http://www.filefront.com/17481830/encodetest.zip/]here for comparison[/url]. I'm attaching another zip file to the post showing all of the video settings the x264 encoder is using in Avidemux.

Attachment:

demuxsettings.zip

ballofsnow

Edit history:

ballofsnow: 2010-11-07 12:14:46 pm

ballofsnow: 2010-11-06 09:06:22 pm

ballofsnow: 2010-11-06 10:38:03 am

ballofsnow: 2010-11-06 10:37:51 am

ballofsnow: 2010-11-06 10:11:16 am

ballofsnow: 2010-11-06 10:10:37 am

ballofsnow: 2010-11-06 09:53:35 am

ballofsnow: 2010-11-06 09:53:25 am

ballofsnow: 2010-11-06 09:53:06 am

ballofsnow: 2010-11-06 09:48:04 am

2010-11-06 09:46:25 am

AviSynth is a bottleneck, looking into it.

continued in anri thread
http://forum.speeddemosarchive.com/post/anrichan_1547.html#anrichan_1547