Username:
B
I
U
S
"
url
img
#
code
sup
sub
font
size
color
smiley
embarassed
thumbsup
happy
Huh?
Angry
Roll Eyes
Undecided
Lips Sealed
Kiss
Cry
Grin
Wink
Tongue
Shocked
Cheesy
Smiley
Sad
<- 1  -   of 69 ->
--
--
List results:
Search options:
Use \ before commas in usernames
ballofsnow
2010-06-19 04:32:52 pm
I made some ninja edits to my post above, in case you didn't see it.
Mystery
2010-06-19 04:42:18 pm
--slow-firstpass is required because we're doing CRF first pass Cheesy
Otherwise it will end up using faster settings that are usually OK for a bitrate first pass, but since we're doing CRF we'll have to use --slow-firstpass or quality will suffer.
AFAIK, x264 always uses two decimals for both fps and kb/s.
ballofsnow
2010-06-24 02:22:53 pm
Another good thing is there's no warning about missing the bitrate due to hitting the min quant, so users won't freak out anymore.

I'm thinking of settling on one crf value for all video instead of the 17/19 we're doing now. I'm voting 17. Any thoughts? Filesize from crf 17 will still be lower than a video hitting min quant 19. Quality is about the same.
Mystery
2010-06-25 03:57:09 am
Well, it should look about lossless. So if it doesn't exceed the bitrate cap, I think it's a good idea.
x264 --preset veryslow --crf 17 should produce some very nice looking encodes  Tongue
ballofsnow
ballofsnow
Edit history:
ballofsnow: 2010-06-26 01:53:34 pm
2010-06-26 01:17:56 pm
There's probably a better and more accurate way to find the settings that the presets use, but I encoded a clip with all the presets then used mediainfo to pulled the info below. This is with crf then pass 2 on x264 r1659.

Code:
ultrafast
cabac=0 / ref=1  / deblock=0:0:0 / analyse=0:0       / me=dia  / subme=0  / psy=1 / psy_rd=0.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0  / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=0                                                                           / weightp=0 / keyint=250 / keyint_min=25 / scenecut=0  / intra_refresh=0                   / rc=2pass / mbtree=0 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=0

superfast
cabac=1 / ref=1  / deblock=1:0:0 / analyse=0x3:0x3   / me=dia  / subme=1  / psy=1 / psy_rd=0.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0  / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3  / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0                   / rc=2pass / mbtree=0 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

veryfast
cabac=1 / ref=1  / deblock=1:0:0 / analyse=0x3:0x113 / me=hex  / subme=2  / psy=1 / psy_rd=0.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=0 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0  / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3  / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=0 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=10 / rc=2pass / mbtree=1 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

faster
cabac=1 / ref=2  / deblock=1:0:0 / analyse=0x3:0x113 / me=hex  / subme=4  / psy=1 / psy_rd=0.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0  / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3  / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=20 / rc=2pass / mbtree=1 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

fast
cabac=1 / ref=2  / deblock=1:0:0 / analyse=0x3:0x113 / me=hex  / subme=6  / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3  / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=30 / rc=2pass / mbtree=1 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

medium
cabac=1 / ref=3  / deblock=1:0:0 / analyse=0x3:0x113 / me=hex  / subme=7  / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3  / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

slow
cabac=1 / ref=5  / deblock=1:0:0 / analyse=0x3:0x113 / me=umh  / subme=8  / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3  / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=50 / rc=2pass / mbtree=1 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

slower
cabac=1 / ref=8  / deblock=1:0:0 / analyse=0x3:0x133 / me=umh  / subme=9  / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=3  / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

veryslow
cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh  / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=8  / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00

placebo
cabac=1 / ref=16 / deblock=1:0:0 / analyse=0x3:0x133 / me=tesa / subme=10 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=0 / chroma_qp_offset=-2 / threads=12 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / constrained_intra=0 / bframes=16 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=2pass / mbtree=1 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / ip_ratio=1.40 / aq=1:1.00


Now, what to use...

Adhering to level 4.1 is a pain at high resolution/framerate. I'm testing a 1920x1200p@30fps fraps clip and it's just not possible. Frame MB size is limited to 8192 and 245760 per second. So my clip is 1920/16 * 1200/16 = 120 * 75 = 9000 which is 270000 in a second, or 540000 if the video happens to be 60 fps. All are too high. Anyway, 1920x1200 at 60 fps is pretty crazy... but it'll happen sooner or later and will hold us back eventually. We either tell people not to record games at such high resolution/framerate or throw away this whole hardware support craziness. I mean, most video would be hardware supported now, and probably for a long time, but there will be some videos that aren't hardware supported. The question is, should we really care so much about hardware support?
Mystery
2010-06-27 03:37:46 am
Regarding the quality settings.
I have pretty much been told that you choose the lowest preset you can stomach and adjust the crf value accordingly. Lower presets will give better quality at the same crf value, pretty much. Compare ultra fast to very slow at the same crf, for example. The ultra fast, for example, will look horrible compared to the veryslow.

But it's interesting to see that basically the only changes between veryslow and placebo is no fast pskip and 16 bframes instead of 8. I don't think bframes will be of that much use for video games, though.

Regarding the hardware support, is it an option to keep hardware compatibility for non-1080 games and not for 1080 games? Don't know if that is an option.
Not that I should have much say in the matter, but I have always been a fan of dropping support for pesky consoles which can never decode video properly. Again, don't take my opinion for an answer Smiley
ballofsnow
2010-06-27 09:55:14 am
Placebo uses the tesa motion estimation instead of umh. That's probably the biggest difference.

Anyway, really need an answer from nate about how to go forward with this. I believe we're already at the breaking point; at least one person at SDA is recording 1080i and deinterlacing to 1080p@60fps which goes over the frame MB rate by almost double.
Mystery
2010-06-27 12:31:43 pm
tesa shouldn't be that much difference. It's basically a dumb brute force method that is much slower than umh with little gain.
But we: hardware support, you're right. Let's wait for nate on that one.
nate
2010-06-29 04:18:31 am
i didn't know we even cared about hardware support except in the mq.
ballofsnow
2010-06-29 10:09:55 am
Huh?

Ok. Tongue

So other than MQ, I'll not specify any level and let x264 autolevel each video. Problem solved.
ballofsnow
ballofsnow
Edit history:
ballofsnow: 2010-07-01 12:06:32 pm
2010-07-01 11:51:11 am
Another thought about crf + pass 2: if any of LQ/HQ/IQ/XQ by chance use the exact same settings as each other, then you should be able to do the crf pass only once and bitrate pass 2 multiple times based off that crf pass.

I can see this being done for low resolution games where LQ and HQ are the same except for the bitrate cap. Or D1 games where HQ/IQ are the same... you get the idea.

On an unrelated note, watch out for this in later versions of x264.



May have to stick an assumeframebased line in the avisynth scripts.. but I would prefer to turn off this "feature" in x264.
Mystery
2010-07-01 12:15:23 pm
Quote from ballofsnow:
Another thought about crf + pass 2: if any of LQ/HQ/IQ/XQ by chance use the exact same settings as each other, then you should be able to do the crf pass only once and bitrate pass 2 multiple times based off that crf pass.

I can see this being done for low resolution games where LQ and HQ are the same except for the bitrate cap. Or D1 games where HQ/IQ are the same... you get the idea.

You mean for the same game, right?
But then, the idea is to NOT use 2-pass at all. You need to adjust the crf factor so that the 2nd pass is not necessary. It should serve as a backup.
Basically, doing one crf pass that yields the same bitrate as the crf + 2-pass will deliver the same quality, so it's useless to set the crf factor low and then complement with a 2-pass.

Quote:
On an unrelated note, watch out for this in later versions of x264.



May have to stick an assumeframebased line in the avisynth scripts.. but I would prefer to turn off this "feature" in x264.

No idea what that is. Although I don't deal with interlaced material, so that's not exactly stuff I'm good at.
ballofsnow
2010-07-01 12:39:44 pm
Quote from Mystery:
You mean for the same game, right?
But then, the idea is to NOT use 2-pass at all. You need to adjust the crf factor so that the 2nd pass is not necessary. It should serve as a backup.
Basically, doing one crf pass that yields the same bitrate as the crf + 2-pass will deliver the same quality, so it's useless to set the crf factor low and then complement with a 2-pass.

Yes, same game.. For example, if HQ and IQ by chance sends the exact same video to x264, IQ does a crf pass with a final bitrate of 4000 which is under 5000 then the second pass is not required. For HQ we can use the results of IQ's crf pass to do a bitrate pass 2 to meet HQ's bitrate cap of 2048. Even if IQ goes over 5000, we can still use its first pass results on IQ obviously but also HQ.

There will already be a mix of crf pass 1 only, and crf + pass 2. There's no way to know how complex the video will be, so leave the crf at 17 and do a pass 2 if needed.
Mystery
2010-07-01 12:47:06 pm
Yeah, reusing the stats file should work for different qualities if it turns out you need to cap the bitrate.
Ideally, we'd like to find some good crf factor that provides good quality for all games and preferably not exceed the bitrate cap. Otherwise we'll end up with some nice looking videos and some not.

But while we're at the topic... I don't know how you're doing it right now, but IQ and XQ are basically just HQ + extra bitrate. But what if the extra bitrate isn't needed? Do you still publish IQ/XQ? That you be a waste of space and time.
Using the new crf system, if you don't have to cap out HQ, then there should be no need for IQ/XQ, right?
ballofsnow
2010-07-01 01:21:48 pm
Quote from Mystery:
But while we're at the topic... I don't know how you're doing it right now, but IQ and XQ are basically just HQ + extra bitrate.

Not necessarily, it depends on the input. A 1080i/p input gets broken down into HQ/IQ/XQ 480p/720p/1080p. We're not too strict on the SD/HD definitions though. For example XQ uses native resolution, like my 1920x1200 sample I've been testing. One day people will be recording 2560x1600...

Quote from Mystery:
But what if the extra bitrate isn't needed? Do you still publish IQ/XQ? That you be a waste of space and time.

Yeah.. if IQ/XQ ends up with only slightly more bitrate than its subalternate quality version then we tell people not to bother. That's only if everything about the video is the same.

Quote from Mystery:
Using the new crf system, if you don't have to cap out HQ, then there should be no need for IQ/XQ, right?

Not sure where you're getting this idea from. We're still capping the bitrates, but in a smarter way now.
Mystery
2010-07-01 01:29:21 pm
Quote from ballofsnow:
Not necessarily, it depends on the input. A 1080i/p input gets broken down into HQ/IQ/XQ 480p/720p/1080p. We're not too strict on the SD/HD definitions though. For example XQ uses native resolution, like my 1920x1200 sample I've been testing. One day people will be recording 2560x1600...

Ah, I see. So IQ/XQ is necessary for HD material, but not for SD material.

Quote from ballofsnow:
Not sure where you're getting this idea from. We're still capping the bitrates, but in a smarter way now.

The idea was that with the new system, we can "see" how much bitrate is optimal for a video. So, if a video uses 1000 kbps and is SD, then there would be no need for IQ/XQ since they would only increase bitrate with little visual improvement.
Or you could lower the crf factor for them, to provide "better" visual quality then HQ. But then again, that might be totally unnecessary, since no one would be able to spot the difference.
And the fact that not all sources want the same crf probably makes this more tricky. Meh.
It was an idea, though.
nate
2010-07-19 10:38:18 am
found this today: http://forum.doom9.org/showthread.php?p=1073371#post1073371

looks like it could be used to combine the first pass of encoding with mvbob and the nmf write. marginal speedup given how long mvbob takes but marginal over a long period of time can translate to many hours saved.
ballofsnow
2010-07-21 04:28:20 pm
I don't understand. To LAGS or h264?
nate
2010-07-21 10:39:12 pm
lagarith yeah.
ballofsnow
2010-07-24 10:03:59 am
So how would this be faster than the current method?
nate
2010-07-26 09:58:07 am
good question, which i guess follows from the assumption that dumping nmf uses all cpu resources. for some reason i was thinking that was single-threaded even though i created and still use the system you implemented for it lol.

i guess if you ignore overhead and shit like context switching it still may actually improve performance because you are eliminating the i/o wait from reading the nmf for the first pass since you only have to read what you've written in terms of nmf for the second pass. but that improvement will only be significant if you have really bad hardware, really bad read, so bad that it would more than cancel out the speed loss from cpu overhead switching between nmf and first pass x264 encode. i can see this on some laptops but few desktops any more. maybe dell could sell you such a machine but no one would ever build one like that.

alternatively, the number of cpu cores minus one could be manually passed to x264 so one would be totally free for the first pass x264 encode. even on an eight core system the x264 dedicated core might be idle most of the time but it would kill the overhead loss especially on good amd or very recent intel hardware.

not actually suggesting we do any of these things lol. just thinking.
Aftermath
2010-08-07 08:55:27 pm
Quits halfway


Just wanted to ask about the MB rate warning. I get it with 1080i/1080p videos, saved in either huffyuv or lagarith. Not sure what other info I should specify, or if it's even a concern.
ballofsnow
2010-08-07 09:20:17 pm
http://speeddemosarchive.com/forum/index.php?topic=6256.msg330790#msg330790 and the next 5 posts.

Basically, don't worry about it unless you really care about keeping within the level 4.1 limit. (And if you do care there's not much you can do besides reducing resolution/framerate.) The code is already changed for the upcoming Anri 3.3 and you won't see the warning anymore.
Mystery
2010-08-08 03:39:18 am
What ballofsnow is trying to say is that your xbox 360 will just sneer at you and refuse to play your video unless you lower resolution/framerate, because that crappy little player can't handle perfectly normal 1080p with good quality Grin
The "warning" will go away in the next version because it's been decided to stop supporting those crappy players for all qualities except MQ IIRC Wink
tate
2010-08-20 04:01:52 pm
Silly question but how does tee.exe work? Does it just grab stdin and spit it back out to a file and stdout?