[x264-devel] Question about x264 real time encoding

[Bo SONG]

>> 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.

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?

P.S. part of the result
2. Commandline:
--tune zerolatency -B 2500
Result:
X264Enc:
59.99 ms/frame (x264_encoder_encode return time),
throughtput 16.2417 frames/sec,
latency 0ms/frame (currenttime - pts returned by x264_encoder_encoder,
this proves that x264_encoder_encode doesn't return until it finish its  
job)

>
>> Another question I thought a lot is how did x264 manage frame based
>> threading? If the sequence is IPPPPPPP..., does that mean x264
encode I
>> frame first, then use seperate thread to encode the following P s? Then
>> how does it handle P referencing P? Or they just all referencing I  
>> frame?
>
> http://akuvian.org/src/x264/sliceless_threads.txt

Thanks! I'll read it.

-- 
Bo SONG