On Eve: A new (and pretty fast) VP9 encoder compared to libvpx

[Dennis Mungai]

Hello guys,

When it comes to encoding video files to the loyalty-free VP9 codec,
the greatest cost we pay is CPU cycles: It's a slow, expensive process
(resource-wise) even on some of the fastest CPUs around.

Having come from libvpx (Built-in with ffmpeg) , I can attest to this.

I came across this guy who's blogged about a new encoder for VP9, Eve,
In his tests (See
https://blogs.gnome.org/rbultje/2016/05/02/the-worlds-best-vp9-encoder-eve-2/
), he claims that:

" Eve offers 5-10% better compression rates (for broadcast-quality
source files) compared to libvpx, while being 10-20% faster at the
same time.

Compared to x264, it offers 15-20% better compression rates, but is
~5x slower. Its target rate adherence is far superior to libvpx and
comparable to x264, and most importantly, these improvements aren’t
just in metrics: the resulting files look visually much better than
those generated (at the same bitrate) by libvpx and x264."


See his data above.


It also seems that Eve is commercial software being developed at Two
Oreoles, a company that specializes in consultancy work around VP8/9
and webM technologies.

I'll run the tests he ran and reproduce these results should I get
access to the software.


Your video encoding enthusiast,

Dennis.

[Alan Orth]

Wow, awesome blog post. Thanks for sending it. I was really impressive with his earlier blog post[0] about VP9 quality.

Eve looks very impressive, but it's annoying that he writes about his commercial software and support offerings on his gnome.org blog... Grrrr.

[0] https://blogs.gnome.org/rbultje/2015/09/28/vp9-encodingdecoding-performance-vs-hevch-264/

Regards,

--
You received this message because you are subscribed to the Google Groups "Nairobi GNU/Linux User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nairobi-gnu...@googlegroups.com.
To post to this group, send email to nairo...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alan Orth
alan...@gmail.com
https://englishbulgaria.net
https://alaninkenya.org
https://mjanja.ch

[Dennis Mungai]

Alan,

I have sent their team an email requesting access to Eve.

It would be interesting to test this encoder across a wider variety of
media types (Raw, muxed, etc) and source codec types (Xvid/DivX,
H.264, On2's VP8 and ITU-T's HEVC) to get statistics on SSIM, PSNR
(image quality measurements) and extras.

And yes, using gnome.org's blogs to write about proprietary software
offerings is a bit off, in the least. Still, good content.

-Dennis.

[Mwaoshe Njemah]

SSIM is the only metric that matters really.
Still, EVE sounds pretty impressive and nice to see open video formats
finally catching on.

Mwaoshe Njemah
Lead,
Teke Teke
www.teketeke.co.ke
mo...@teketeke.co.ke
0722 99 19 18 | 0733 66 55 77

[Dennis Mungai]

Nj3ma,

Both SSIM and PSNR matter.

For one, you cannot compute proper psychovisual trellis (particularly for H.264) without PSNR data, yet trellis falls under SSIM mechanics. Both complement each other when it comes to quality control schemes.

It is of interest to note that only SSIM is perceptible to the human eye whereas PSNR is not, and is often overlooked despite its tremendous value to the former.

[Dennis Mungai]

Well guys, bad news:

Seems I need a hefty sum and a contract to gain access to Eve's binaries:

"Dear Dennis

Thank you for your interest in Eve. Unfortunately the encoder is
currently not available as a free product on the open source. We offer
licensing contracts on an annual basis at US$50k per month for use of
the binary. We do offer potential clients the opportunity to evaluate
a test version of Eve for a period of 2 months prior to committing to
the licensing contract at a cost of US$20k.

Please do not hesitate to contact us if you have any questions or if
you would like to move forward with a contract to test Eve.

Kind regards,

Li-Ling Lee
"

So no tests will follow. Back to libvpx then.

[Tony White]

Dennis, how do you think this VP9 encoder stacks up against x265 -
which seems to be gaining in popularity?

50k per month!!! - sheesh! - seems this product is aimed at
broadcasters, with more money than sense!

Cheers,
Tony

Tony White

[Dennis Mungai]

Tony,

Here's my breakdown, based on my tests on the hardware I own:

Let's begin with the actual codecs: VP9 and HEVC/H.265:


In terms of (subjective) visual quality, I have observed that HEVC is
considerably better at quality retention in low-bitrate,
low-resolution scenarios whereas VP9's superiority is demonstrated at
higher resolution, low bitrate scenarios (As in the case of Youtube's
VP9 streaming on supported platforms). Where they both level off,
perceptually, is when similar bitrate is applied (fixed-rate) on
resolutions at and above 1080p.

For fast motion scenarios, HEVC is better at retention, yet VP9 is
better at bitrate adherence for the same container specification
(Matroska, at the time of testing).

Now, on encoders:

libvpx (Which does both VP8/9 encoding in ffmpeg, if configured as
such at build time) is atrociously slow and compute expensive. Also
not very well threaded. This might change in the future, but for now,
this is the case.
x265 (I currently run this as libx265, built in ffmpeg as a
configuration switch) has proven to be significantly faster than
libvpx on the same hardware, has excellent threading and great
instruction level support (MMX, SSE, AVX, BMI on supported processors)
and is also highly configurable.

However, compared to the standard x264 encoder, both libvpx and
libx265 are way slower, and they'll both munch on delicious CPU
cycles.

And now, let's look at common encoding scenarios you may run into:

At the moment, I use Nvidia's NVENC to encode HEVC content (via
FFmpeg, needs to be compiled with --enable-nvenc switch and a
provision of the NVENC SDK+ headers) on Maxwell GM200, GM204 and
Pascal's GP104 hardware (GeForce GTX 980Ti, GeForce GTX 980M SLI combo
and a pair of GeForce GTX 1080 GPUs respectively) and when using this
form of hardware-accelerated encoding, the quality of the encoded
material is considerably worse at the same settings as a
software-based encoder such as libx265. And by the way, MainConcept's
proprietary encoder is inferior to x265 interms of performance and
output quality, at the moment.

When using hardware-accelerated encoders, one must bump up the bitrate
to offset the sub-par bitrate allocation on these encoders, so your
mileage here may vary as more platforms with this feature emerge.

At the moment, I'm aware that Intel's up and coming Kaby Lake iGPs,
current-generation Skylake and AMD's Carrizo-L APUs have support for
this feature (through VAAPI for Intel and OpenMAX IL for AMD's VCE
hardware) on Linux.

For VP9 hardware-accelerated encoding, Intel's current-generation
Skylake and up-and coming Kaby Lake SKUs wil support it theough VAAPI
(exposed through both gstreamer and Libva's implementations).

I hope that the information provided above will be of help to you.

Thanks and regards,

Dennis.

[Tony White]

Dennis, -- Wow!! What an outstanding answer to my (simple) question.

At the moment, all I do is re-encode stuff to x264/mp3 in an mp4
container - cos that's what my (LG non-smart) TV can handle from my
external usb hdd. On my (old) kubuntu laptop, that takes about as
long as the programme's run time - sometimes longer :(

Thanks again for the info,

[Dennis Mungai]

Well, if I may suggest an ideal scenario that would suit you:

Acquire a simple set-top box (Like the MX4, @eebrah has one of these
sweet devices that also supports HDMI CEC and HEVC
hardware-accelerated decoding, sweet stuff!) connected to your TV as a
monitor would suit you from a media server perspective:

Store all your media on a HTPC, run Kodi, enable media sharing (upnp)
(Commonly termed as DLNA, the Digital Living Network Alliance) such
that all clients on your home network can access the HTPC's media
shares and no one has to fight for remotes anymore :-)

Be they tablets, gaming consoles (All the way from Sony's PS3),
set-top boxes and hand-held consoles (Like the Nvidia Shield series),
they can all be served without the need for expensive transcoding
(that also happens to be lossy by default).

That's my current setup over two Nighthawk X6 routers, one HTPC
(AMD-based box, ~28 TB of movies and music) and clients range from two
Smart TVs (One in the table room + One in the bedroom) , a PS3 that
runs Linux (Also plays H.264 content really well, connected over
ethernet), two tablets and a couple of Android phones running Kodi.

Sure, this one needs an actual network setup (A fast Wireless network
served by a recent router, AC strongly recommended) and some hardware,
but it serves multiple clients at the same time.

PS: Does anyone here run Plex? It's been a while since I deployed it
(and back then it required live transcoding when serving specific
clients :-( ).

Note to self: Should look into a proper set-top box situation for the
clients. Smart TVs can get dumb at times, failing to reconnect when
the network configuration changes.

[Tony White]

Ahhhhh..... (Dreams)

Great suggestions... one day...

Meanwhile... here in the shamba, on solar power, with a barely
workable Safcon connection, I have to make the best of it :(

[Adam Nelson]

Dennis,

It's time to stop posting on this list and get a job with somebody like Eve or JWPlayer or Wowza :-)

I might be able to connect you with JWPlayer if you're interested.

-Adam

--

About Adam: www.linkedin.com/in/adamcnelson

[Mwaoshe Njemah]

Dennis,

Before you get hired and we can't afford your expertise anymore, what's a good low-TDP processor to build HTPC with currently? 

Richland any good?

[Dennis Mungai]

Hello Njema,

Any cheap box would do, so long as storage is sufficient to your needs.

Note that for such a setup( as inferred with what I run at the
moment), the HTPC is a headless system that does no local playback.
It's key function is running Kodi (as a session, systemd) and I
connect to it via SSH and transfer files over rsync and scp should the
need arise.

Key note here is storage, the processor you choose is of no
significance. The second part is the networking. Some Gigabit ethernet
and a strong AC wireless network will suffice.

My current setup has twelve 8 TB WD Red (NAS-Ready as branded), see
https://www.amazon.com/Red-6TB-Hard-Disk-Drive/dp/B00LO3KR96, and
storage is over ZFS mounts, RAIDed as appropriate.
Migrated a while back from BTRFS prior to upgrading to Ubuntu 16.04LTS
(I do use it internally on a few hosts).
Boot drive is a 256GB SSD (Intel). And the CPU on it is a much older
Kaveri APU (A10-7850K), a 2014 model.

I would not recommend Richland (Due to the much older VLIW4-based GPU
architecture, Terascale) as you'd have to use the radeon driver.
Stable at the moment, yet has no support for Vulkan and performs
sub-par to it's windows equivalent on Linux. Secondly, you'd be unable
to use AMD Catalyst as it's too old for the much newer X and kernels
(ABI breakages) and on top of that, the GPU architecture is no longer
supported by the current Catalyst suite (Which now requires all cards
to be GCN 1.0+ SKUs).

With the Kaveri APUs, I can run the current-generation opensource
driver, amdgpu. I wrote of my experiences with it here on Ubuntu
16.04LTS: https://www.linkedin.com/pulse/using-newer-amdgpu-driver-ubuntu-1604lts-dennis-mungai?trk=pulse_spock-articles

Kaveri has an on-board Hawaii GPU, a GCN 1.1 part that plays really
well with the amdgpu driver (both power management and rendering are
okay. Not tested with any form of Linux gaming apart from Phoronix's
benchmarks).

If you'd rather go team Intel, take on the ~$70 Intel Pentium G3258
whose integrated GPU (Haswell) works flawlessly and out-of-the-box on
Linux, for both power management and graphics rendering. Sure, it's
GPU is weak on rendering, but for media decode, its a small beast.
Plus, VAAPI is awesome and works out of the box for most setups.

Take your pick.

[Dennis Mungai]

And a few notes on hardware-accelerated HEVC decode availability in
current-generation SKUs, should you be out shopping for the likes:


Earlier Nvidia Maxwell SKUs (namely the GM107,GM108 and GM204) as well
as Intel Haswell(4th Generation) and Broadwell (5th Generation) IGPs
can handle up to 4k HEVC decode in hybrid mode (Using both software
and partial decode offload on hardware) with ease on both Windows
(DXVA) and Linux (via VDPAU for Nvidia and VAAPI for Intel).

Current-generation Nvidia GPUs(namely the Maxwell-based GM206 and
GM200 as well as the latest Pascal (GP104) can handle full HEVC decode
up to 4k in hardware, and so can Intel's Skylake IGPs. (6th Generation
Intel Core processor GPUs).

On AMD's part:

Kaveri-based APUs can perform partial HEVC decode (I am yet to test
this on any hardware, if you have a kaveri SKU, please run DXVAChecker
on it and report back) via decoders such as UHDCode.
Carrizo and Carrizo-L based APUs can perform full HEVC decode in
hardware (up to 4k) with a similar, or better, decode feature set as
Intel's 6th Generation Skylake IGPs.

And on ARM:

There are a wide variery of ARM-based SoCs that offer HEVC decode
support, and software fallbacks exist for such platforms, such as the
HEVC decoder provided by Ittiam systems. On ARM-based hardware, you
are advised to seek further information on this from the vendor
shipping such a product (as is the case with set top boxes and mobile
devices). At the moment, I'm aware that some platforms such as the
Odroid C1 and the the Meizu MX series of set top boxes provide this
feature.

[Dennis Mungai]

Tony White, et al,

For your reference, here are three clips (in 4k) showcasing the same
video stream encoded to the same visual quality level (AQ mode) with
x264,x265 and libvpx for H.264, H.265/HEVC and Google's VP9 codecs
respectively:

https://1drv.ms/f/s!AjAHK3AVf89tqVyMtyoS7cUs6_Jd

You can view the video encoding options used by running FFmpeg's
ffprobe or mediainfo (May require installation on your distribution
prior to usage).
Both tools should provide you with the encoding options used.

PS: That's a OneDrive link, and that is a read-only share.

Documentation:

1. ffprobe's usage: https://trac.ffmpeg.org/wiki/FFprobeTips
2. ffprobe's documentation: https://ffmpeg.org/ffprobe.html
3. mediainfo's manpage entry:
http://manpages.ubuntu.com/manpages/precise/man1/mediainfo.1.html

Thanks and regards,

Dennis.

[Tony White]

Thanks, Dennis

Cheers,

--
Tony White

[Dennis Mungai]

Njema,

See the attachment. Details on SSIM and PSNR inside.