H265/HEVC samples

[Mephesto]

1) the notion that h265 can't keep up with x264 is a flat out lie, there are samples i linked to where h265, a codec that is still in it's infancy walks all over x264, an h264 encoder that has been around for 10 years.

I'm not denying H.265 is higher quality now and will get better later. I've already tested it out and it had better grain-preserving ability but I couldn't tell the difference on clean, animated samples where the mb-tree was clearly triumphing. mb-tree negated HEVC's initial goal of 20% better objective quality.

2) more importantly, mb-tree is not revolutionary, want to guess how mb-tree came about? it's because jason, aka dark shakari, aka lead x264 developer was testing x264 against main concept's h264 encoder and discovered that MC was producing much higher quality I frames than x264:

http://x264dev.multimedia.cx/archives/98

I see the dev being inspired by mainconcept's HQ I-frames to write mb-tree for HQ P frames, not outright stealing an idea. Aren't I frames the least populous frames in the video anyway?

The features you listed can be useful, but not for me as I clean all my videos of all noise and let other people add noise via post-processing if they want it.

The "Detail AQ" already exists in x264 and all other encoders, it's called the QP curve which you can adjust. Default is 0.6.

In the end, the lower average quality mainconcept produces mitigates any potential tuning feature.
http://www.compression.ru/video/codec_comparison/h264_2012/figures/results.png

[poisondeathray]

I'm not denying H.265 is higher quality now and will get better later. I've already tested it out and it had better grain-preserving ability but I couldn't tell the difference on clean, animated samples where the mb-tree was clearly triumphing. mb-tree negated HEVC's initial goal of 20% better objective quality.

I think the claims were 50% , not 20% , or something like that ? Perhaps that figure is true for "generic" h.264 encoders, not x264, at least with my observations

I tested a variety of samples, including anime; my general impressions - HEVC is impressive, and does beat x264 in most scenarios overall - but only by a small amount. It's strengths : very clean encodes, very minimal artifacting, very temporally stable images at low bitrates . I haven't gotten around to testing higher bitrate range, (ie. grain and noise retention, visually lossless settings) or tweaking any settings so far . It's just too difficult and time consuming to do numerous encodes (too slow) for complete testing

It's weaknesses (in terms of quality) at "regular" settings - same problems similar to other encoders with dark areas (areas that AQ tends to fix with x264) . HEVC does have aq settings, but I haven't gotten around to testing them

-aq, --AdaptiveQP QP adaptation based on a psycho-visual model
-aqr, --MaxQPAdaptationRange QP adaptation range

The other huge weakness is speed, but that should be rectified within the next few months with optimization patches. It's easily 40-60x slower than x264 using typical settings

It does look VERY promising. With optimizations and farther development it should be awesome. The way I see it, x264 has pretty much plateaued (I mean in terms of quality, it will still be developed to include new instruction sets for speed ). I'm almost ready to jump ship as soon as it becomes "usable" for regular use

The huge difference this time around vs. h.264 is HEVC hardware support is being developed very early on. I expect to see hardware support by Christmas or early next year

[deadrats]

I see the dev being inspired by mainconcept's HQ I-frames to write mb-tree for HQ P frames, not outright stealing an idea. Aren't I frames the least populous frames in the video anyway?

P frames and B frames depend on I frames, higher quality I frames would invariably result in higher quality P and B frames as they make reference to I frames.

furthermore, as far as i can tell mb-tree is really aimed at improving B frames, not P frames:

http://forum.doom9.org/showthread.php?t=148686

with regard to the MSU comparisons i don't think they are an accurate representation of what each encoder is capable of. x264 is coded in a very deceitful way, in addition to the psychovisual switches everyone knows and loves/hates (psy-rod, psy-trellis and AQ) it also has a number of internal psychovisual optimizations that aren't configurable, you can only turn them off via --no-psy, basically instead of trying to encode a picture as close to the source as possible it tries to make it more visually pleasing.

as i said and as you noted, in general it's not the job of the encoder to improve the output compared to the input, it's job is to reproduce the input as closely as possible. now if they wanted to code a bunch of filters to do the job of their precious little psychovisual enhancers, then they should have done just that.

furthermore, the MSU test is flawed for one very big reason, it tests MC based encoders that don't support all the features of the MC SDK and that does include main concept's own offering total code. the SDK exposes tons of features of the MC encoder but ISV pay for what features they wish to support, just because you buy a base SDK license you don't get to offer all the encoder features in your product, you pay for each level of features you want.

to the best of my knowledge there have only been a handful of software vendors that supported a reasonably large number of MC's optional encoding parameters, with one being magix video editing software (don't know if it still does but it used to have over 50 encoding parameters that were configurable).

[poisondeathray]

with regard to the MSU comparisons i don't think they are an accurate representation of what each encoder is capable of.

I agree isn't not accurate, but for different reasons. MSU isn't an accurate representation of "quality", because it relies on 1 metric, SSIM , which is problematic and doesn't necessarily reflect "quality" accurately

However, it IS an accurate represenation of what they purported to measure and does reflect what each encoder is capable of in terms of SSIM. Mainconcept gave them the SDK available at the time and even configured the presets and settings for them.

x264 is coded in a very deceitful way, in addition to the psychovisual switches everyone knows and loves/hates (psy-rod, psy-trellis and AQ) it also has a number of internal psychovisual optimizations that aren't configurable, you can only turn them off via --no-psy, basically instead of trying to encode a picture as close to the source as possible it tries to make it more visually pleasing.

How is x264 coding "deceitful" ? You have more options to turn things on/off or adjust values

as i said and as you noted, in general it's not the job of the encoder to improve the output compared to the input, it's job is to reproduce the input as closely as possible. now if they wanted to code a bunch of filters to do the job of their precious little psychovisual enhancers, then they should have done just that.

You have the option to use them, or not, or adjust them ... How is having more options a bad thing ?

Have you actually tested --tune ssim or --tune ssim ?? (they turn of psy opts as you know) . The visual quality is a lot worse despite "scoring" higher on metrics

furthermore, the MSU test is flawed for one very big reason, it tests MC based encoders that don't support all the features of the MC SDK and that does include main concept's own offering total code. the SDK exposes tons of features of the MC encoder but ISV pay for what features they wish to support, just because you buy a base SDK license you don't get to offer all the encoder features in your product, you pay for each level of features you want.

Not flawed for this reason. MC gave them the most up to date SDK at the time (9.2), and even provided what settings and configrations to use. Without a time machine, they couldn't have given them today's SDK...

to the best of my knowledge there have only been a handful of software vendors that supported a reasonably large number of MC's optional encoding parameters, with one being magix video editing software (don't know if it still does but it used to have over 50 encoding parameters that were configurable).

Trust me, I've tested them, MC is still inferior in almost every test, every situation, every bitrate range, in its most recent iteration (Total Code)

[deadrats]

The other huge weakness is speed, but that should be rectified within the next few months with optimization patches. It's easily 40-60x slower than x264 using typical settings

x264 has loads of hand coded simd (mmx/sse/avx2) while all the h265 encoders currently available are based on the C/C++ coded reference encoder. i honestly think even compiling the reference compiler with a good optimizing compiler, like intel's or microsoft's would result in a substantial speed up. AVX2 should effectively do away with the speed penalty once processors that support that instruction set become widely available.

i would expect the mainconcept/rovi/divx h265 encoder to arrive well optimized and fast enough, plus they have promised gpu acceleration from the get-go.

[poisondeathray]

The other huge weakness is speed, but that should be rectified within the next few months with optimization patches. It's easily 40-60x slower than x264 using typical settings

x264 has loads of hand coded simd (mmx/sse/avx2) while all the h265 encoders currently available are based on the C/C++ coded reference encoder. i honestly think even compiling the reference compiler with a good optimizing compiler, like intel's or microsoft's would result in a substantial speed up. AVX2 should effectively do away with the speed penalty once processors that support that instruction set become widely available.

Yes, I expect it to be much faster (well it can't go any slower LOL). The way the HEVC engineer explained it in the doom9 thread, it seems HEVC is much more amenable to parallelization also. If you 've used JM reference AVC encoder, it's not very optimized either (slow, low quality). So it bodes well that the HEVC reference encoder pretty much beats everything else in terms of compression at this early stage and it can only get better and faster

i would expect the mainconcept/rovi/divx h265 encoder to arrive well optimized and fast enough, plus they have promised gpu acceleration from the get-go.

I hope so, it's almost impossible to do proper serial testing right now unless you have a lot of time on your hands with a server farm of idle computers.

[david55]

Allegro DVT :world first live broadcast encoder and transcoder for HEVC


http://www.allegrodvt.com/broadcast/index.php?option=com_content&view=article&id=89&Itemid=61

[exmplayerdev]

Use ExMplayer 3.0 which can play any media formats http://exmplayer.sourceforge.net/downloads.html Download it for free

[arizonastar]

Got an RSS feed saying about SUPER ©
HEVC/H.265 Video Codec full support to decode/play any file or encode it inside MKV, MOV, MP4 containers
VP9 Video Codec full support to decode/play any file or encode it inside MKV and WebM containers

[posdnya]

The first 4K experience with BlackMagic Production Camera 4k
http://www.elecard.com/en/download/videos.html

3840x2160 HEVC elementary 3 mbps 3:39 min 77 MBytes

For faster download: https://mega.co.nz/#!YAAw0RhJ!LJKIGnx9qIdmSj_77A8KU5OVxz1lIfW_IzjVRzjuJlE

[Gravitator]

The first 4K experience with BlackMagic Production Camera 4k
3840x2160 HEVC elementary 3 mbps 3:39 min 77 MBytes

It is quite enough for family video libraries HQ camera provided good compression

[Gravitator]

Hi!
You can look (sample) on Your Elecard analyzer and think what is the reason residues trash / bands? This may be due to the fact that the encoder:
not exactly cuts frame;
not correctly subtracts the difference between frames;
not properly compensate for movement (not exactly take into account the movement);
smoothing problem:
Wrong!!! - draw grid # > smooths (possibly hit the texture neighbouring block) > cuts on operational units queerly;
That's right - to draw grid # > cuts on operational units > smooth (to exclude contact with the neighbouring block).

[wxhynwxhyn]

The Strongene OpenCL HEVC decoder is the fastest one in the world. It produces extreme low CPU usage. If you have AMD GPUs, the CPU usage will be even lower. Now the version 2.0.0.0 is available on their website. You can follow this link to download it. http://xhevc.com/en/downloads/downloadCenter.jsp

[Kaustubh.patankar]

has any one tried the Ittiam plugin for HEVC encoder and decoder?

[Gravitator]

Realtek became friends with the video codec HEVC > Ittiam

[Gravitator]

Elecard added new demo video HEVC with a resolution of 4k > http://www.elecard.com/en/download/videos.html

[Gravitator]

Hi posdnya,
Win7x64, Fireox 30 refuses to download videos when you click on the link (I have through the right button> save object as).

Video, for a diversity would not hurt to visit the station / train (mass of people), sports games (hockey, football, basketball, chess).

[Kaustubh.patankar]

Ittiam has best in class HEVC solutions. http://www.ittiam.com/News/en/press-releases/2014/156-Ittiam-Systems-to-Demonstrate-La...-at-NAB14.aspx

[Gravitator]

Ittiam has best in class HEVC solutions.

Hi!
Good to see benchmarks encoder / decoder on OpenCL acceleration

[Kaustubh.patankar]

Ittiam's H.265 / HEVC Encoder : Announces Availability of Its Third Generation H.265/HEVC Codec with 422 12-Bit Support

[Gravitator]

Elecard has once again joined the 4k video (cows on the meadow) > http://www.elecard.com/en/download/videos.html
Download speed is very low 50 kb/s .... Прием через интернет дома от Билайн.

[posdnya]

Couple more 4K TS files. High quality 17 min video in AVC (PSNR 48 db) and HEVC (49 db) - free for any type of use.
http://www.elecard.com/en/download/videos.html
Russian Beatles. Absolutely Russian.