[x265] X265 source codes

[steve]

On 03/30, Haixu Han wrote:
> Dear Steve???
>  
> Hi, I???m Haixu Han. I???m now a postgraduate at BBNC Lab of
> Department of Automation at Tsinghua University, China. I have being
> doing some research in HEVC, and I recently read your source codes of
> X265, in which I???m very interested.
>  
> I think the structure of source is very novel and I want to study it
> anxiously .
>  
> Because I am a beginner, I feel very confused about the parallel
> approaches,especially the relationship between frame threads, thread
> pools and worker threads.So if convenient, could you explain it to me
> explain it to me?
> 
>  It will be a big help for me to better understand your codes .

Hello, please direct questions about the source code to
x265-devel at videolan.org (CC'd)

Threading in x265 if fairly complicated because parallelism in HEVC is
hard to expose. Frame parallelism and slice parallelism are less
effective because of the large CTU block sizes (64x64 vs H.264's 16x16).

x265 can work with or without a thread pool.

With a thread pool, one worker thread is allocated per logical CPU core,
and a small number of frame threads manage the progress of frame
parallelism but spend ~99% of their time blocked. The worker threads
compress the CTUs of the frames currently being compressed, using WPP to
encode multiple rows of each frame simultaneously.

Without a thread pool, x265 allocates one frame encoder thread per
logical CPU core (up to a point) and each frame encoder thread
compresses the CTUs in its frame in scan order (all the work for one
frame is done in one thread).

In general, enabling the thread pool and WPP will give you better
performance for the same thread count.

On top of this you add the lookahead and pmode, and pme. Note that x265
does not support slices or tiles because you give up more parallelism
than you gain with those features (except in cases where no frame
parallism can be tolerated).

http://x265.readthedocs.org/en/latest/threading.html

-- 
Steve Borho