[x265] [ANN] x265 version 1.1

Wed Jun 4 11:45:24 CEST 2014

Thank you Nicolas for pointing this out. It was indeed a bug, pushing in a
fix now.

On Wed, Jun 4, 2014 at 1:48 PM, Nicolas Morey-Chaisemartin <nmorey at kalray.eu
> wrote:

>  Hi,
>
> I just pulled the last version and I think there is an issue with the
> --no-b-intra.
> I had a quick look and the only place where it is used in in xCompressCU:
>             if ((slice->getSliceType() == I_SLICE ||
>                 outBestCU->getCbf(0, TEXT_LUMA) != 0   ||
>                 outBestCU->getCbf(0, TEXT_CHROMA_U) != 0   ||
>                  outBestCU->getCbf(0, TEXT_CHROMA_V) != 0) &&
> m_param->bIntraInBFrames) // avoid very complex intra if it is unlikely
>
> (On another note, I don't think that the slice type can ever be I in the
> current implem as xCompressIntraCU is called in this case).
> As this function is called for both P and B frames, the test means that
> with --no-b-intra, P frames cannot have intra blocks either...
>
> Either this is a bug, or the documentation should be updated/clarified to
> match this behavior.
>
> Nicolas
>
>
> On 06/04/2014 12:25 AM, Steve Borho wrote:
>
> Hello,
>
> Release 1.1 has been tagged.  This is an incremental update with
> several important rate control improvements and a few new features.
>
> = New Features =
>
> 1. Psycho-visual rate distortion optimizations. These RD optimizations
> are only effective on presets which use RDO (rd levels 5 and 6).
> Psy-rd is still considered experimental in this release and is not
> enabled by default. We recommend evaluating with a low psy weight
> factor, for instance: --rd 5 --psy-rd 0.4
>
> 2. Lossless coding.  This release of x265 can create a bit-accurate
> output bitstream by using --lossless. This feature disables rate
> control and distortion metrics, and instead just reports the
> compression ratio at the end of the encode.  Lossless coding is
> considered experimental in this release, we believe there is room for
> improvement in both compression efficiency and performance.
>
> 3. Support for Y4M streams with more than 8bit depth (ffmpeg -i
> vid.avi -pix_fmt yuv420p10le -strict -1 -f yuv4mpegpipe - | ./x265 -
> --y4m o.hevc)
>
> = API Changes =
>
> * new x265_picture.forceQp for qpfile functionality
> * new param.levelIdc to force a decoder requirement level
> * new param.psyRd for (experimental) psycho-visual rate distortion optimizations
> * new param.bIntraInBFrames to disable intra predictions in B slices
> regardless of preset
> * new param.noiseReduction, very similar to x264 noise reduction
> * new param.bLossless to enable lossless coding (experimental)
> * new param.bCULossless to include trans-quant bypass modes in CU RD analysis
> * new param.rc.rfConstantMin to limit rate factors in rate control
> * param.rc.aqMode now defaults to 2 (to match CLI behavior)
>
> new x265_encoder_parameters() function which retrieves a copy of the
> active parameters from the encoder. x265_encoder_open() was modified
> to ensure it never modified the param structure passed to the
> function; it makes a private copy of the param prior to making any
> modifications to it.
>
> The default setting (the medium preset) was be adjusted to include the
> --no-rect and --no-amp options, becoming faster (on average, about
> 70%, but as much as 90%), with a very slight (~ 1 - 4%) impact on
> encoding efficiency.
>
> We have sped up the ultrafast preset by about 10 to 30% (bigger
> benefit at higher bit rates). There is a very small impact on encoding
> efficiency, but you can always increase efficiency by using a slower
> (higher quality) preset. We've also sped up the superfast, veryfast
> and faster presets in a similar way.
>
> = CLI Changes =
>
> New options:
> --level
> --repeat-headers (older feature, newly exposed to CLI)
> --nr
> --lossless
> --psy-rd
> --crf-min
> --no-b-intra
> --cu-lossless
> --qpfile
>
> --tune fast-decode now also disabled intra in B frames
>
> As always, the most detailed documentation for the command line
> arguments can be found in our online documentation:http://x265.readthedocs.org/en/1.1/
>
> = Rate Control =
>
> Single pass ABR received a lot of attention in this release, in
> particular the tendency for ABR to undershoot and overshoot wildly in
> the first two seconds of the video.  We added two new features to ABR
> to limit this tendency.  First, we now amortize a portion of the cost
> of I frames across many frames.  Second, we limit frame parallelism
> until we have about a half-second of P frames encoded.  Together these
> two changes have greatly improved the ability of single pass ABR to
> arrive at the good QP for the first GOP without any large swings.
>
> Further improvements were made to ABR to allow it to reach very high bitrates.
>
> We also did some re-balancing of CRF between Main and Main10 so they
> achieve closer quality, and several fixes were made to VBV.
>
> Recovery Point SEI are now generated at each keyframe
>
> In the near future we will be focusing on two-pass encoding and making
> mode decision more efficient.
>
>
>
>
> --
>
>
>    *Nicolas Morey-Chaisemartin*  [image: kalray_logo]
> <http://www.kalray.eu/> *KALRAY SA*   Software Architect
>   www.kalray.eu
>    Phone : +33 6 42 46 68 87
> nmorey at kalray.eu Follow us [image: twitter_logo]
> <https://twitter.com/Kalray1> [image: linkedin_logo]
> <http://www.linkedin.com/company/kalray>  445 rue Lavoisier
> 38330 Montbonnot FRANCE
> <http://www.kalray.eu/news-7/news/latest>
>   This message contains information that may be privileged or
> confidential and is the property of the KALRAY SA. It is intended only for
> the person to whom it is addressed. If you are not the intended recipient,
> you are not authorized to print, retain, copy, disseminate, distribute, or
> use this message or any part thereof. If you receive this message in error,
> please notify the sender immediately and delete all copies of this message.
>
> _______________________________________________
> x265-devel mailing list
> x265-devel at videolan.org
> https://mailman.videolan.org/listinfo/x265-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20140604/b29617ff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: newsbanner.gif
Type: image/gif
Size: 16226 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20140604/b29617ff/attachment-0001.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: LOGO_KALRAY_200x28.png
Type: image/png
Size: 5390 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20140604/b29617ff/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linkedin_50x50.png
Type: image/png
Size: 1094 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20140604/b29617ff/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: twitter_50x50.png
Type: image/png
Size: 1037 bytes
Desc: not available
URL: <http://mailman.videolan.org/pipermail/x265-devel/attachments/20140604/b29617ff/attachment-0005.png>