Kvazaar HEVC encoder - academic project from Technical University of Tampere [GPL]

[mandarinka]

http://ultravideo.cs.tut.fi/#encoder
https://github.com/ultravideo/kvazaar

This encoder seems to have been released yesterday (the github repository goes years back though). From a glance it seems less feature-complete than x265 and I don't know if it is based on HM like it - probably not since it claims to be written in C /YASM for assembly I guess/.

If somebody is curious, the first link has even windows builds for testing (didn't try). There is also a feature roadmap.

Supported platforms are Windows and Linux, code is licensed under GNU GPLv2.

Edit: ugh, I got the name of the university mixed up, it is Tampere University of Technology. Sorry.

[xooyoozoo]

It seems to be an academic project with a very conservative timeline. B-frames won't come for another several months, and it'd be a year before we get parallel processing...

The more the merrier, but between a reasonably exhaustive reference implementation (HM) and a reasonably practical real-world encoder (x265), I don't see why a license-compatible encoder wouldn't have started with a stronger foundation.

[Daemon404]

The more the merrier, but between a reasonably exhaustive reference implementation (HM) and a reasonably practical real-world encoder (x265), I don't see why a license-compatible encoder wouldn't have started with a stronger foundation.

I don't think I would call x265 a "reasonably practical real-world encoder" -- it looks visually crappy still.

Competition is good, especially one written from scratch, that isn't just another HM fork.

The more the merrier, may the best "win".

[Procrastinating]

v0.2.1

Intra frame period added as a command line option (-p).
Stdin support (give dash as input filename). (thanks @jeeb)
New unit test framework.
Replaced broken x86 cpuid asm implementation with a single implementation for both x86 and x64 using x264asm abstraction layer. We will be using x264asm for asm from now on.
Fixed Makefile to give correct build options for Mac and 32-bit Linux. (thanks @dirk and @rmustacc)
Fixed a small per frame memory leak.
Quality and bitrate improvements.
Merged a branch for changes related to intra 4x4 prediction block coding that isn't in use yet but fixed something resulting in improved quality.
Fixed bug in intra mode search resulting in increased intra quality.
Fixed CU split cost calculation, resulting in decreased bitrate.

We measured a cumulative average decrease in bitrate for a given quality (BD-rate) of 15% in LP configuration from v0.2.0 to v0.2.1. Although that was with a limited test set of just one 600 frame video.


With Stdin Support, Kvazaar should be functional now. It could be interesting to compare this to older versions of x265.

[Selur]

Does anyone know why MP4Box crashes when fed with the output of Kvazaar? (mkvmerge from ROVI and newer tsMuxeR versions work fine)

[Kurtnoise]

Dunno but did you drop a bug report to the gpac developers ? Did you test with l-smash muxer ?

[Selur]

Dunno but did you drop a bug report to the gpac developers ?
yes -> http://sourceforge.net/p/gpac/bugs/303/ (16 days ago)
Did you test with l-smash muxer ?
No.
a. didn't know l-smash muxer does support hevc
b. not sure where to find a current l-smash muxer binary

[JEEB]

L-SMASH has supported 14496-15 3rd edition HEVC muxing from quite some time ago, but it is currently disabled for the CLI because the standard still isn't officially out (it got into FDIS ballot last week, so we will finally see it officially out in April, as the FDIS ballot takes two weeks). If you use the library, you've been able to use it just fine.

I have made a pull request (https://github.com/l-smash/l-smash/pull/14) for enabling muxing here, as FDIS ballot starting means that there cannot be any technical changes in this version of the specification. One also has to note that the configurationVersion has to be updated as well, which is done in the pull request's commit as well.

You can have a current L-SMASH tools build with that pull request's commit merged here (http://fushizen.eu/builds/l-smash/l-smash_tools_r855_b5a2d08_hevc_enabled.7z).

[Selur]

Thanks JEEB!
Tested with the muxer you linked and L-SMASH also has no problem with Kvazaars output.
-> so only tool which fumbles seems to be MP4Box :(

[Selur]

got fixed! Muxing works with latest Mp4Box (rev5092) :)

[Shevach]

In HM there is an option ('-m') enable user to provide his own QP (actually QP delta) to each frame.
Is it or will this option available in Kvazaar?

[Selur]

Nope.
These are the user exposed options atm. :
/***********************************************/
* Kvazaar HEVC Encoder v. 0.3.0 *
* Tampere University of Technology 2014 *
/***********************************************/

Usage:
kvazaar -i <input> --input-res <width>x<height> -o <output>

Optional parameters:
-n, --frames <integer> : Number of frames to code [all]
--seek <integer> : First frame to code [0]
--input-res <int>x<int> : Input resolution (width x height)
-q, --qp <integer> : Quantization Parameter [32]
-p, --period <integer> : Period of intra pictures [0]
0: only first picture is intra
1: all pictures are intra
2-N: every Nth picture is intra
-r, --ref <integer> : Reference frames, range 1..15 [3]
--no-deblock : Disable deblocking filter
--deblock <beta:tc> : Deblocking filter parameters
beta and tc range is -6..6 [0:0]
--no-sao : Disable sample adaptive offset
--no-rdoq : Disable RDO quantiztion
--aud : Use access unit delimiters
--cqmfile <string> : Custom Quantization Matrices from a file
--debug <string> : Output encoders reconstruction.

Video Usability Information:
--sar <width:height> : Specify Sample Aspect Ratio
--overscan <string> : Specify crop overscan setting ["undef"]
- undef, show, crop
--videoformat <string> : Specify video format ["undef"]
- component, pal, ntsc, secam, mac, undef
--range <string> : Specify color range ["tv"]
- tv, pc
--colorprim <string> : Specify color primaries ["undef"]
- undef, bt709, bt470m, bt470bg,
smpte170m, smpte240m, film, bt2020
--transfer <string> : Specify transfer characteristics ["undef"]
- undef, bt709, bt470m, bt470bg,
smpte170m, smpte240m, linear, log100,
log316, iec61966-2-4, bt1361e,
iec61966-2-1, bt2020-10, bt2020-12
--colormatrix <string> : Specify color matrix setting ["undef"]
- undef, bt709, fcc, bt470bg, smpte170m,
smpte240m, GBR, YCgCo, bt2020nc, bt2020c
--chromaloc <integer> : Specify chroma sample location (0 to 5) [0]

Deprecated parameters: (might be removed at some point)
Use --input-res:
-w, --width : Width of input in pixels
-h, --height : Height of input in pixels
May be they will add something similar to x264s qp-files in the future, if you make a feature request in their bug tracker.

Cu Selur

[ReinerSchweinlin]

There is not much talk about this encoder, it seems.
In the beginning, it claimed to have much better scaling capability over x265 when using many cores. So this could be interesting with the newer CPUs where x265 can't saturate all the cores.
I have been looking around for some benchmarks, comparisons or Encoding GUIs using this encoder - no luck.
Does anyone have more recent informations about this encoder, any experience with it?

[benwaggoner]

There is not much talk about this encoder, it seems.
In the beginning, it claimed to have much better scaling capability over x265 when using many cores. So this could be interesting with the newer CPUs where x265 can't saturate all the cores.
I have been looking around for some benchmarks, comparisons or Encoding GUIs using this encoder - no luck.
Does anyone have more recent informations about this encoder, any experience with it?
x265 has gotten a lot better in scaling since then, and a lot faster in general. And with the Intel SVT integration, even more scaling is now available.

And encoder that hasn't seen substantial development since the commercial launch of HEVC content and services is unlikely to be competitive in any fashion by this point. >90% of HEVC encoder development has taken place since then.

[benwaggoner]

...although I just looked at the GitHub, and there have been at least some checkins since then. Not sure how material they are.

[ReinerSchweinlin]

Ben, thank you for the quick answer!
Is the SVT Integration activated by default in x265? I have a dual socket Xeon machine with 2 x 6 Cores (24 threads), in 1080p encodes only about 6 cores are used..

Edit: Found something. As far as I understand, SVT can be enabled, but it´s not simply a "tuneup" for x265, but a seperate encoder, primed for real-time encoding. So enabling SVT won´t give me the same results in x265 quality vise. Do I get it right? Thanx for your help :)

[Blue_MiSfit]

That is correct.

You should be able to saturate all those cores with x265 if you're using slow enough settings ;)

[Arizer]

Hi, Kvazaar developer here. I can confirm that we are not done with Kvazaar :)

Rate of progress can be sometimes a bit varying but we have improved Kvazaar a lot during the past months. New preset tables, significant optimizations and algorithms are work-in-progress.

I'm afraid not many 3rd party comparisons (that are not out of date by now) exist. Our own comparisons are available online mostly as conference proceedings (IEEE and ACM). IEEE Xplore for example has many of our papers. The research papers have been mostly about all-intra coding so far, but inter coding papers are on their way.

[ReinerSchweinlin]

Blue_MiSfit. thank you for confirming :)