[x264-devel] Multithread in x264

[Loren Merritt]

On Fri, 6 Jul 2007, Son Minh Tran wrote:

> 1. Before revision 607, each thread encodes one slice, whose size (in
> MB) is equal to the frame size divided by No. of thread. You said
> this method has penalty on bitrate. Is it due to the independent
> treatment of slices in the same frame (therefore no spatial corellation
> can be exploited at the boundary of slices)?. There is no synchron at
> all between threads, isn't it ?

http://forum.doom9.org/showthread.php?p=881381#post881381
http://forum.doom9.org/showthread.php?p=881706#post881706

> 2. From revision 607, you deployed multithread based on frame. It means
> that frame can no longer be devided into more slices (I cannot find any
> parameters for setting the size of slice)?

It means that if you were to divide a frame into slices, you could not
use slice based threading at the same time as frame based threading. You
could still encode multiple slices in one thread. But I didn't implement
that because it's only for error resilience and not speed.

> With this method, you have to introduce the function
> x264_frame_cond_wait to ensure the fact that in the current Frame B/P
> encoded by thread X, before encoding a MB, all of its probable
> reference MBs in other frames (therefore encoded by other threads)
> must be encoded and reconstructed (then they can be used as
> references). I still don't understand the reason you set 24 to
> X264_THREAD_HEIGHT.

commented.

--Loren Merritt
_______________________________________________
x264-devel mailing list
x264-devel at videolan.org
http://mailman.videolan.org/listinfo/x264-devel