x265 HEVC Encoder

[kolak]

I am running some tests on UHD 60p content as our client requested final delivery as DPX and H265 transport stream. This is high-end footage shot on Sony F65. I was surprised that they are asking for h265, but they want the best possible quality at 50mbit.
I am using ffmpeg as it can mux h265 into ts and h265 definitely gives better than x264 overall quality. I think blurring problem is not that obvious anymore. I just have decoding speed issues :p

Is latest ffmpeg on pair with x265 libraries?

I have also tried 4096x2160, but this seams to producing unplayable streams (at least by ffplay and LAV decoder). Picture breaks up.

Another question, does 50mbit for UHD 60p footage fall in medium or low bitrate area?

[x265_Project]

I am running some tests on UHD 60p content as our client requested final delivery as DPX and H265 transport stream. This is high-end footage shot on Sony F65. I was surprised that they are asking for h265, but they want the best possible quality at 50mbit.
I am using ffmpeg as it can mux h265 into ts and h265 definitely gives better than x264 overall quality. I think blurring problem is not that obvious anymore. I just have decoding speed issues :p

Is latest ffmpeg on pair with x265 libraries?

I have also tried 4096x2160, but this seams to producing unplayable streams (at least by ffplay and LAV decoder). Picture breaks up.

Another question, does 50mbit for UHD 60p footage fall in medium or low bitrate area?
We have a high-speed decoder called UHDcode. Our decoder is not open sourced. I can provide this for your evaluation under NDA.

As I understand it, FFMPEG links with x265 statically. So you'll get whatever version of x265 was available when FFMPEG was built. You can pipeline FFMPEG into your own build of x265 to get the latest and greatest x265.

If you provide me with a sample 4096x2160 video file we can debug the issue you're seeing. We had no problems with traffic_4096x2048_30p.yuv.

50 Mbit is a fairly generous (high) bit rate, even for UHD 60p. Certainly some people use higher bit rates, but 50 Mbit is not what most people would call a low or medium bit rate.

[kolak]

Yes, this is what I thought, but we want to have high transparency to the master, so even if it looks quite good at 50mbit, it's lacking most of the original grain when compared to DPX master. Overall, I think it looks good and definitely better than x264.

Any special settings to preserve grain? Higher aq-strength ?
I have to use ffmpeg as I need to mux to ts stream and if I feed ffmpeg with raw x265 file it seams to not liking it.
It uses one of the latest x265 version, but not exactly the latest.

I don't think its related to actual source file, it maybe just 4096x2160@60p problem. I will try on some bars file with these parameters.

[x265_Project]

Any special settings to preserve grain? Higher aq-strength ?

Higher AQ strength might help a bit, but our current AQ implementation varies QP at the usually 64x64) CTU level. We're working to implement finer granularity to AQ, to the PB level.

I have to use ffmpeg as I need to mux to ts stream and if I feed ffmpeg with raw x265 file it seams to not liking it.
It uses one of the latest x265 version, but not exactly the latest. I understand.

I don't think its related to actual source file, it maybe just 4096x2160@60p problem. I will try on some bars file with these parameters.

[smegolas]

I've missed the progression of this thread, but I have a question.

Is x265 up to par with x264? I remember not so long ago x265 would destroy the fine detail...
My real question is, is it good enough for professional studios to use it as the next blu-ray standard?

Thanks.


There is still a blurring effect.

At very low bitrates - the type of bitrates that most people would consider too low for watchable quality - x265 easily outperforms x264. The artifacts have a smoother, rounder quality.

However if you want to do a high quality encode it's still not capable of outperforming x264 yet. It's just too blurry.

So it is great in bitrate starved conditions, but no good if you are trying to achieve high quality, fine detail with grain retention etc.

[Audionut]

And I recall the same things being said about x264 vs xvid/mpeg2, when it was in it's initial development cycle.

[smegolas]

And I recall the same things being said about x264 vs xvid/mpeg2, when it was in it's initial development cycle.

That's why I said 'yet'. The question he asked was about the current status. Not about the future.

[Daemon404]

As I understand it, FFMPEG links with x265 statically. So you'll get whatever version of x265 was available when FFMPEG was built. You can pipeline FFMPEG into your own build of x265 to get the latest and greatest x265.

Author here. It only does so when you tell it to.

You can link dynamically, and as long as the x265 ABI is stable/matches the build time ABI, it will work.

There is still a blurring effect.

At very low bitrates - the type of bitrates that most people would consider too low for watchable quality - x265 easily outperforms x264. The artifacts have a smoother, rounder quality.

However if you want to do a high quality encode it's still not capable of outperforming x264 yet. It's just too blurry.

So it is great in bitrate starved conditions, but no good if you are trying to achieve high quality, fine detail with grain retention etc.

This anecdote matches every test I've done thus far, since I only care about the mid-to-high end.

[LigH]

Is there anyone with a big fat modern intel multi-core CPU who can provide some coarse "benchmark" results for 720p and 1080p material at different (ultrafast .. fast) speed presets?

I have only some AMD Phenom-II available: no AVX, no SSE4+, x265 honors at most "SSE2Fast" (SSE3 seems to be not very relevant for HEVC encoding algorithms, or its implementation is too slow on K10).

Samples from LDV tests on a Phenom II X6 1045T using v0.8+195 (GCC 4.8.2, Win64):

720p

ultrafast: 17.84 fps
veryfast: 15.49 fps
faster: 12.35 fps
fast: 4.61 fps


1080p

ultrafast: 5.08 fps
veryfast: 4.00 fps
faster: 3.19 fps
fast: 1.60 fps

[anonymlol]

Is there anyone with a big fat modern intel multi-core CPU who can provide some coarse "benchmark" results for 720p and 1080p material at different (ultrafast .. fast) speed presets?

I have only some AMD Phenom-II available: no AVX, no SSE4+, x265 honors at most "SSE2Fast" (SSE3 seems to be not very relevant for HEVC encoding algorithms, or its implementation is too slow on K10).

Samples from LDV tests on a Phenom II X6 1045T using v0.8+195 (GCC 4.8.2, Win64):

720p

ultrafast: 17.84 fps
veryfast: 15.49 fps
faster: 12.35 fps
fast: 4.61 fps


1080p

ultrafast: 5.08 fps
veryfast: 4.00 fps
faster: 3.19 fps
fast: 1.60 fps


I have an i7 2700K @4.4GHz.

HEVC encoder version 0.8+185-27e0620327e5
build info [Windows][MSVC 1800][64 bit] 16bpp
using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX

Settings are --recon-depth 10 and the presets below.

720p

ultrafast: 38.39 fps
superfast: 33.24 fps
veryfast: 23.34 fps
faster: 19.04 fps
fast: 13.48 fps
medium: 8.84 fps
slow: 5.20 fps
slower: 2.72 fps
veryslow: 1.70 fps

1080p

ultrafast: 18.29 fps
superfast: 15.85 fps
veryfast: 10.65 fps
faster: 9.36 fps
fast: 6.24 fps
medium: 4.09 fps
slow: 2.39 fps
slower: 1.36 fps
veryslow: 0.86 fps

[LigH]

Nice, thank you; however, I expect 10 bit encoding to be much slower than 8 bit encoding.

I was curious if realtime 1080p encoding with x265 (despite not yet being completely optimized) is already close to "possible", and regarding your results, I would agree that it won't take forever to get there.
__

P.S.:

There is a preset "superfast"? Appears to be undocumented in the help output and the explanations in the Evaluator's Guide on page 3, but appears in the table of quality presets on page 9.

[mandarinka]

For the results to be comparable, I think the same source is needed, and also the same crf. The speed probably scales with bitrate, at least with the slow settings?

[LigH]

I was not yet interested in comparable results, only in a magnitude. And regarding some results reported in the VideoHelp forum, realtime encoding of 1080p is already possible with fastest presets and fast desktop PC CPUs. The result will just not be as efficient as HEVC is meant to be...

So thank you for this little experiment. But of course, it has little relevance for practical use.

[Audionut]

I was curious if realtime 1080p encoding with x265 (despite not yet being completely optimized) is already close to "possible", and regarding your results, I would agree that it won't take forever to get there.

Semi related.

http://forum.doom9.org/showthread.php?t=141352&highlight=speed

[benwaggoner]

I was curious if realtime 1080p encoding with x265 (despite not yet being completely optimized) is already close to "possible", and regarding your results, I would agree that it won't take forever to get there.
Certainly for some scenarios and quality levels with a dual Ivy Bridge or something. Of course, realtime encoding also requires a fair amount of buffering if encode time per frame varies a bunch. Reliable live encoding is a tricky thing, and until the x265 devs say they've tested and tuned for the scenario, I wouldn't do more than experiment with it for the time being.

There are already live HD HEVC commercial encoders, so it is certainly possible.

[kolak]

Yes, this is what I thought, but we want to have high transparency to the master, so even if it looks quite good at 50mbit, it's lacking most of the original grain when compared to DPX master. Overall, I think it looks good and definitely better than x264.

Any special settings to preserve grain? Higher aq-strength ?
I have to use ffmpeg as I need to mux to ts stream and if I feed ffmpeg with raw x265 file it seams to not liking it.
It uses one of the latest x265 version, but not exactly the latest.

I don't think its related to actual source file, it maybe just 4096x2160@60p problem. I will try on some bars file with these parameters.

I've tried latest ffmpeg and all decoding problems seams to be gone. Looks like it uses more recent x265 libraries and has fixed some problems from previous version.
I do have a bit of blurring issues, even when using 50Mbit for UHD. It almost looks like some bug in whole engine (some areas get over quantized). Any way of stopping it?

[x265_Project]

I've tried latest ffmpeg and all decoding problems seams to be gone. Looks like it uses more recent x265 libraries and has fixed some problems from previous version.
I do have a bit of blurring issues, even when using 50Mbit for UHD. It almost looks like some bug in whole engine (some areas get over quantized). Any way of stopping it?
Our engineering team is reviewing all of the many coding algorithms that affect visual quality right now, as part of a final overall optimization and tune-up in the current development phase. We're aware of this concern, and we're focused on it.

Tom

[kolak]

x264 has very similar problem. Even with high bitrates it would sometimes destroy all details on areas with high contrast. It's not as visible and common like with x265, but the same problem is also there.
I hope it can be fixed.

[LigH]

You can try to reduce in-loop deblocking (like in film or grain tunings) to keep more of high frequency parts.

But an important part of the efficiency of current video encoders is based on reducing the accuracy of frequencies which are notorious for representing noise and less important for recognizing whole objects. A little more high frequency accuracy means a lot more required bitrate.

[mandarinka]

x264 has very similar problem. Even with high bitrates it would sometimes destroy all details on areas with high contrast. It's not as visible and common like with x265, but the same problem is also there.
I hope it can be fixed.

Note that such "killed" frames with x264 could very likely be the result of capped bitrate/VBV, which oyu as a professional user probably have enabled.

If a majorly complex scene needs bits and the encoder doesn't have them available, the result is washed out detail, decimated grain, or artifacts.

That being said, x265 does have issues with dropping texture detail in some areas even at high bitrates (I tried 18 megabits with 1440x1080p24 for example). This behaviour might improve once it gets PsyRDO.

[kolak]

You are correct- this was under max bitrate/vbv restrictions.
Saying that I would prefer if encoder would reduce bits over whole frame, than create some small flat spots (but this is part of the whole PsyRDO I assume).
Whole AQ needs just a more work which as it has been said is already in progress.

I also have I frame pumping issue, any setting to stop it? I can't see anything which would give P, B frames more bits.

[x265_Project]

You are correct- this was under max bitrate/vbv restrictions.
Saying that I would prefer if encoder would reduce bits over whole frame, than create some small flat spots (but this is part of the whole PsyRDO I assume).
Whole AQ needs just a more work which as it has been said is already in progress.

I also have I frame pumping issue, any setting to stop it? I can't see anything which would give P, B frames more bits.

Kolak, et al,
We're all over this... the whole x265 team. We've been looking at everything that affects visual quality, and we're working on a number of improvements. Fine-grained AQ is just one of many things that will help.

I also want to let everyone know that our documentation (the document formerly known as the "Evaluator's Guide" is online in the form of RestructuredText here ... http://x265.readthedocs.org. A new rule for x265 developers - changes to the code that affect the command-line syntax, debug or log file output (or anything we've documented) must include changes to the documentation at the same time. Anyone can suggest improvements to the documentation simply by submitting a patch to the x265-devel mailing list. Patches will be reviewed just as code patches are. If the x265 developer community deems the change to be an improvement, it will be committed.

Thanks
Tom

[filler56789]

For the notes...

now libx265 breaks FFmpeg's compatibility with Windows XP :mad: :mad: :mad: :mad: :mad:

http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=1889

May I ask why for Command Line Tool something higher than Win XP is required?

Also,

On Tue, Mar 25, 2014 at 4:44 PM, Jason Garrett-Glaser <jason@x264.com> wrote:

> On Tue, Mar 25, 2014 at 10:32 AM, Steve Borho <steve@borho.org> wrote:

>> On Tue, Mar 25, 2014 at 11:25 AM, Roger Pack <rogerdpack2@gmail.com>
wrote:

>>> Hello. I noticed in a recent discussion that seemingly windows xp
>>> support had been "dropped" to clean up code:
>>>
>>>
http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?goto=newpost

>>
>> I would describe the situation more as we needed to use a
>> synchronization primitive (condition variable) in order to prevent
>> deadlocks and that primitive is not supported on XP. This wasn't a
>> code cleanup, it was fixing a serious race hazard.

>
> x264 supports condition variables on XP just fine.

I see that now in win32thread.c around line 117, thanks for the pointer.

So it is definitely possible to mimic a condition var on XP. Any
volunteers to adapt this to our threading.h?

--
Steve Borho

[nevcairiel]

If you care about XP (most developers don't), you should volunteer to provide the XP compatibility wrapper, like Steve asked someone to do.

[filler56789]

^ Wrong answer, Hendrik.

[LigH]

The usual story about teamwork (someone, anyone, noone and everyone)?

Do or do not. But don't blame.

[foxyshadis]

^ Wrong answer, Hendrik.

It was a hasty decision to fix a bug, it's a known issue, there are workarounds, and a fix is already somewhere in the works. How much more exposure is necessary?

(The fact that few developers still care about XP is true, though, especially if they aren't paying customers.)

[fumoffu]

I was testing latest build from http://chromashift.org/x265_builds/
btw. can someone explain what is the difference between builds tagged icl14 and msvc2012 is it just different compiler? I'm asking because for me the first one is literary 2 times faster than the second which I find surprising... (I'm testing on i5-3570)

[LigH]

Yes, it is just a different compiler (Microsoft Visual C++ vs. Intel C Compiler). The ICL may optimize C/C++ code (much?) better for intel CPUs, if it works correctly. But the more manually tuned Assembler code gets implemented, the less the used C compiler will matter.

[mandarinka]

I had the same result on AMD chips (K10), only the difference was more like three times faster encoding with ICL.

IIRC though, with a different version of MSVC, the results were actually the same for both. We talked about it in the IRC channel, but IIRC no clear cause/solution was arrived at.

[anonymlol]

That's weird, my MSVC builds are way faster than the ICC (and MSVC) builds from that site.

If anyone wants to compare: x265 highbitdepth 64bit 0.8+243 msvc (https://db.tt/tq3ZTDGf)

Mine: 13.69s (1.31 fps)
MSVC from there: 27.18s (0.70 fps)
ICC from there: 22.30s (0.81 fps)

[nevcairiel]

Sounds like some of the builds are flat out broken - maybe issues with multithreading?

[vood007]

Could it be they are debug builds? i remember i could not use a build because it tried to load msvcp110d.dll (d=debug version)?

[cyberbeing]

That's weird, my MSVC builds are way faster than the ICC (and MSVC) builds from that site.
I can reproduce this. The builds on chromashift.org are extremely slow for some reason. Quick test with default settings on a 720p y4m with i5-3570K.

VC12 highbitdepth (my build): 9.18 fps
VC12 highbitdepth (anonymlol's build): 9.18 fps

VC12 highbitdepth (chromashift): 4.33 fps
ICL14 highbitdepth (chromashift): 7.34 fps

[filler56789]

It was a hasty decision to fix a bug, it's a known issue, there are workarounds, and a fix is already somewhere in the works.

How much more exposure is necessary?

I think the pertinent questions are these,

¿why does the X265 Wiki (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2274443i#post2274443) (<= click) still deny or ignore the existence of MinGW?

¿what's the point of their prior commitment to Visual C++ and CMake?

[qyot27]

I think the pertinent questions are these,

¿why does the X265 Wiki (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2274443i#post2274443) (<= click) still deny or ignore the existence of MinGW?

¿what's the point of their prior commitment to Visual C++ and CMake?
That's a forum thread, not a Wiki.

This is the Wiki, and it does, in fact, refer to MinGW:
https://bitbucket.org/multicoreware/x265/wiki/CrossCompile

Talking about MinGW under the cross-compile section is the correct place to do it, since it's far more notable as a cross-environment running under Linux or Cygwin than it is running under MSys (although the page there does mention MSys as an aside).

Visual Studio is the native compiler for Windows, that's why they focus on it. CMake has nothing to do with it, and isn't a factor in this at all.

[filler56789]

That's a forum thread, not a Wiki.

Yes, and that forum post presents a pertinent criticism to the X265 Wiki.

CMake has nothing to do with it, and isn't a factor in this at all.

Perhaps.

Visual Studio is the native compiler for Windows, that's why they focus on it.

That sounds a lot like a rationalization :)

http://en.wikipedia.org/wiki/Rationalization_(making_excuses)

[nevcairiel]

They focus on Visual Studio because thats the primary development platform of a lot of their developers. :p

[Daemon404]

I can reproduce this. The builds on chromashift.org are extremely slow for some reason. Quick test with default settings on a 720p y4m with i5-3570K.

VC12 highbitdepth (my build): 9.18 fps
VC12 highbitdepth (anonymlol's build): 9.18 fps

VC12 highbitdepth (chromashift): 4.33 fps
ICL14 highbitdepth (chromashift): 7.34 fps

Think I figured out why -- it was my fault. When I was telling it to use /MT instead of /MD, cmake was completely nuking all the CFLAGS/CXXFLAGS (read: /O2 and pals).

The current build at the usual place is fixed now, as are all future builds.

[LigH]

Also there is an interesting side note in the Wikipedia that the ICL only creates optimized code if it is running on a "GenuineIntel" CPU, but badly unoptimized code when running on any other CPUID. Which made me stop thinking further about it before even trying, knowing that I have only AMD CPUs available.

[mandarinka]

You can get around that by overwriting ICL's CPU detection. x264 has something to do that, not sure about x265.

[cyberbeing]

Think I figured out why -- it was my fault. When I was telling it to use /MT instead of /MD, cmake was completely nuking all the CFLAGS/CXXFLAGS (read: /O2 and pals).

The current build at the usual place is fixed now, as are all future builds.

I can confirm the speed of your MSVC builds is now normal on my i5-3570K. No change with the ICL14 builds compared to my previous results, so I guess MSVC just optimizes x265 64bit better for Ivy Bridge at this time.

[LigH]

From the developer mailing list:

[PATCH] restore WINXP_SUPPORT build option, workaround for CONDITION_VARIABLE on XP

Are you happy now, as soon as it is commited?

[foxyshadis]

I think the pertinent questions are these,

¿why does the X265 Wiki (http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2274443i#post2274443) (<= click) still deny or ignore the existence of MinGW?

¿what's the point of their prior commitment to Visual C++ and CMake?

HM was built on Visual Studio, and x265 started as an extension of HM. You don't like it, go harass the guys who ran the JCT-VC and created H.265; I'd rather be glad that MCW took the time to make it cross-compatible. Now take this garbage out of here, this thread isn't the place for harassing developers because you don't understand things.

[benwaggoner]

Anyone know what the proper max values of --vbv-maxrate are by level? The --bitrate values are well documented.

[sneaker_ger]

How can "--bitrate" be documented?

Vbv values can be found in the spec, table A.1 (page 203/217) and A.2 (page 205/219).
http://www.itu.int/rec/T-REC-H.265-201304-I

[benwaggoner]

How can "--bitrate" be documented?

Vbv values can be found in the spec, table A.1 (page 203/217) and A.2 (page 205/219).
http://www.itu.int/rec/T-REC-H.265-201304-I
Sorry, I meant for --vbv-bufsize. --bitrate and --vbv-maxrate have identical restrictions.

[LigH]

For AVC in Blu-ray, there is this table in Encoding Video for Blu-Ray using H264/AVC (http://forum.doom9.org/showthread.php?t=154533); I guess there has to be a similar specification for any specific hardware player that will use HEVC.

[D3C0D3R]

Are you happy now, as soon as it is commited?

A lot :)

Meanwhile some strange perfomance regression was found in MinGW-compiles.

[LigH]

Strange, indeed. Now that the reprogrammed Condition Variables (based on x264 code) are default because they are reportedly faster than the native kernel functions ... can you provide a few more details?