Re: [x265] [ANN] x265 0.8 released
Do you have some information on quality/speed improvements relative to previous release? Thanks,-Purvin Date: Tue, 4 Mar 2014 13:32:27 -0600 From: st...@borho.org To: x265-devel@videolan.org Subject: [x265] [ANN] x265 0.8 released Hello, x265 0.8 is a regularly scheduled feature release = New in 0.8 = * 4:4:4 internal color space is now supported. Input pictures must also be 4:4:4, 8 or 10bit. We advise to disable weightp with 4:4:4. Note that since the HEVC Range Extensions are not finalized, this feature should be considered highly experimental. Our output streams may not be compliant with the final spec. * Improved VBV. x265 will now do mid-frame QP adjustments in order to better meet the bit target. Further improvements will be in the next release (partial slice re-encode when bit budget is very tight). * FPS is finally handled in a sane fashion. It may be configured as a rational number (numerator/denominator) or as a float. The frame rate is now signaled in the VPS header for use by the decoder. * VUI signaling is now exposed in the x265_param structure and in the x265 CLI. The exact params and CLI options should be considered experimental at this point, and are liable to change. * Near full ASM coverage of the 8bit build, and much more 10bit assembly than the previous release. All of the interpolation and intra primitives that were written with SIMD intrinsics have been replaced with assembly routines. * Input pixel bit depth is now decoupled from the internal bit depth. An 8bpp build and a 16bpp build of x265 will both be able to encode 8bit or 10bit or 16bit raw video streams. The encoder will shift and mask pixels as necessary to get them to the internal depth. * Motion compensated weight analysis. This will be further improved in the next release. = CLI changes since 0.7 = # Added # --scenecut integer -i/--min-keyint integer --vui --sar int:int|int --overscan string --videoformat string --range string --colorprim string --transfer string --colormatrix string --chromaloc integer --[no-]fieldseq --[no-]framefieldinfo --crop-rect string --timinginfo --nal-hrd --bitstreamrestriction --subpichrd See CLI help for descriptions # Replaced options, to sync with x264 # --refresh integer is now --[no]open-gop --frame-skip integer is now --seek integer -i/--keyint integer is now -I/--keyint integer (short opt case change) = Upcoming work = The next release will focus on improving all of the recently added features, particularly VBV and adaptive quant, and focusing heavily on improving perceptive visual quality. Regards, -- Steve Borho ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel
Re: [x265] [PATCH] Modifications to address review comments to support multiple color space format
I tried to complie x265 under windows for VS. I get the following errors any suggestions: Error 5 error LNK1112: module machine type 'X86' conflicts with target machine type 'x64' X:\x265\multicoreware-x265-b970ffbdd696\build\vc10-x86_64\pixel-a.asm.obj 1 x265-shared Error 6 error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' X:\x265\multicoreware-x265-b970ffbdd696\build\vc10-x86_64\encoder\encoder.dir\Release\NALwrite.obj 1 x265-static Error 7 error LNK1181: cannot open input file 'Release\x265-static.lib' X:\x265\multicoreware-x265-b970ffbdd696\build\vc10-x86_64\LINK cli Thanks,-Purvin___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel
Re: [x265] [ANN] x265 0.4.1
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: st...@borho.org To: x265-devel@videolan.org 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 longercaches 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. Consultthe online help for the current set of options. = Known Bugs = * all intra encodes (--keyint 1) require --b-adapt 0 to avoida lookahead bug * --no-sao-lcu-bounds cannot be used in conjunction with frame parallelism. The encoder will use incomplete reference pixelswith predictable bad effects. * we have a report that our DPB signalling is potentially incorrectfor 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 x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel ___ x265-devel mailing list x265-devel@videolan.org https://mailman.videolan.org/listinfo/x265-devel
