[x264-devel] Question about x264 real time encoding

[Jason Garrett-Glaser]

On Tue, Apr 6, 2010 at 10:09 PM, Bo SONG <benben841212 at gmail.com> wrote:
>>> Thanks. Actually when encoding 720P video file using zerolatency +
>>> veryfast I can get 43fps, while removing sliced-threads I get 81fps.
>>> Besides,
>>> I used the version 1510 from x264.nl and the result is 45fps and 82fps.
>>> So
>>> it seems my compiled version is functioning right. My cpu is a E5345
>>> which
>>> has 2 physical cpu and each have 4 cores. 2.33MHz
>>>
>>> I think the throughput difference comes from cpu usage: using
>>> frame-based threads I can get 66% in the previous experiment, while
>>> using sliced-based I can get 40%. But I don't know how to improve cpu
>>> usage and thus further reduce encoding time of one frame in
>>> sliced-mode. This is critical in real time encoding because if x264
>>> cannot
>>> encode a frame within 30ms, then there have to be a frame drop.
>>
>> In tests we have gotten a 1080p frame encoded as fast as 8
>> milliseconds.  720p should be easy.  Are you running a pre-2.6.32
>> Linux kernel?  If so, update; the scheduler was bugged, hurting x264.
>> Is your input decoding/reading off disk/whatever fast enough to feed
>> x264?
>
> I'm using Windows XP 32bit SP3 now. I use x264 win 32bit version 1510
> from x264.nl as well as my own compiled version (using MSVC9 +
> pthreadwin32).
>
> As I can get 82fps when using sliceless threading, I assume the disk
> reading throughput shouldn't be the bottleneck.

With sliceless threading, x264_encoder_encode is blocking.  With
regular threading, it often is not.

>
> Besides, when using slice based threading, I measured the return time of
> x264_encoder_encode. This time should be the encoding time of a frame,
> because x264_encoder_encode won't return until it finished encoding. I
> wrote the result in the first mail of this thread. I noticed that it cannot
> fully
> utilize CPU, less than frame threading, and costs 56ms per frame. Is it
> because of I'm using windows?

I have no idea, as I'm not psychic, but it works just fine here.  This
is on my laptop:

$ ./x264 videos/720p50_mobcal_ter.y4m --tune zerolatency --vbv-maxrate
5000 --vbv-bufsize 100 --preset superfast -o NUL --threads 4
--intra-refresh --crf-max 40
y4m [info]: 1280x720p 1:1 @ 50/1 fps (cfr)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 FastShuffle SSE4.2
x264 [info]: profile High, level 3.2
x264 [info]: frame I:2     Avg QP:25.56  size:  6793
x264 [info]: frame P:502   Avg QP:28.87  size: 10542
x264 [info]: mb I  I16..4: 98.1%  1.8%  0.1%
x264 [info]: mb P  I16..4:  6.1%  1.2%  0.4%  P16..4: 45.4%  0.0%  0.0%  0.0%  0
.0%    skip:46.8%
x264 [info]: 8x8 transform intra:14.6% inter:53.8%
x264 [info]: coded y,uvDC,uvAC intra: 47.0% 31.3% 13.3% inter: 15.1% 11.1% 0.8%
x264 [info]: i16 v,h,dc,p: 40% 30% 25%  5%
x264 [info]: i8 v,h,dc,ddl,ddr,vr,hd,vl,hu: 10% 13% 56%  4%  3%  3%  3%  3%  6%
x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 26% 17% 15%  6%  6%  7%  5%  7%  9%
x264 [info]: kb/s:4210.69

encoded 504 frames, 65.54 fps, 4210.69 kb/s

Dark Shikari