about real time encoding with 2pass

[Dark Shikari]

Originally Posted by seanxu_2010

x264 --profile main --bitrate 800 --vbv-init 0.9 --vbv-maxrate 800 --vbv-bufsize 8000 --me umh --analyse all --qcomp 0.90 --subme 6 --trellis 2 --ref 3 --rc-lookahead 250 -o Estimate_720x576_30fps_NR_max_NRT_max_1.264 Estimate_720x576_30fps_NR_max_NRT_max.yuv 720x576 --fps 30 --psnr --ssim --deblock 0:0 --slices 3

I use VBV to obtain a proper bitrate to accommodate the network. I used ESEyE to observe the size of every frame, I found some B frame used very high bit because of fash lamp, what I expect is when we find it's B frame, and consume an extreme high bits, I will drop it for saving bits for other frame.

x264 intentionally makes them B-frames in order to save bits. It also refuses to trigger a scenecut, saving bits. Furthermore, MB-tree raises the quantizer a ton, saving bits. Of course, you screwed with qcomp, which is probably preventing MB-tree from doing its job. Don't touch it.

Originally Posted by seanxu_2010

because in the match, we will concentrate on the athletes in the middle slice, and up and down are always audience, we can use higher QP to blue them for saving bits

I don't recall any sports match in which there's an audience on both the top and bottom of the frame, but no, x264 doesn't do that.

[seanxu_2010]

Originally Posted by Dark Shikari

x264 intentionally makes them B-frames in order to save bits. It also refuses to trigger a scenecut, saving bits. Furthermore, MB-tree raises the quantizer a ton, saving bits. Of course, you screwed with qcomp, which is probably preventing MB-tree from doing its job. Don't touch it.I don't recall any sports match in which there's an audience on both the top and bottom of the frame, but no, x264 doesn't do that.

thank you, I remember qcomp is relative with complexity, higher qcomp will lead more constant quality which conflict with what I need.

and you mean B refuses to trigger a scenecut, what about I and P? any method to cut some scenes ?

[seanxu_2010]

Originally Posted by Dark Shikari

x264 intentionally makes them B-frames in order to save bits. It also refuses to trigger a scenecut, saving bits. Furthermore, MB-tree raises the quantizer a ton, saving bits. Of course, you screwed with qcomp, which is probably preventing MB-tree from doing its job. Don't touch it.I don't recall any sports match in which there's an audience on both the top and bottom of the frame, but no, x264 doesn't do that.

Dark Shikari, I have a question about lookahead in X264 code, take lookahead=25 for example, x264_encoder_encode will excuse x264_adaptive_quant_frame to get f_qp_offset for every mb for 25 frames without really encoding these frame. And then, begin to really encode. My question is how to use lookahead results for revise the bitrate? or which functions include these section, are they in X264_lookahead_get_frame? can you give me a more detailed explanation?

[Dark Shikari]

Originally Posted by seanxu_2010

Dark Shikari, I have a question about lookahead in X264 code, take lookahead=25 for example, x264_encoder_encode will excuse x264_adaptive_quant_frame to get f_qp_offset for every mb for 25 frames without really encoding these frame. And then, begin to really encode. My question is how to use lookahead results for revise the bitrate? or which functions include these section, are they in X264_lookahead_get_frame? can you give me a more detailed explanation?

clip_qscale, encoder/ratecontrol.c.

[seanxu_2010]

Originally Posted by Dark Shikari

clip_qscale, encoder/ratecontrol.c.

Hi Dark Shikari, do you know any release x264 code based on Marvell pxa270(ARMv5TE and intel wireless MMX)?
or if only I define ARM ARCH and define HAVE_MMX, I can get high efficient code on pxa270?