x265 HEVC Encoder

[xooyoozoo]

Adaptive Quantization is still considered experimental. We are not always seeing the expected improvements to SSIM when it is enabled, and thus it is still not enabled by default.

I've been testing AQ on still images because it's quick and *SSIM is still a spatial metric, and I also assumed it was reasonable that changes in Intra results would represent changes in the rest of a clip. Here, 5-20% bdrate improvements versus HM12 on MS-SSIM seems normal.

Just did an actual short clip, and x265+AQ scored worse than HM12, in contrast to what both a set of single-frame encodes and visual inspection of mid-clip snaps (http://i.imgur.com/eKd71Bp.png) demonstrate. ¯\_(ツ)_/¯

[x265_Project]

I've been testing AQ on still images because it's quick and *SSIM is still a spatial metric, and I also assumed it was reasonable that changes in Intra results would represent changes in the rest of a clip. Here, 5-20% bdrate improvements versus HM12 on MS-SSIM seems normal.

Just did an actual short clip, and x265+AQ scored worse than HM12, in contrast to what both a set of single-frame encodes and visual inspection of mid-clip snaps (http://i.imgur.com/eKd71Bp.png) demonstrate. ¯\_(ツ)_/¯

Interesting! Thanks for sharing.

[LigH]

Now when using "--fps 23.976" the log says "23Hz".

It still does? I don't even remember when I reported this missing precision... during v0.3?

[sneaker_ger]

I revisited the --crf encodes today and compared 10 Bit to 8 Bit encoding and the 10 Bit crf feature really looks to be far off/have a different scale.

[Kurosu]

visual inspection of mid-clip snaps (http://i.imgur.com/eKd71Bp.png) demonstrate. ¯\_(ツ)_/¯

Visual inspection of that snap shows me a vast superiority of x265+AQ over HM12 to my eyes: the HM12 is a blurry mess (tree, grass, sky). And the parts where it is a lot more blurry have less motion, so one may notice that more easily.

[Procrastinating]

Just did an actual short clip, and x265+AQ scored worse than HM12
As kurosu said, did you look at those pictures? HM12 looks awful in comparison on just about every noticeable front.

[sneaker_ger]

It still does? I don't even remember when I reported this missing precision... during v0.3?

Fractional rates seem to be on the to-do list at least.

https://bitbucket.org/multicoreware/x265/wiki/TODO

[foxyshadis]

I revisited the --crf encodes today and compared 10 Bit to 8 Bit encoding and the 10 Bit crf feature really looks to be far off/have a different scale.

In AVC & HEVC, every extra bit of depth bumps the quant scale up by 6, so 10-bit is +12. If you'd normally use crf 24, you'd have to use crf 12 in 10-bit or you'll get files about four times as large. If you normally use 10, you have to use -2. (Yup, negative crf is allowed.)

I have no idea why they chose that method.

[Procrastinating]

I may be missing something here, but can x265 input yuv420p10le color space? Otherwise in what format should the 10-bit YUV/Y4M be? Or am I really missing something here and x265 cannot yet input 10-bit video?

x265 crashes with the error "header missing" on a yuv420p10le .y4m when using --input-depth 10 (displays no error and just crashes on --input-depth 8)
and displays the processing of the first frame before crashing when providing the parameters and using a raw .yuv
The YUV's and Y4M's were processed with FFMPEG using the rawvideo yuv420p10le and yuv4mpegpipe formats respectively.
For the record, x264 processes these raw inputs fine.

Similarly, what is the best way for outputting x265 compatible 10-bit y4m through ffmpeg?

[easyfab]

for raw 10-bit .yuv it's ok for me with --input-depth 10 --input-csp i420 --input-res ***x*** --fps ***
But from ffmpeg with : -pix_fmt yuv420p10le -f yuv4mpegpipe it doesn't work

[Selur]

yuv420p10le through ffmpeg works fine here,...
ffmpeg -v -10 -i "H:\TestClips&Co\test.avi" -an -sn -threads 8 -vsync 0 -r 25 -pix_fmt yuv420p10le -f rawvideo - | x265-16bit --input - --input-depth 10 --input-res 640x352 --fps 25 --frames 429 --b-adapt 2 --rd 0 --no-signhide --output "H:\TESTCL~1\test_09_26_58_7410_01.265"
when using y4m with ffmpeg you simply need to exchange '-f rawvideo' with '-f y4m' iirc.

[easyfab]

Selur,

You're right with -f rawvideo it's ok so it's only -f yuv4mpegpipe that doesn't work for me.

[sneaker_ger]

Yes, raw 10 bit worked fine here, too. What doesn't seem to work is 10 Bit data with an y4m header (which x264 does support).

[Selur]

Does anybody know why:
mencoder -lavdopts threads=8 -of rawvideo -o - -ovc raw -demuxer lavf -noskip -vf scale,format=i420,scale,format=420p10le -forcedsubsonly -nosub -nosound -mc 0 "H:\TESTCL~1\test.avi"
fails, due to the decoding part:
mencoder -lavdopts threads=8 -of rawvideo -o - -ovc raw -demuxer lavf -noskip -vf scale,format=i420,scale,format=420p10le -forcedsubsonly -nosub -nosound -mc 0 "H:\TESTCL~1\test.avi"
which fails with:
MEncoder SVN-r36521-4.8.2 (C) 2000-2013 MPlayer Team
success: format: 0 data: 0x0 - 0x1c2c9e
libavformat version 55.21.102 (internal)
libavformat file format detected.
[lavf] stream 0: video (mpeg4), -vid 0
[lavf] stream 1: audio (mp3), -aid 0
VIDEO: [MP4V] 640x352 24bpp 25.000 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:35 fourcc:0x5634504D size:640x352 fps:25.000 ftime:=0.0400
Writing to stdout
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1, osd: 1, aspect: 0.000000, round: 1
Opening video filter: [format fmt=420p10le]
Opening video filter: [scale]
Opening video filter: [format fmt=i420]
Opening video filter: [scale]
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
libavcodec version 55.44.100 (internal)
Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4)
==========================================================================
The selected video_out device is incompatible with this codec.
Try appending the scale filter to your filter list,
e.g. -vf spp,scale instead of -vf spp.

Exiting...
-> Did I miss something, doesn't '-of rawvideo -ovc raw' support 420p10le as output?

Cu Selur

[qyot27]

I mentioned the fact that x265 doesn't support FFmpeg's extended y4m format back on page 4 (http://forum.doom9.org/showthread.php?p=1653130#post1653130). The situation is that those extensions are purely on FFmpeg's side (libav doesn't support them), not from MJPEGTools, and the argument that it's an unofficial extension to Y4M (no matter that x264 and VapourSynth both use it) is probably why it's been overlooked. Or it might not have such ulterior motives and merely be an honest mistake of omission. Without an actual explanation, all there is is conjecture.

-> Did I miss something, doesn't '-of rawvideo -ovc raw' support 420p10le as output?
My guess: mencoder simply doesn't support it because it has to be specifically modified to do so, which is unlikely because of how badly unmaintained it is. A year ago, I'd done some fiddling in mpv to add support for the 12-bit and 14-bit outputs, and it required going in and adding a bunch of IDs to the pixel format lists specifically so it could see them (this is no longer how it works in mpv, so all those pixfmts are handled automatically now, but what I just described is highly likely to be how mencoder handles it - the 'old way' is probably from the legacy mplayer codebase that mencoder is derived from, but possibly even older than mplayer-svn's current method of handling it might be).

[fumoffu]

I have a problem with x265 - it blurs delicate skin textures way too much.
(If there is a strong texture it preserves it and other strong details are well preserved too but those more delicate textures are just becoming flat).
I tried almost every possible setting and I didn't find anything that makes much difference. Setting aq strength to 2 increases bitrate very much for very small visual improvement. The weird thing is that increasing crf/bitrate doesn't help much either.
(I also tried: no-sao, no lft, subme 7, b-adapt 0-2, rd 4-5 and cbqpoffs/crqpoff)
The reason I'm mentioning it is I tested divx encoder today with the same bitrate and it did much better. In the past I also played with Strongene encoder and from what I remember it didn't had this problem until really low bitrates.
Of course I'm not writing this to argue that DivxHEVC is better - devs are doing great job with x265 and I'm a fan ;) Just wanted to point out that there might be a problem with something.

Example: original/divx and x265 at around 2500kbps
http://i.imgur.com/74WD2B2.png http://i.imgur.com/1J1h0Wo.png http://i.imgur.com/oBL7kZX.png

Or maybe I'm doing something wrong? Maybe it's color space conversion issue or something?
I have been just encoding with command like this:

ffmpeg.exe -i test.mp4 -an -f yuv4mpegpipe - | x265 --y4m --input-res 1280x720
--fps 29.97 --merange 32 --no-progress --crf 20 - -o test.hevc

and optionally adding other stuff like --rd 4 --aq-mode 1 --aq-strength 1.8 or other switches..

edit:
I've done some more test and:
-x265 @4000kbps still looked worse than DivxHevc (@2500kbps) and worse than x264 @4000kbps (preset slow with some tweaks)
-x265 @4000kbps +aq-strength 1.8 - better, similar to DivxHevc (@2500kbps)

[Procrastinating]

None of the various 10-bit sources I have seem to work with x265, even after converting to YUV, and even on default parameters. Could someone upload a short 10-bit .yuv/source which worked for them?
x265 crashes immediately after beginning the processing for the first frame, not even a log is produced with --log 3 and --csv enabled.

Tried both 32 and 64 bit 16bpp 0.6+83-a482cf5de173 MinGW builds. I'm using Win8 64-bit i5 3570, but I find it hard to believe that my system is causing it to crash.

[sneaker_ger]

It can't have anything to do with the source since we are talking about raw data. Even if you use a wrong one it should produce (syntactically correct) garbage at worst. Did you try the VC builds?

https://x265.cc/

[filler56789]

Over here, crashes happen only if I try to use other --input-csps than i420.

[x265_Project]

The developer team is working on a bug that is causing builds from the default branch (development tip) to crash. The stable branch is not affected.

[x265.cc]

The stable branch is not affected.

..and the stable version is just a development version flagged as stable.

So if somebody want to get this version, build it yourself or simply check out which development version (https://bitbucket.org/multicoreware/x265/commits/all) has been flagged as stable, and download it at the buildbot site.

[zerowalker]

No. x265 produce in my test quality between H264 Mainconcept (slowest mode) and x264 10 bits (placebo mode) at half bitrate. I have simply never see this difference bettwen previous and next generation codec ... :D


I don´t quite get what you mean.

Are you saying that x265 produces something in the middle of the 2 (h264 slowest, x264 10bit placebo) but at half the bitrate compare to those 2?

Meaning x264 10bit 5k bitrate will look a little bit better than 2.5k bitrate x265, but increasing the bitrate a bit will make it better?

[Procrastinating]

So if somebody want to get this version, build it yourself or simply check out which development version (https://bitbucket.org/multicoreware/x265/commits/all) has been flagged as stable, and download it at the buildbot site.

It seems that none of the (two) 0.6 "stable" builds are available on the buildbot site, and neither are several previous commits, which is a shame. I guess I'll wait it out to see if the crash they are describing is also the crash I am encountering. I have tried all variations of the latest build and the 64bit 16bpp mingw builds of several earlier builds, and they all either crash immediately after entering the parameters, or on processing the first frame (ie [0.1%] 1/1684 frames...)

[x265.cc]

It seems that none of the (two) 0.6 "stable" builds are available on the buildbot site

use the "x265_0.6+3-55c0bf9d9966.zip" version, it should mostly be this what the call "stable".

I have tried all variations of the latest build and the 64bit 16bpp mingw builds of several earlier builds, and they all either crash immediately after entering the parameters, or on processing the first frame (ie [0.1%] 1/1684 frames...)

The 8bpp builds don't crash for me. (low res source, ffmpeg pipe, medium preset)

[qyot27]

The only crashes (more precisely, segfaults that I haven't had time to run through gdb) I've experienced where/are when using certain presets. At one point a couple weeks ago it was there on the default preset and the ones higher than it (but not ultrafast), a couple days ago when I tried it only happened when I tried using placebo; veryslow was unaffected. So what trips it is probably some option that got moved around in the preset reshuffling.

I have no idea if this is related to the ones described above, though. This was on OSX 10.7¹, as I've not attempted it on Linux or Windows². The video was 848x480, 23.976fps, 4:2:0, as a standalone y4m file.

¹and thereby, whatever version of Clang that Xcode is using, I can't remember at the moment

²which use GCC 4.8 for both - .1 and .2, respectively

[Procrastinating]

That particular x265 build seems to have been stable enough! Videos are encoding fine now :|

It seems that with 1080p anime, on untuned placebo settings, 10-bit x265 is ~ 2-4 times more efficient than 10-bit x264. You start to see diminishing returns in terms of artifacts:size above 10bit CRF 24, though the artifacts look "nicer".

Unfortunately it also takes ~3-5 times longer to encode. My one-minute dialogue+action sample took ~30 minutes to encode with placebo 10bit on x264, vs 2 hours with x265, though higher CRF values cut that time by 15 minutes or so.

Not all tuning parameters are equal however, and x265 still has plenty of room for optimization.

I'll probably make a couple different comparisons at low and high presets as well as tuning over the course of this week, and maybe create some actual statistics.

Nevertheless, the results so far have been pretty phenomenal. I would imagine that once fansub groups get the hang of tuning this, any anime distribution service which holds back on h265, let alone 10bit could be hurting themselves pretty badly. On the flipside, if streaming services do implement h265, I think internet video could become an undeniably better source of video compared to TV (This could also make fancode groups redundant).

I think the biggest shift that this could make however is in live streaming. If faster presets enable significant gains in realtime quality, we could see a marked improvement in streaming quality across the board on sites like twitch over the next year or so.

[zerowalker]

What settings do you use, just placebo on both?
When i try HEVC , x264 wins by quite a bit even though HEVC take alot more time.

I wasn´t confused as i know that x264 has been optimized for years, but if you say it´s 2-4 time more efficient, i am starting to wonder.
Though i haven´t tried 10bit, 8bit should be pretty much the same if i compare the two.

[Atak_Snajpera]

On real very detailed footage x264 easily beats x265.

x264 8 bit rev 2345
x265 8 bit rev 0.6+89-55d99b6651f2 (UTC 11:21:27 AM) from https://x265.cc/

Sample: park_joy_1080p50.y4m (http://media.xiph.org/video/derf/)
x264 --preset veryslow --crf 32.4
https://mega.co.nz/#!9Z9C0JLZ!Y7GcCgWMehUgezvJhXb_qX6FIKRYrp2AEhxsm6s-6xQ
AVERAGE BITRATE: 6757 kbps

x265 --preset medium --crf 28 (default value) --fps 50
https://mega.co.nz/#!wE0SyRhA!RcDCBnXnEwvZCxbDymM9FxIzwCZ36Qs14vt3Rqrviyg
AVERAGE BITRATE: 6821 kbps

Use latest mpc-hc to play raw .265 files

Encoding time on Q6600@3Ghz
x264 : 2m:45s
x265 : 10m:03s

Screenshots
x264 -> http://s17.postimg.org/4r8nvo0wv/park_joy_1080p50_mkv_160.png
x265 -> http://s17.postimg.org/cy0nn8qzj/park_joy_1080p50_265_160.png



Sample: crowd_run_1080p50.y4m (http://media.xiph.org/video/derf/)
x264 --preset veryslow --crf 31.32
https://mega.co.nz/#!9EsDBbKS!DlWsrS3Net8Vt9MjZzSaJhvhJ3UhtKFLQ4HpUDriavA
AVERAGE BITRATE: 7049 kbps

x265 --preset medium --crf 28 (default value) --fps 50
https://mega.co.nz/#!RUc0QSpC!JY5mH3bALvcifyuo_uSC-hzIudNFGpPiPVi42PRN1Ro
AVERAGE BITRATE: 7047 kbps

Use latest mpc-hc to play raw .265 files

Encoding time on Q6600@3Ghz
x264 : 2m:50s
x265 : 10m:28s

Screenshots
x264 -> http://s17.postimg.org/nqcieh40v/crowd_run_1080p50_mkv_160.png
x265 -> http://s17.postimg.org/mzjs8p1nj/crowd_run_1080p50_265_160.png

[benwaggoner]

It seems that with 1080p anime, on untuned placebo settings, 10-bit x265 is ~ 2-4 times more efficient than 10-bit x264. You start to see diminishing returns in terms of artifacts:size above 10bit CRF 24, though the artifacts look "nicer".
Are you comparing without any --tune parameter in x264 as well? Even if so, that's still a dramatic delta!

Unfortunately it also takes ~3-5 times longer to encode. My one-minute dialogue+action sample took ~30 minutes to encode with placebo 10bit on x264, vs 2 hours with x265, though higher CRF values cut that time by 15 minutes or so.
There's lots of optimization still be done for 10-bit I believe. Compared to the speed of the reference encoders a year ago, only 3-5 slower is pretty tremendous. I've heard some codec engineers estimate that at equivalent levels of exhaustiveness*, H.265 would be about 3-5 times slower than H.264. It sounds like we'll likely wind up with a smaller gap than that.

* I guess you could think of this as a setting that's a certain percentage below the maximum possible placebo encode.

On the flipside, if streaming services do implement h265, I think internet video could become an undeniably better source of video compared to TV (This could also make fancode groups redundant).
I'll take my 1080p AIV encodes over against anything Comcast delivers for Anime by a HUGE margin already :)!

I think the biggest shift that this could make however is in live streaming. If faster presets enable significant gains in realtime quality, we could see a marked improvement in streaming quality across the board on sites like twitch over the next year or so.
I don't know that we can expect broad support for HEVC decode in most web clients in 2014. I can't think of any clients/players/platforms/browsers other than VLC that has even announced HEVC support yet.

Silicon is certainly coming for CE devices, though. And software decode of WPP HEVC on a multicore system will be more performant than single-slice H.264 decode.

[fumoffu]

On real very detailed footage x264 easily beats x265.



Yes, this is rather worrying. Can some bug in the code cause this? Or is it rather lack of certain x264 features not yet implemented in x265?
In my earlier post I was complaining that x265 seems to be destroying delicate details and blurs everything a bit. I'm surprised that in your test even "rough" and detailed part of the image like trees look ugly and smeared :/

[Atak_Snajpera]

Files created by x265 remind me WMV3/9 ;) Ultra slow encoding and everything smeared.

[x265_Project]

The Dev team just pushed a bug fix to the development tip. This fixes the crash that some of you were seeing.

Tom

[x265.cc]

The Dev team just pushed a bug fix to the development tip.

And it also got the "stable" tag.

[Sagittaire]

Files created by x265 remind me WMV3/9 ;) Ultra slow encoding and everything smeared.

No it's simply that you compare x264 and x265 for extreme sample example. New H265 functionality are certainely simply useless for these really complexe sample. Moreover x264 is really highly optimized for these really complexe content. Certainely that psy, AQ, mbtree or trellis will really help for x265.

[foxyshadis]

x264 had the same blurring problem before AQ, as well; that was the entire impetus to create it. It's just one of those things we have to wait for a final implementation of.

[MythCreator]

There is a strange situation

AVS:
LWLibavVideoSource("00002.m2ts")

avs2yuv "test.avs" -o "test.yuv"

x265 --input-res 1280x720 --input-csp i420 --fps 23.976 --no-lft --crf 18 --input "test.yuv" -o "test.265"

It's crashed on 1st frame over and over again (I tried 32bit & 64bit, 8bpp & 16bpp), 0.6+3 & 0.6+111 and even a version of 0.5 but still get crash


In the other hand, When I use MeGUI to input an 1080p source, it also get an error, but works well when I simply resize it to lower resolution.

My system is Windows 8.1 Pro 64bit

[Selur]

@MythCreator: If you feed raw yuv input via pipe to x265 you also need to specify the number of frames to encode. (in example "--frames 429")

[MythCreator]

@Selur

C:\ffmpeg_64\ffmpeg.exe -i "E:\Downloads\STREAM\00002.m2ts" -pix_fmt yuv420p -an -f rawvideo - | E:\avs2yuv\x265_64_8bpp.exe --frames 35654 --input-csp i420 --input-res 1920x1080 --fps 23.976 --no-lft --crf 18 - -o "E:\Downloads\STREAM\test.265"

Still crash on 0.6+112 -_-

[Selur]

Uploaded versions I build using media-autobuild_suite (https://github.com/jb-alvarado/media-autobuild_suite) to my google share (https://drive.google.com/folderview?id=0B_WxUS1XGCPASUZibG5XZkRfeTg&usp=sharing), try if it works if you use these.

[x265.cc]

try if it works if you use these.

Have you added anything to the source / your binary?

If not, it will still not work.


C:\ffmpeg_64\ffmpeg.exe -i "E:\Downloads\STREAM\00002.m2ts" -pix_fmt yuv420p -an -f rawvideo - | E:\avs2yuv\x265_64_8bpp.exe --frames 35654 --input-csp i420 --input-res 1920x1080 --fps 23.976 --no-lft --crf 18 - -o "E:\Downloads\STREAM\test.265"

Try:

ffmpeg.exe -i {INPUT} -f yuv4mpegpipe -pix_fmt yuv420p - | x265.exe --y4m -o {OUTPUT} -

I recommend the latest "FFmpeg x64 static" build from zeranoe.com (http://ffmpeg.zeranoe.com/builds/) and the latest "x265 x64" build from x265.cc (https://x265.cc/builds/MSYS-x86_64/8bpp/x265_latest.zip)

[MythCreator]

@x265.cc

I tried it, and still crash... I think I'm gonna be crash (((

[Atak_Snajpera]

No it's simply that you compare x264 and x265 for extreme sample example. New H265 functionality are certainely simply useless for these really complexe sample. Moreover x264 is really highly optimized for these really complexe content. Certainely that psy, AQ, mbtree or trellis will really help for x265.

Is this also an extreme sample?
Original file -> http://www.diktafon.atw.hu/112.MTS

x265 (rev 110) --crf 28 --preset medium --aq-mode 1 --aq-strength 1 --fps 25
https://mega.co.nz/#!pBsEzAxQ!RMsqjjAyyyJQ_TH74kFNgEw2Tj953IWYVu__Xo9LDMg
AVERAGE BITRATE: 1948 kbps

x264 --crf 34.25 --preset veryslow
https://mega.co.nz/#!RN9xlaZB!aiRSSGtZIxFERVgmrtbc9RnJWn8Y1879BfCkTeBFc7s
AVERAGE BITRATE: 1972 kbps

Screenshots
x265
http://i.cubeupload.com/bb6tcp.png
http://i.cubeupload.com/8behZ6.png

x264
http://i.cubeupload.com/dfh31Y.png
http://i.cubeupload.com/I4XZl2.png

Sad thing is that x265 --preset medium is about 4x slower on my Q6600@3Ghz than x264 --preset veryslow :(

[Sagittaire]

Is this also an extreme sample?
Original file -> http://www.diktafon.atw.hu/112.MTS


Yes, all your sample are particular and extreme example (high detail level, high motion level). Try with real life example like complete movie or trailer (if you have no time) ... and see the result: you have in general case half bitrate for H265 for the same quality than H264.

[Atak_Snajpera]

But this footage was taken from camcorder for god sake. Are you saying that x265 is designed only for static anime?

[vood007]

x265 is in early stage of development, whats so hard to understand about this?

[Atak_Snajpera]

x265 is in early stage of development, whats so hard to understand about this?

That's true and unfortunately useless for now. I doubt that in 2014 x265 will beat x264 in those "extreme samples" by 50%.

[x265_Project]

We had a bug which only appeared on certain machines (causing x265 to crash immediately). x265 builds from the development tip were crashing on my system, but not crashing on our developers' systems. Debug builds weren't crashing. Fortunately, I was able to build a "release with debug info" build, and we were able to figure out where and why this was happening (in CU logging code). The development tip (default) build from this morning isn't crashing. So, if you were experiencing crashes in development builds, please try again with a new build (0.6 + 150).

I would encourage all technically savvy x265 adopters to help us find and isolate bugs in the same way. If x265 crashes on your system, create a Debug or Release with Debug Info build, run it under the same conditions that crashed before and when x265 crashes, copy and submit the call stack to the devel mailing list with your system configuration, x265 command line and input test sequence you are using.

Tom

[benwaggoner]

That's true and unfortunately useless for now. I doubt that in 2014 x265 will beat x264 in those "extreme samples" by 50%.
It's not supposed to be useful yet :). There aren't ANY mainstream players that can play HEVC so far.

Useful in the second half of 2014 would be tremendous, honestly.

Has anyone heard about any browsers, Flash, etcetera (anything other than VLC) that has announced HEVC playback support?

[filler56789]

Has anyone heard about any browsers, Flash, etcetera (anything other than VLC) that has announced HEVC playback support?

MPC-BE
LAV Filters
Strongene Lentoid HEVC Decoder
Osmo Player from GPAC

[fumoffu]

you forgot
MPC-HC
...and DivX player