Hi
When you use WPP does that mean the HEVC specified parallelism tool or this is
just the way you process the frame?
Thanks,-Purvin
Date: Wed, 25 Sep 2013 00:27:59 -0500
From: [email protected]
To: [email protected]
Subject: [x265] [ANN] x265 0.4.1
Hello,
I've made a tag on the stable branch for 0.4.1. This email describes the state
of the encoder at that tag.
x265 can be compiled and run on Linux, Mac OS X, and Windows. Its cmake based
build system supports MSVC 9-11, Xcode, gcc+gmake, MinGW/MSYS, and Intel C++
(both icl and icpc)
x265 currently generates HM11 compliant bitstreams.
= New features since 0.3 =
1. Frame parallelism
* The GOP level parallelism and mini-gop cadence of the 0.3 release
were removed and replaced with fine-grained frame level parallelism. * The
memory requirements were drastically reduced, x265 no longer caches subpel
planes per reference frame
* Latency is drastically reduced, WPP + 5 frame threads is enough to
saturate a dual socket 8 core Xeon.
2. New simple average bitrate (ABR) rate control
* converges on target bitrate via frame level QP adjustments
* algorithm was adapted from x264 for HEVC * safe for use in combination
with frame parallelsim (new since 0.4)
3. New Lookahead
* three complexity levels of slice decision with scene cut and flash detection
* algorithm was adapted from x264 for HEVC * still missing bidir cost
estimates, multiple refs, weightp, and MBtree
= Disabled Features since 0.3 =
* weightp and weighted bidir prediction are both disabled; they were
broken when we stopped pre-generating reference (subpel) pixels * GOP
parallelism is dead, hopefully to never return to the core
library. It could be added above x265 if necessary. * many CLI options
were added, removed, or renamed since 0.3. Consult the online help for the
current set of options.
= Known Bugs =
* all intra encodes (--keyint 1) require --b-adapt 0 to avoid a lookahead
bug * --no-sao-lcu-bounds cannot be used in conjunction with frame
parallelism. The encoder will use incomplete reference pixels with
predictable bad effects. * we have a report that our DPB signalling is
potentially incorrect for decoders which respect max DPB size. This is under
investigation.
ABR and lookahead are very new and we will not be surprised to find bugs in
those features. Please report any bugs you find to this mailing list.
= Performance Characteristics =
See https://bitbucket.org/multicoreware/x265/wiki/Performance
= Upcoming features =
We are trying to make the encoder deterministic with -Fn for all values of n
greater than 1. In other words, there will always be a slight benefit to
having only one frame thread (unlimited motion search to reference frames) but
-F2 and -F10 should output the exact same bitstream with CQP rate control.
This is considered a debugging feature to validate our frame parallelism.
We are also planning to swap out the HM's bidir search with logic adapted from
x264 (for performance reasons) and to add estimation logic for this new bidir
search to the lookahead (to improve lookahead accuracy).
We plan to repair the weighted prediction features and re-enable its command
line options.
Lastly, the lookahead will use wave-front scheduling of the lowres CUs using
the existing thread pool. This should lesson the bottlenecking effects of
--b-adapt 2.
--
Steve Borho
_______________________________________________
x265-devel mailing list
[email protected]
https://mailman.videolan.org/listinfo/x265-devel
_______________________________________________
x265-devel mailing list
[email protected]
https://mailman.videolan.org/listinfo/x265-devel
