Turing HEVC encoder

[mandarinka]

It seems there is a new GPL2 (with commercial license supposedly available) HEVC encoder out, called Turing.

I see "Copyright (C) 2016 British Broadcasting Corporation, Parabola Research and Queen Mary University of London." written in the source codes, so I assume the origin lies mainly in research/university project code.

http://turingcodec.org/
https://github.com/bbc/turingcodec

Some commandline options (I guess those say something about capabilities): http://turingcodec.org/index.php/documentation/

They publish some "performance comparison" with "other practical HEVC encoder" (x265 probably) and HM, but the graph only compares memory usage when encoding. So realistically don't expect this encoder to outdo x265...

[filler56789]

Oh no, yet another CMake-driven project :mad:

[MoSal]

Oh no, yet another CMake-driven project :mad:

CMake caught your eye, not C++ and the lack of ASM? :sly:

[filler56789]

CMake caught your eye, not C++ and the lack of ASM? :sly:

Yes, because I can't even try to compile the goddämn thing.

[MasterNobody]

CMake caught your eye, not C++ and the lack of ASM? :sly:
Looks like it use something named HAVOC (Handcoded Assembly Optimisations for VideO Codecs) which use Xbyak JIT compiler for optimizations.
And I also wasn't able to build this codec not with MSVS, no with MinGW. May be it need Boost installed but I am not going to install it to test this.

[Parabola]

You don't need boost installed but you do need a relatively recent compiler with good C++11 support. i.e. gcc 5 or VS2015.

[hajj_3]

maybe someone with the right skills can compile this so that the masses can test out this codec.

[filler56789]

f.w.i.w.:

https://github.com/bbc/turingcodec/issues/4

[MoSal]

I managed to cross-compile it with mingw-w64. But running `turing-exe.exe help encode` under wine64 crashes.
I don't know if that's a wine bug, or the binary is broken. I'm on a limited data cap ATM(mobile). So I can't investigate further. I don't care enough anyway to spend more time on this.

If anyone wants to tackle this:


git clone https://github.com/bbc/turingcodec.git
cd turingcodec
patch -Np1 < <(curl https://gist.githubusercontent.com/anonymous/7af7ddea2bcbf7d3ce996ae0bec3b112/raw/d90802fa9719b296efdb7f1143e8c1aef6397bb9/fix_build_mingw.patch)
mkdir build
cd build
cmake -DCMAKE_SYSTEM_NAME=Windows -DCMAKE_C_COMPILER=/usr/bin/x86_64-w64-mingw32-gcc -DCMAKE_CXX_COMPILER=/usr/bin/x86_64-w64-mingw32-g++ -DCMAKE_FIND_ROOT_PATH=/usr/x86_64-w64-mingw32/ -DCMAKE_CXX_FLAGS='-Ofast -DWIN32=1' ..
make


Change the paths to where your MinGW installation is located. And note that you need to define WIN32. That's right, they neither use _WIN32 consistently, or define what needs to be defined.

[filler56789]

^ The recipe above does not work under MSYS2.
CMake returns stupid messages about "NMake files"... :rolleyes:
How good is that?

[anonymlol]

I compiled them, download here (https://mega.nz/#!eIoE0YyJ!kwNemtf8yWiruoasFzqli9zIto_rXqfOacCMOmOU5xY). The linux binary was compiled on win10 (linux subsystem), so I'm kinda curious how well it works on linux.

edit: "help encode" output added


[turing] Project Turing HEVC Encoder Version (1.01) - hash commit: <unknown>
[turing] patents pending / copyright 2016 Project Turing contributors
Usage: turing_win.exe encode [options] input-file

Input options:
--input-res arg video frame resolution <width>x<height>
--seek arg number of initial frames to be omitted before
encoding starts
--frames arg number of frames to encode
--frame-rate arg sequence frame rate
--bit-depth arg (=8) video bit depth (of both input YUV and output
stream)

Output options:
-o [ --output-file ] arg output file name
--dump-pictures arg reconstructed YUV file name (separate fields
if field-coding is enabled)
--dump-frames arg reconstructed YUV file name (interleaved
frames if field-coding is enabled)
--hash arg Decoded picture hash: 0 = MD5 sum, 1 = CRC, 2
= Check sum
--atc-sei arg (=-1) Alternative transfer characteristics SEI
message: --atc-sei ptc (preferred transfer
characteristics)

Rate control options:
--qp arg (=26) quantization parameter
--aq TM5-like adaptive quantisation based on
psycho-visual model
--aq-depth arg (=3) maximum depth at which adaptive quantisation
can be performed
--aq-range arg (=6) maximum range at which the qp can vary during
adaptive quantisation
--dqp-depth arg (=-1) cu depth where QP can be varied
--bitrate arg cbr rate control based on lambda-rate model

Structure options:
--shot-change enable shot change detection
--field-coding enable field coding
--max-gop-n arg (=250) maximum intra picture interval
--max-gop-m arg (=8) maximum anchor picture interval (1 or 8)
--wpp enable wave-front parallel processing
(default enabled)
--ctu arg (=64) CTU size in luma pixels
--min-cu arg (=8) minimum CU size in luma pixels
--repeat-headers emit VPS/SPS/PPS on every keyframe (default
first keyframe only)

Coding tool options:
--deblock enable deblocking filter
--strong-intra-smoothing enable strong intra smoothing
--rqt enable one level of rqt (inter coding only)
--amp enable asymmetric motion partitions
--smp enable symmetric motion partitions
--rdoq enable rate distortion optimised quantisation
--max-num-merge-cand arg (=5) maximum number of merge candidates tested
--sdh enable sign data hiding, only with --rdoq
--tskip enable transform skip

Performance options:
--speed arg (=slow) speed / efficiency tradeoff (one of slow
medium fast)
--fdm fast decision for merge
--fdam fast decision for all modes
--ecu enable early cu termination
--esd enable early skip detection
--cfm enable coding flag mode
--met enable multiple early termination for motion
estimation
--aps enable adaptive partition selection
--rcudepth enable rcu-depth algorithm

Optimisation options:
--threads arg (=0) size of thread pool (0=auto detect)
--concurrent-frames arg (=4) maximum number of pictures that may encode in
parallel
--no-parallel-processing disable parallelisation (wpp, multithreading
and encoding of concurrent frames)
--asm arg (=1) enable assembly language optimisations

Reporting:
--psnr measure PSNR and report
--profiler profile CPU usage and report
--verbosity arg (=1) output during encoding (0, 1 or 2)
-h [ --help ] display help message

Video Usability Information (VUI):
--sar arg sample aspect ratio <w:h>
--display-window arg specify display window <left,right,top,bottom
>
--overscan arg indicate whether is appropriate to display
the overscan area <show|crop>
--video-format arg indicate the video format <integer|string>
--range arg indicate the video full range <full|limited>
--colourprim arg indicate the colour primaries
<interger|string>
--transfer-characteristics arg indicate the transfer function associated
with the source material <integer>
--colour-matrix arg indicate the colour matrix used to derive
luma and chroma
--chroma-loc arg indicate the location for chroma samples
<0..5>

[MoSal]

^ The recipe above does not work under MSYS2.
CMake returns stupid messages about "NMake files"... :rolleyes:
How good is that?

I cross-compiled from a GNU/Linux environment.

I think you should install mingw-w64-x86_64-cmake then call /mingw64/bin/cmake.exe instead of calling cmake directly.

[Parabola]

Some of the developers are at IBC - we'll be at the EBU open source event tomorrow: if you're in Amsterdam, do join us for a beer.

[filler56789]

I cross-compiled from a GNU/Linux environment.

I already knew that.

The actual problem is 1) they chose CMake and 2) they did a lousy job.

At least the x265 folks knew what they were doing (regarding the proper use of CMake).

[MoSal]

The actual problem is 1) they chose CMake and 2) they did a lousy job.


I concur.

x265 (and probably Kvazaar (https://github.com/ultravideo/kvazaar) too) are way ahead in development.

Turing could end up being more of a code dump than an actively-developed in-the-open encoder anyway.

[filler56789]

"Build fail OS-X" (sic)

https://github.com/bbc/turingcodec/issues/5

[nevcairiel]

Whats with everyone being so entitled over here? Its their project, and they get to decide how much time they want to spend either on actually working on the encoder, or the build system. In the very early stage of a project (which this is clearly in), any sane developer will chose working on the code, everytime.
If you want to help, then extend the build system properly, and send them a pull request.

[hajj_3]

v1.2 of this was released in May, not sure what the changelog is. Has anyone compared this to x265?

[iwod]

I just came across this. Has anyone done any test on this?

[ChaosKing]

Found only this "test" https://github.com/bbc/turingcodec/issues/18