I thought crf=2 pass

[Chengbin]

I encoded two videos, using the same settings, except keyint is 1000 in crf and 250 in 2 pass. The 2 pass encode is 1497Kbps and the crf is 1470kbps. I thought if the final size is the same, crf=2 pass in terms of quality. In this video, at 33:30 there is an I frame, at 33:36 there is another I frame. But I noticed that in the 2 pass encode it has another I frame at 33:32, which should have an I frame, but in the crf encode there wasn't an I frame at 33:32. This resulted in the 2 pass encoding having a higher quality image at that time, and even quite noticeable on a 5'' screen (!) . Can someone explain?

[nurbs]

CRF and 2 pass won't give you the same file. I think even two encodes with exactly the same settings won't result in the same file if you use multiple threads.
I remember Dark Shikari posting that the encoder uses among other things the distance of the current frame to the maximum keyframe interval to decide if it should put an I frame or not, so if thats true changing the maximum keyframe intervall should have some effect on the position of I frames. I could be wrong and maybe he said distence from the minimum keyframe interval.

Your other settings would be interesting as well.

[Sagekilla]

It's also possible that on your 2nd pass, x264 determined it was (and rightfully so) beneficial to place that extra I-frame.


Have a second pass is almost always beneficial, since x264 gets a second shot at analyzing for the optimal frame placement.

[nurbs]

IIRC frametype decision is done in first pass, so frame placement doesn't change on the second.

[LoRd_MuldeR]

It's also possible that on your 2nd pass, x264 determined it was (and rightfully so) beneficial to place that extra I-frame.

I think that x264 does the frame-type decision during the first pass and doesn't alter frame-types during the second pass.

[Sagekilla]

Hm, why would he get an extra I-frame in the second pass then? Could that just be from the changed keyint?

[Chengbin]

Is it good to have a high keyint value if you don't care about seeking? Correct me if I'm wrong. I think keyint x means that x is the maximum amount of frames x264 can go without putting an I frame. And seeking can only seek in I frames. Having a higher keyint value can mean higher compression because maybe in some extended static scenes x264 don't have to waste bits on another useless I frame.

I'm running another crf encode now, with keyint changed to 250, and see if it makes a difference.

[nurbs]

Higher keyint helps compression, but the gains get less the higher the intervall is, so the difference between say 100 and 250 is probably much higher then when you go from 250 to 1000. Also there can always be situations where the encoder puts a keyframe where it probably shoudn't.

[Sagekilla]

High keyint is useful when you have sequences like a camera pan or a static scene, or even animated content. Like nurbs said though, the compression gains are usually very small. Unless you're encoding video from a security camera, there's not much to be gained from using absurdly high keyints (i.e. --keyint 9999)

[Chengbin]

IMO animated content gets some benefit using high keyint (especially Family Guy).

Here are the settings for the crf and 2 pass videos

crf

cabac=1 / ref=6 / deblock=1:-1:-1 / analyse=0x1:0x111 / me=umh / subme=9 / psy_rd=1.0:1.0 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-4 / threads=6 / nr=0 / decimate=1 / mbaff=0 / bframes=4 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=1000 / keyint_min=25 / scenecut=40 / rc=crf / crf=22.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

2 pass

cabac=1 / ref=6 / deblock=1:-1:-1 / analyse=0x1:0x111 / me=umh / subme=9 / psy_rd=1.0:1.0 / mixed_ref=1 / me_range=32 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / chroma_qp_offset=-4 / threads=6 / nr=0 / decimate=1 / mbaff=0 / bframes=4 / b_pyramid=1 / b_adapt=2 / b_bias=0 / direct=3 / wpredb=1 / keyint=250 / keyint_min=25 / scenecut=40 / rc=2pass / bitrate=1497 / ratetol=1.0 / qcomp=0.60 / qpmin=10 / qpmax=51 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=25000 / vbv_bufsize=14000 / ip_ratio=1.40 / pb_ratio=1.30 / aq=1:1.00

The keyint 250 crf encode will be finished in 4 hours. I'm also doing another test with that video too (how much me=tesa + p4x4 actually helps), so 2 tests in one.

I'm curious, how does x264 encode a conversation between 2 people. For example, 2 people have a conversation together, the camera switches between the 2 people say like every few seconds, same background scene every time. Does x264 use an I frame every time the camera switches to another person or will it make a reference to the frames before?

[nurbs]

IMO animated content some some benefit using high keyint (especially Family Guy).
I guess the benefit is bigger on animation, just like it is with reference frames, but I really don't think it's significant enough to warrent the loss in seekability. Saggitaire once mentioned that the difference between a keyint of 24 and an infinite lenght would only be around 10% of the bitrate, and most of it will probably already be included if you go up to 250.
Personal opinion on tesa: not worth it, but probably also better on animation. I like umh.

[LoRd_MuldeR]

Hm, why would he get an extra I-frame in the second pass then? Could that just be from the changed keyint?

I'm pretty sure frame-type decision happens in the first pass. That's also the reason why "--b-adapt 2" can slowdown the first pass a lot, when using a high number of b-frames, but it doesn't effect the second pass' speed. Consequently the "--keyint" and "--min-keyint" options should have no effect when "--pass 2" is specified...

[Sagekilla]

Yes, I realize that b-adapt 2 slows down first pass. But my question is why the frame type changed from pass 1 to pass 2.

[Chengbin]

We'll find out in 2 and a half hours when the keyint 250 crf encode is done. If it puts a I frame at 33:32 like the 2 pass encode, then problem solved. But we're left with the question why does a keyint of 250 put a I frame at 33:32 between 33:30 and 33:36 when an keyint 1000 doesn't. If that crf encode still doesn't put an I frame there, then we can wonder about frame type decisions.

Maybe Dark Shikari can chime in here when he's online, hopefully, and explain this to us.

BTW, how do you know if a frame is an I frame on the computer? I use MPC-HC and it doesn't tell. I know where are the I frames because my Archos 5 only seek in I frames.

[LoRd_MuldeR]

BTW, how do you know if a frame is an I frame on the computer? I use MPC-HC and it doesn't tell. I know where are the I frames because my Archos 5 only seek in I frames.

Play the stream in DGAVCIndex -or- use ffdshow's "frame type" OSD option -or- use H.264 Visa ;)

[nurbs]

Yes, I realize that b-adapt 2 slows down first pass. But my question is why the frame type changed from pass 1 to pass 2. I am pretty sure my first post in this thread explains why.

[kemuri-_9]

most of everyone is seemingly confused by his initial post of '2pass w/ keyint=250, and crf w/ keyint=1000'.

i read that as he did two completely different encodes:
one using 1pass (abr) w/ keyint 250, and then running a 2nd pass on that.
and another with crf w/ keyint 1000.

and nurbs is correct in that IDR/I frames are placed based with a decision algorithm that uses the %difference between the
(current_frame - last_I/IDR_frame) and keyint values.
I/IDR frames are more likely to be placed as the current GOP size reaches the keyint value.
this is only if scenecut is enabled though.

that's why the crf w/ keyint=1000 and 2pass w/ keyint=250 (can and did) have a difference in IDR/I frames.

and on 2nd/3rdpasses, all frame decisions are kept from the stats file as is.
the only way to change the decisions for the 2nd pass from 1st pass is to actually edit/hack the stats file before encoding the 2nd pass.

[Chengbin]

OK, the CRF encode finished. The file was actually 3MB bigger. Maybe keyint 250 did that, and it also showed me=tesa and p4x4 does next to nothing.


Back to business. The new CRF encode now puts a I frame there.

[nurbs]

You do know that you can't take size changes in crf mode to determin wheter and how much an option increases or decreases quality, right? Has been discussed to death, use search.

[Chengbin]

You do know that you can't take size changes in crf mode to determin wheter and how much an option increases or decreases quality, right? Has been discussed to death, use search.

Yes, but we can agree that me=tesa and p4x4 does do next to nothing.

[nurbs]

Well yeah. With tesa the quality gain compared to the encoding speed increase isn't worth it on any source in my opinion, but p4x4 isn't really slower IIRC and if it doesn't help (much) it won't hurt either.

[Chengbin]

Is there a way to get x264 to use more bits in motion? Many scenes without too much motion looks incredibly detailed, even in very low bitrate, but motion look terrible in low bitrate (of course). I really love and hate this screen. I really don't want to use the minimum 1500Kbps to fully take advantage of the capability of this little 5'' screen. I'm spending way too some time on this:D.

[Chengbin]

Well yeah. With tesa the quality gain compared to the encoding speed increase isn't worth it on any source in my opinion, but p4x4 isn't really slower IIRC and if it doesn't help (much) it won't hurt either.

It takes 25% more processing power of my quad. So if I'm not running MVDegrain 3, it is 25% slower.

[nurbs]

Are you talking about p4x4. Has been some time since I tested options, but I don't think there was much speed difference on my dual core. You can raise qcomp if you want more bits in the high motion sceens. Of course static sceens will have less bitrate then.

[LoRd_MuldeR]

Yes, but we can agree that me=tesa and p4x4 does do next to nothing.

Tell us something new ;)

It takes 25% more processing power of my quad. So if I'm not running MVDegrain 3, it is 25% slower.

x264 will always take 100% processing power of your Quadcore, unless you bottleneck it with slow input and/or use insane settings (e.g. b-adapt 2 + high bframe count).

Also looking at the CPU load in Taskmanager is not a valid speed measure.
If you want to do a proper speed measure, run two encodes of the same source. Once with "--analyse all" and once without "--analyse" (default). Then compare at the "fps" numbers!
Of course you must use the identical source and all other settings must be identical too...

[Chengbin]

Yeah, I meant p4x4.

[Chengbin]

Tell us something new ;)

OK, I'll tell you something new:D

I plan to use a CRF value of 23, or 24 (I won't know the result of CRF 24 for another 3 hours). I see that even though I can tell the difference between a 1000Kbps and 1500Kbps video, but I can only do that in stills, but when the video is playing, I don't see as much. So I choose space over quality. But the CRF 22 encode really showed off the astonishing amount of details a 5'' screen can show(high quality photos are even better). Can't believe Archos used a cheap resistive touchscreen on it when this screen is probably the most expensive one out there. A capacitive touchscreen would of made it even better.

Tell us something new ;)



x264 will always take 100% processing power of your Quadcore, unless you bottleneck it with slow input and/or use insane settings (e.g. b-adapt 2 + high bframe count).

Also looking at the CPU load in Taskmanager is not a valid speed measure.
If you want to do a proper speed measure, run two encodes of the same source. Once with "--analyse all" and once without "--analyse" (default). Then compare at the "fps" numbers!
Of course you must use the identical source and all other settings must be identical too...

AutoMKV is bottlenecking x264 by not supporting MT avisynth (So x264 is only using 50% of my CPU). I go around this issue by running 2 encodings simultaneously, and it works perfectly, except it makes my computer go low on RAM. Now I kick myself for only getting 3GB of RAM when I bought my computer a year ago.

[Inspector.Gadget]

RAM is cheap. Load it to the gills.

[Chengbin]

RAM is actually pretty expensive for me. I have to replace all my RAMs, and buy 64bit Vista (!).

[LoRd_MuldeR]

RAM is actually pretty expensive for me. I have to replace all my RAMs, and buy 64bit Vista (!).

You can get a 4 GB Kit of RAM for ~40€ and that's not some Noname brand.

If you want to utilize more than ~3GB of RAM you need a 64-Bit OS indeed, but not necessarily Vista. There is WinXP 64-Bit too and of course there's Linux ;)

Anyway, I doubt that x264 can eat that much RAM. Only really heavy-weight Avisynth filters could do that...