Тестирование скорости кодека x265

Для оценки прогресса в разработке кодека x265 мы провели небольшое тестирование. А как же изменялась скорость кодирования на разных пресетах от версии к версии. Тестирование проводилось на следующем конфиге: Intel(R) Core(TM) i7-4930K CPU @ 3.40GHz, 32 GB DDR3. Измерялся средний FPS кодирования на одном и том же тестовом видеофайле (1080p@25fps).

Тестировались версии x265:
1.0, 1.1, 1.2, 1.3, 1.4
Проверялись пресеты:
DEFAULT — запуск кодека без параметров
CRF-20 — запуск кодека только с ключом -CRF 20 без параметров
ultrafast, superfast, veryfast, faster, fast, medium, slow, slower, veryslow, placebo — был задан только соответствующий -preset
Компиляторы:
GCC 4.9.2, ICC 1400, MSVC 1800 — на этих трех разных компиляторах был собран x265

Ниже приведена сводная таблица и графики:

ver. comp iler DEF AULT CRF -20 ultra fast super fast very fast faster fast medium slow slower veryslow placebo
1.0 GCC 4.9.2 4.50 4.08 10.94 7.00 6.93 7.84 7.97 4.72 2.45 0.52 0.35 0.20
1.0 ICC 1400 4.76 4.10 10.82 6.62 6.56 7.62 7.90 4.74 2.42 0.51 0.35 0.20
1.0 MSVC 1800 4.76 4.14 11.44 6.97 6.92 7.95 8.08 4.78 2.46 0.54 0.35 0.20
1.1 GCC 4.9.2 8.07 6.44 13.12 9.30 8.81 10.29 8.69 8.07 2.40 0.51 0.34 0.20
1.1 ICC 1400 8.11 6.48 13.10 9.13 8.72 10.26 8.74 8.14 2.37 0.51 0.34 0.20
1.1 MSVC 1800 8.11 6.58 13.82 9.61 9.12 10.64 8.87 8.26 2.41 0.54 0.34 0.20
1.2 GCC 4.9.2 9.02 7.40 15.06 12.18 11.44 12.26 11.06 8.82 2.62 0.58 0.39 0.24
1.2 ICC 1400 9.02 7.42 14.88 11.96 11.16 12.17 10.91 8.83 2.60 0.57 0.39 0.24
1.2 MSVC 1800 9.02 7.53 15.44 12.68 11.83 12.68 11.32 8.99 2.69 0.61 0.39 0.24
1.3 GCC 4.9.2 8.88 7.29 15.24 12.85 12.00 12.77 11.57 8.88 2.60 0.59 0.39 0.24
1.3 ICC 1400 8.95 7.48 14.92 12.56 11.81 12.69 11.64 8.95 2.58 0.59 0.39 0.24
1.3 MSVC 1800 8.95 7.55 16.13 13.25 12.53 13.30 11.97 9.13 2.62 0.61 0.39 0.24
1.4 GCC 4.9.2 9.32 7.47 17.95 13.92 12.25 13.09 11.66 9.33 2.64 0.73 0.51 0.32
1.4 ICC 1400 9.41 7.67 17.78 13.72 12.19 13.21 11.78 9.42 2.62 0.73 0.51 0.32
1.4 MSVC 1800 9.41 7.63 18.42 14.34 12.58 13.44 11.92 9.48 2.65 0.74 0.51 0.32

Читать полностью…

Готов ли твой компьютер к x265?

На сайте x265.ru совместными силами пользователей собирается статистика, насколько эффективно различные процессоры справляются с задачей кодирования кодеком x265. На текущий момент в табличке собрано 17 различных процессоров. Вы также можете помочь нам и прислать данные тестирования вашего процессора. Для этого надо скачать бенчмарк и запустить его на своем компьютере, а затем отправить результаты на нашем форуме. После проверки они будут занесены в общую табличку.

Результаты тестов различных процессоров

Скачать x265 HD Benchmark

Отправить свои результаты на форуме

Релиз x265 версии 1.4

x265 1.4 is a regularly scheduled release, mostly focused on performance
enhancements. There was a large refactor of the analysis code that
exposed further parallelism without sacraficing any compression
efficiency. In general, 1.4 should have slightly better compression
efficiency than 1.3 for the same encodes.

The refactors also generally lowered the memory requirements and made
the faster presets more compute efficient.

The two most important new features are --pmode (parallel mode decision)
and --pme (parallel motion estimation).

= —pmode : param.bDistributeModeAnalysis =

This feature will distribute mode analysis for each CU. The more modes
that must be analyzed, the more effective this feature becomes. So the
slow preset that enables rectangular prediction modes benefits from
pmode more than medium preset, and the slower modes which use RD level
6 benefit from pmode even more since they enable AMP predictions and
evaluate the rate distortion cost of each mode.

The output of --pmode encodes should have slightly better compression
than those with it disabled, since certain early outs are impossible
with --pmode and thus all modes are measured naievely.

= —pme : param.bDistributeMotionEstimation =

This feature will distribute the motion estimations for each CU that has
more than 2 references. Its effectiveness is proportional to the number
of references, but this feature can often be a net performance loss as
the overhead of involving other CPU cores is often more expensive than
the parallelism benefit.

The output of the encode is completely unaffected by --pme.

Both --pme and --pmode are only useful when x265 is otherwise unable to
fully saturate the CPU cores, and both can also at times result in lower
performance on multi-socket machines (depending on the situation) since
we are not yet keeping work localized to neighbor CPUs.

= Also in 1.4 =

As a result of the refactor work, none of the original HM classes or
source files remain in x265.

Temporal motion vector predictions (previously hard-coded to always be
enabled) are now runtime selectable (param.bEnableTemporalMvp) but still
default to being enabled in all presets.

Frame based SAO analysis was removed (frame based SAO signaling did not
make it into the final HEVC spec), and --sao-lcu-bounds=<0|1> was
renamed to --[no-]sao-non-deblock (param.bSaoNonDeblocked)

Some inconsistencies in the analysis logic were fixed. --amp is now
respected in RD levels 2, 3, and 4 (previously only in 5 and 6).
--b-intra is now respected in all RD levels. --fast-cbf, which has only
ever effective at RD levels 5 and 6, is no longer enabled uselessly in
the fastest presets.

--weightb is now enabled by default at presets slower, veryslow, and
placebo.

--cu-lossless was changed to only attempt a lossless encode of the best
lossy encode method. This made --cu-lossless a much less expensive
encode option to have enabled, and hopefully made the feature more
robust and maintainable.

The upper threshold for --psy-rdoq was raised to 50 (from 10) since the
higher values were found to be beneficial for sources with high
frequency noise (film grain).

The default thread pool size logic was updated to account for the
addition of --pmode and --pme (if WPP is disabled but --pmode or --pme
are enabled, a thread pool is still allocated).

In 1.4 there also appeared an incomplete analysis re-use feature. This
will be completed and further improved in the coming weeks.

H.265/HEVC станет основным кодеком для дисков 4K Blu-ray

blu_ray_4k_logoНовые оптические носители, диски формата 4K Blu-ray, появятся на рынке только в будущем году, однако технологическая разработка их уже завершена, и стали известны подробности спецификаций.

В частности, окончательно определён кодек, который будет использоваться в новой технологии. Им стал H.265/HEVC, алгоритм которого гораздо более эффективен, чем у предшественника — кодека H.264/AVC — и позволяет добиваться более высокой степени сжатия изображений, особенно движущихся, без потери качества.

Кроме того, новая 4K Blu-ray технология даёт возможность потоковой передачи данных со скоростью 50-60 Мбит/с и выше (что в два раза больше скорости передачи данных с существующих сейчас дисков Blu-Ray 50 Гб). И хотя объём 4K Blu-ray дисков будет таким же (50 Гб), именно эффективное сжатие кодеком H.265/HEVC позволит использовать десятибитную, а не восьмибитную, как было до этого, цветность и даст четырёхкратное увеличение количества пикселей в кадре (3,820×2,160 вместо 1,920×1,080).

Как сообщил во время своего выступления на выставке IFA 2014 в Берлине Виктор Мацуда, председатель Blu-Ray Disc Association (BDA), процесс лицензирования технологии оптических дисков 4K Blu-ray начнётся весной 2015 года с тем, чтобы к зимнему торговому сезону, традиционно сопровождающемуся повышением покупательского спроса, в продажу поступили и новые носители, и воспроизводящие устройства для них.

Таким образом, кодек H.265/HEVC полностью займёт ещё одну из существенных ниш на рынке оптических носителей. Это в очередной раз подтверждает тенденцию постепенного вытеснения видеопотоков H.264/AVC новой, наиболее эффективной на настоящее время технологией.

Mediainfo выводит информацию о параметрах x265

Media InfoВ последней версии MediaInfo 0.7.70, которая вышла 3 сентября 2014 года, добавлена поддержка вывода параметров кодирования библиотеки x265.

Пример:
Writing library : x265 1.3+57-44b95661db56df0a:[Windows][GCC 4.9.1][64bit]
Encoding settings : wpp / ctu=64 / tu-intra-depth=1 / tu-inter-depth=1 / me=1 / subme=2 / merange=57 / no-rect / no-amp / max-merge=2 / no-early-skip / no-fast-cbf / rdpenalty=0 / no-tskip / no-tskip-fast / strong-intra-smoothing / no-lossless / no-cu-lossless / no-constrained-intra / no-fast-intra / open-gop / interlace=0 / keyint=250 / min-keyint=25 / scenecut=40 / rc-lookahead=20 / bframes=4 / bframe-bias=0 / b-adapt=2 / ref=3 / weightp / no-weightb / aq-mode=2 / aq-strength=1.00 / cbqpoffs=0 / crqpoffs=0 / rd=3 / psy-rd=0.00 / psy-rdoq=0.00 / signhide / lft / sao / sao-lcu-bounds=0 / sao-lcu-opt=1 / b-pyramid / cutree / rc=crf / crf=17.0 / qcomp=0.60 / qpmin=0 / qpmax=51 / qpstep=4 / ipratio=1.40 / pbratio=1.30

Релиз x265 версии 1.3

The primary changes in this release are the completion and tuning of the psycho-visual optimizations and new support for multiple pass encoding.

—psy-rd and —psy-rdoq are now completed and scaled such that their recommended initial values are 1.0.

Multipass encodes are now possible with —pass N and —stats FNAME

As usual, full documentation is at: http://x265.readthedocs.org/en/1.3/

= API Changes =

* param.bEmitInfoSEI, —[no-]info
include an SEI identifying the encoder and encoding options.

* param.bHighTier —high-tier
specify tier (used in conjunction with —level-idc)

* param.bEnableFastIntra —[no-]fast-intra
Use a gradient descent to scan angular intra modes

* param.totalFrames
optional indicator of total frame count, may improve rate control

* param.scalingLists
specify custom quantization matrices, «default» or filename

* param.psyRdoq
Psycho-visual optimizations for quantization

* param.bEnableSlowFirstPass
The first pass of multi-pass encodes will run in *turbo* mode unless this option is enabled.

Релиз x265 версии 1.2

This was a regularly scheduled release with improvements in performance, major improvements in memory usage, and improved psy-rd behavior.

There were a few of new options introduced:
—cu-stats, x265_param.bLogCuStats — enabling logging of CU stats (for R&D purposes only)
—hrd, x265.bEmitHRDSEI — enable HRD SEI signaling (use this option to add Hypothetical Reference Decoder information into the HEVC bitstream, in order to comply with HRD specifications)
—ipratio/—pbratio were exposed to the CLI
—lambda-file — allows experimentation with lambda tables (for R&D purposes only — this should not be needed for normal production encoding purposes)

Plus a number of options added for multi-pass encoding (incomplete).

Промежуточное сравнение x265 и x264 (лето 2014)

В этот раз сравниваем видео большого формата с большим числом кадров в секунду. Для теста используется ролик Crowd Run в разрешении 3840х2160 и частотой кадров 50 FPS. Всего в ролике 500 фреймов. Сам ролик можно скачать отсюда: Crowd Run 2160p@50 (~5.8 GB).

Для кодирования используется экстремально низкий битрейт для таких параметров видео: 4000kbps.
Читать полностью…

Релиз x265 версии 1.1

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 8 bit depth (for example, 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 bit rates.

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.

Релиз x265 версии 1.0

There were many bugs fixed since the 0.9 tag, particularly in rate control and Main10 mode decision. There have been a couple of minor performance improvements.

= Feature changes =

* Experimental support for 4:2:2
* improved profile and level detection
* imported checkasm-a.asm from x264 and fixed the asm bugs it exposed
* lookahead will use a worker thread when beneficial
* Many more motion candidate vectors are passed to motion estimation
* Lambda table improvements for better bitrate response at low QP

= API changes =

* added param.bEnableAccessUnitDelimiters
* removed param.vui.bEnableVuiParametersPresentFlag (now implied)
* removed param.vui.bEnableAspectRatioIdc (now implied)
* removed param.vui.bEnableVuiTimingInfoPresentFlag (always enabled)

= CLI changes =

—aud was added
—vui was removed
—timinginfo was removed (it is always enabled)