x265 HEVC Encoder

[divxmaster]

If I use the x265 Nic Mod V2, the fine grained adaptive quantization works well and the picture is near from what we can see in x264, but when I use --qg -size 32, I don't see any differences, below two pictures, the first with x265 v1.6 298 --qg -size 32 and the second with x265 Nic Mod V2.


http://t.imgbox.com/EWT3D4io.jpg (http://imgbox.com/EWT3D4io)

x265 Test.y4m --preset slow --qg -size 32 Test.hevc --bitrate 2000



http://t.imgbox.com/mq9hzarJ.jpg (http://imgbox.com/mq9hzarJ)

x265.exe Test.y4m -o Test.hevc --preset nic --bitrate 2000


As Ligh mentioned, you wont see visual difference in every case. Are the output file sizes different? Every test I have done, qgsize32 is smaller. Also, are you using '--qg -size 32'?? I should be '--qg-size 32' No space before -size, although it should report an error with the wrong parameter.
I see you have preset slow in one screenshot and preset nic in the other? Are you using the same version of x265 for both tests? I think the best way to test it is to use the exact same parameters, but vary only --qg-size 32/64.

Cheers,
Divxmaster

[qyot27]

I don't have much experience with writing/modifying CMake systems either (I've been meaning to), but I did find this:
http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries#Piggybacking_on_pkg-config

And the example directly below that seems to make use of it via pkg_check_modules. Whether it needs special handling to deal with a pkg-config --static situation I don't know.



EDIT: And a cursory Google search brings up FindFFmpeg.cmake modules others have already written, like this one which seems to be relatively complete (it's missing AVFilter and SWResample/AVResample):
http://www.morethantechnical.com/2013/08/23/finding-ffmpeg-with-cmake/

[MeteorRain]

I don't have much experience with writing/modifying CMake systems either (I've been meaning to), but I did find this:
http://www.cmake.org/Wiki/CMake:How_To_Find_Libraries#Piggybacking_on_pkg-config


https://gist.github.com/msg7086/b949e7af71b238527b73

But I'm still not quite sure if I'm doing this correctly. On MSYS2 I have to specify -DCMAKE_PREFIX_PATH="//mingw64" to force a relative path to find the .pc files.

Please share your ideas :thanks:

[MeteorRain]

Hi Yuuki,

It seems that your builds do not support avisynth using lavf input patch, am I right?...how did you compile libav libs ?

This is what I'm using for release.

./configure \
--disable-parser=opus \
--disable-decoder=opus,libopus \
--disable-encoders --disable-muxers \
--disable-devices --disable-avdevice \
--disable-hwaccels \
--disable-swresample --disable-swscale \
--disable-ffplay --disable-ffserver \
--disable-network --disable-bzlib --disable-lzma --disable-iconv --disable-zlib --disable-xlib \
--enable-gpl \
--arch=x86_64 --target-os=mingw32 --prefix=/mingw64


To me, 64bit avisynth lacks quite a lot filters, and thus for now I'd rather stay with 32bit avs. VapourSynth might be a good replacement, let's see.

[ndkamal]

Thanks for jour answer, I made an another test with x265 v16 without --qg-size 32, and the result is the same. The size of the files are not the same, the video with --qg-size is smaller.

[Kurtnoise]

This is what I'm using for release.

Thanks to you and qyot27. Finally, that's succeeded :

lavf [info]:
Format : avisynth
Codec : rawvideo ( raw video )
PixFmt : yuv420p
Framerate : 24/1
Timebase : 1/24
Duration : 0:00:41
lavf [info]: 1598x1826 fps 24000/1000 i420p8 frames 0 - 1000 of 1001
raw [info]: output file: C:\temp\out.avs.h265
x265 [info]: HEVC encoder version 1.6+321-13290abce29209be
x265 [info]: build info [Windows][GCC 4.9.2][64 bit] 8bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: frame threads / pool features : 2 / wpp(29 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 15 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 15 / 4 / 0
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 1
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 64 / 0
x265 [info]: Rate Control : CRF-28.0
x265 [info]: tools: rd=2 psy-rd=0.30 early-skip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock sao

x265 [info]: frame I: 5, Avg QP:14.84 kb/s: 23377.82
x265 [info]: frame P: 196, Avg QP:20.30 kb/s: 50.53
x265 [info]: frame B: 800, Avg QP:22.19 kb/s: 42.16
x265 [info]: global : 1001, Avg QP:21.78 kb/s: 160.36
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 0.5% 0.0% 0.0% 0.0% 99.5%

encoded 1001 frames in 142.79s (7.01 fps), 160.36 kb/s

[uneedme]

x265 1.6+298-4a7176bab742 (https://www.mediafire.com/download/z3r9ly5cz5ax5a6/x265_1.6+298-4a7176bab742.7z)

New published parameter:

--qpstep <integer> The maximum single adjustment in QP allowed to rate control. Default 4

The maximum single adjustment in QP allowed to rate control. Default 4............

:confused:

What function is this parameter adjusted?

[LigH]

I believe it is a kind of dampening for the rate control, so that the difference of quantization factors between adjacent or dependent frames (B frames in relation to their referred I and P frames) is not too big, to avoid an annoyingly noticeable – because repetitive – "flickering" of compression artifacts in only a few frames, a.k.a. "quantization pumping". It will probably also limit expectable heavy fluctuations caused by very short scenes with a lot of detail (imagine dramatic flashbacks of a victim remembering an incident for parts of a second), they would need a brief raise of the bitrate, causing the following scene to drop the bitrate to avoid exceeding bitrate limits...

Just guessing. More details from a developer, possibly...

[foxyshadis]

I believe it is a kind of dampening for the rate control, so that the difference of quantization factors between adjacent or dependent frames (B frames in relation to their referred I and P frames) is not too big, to avoid an annoyingly noticeable – because repetitive – "flickering" of compression artifacts in only a few frames, a.k.a. "quantization pumping". It will probably also limit expectable heavy fluctuations caused by very short scenes with a lot of detail (imagine dramatic flashbacks of a victim remembering an incident for parts of a second), they would need a brief raise of the bitrate, causing the following scene to drop the bitrate to avoid exceeding bitrate limits...

Just guessing. More details from a developer, possibly...

Pretty much that, though that it also applies to the per-row QP changes needed to keep VBV happy. I suppose you could break VBV with it, if you really wanted to. It doesn't apply to AQ, though. Like most ratecontrol options, you should envision a giant flaming HERE THERE BE DRAGONS sign before you mess with it.

When you talk about B frame ratios, that would be the allowed difference after the base ratio is already calculated. (Normally 1.3:1 to P frames.)

Oddly enough, it's been in there for a while, it just wasn't listed in the help screen.

[mandarinka]

Pretty much that, though that it also applies to the per-row QP changes needed to keep VBV happy. I suppose you could break VBV with it, if you really wanted to. It doesn't apply to AQ, though. Like most ratecontrol options, you should envision a giant flaming HERE THERE BE DRAGONS sign before you mess with it.

When you talk about B frame ratios, that would be the allowed difference after the base ratio is already calculated. (Normally 1.3:1 to P frames.)

Oddly enough, it's been in there for a while, it just wasn't listed in the help screen.

It is taken over from x264 AFAIK, it has that parameter too (same default I think).

[Minamiya]

I have a funny problem with libx265 and ffmpeg.

if I give this line, directly:

wine avs2yuv_mod ./test.avs -o - | ffmpeg -i - -c:v libx265 -preset medium -pix_fmt yuv422p10le -crf 19 -x265-params "deblock=0:-1:rdoq-level=1:psy-rd=0.40:psy-rdoq=10.0:aq-mode=2:aq-strength=1.2:bframes=6:ref=6:rd=5:tu-intra-depth=4:tu-inter-
depth=4:me=3:max-merge=5:subme=6:merange=25:keyint=240:rc-lookahead=80:b-adapt=2:rect:amp:no-sao:no-open-gop:no-cutree:no-tskip:no-tskip-fast:weightp:weightb:no-strong-intra-smoothing" -y anime_01_x265.hevc

If he takes over to me no parametres from deblock etc.

x265 [info]: HEVC encoder version 1.6+360-bca33880585ax265 [info]: build info [Linux][GCC 4.9.2][64 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 4:2:2 10 profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(12 rows)
x265 [info]: Internal bit depth : 10
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut : 23 / 250 / 40
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 3
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 64 / 1
x265 [info]: Rate Control : CRF-19.0
x265 [info]: tools: rd=3 psy-rd=0.30 signhide tmvp strong-intra-smoothing
x265 [info]: tools: deblock sao

If I take, however, the Red marked lines out, he takes over the parametres suddenly, then grumbles though for the orange line, but then, otherwise, he takes over everything. With what does this lie that he does not take from me the lines?

x265 [info]: HEVC encoder version 1.6+298-4a7176bab742x265 [info]: build info [Linux][GCC 4.9.2][64 bit] 16bpp
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 4:2:2 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: frame threads / pool features : 3 / wpp(12 rows)
x265 [info]: Internal bit depth : 10
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 25 / 6 / 5
x265 [info]: Keyframe min / max / scenecut : 23 / 240 / 40
x265 [info]: Lookahead / bframes / badapt : 80 / 6 / 2
x265 [info]: b-pyramid / weightp / weightb / refs: 1 / 1 / 0 / 6
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.2 / 64 / 1
x265 [info]: Rate Control : CRF-19.0
x265 [info]: tools: rd=5 psy-rd=0.40 signhide tmvp strong-intra-smoothing
x265 [info]: tools: deblock sao

FFmpeg I have built thus:

./configure --enable-gpl --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libx264 --enable-nonfree
--enable-postproc --enable-version3 --enable-x11grab --enable-librtmp --enable-libxvid --enable-libass --enable-libx265

and x265

cmake -G "Unix Makefiles" -D HIGH_BIT_DEPTH:BOOL=ON ../../source
make -j4
./make-Makefiles.bash
make
checkinstall --pkgname=x265 --pkgversion="3:$(./version.sh | \
awk -F'[" ]' '/POINT/{print $4"+git"$5}')" --backup=no --deldoc=yes --fstrans=no --default

[easyfab]

And with rect=1:amp=1:no-sao=1.....

[foxyshadis]

You broke the argument list with the unparsable :-1:. Use :deblock=0,-1:rdoq-... for ffmpeg.

[benwaggoner]

Quick verification. For chroma offsets in x265, cbqpoffs and crqpoffs work like chroma-qp-offset does in x264, So negative values reduce QP for chroma and thus increasing chroma quality relative to luma, right? And positive values would shift bits and quality away from chroma towards luma?

--cbqpoffs <integer>
Offset of Cb chroma QP from the luma QP selected by rate control. This is a general way to spend more or less bits on the chroma channel. Default 0

Range of values: -12 to 12
--crqpoffs <integer>
Offset of Cr chroma QP from the luma QP selected by rate control. This is a general way to spend more or less bits on the chroma channel. Default 0

Range of values: -12 to 12

[Ely]

Hi everyone,

I'm having some trouble encoding animation movies as I encounter "glitches" around any character's movement.

Here's an example with an episode of family guy. Between the source and the x265 files, please take a look at the blonde's woman shoulders in the background :

source - frame 1 (http://i.imgur.com/fOOOvr9.png)
source - frame 2 (http://i.imgur.com/qu5XL8c.png)
source - frame 3 (http://i.imgur.com/FWNXEcN.png)

x265 - frame 1 (http://i.imgur.com/my75rU3.png)
x265 - frame 2 (http://i.imgur.com/1nPhkvs.png)
x265 - frame 3 (http://i.imgur.com/93mO1Hy.png)

To encode this part, I used x265 1.6+57f8246, default settings + preset slower.

Obviously the quality is worse than the source, but I wasn't expecting it to be _that_ worse. Plus, the decrease in quality seems more like glitches rather than just a simple blurring.

Soo.. Am I doing something wrong ? Should I tune further an important setting for animation ? Is x265 actually glitchy for this kind of content right now ?

Or is my CRF setting (28) simply too high ?

Thanks !

[Ma]

Soo.. Am I doing something wrong ? Should I tune further an important setting for animation ? Is x265 actually glitchy for this kind of content right now ?

You can try 10-bit x265 (if you used 8-bit) -- after fast check at preset slower & crf 28 on anime source I can't watch 8-bit x265 output. 10-bit is much better.

[RBX]

Are frame comparisons valid with psy settings on? I encoded an anime clip and in a certain frame I can see elements from next frame as well.

[nandaku2]

Quick verification. For chroma offsets in x265, cbqpoffs and crqpoffs work like chroma-qp-offset does in x264, So negative values reduce QP for chroma and thus increasing chroma quality relative to luma, right? And positive values would shift bits and quality away from chroma towards luma?

--cbqpoffs <integer>
Offset of Cb chroma QP from the luma QP selected by rate control. This is a general way to spend more or less bits on the chroma channel. Default 0

Range of values: -12 to 12
--crqpoffs <integer>
Offset of Cr chroma QP from the luma QP selected by rate control. This is a general way to spend more or less bits on the chroma channel. Default 0

Range of values: -12 to 12

Ben,
Correct. Positive offsets shift bits away from chroma. Here's roughly what the code looks like.

qpChroma = qpLuma + slice.m_pps->chromaQpOffset[0];

[foxyshadis]

Are frame comparisons valid with psy settings on? I encoded an anime clip and in a certain frame I can see elements from next frame as well.

If there are corruption artifacts, then definitely. Posting a short video sequence and command line that leads to artifacts would be the best of all. Also, what is your processor, just in case it's related to a particular instruction set?

[LigH]

@ Ely:

Indeed, there is a very obvious sample of a lack of good references and a possible intra encoding with heavy ringing (like Gibb's phenomenon). Another less obvious, but still typical place to spot them is in the ... what is that, a wooden arm? ... to the right of the blonde woman.

I guess if the developers had the original material available to recreate this glitch and test what happens exactly, they may find a way to avoid it getting as heavy as in the shoulder; unfortunately, HD cartoons with a cooperative license are hard to find.

[Ely]

You can try 10-bit x265 (if you used 8-bit) -- after fast check at preset slower & crf 28 on anime source I can't watch 8-bit x265 output. 10-bit is much better.

I did use 8bit x265. Can anyone explain to me what's the difference between 10-bit and 8-bit ? What kind of information is stored on 10 instead of 8 bits ?
I thought that only applied to source material where components are coded on 10 bits instead of 8, but apparently I'm wrong..?

@LigH okay, thanks for the information.

I did do another encode with CRF 23 (x265 8-bit), and the result was much better, all artifacts gone.

[LigH]

In general, not only for HEVC encoding: An encoder stores internal data (mainly the frequency parameters of the coding units, like "macro blocks") with a specific maximum precision (already many MPEG-2 encoders offered a DC precision of 8..11 bits). And when their values are quantized, they lose even more precision. This leads to rounding errors, but is also the usual way to reduce the diversity of values to be compressed by an entropy encoder (e.g. Huffman, Arithmetic Coding, etc. - depending on the video format), the usual method to reduce bitrate.

The 8 bit version of x265 provides an internal resolution of 8 bit = only 1 byte, which is quite easy to implement and often convenient; furthermore, many hardware decoders may only support 8 bit precision.

The "high bit depth" version of x265 currently provides routines for 10 bit resolution (more precision, like 12 bit, is also possible), which need 2 bytes each, therefore a lot more RAM, and a more complex implementation of internal calculations. It can store encoded values more exactly, but this means that they are less compressible because they are more diverse, therefore the required bitrate may be higher ... but does not have to. There is material which is even better compressible in higher parameter resolutions. Cartoons are known to profit from a higher bit depth.

[MeteorRain]

What kind of information is stored on 10 instead of 8 bits ?
I thought that only applied to source material where components are coded on 10 bits instead of 8, but apparently I'm wrong..?

Every channel of pixels will be encoded as 10 bit data.
10 bit is 25% larger than 8 bit, but it provides much more accurate value during computation. Think about the difference between 3.14159 and 3.1415926.

Besides, 8 bit YUV can barely represent ~6 bit RGB while 10 bit YUV can do ~8 bit RGB.

[Ma]

I did use 8bit x265. [...]
I thought that only applied to source material where components are coded on 10 bits instead of 8, but apparently I'm wrong..?

You can take 10-bit x265 and encode exactly like before -- preset slower & crf 28. Encoding time will be longer (not much), file size the same, quality you can evaluate your own eyes.

In theory 8-bit encoding is a little worse than 10-bit (assuming good encoder), but in practice x265 adds its imperfections and the result is very bad. 10-bit x265 is probably as bad as 8-bit x265 at 2 least significant bits, but if you decode 10-bit hevc you simply ignore these 2 bits and the result is OK.

[LigH]

Another weekly: x265 1.6+332-c4d9ee2cef03 (https://www.mediafire.com/download/8ks8af1c81smk4m/x265_1.6+332-c4d9ee2cef03.7z)

[Barough]

Another weekly: x265 1.6+332-c4d9ee2cef03 (https://www.mediafire.com/download/8ks8af1c81smk4m/x265_1.6+332-c4d9ee2cef03.7z)

Thnx 4 the new compile :)

[RBX]

If there are corruption artifacts, then definitely. Posting a short video sequence and command line that leads to artifacts would be the best of all. Also, what is your processor, just in case it's related to a particular instruction set?
I won't be able to post the video, but here is the frame I came across. http://screenshotcomparison.com/comparison/125530

The petal stays in the position for exactly 1 frame, so the difference isn't really visible during playback.

I used x265 1.6.298 16bpp compiled with ICC15. The CPU was i7-2630QM, and settings were preset:slow, tune:off, rc-lookahead:144, bframes:16, qg-size:16, crf:24
The video had few seconds of grainy scenes, and I was testing the effect of qg-size.

[Ely]

Okay, thank you all for clearing up high bit depth builds vs 8-bit builds.

As far as the sources are concerned, looks like x265 doesn't support any 10+bit YUV formats anyway, don't know why I was fixated on that.

Cheers

[LigH]

As far as I know, you can feed "DeepColor" video into x265. But I never did, so I don't have a matching workflow available to explain. I remember, though, that it has been discussed. I believe avs4x26x will help you, detecting such scripts and handling the pipe accordingly (e.g. using half the doubled size, because AviSynth has to stack the lsb and msb planes of 8 bit depth each).

[foxyshadis]

Okay, thank you all for clearing up high bit depth builds vs 8-bit builds.

As far as the sources are concerned, looks like x265 doesn't support any 10+bit YUV formats anyway, don't know why I was fixated on that.

Cheers

Why would you think that? x265 supports up to 16-bit YUV or Y4M input; if using YUV, you just have to specify --input-depth, and it'll always be converted to whatever depth the x265 build internally uses.

[burfadel]

I think they (as in the ITU and MPEG groups) should have made it as part of the h265 spec that 10-bit encoding is a requirement, and drop 8-bit all together. Why? Well, for 'standard' resolutions it looks better and is more efficient, and for encoding in 2160P it seems pointless if you're only using 8-bit. No point having 2160P resolution if you have banding or whatever!

For now, the wider the use of 10-bit, the more pressure will be on hardware makers to support it.

[littlepox]

Agreed. YUV-8bit has its native weakness in precision, resulting in a lot of banding.
It might not be obvious if you encode grainy sources, e.g., most movie clips; but they become extremely annoying if you are encoding anime, CG, or whatever clean-and-dark sources.
This cannot be overcome by any improvement in encoding technique. Some tricks, like adding noise, may help a little, but YUV-10bit is the true solution.

[Ely]

Why would you think that? x265 supports up to 16-bit YUV or Y4M input; if using YUV, you just have to specify --input-depth, and it'll always be converted to whatever depth the x265 build internally uses.

Oh indeed ! My bad (again) :-) .

[burfadel]

Agreed. YUV-8bit has its native weakness in precision, resulting in a lot of banding.
It might not be obvious if you encode grainy sources, e.g., most movie clips; but they become extremely annoying if you are encoding anime, CG, or whatever clean-and-dark sources.
This cannot be overcome by any improvement in encoding technique. Some tricks, like adding noise, may help a little, but YUV-10bit is the true solution.

If you're encoding an 8-bit source to 10-bit, I think it's also good to run a good deband and dither filter over it. It may seem counter-intuitive, but if you don't, you are actually encoding the banding. I find flash3kyuu to be exceptionally good at this (I'm using the 02 May 2015 2.0 prerelease). Works wonders :). The only option I use is f3kdb(dither_algo=2) despite algo_3 being supposedly better. The reason for this is number 2 encodes much better (unless you set a very low CRF or very high bitrate), and still looks vastly superior to not having it at all. It doesn't seem to affect bitrate either on 2 with CRF mode :).

Encoding an 8-bit source to 10-bit is still advantageous even if the source is banding and you don't use a filter. Even though you are encoding the banding, you are limiting the introduction of new banding and other associated artifacts. Ideally though, you get rid of the banding so you're not reencoding those artifacts.

[plonk420]

is there an issue with --tu-intra-depth 2 (and tu-inter) and decoders? or just a specific version? using MeGUI version 1.5+21 (LigH). i'm getting blocks flying all over in both CCCP+Lav but also VLC 2.2.1

i get the crazy blocks if i do --preset slower, but not if i do --preset slower --tu-intra-depth 1 --tu-inter-depth 1

http://i1.minus.com/i62UkijzwKkGL.png

[Santa]

I want to encode a 4k 16bpc png sequence to HEVC 4k 8bit 420

with x264 i was able to use a %04d.png as input, but with x265 it doesn't seem to work.
how do you input image sequences?

[sneaker_ger]

The standard x265 builds only support raw YUV input (with and without y4m headers). You cannot directly input any compressed formats. You need to find a different program that can input png and output to a pipe readable by x265. (Look for ffmpeg, VapourSynth, AviSynth).
Example: ffmpeg -i %04d.png -f yuv4mpegpipe -pix_fmt 420p - | x265 - --y4m -o output.265
(watch out for the colors, not sure how ffmpeg handles them)

There are patched x265 builds but I don't know if they offer the same functionality as x264 regarding

[burfadel]

Yeah, it would be nice to use x265 directly instead of using a pipe.

[feisty2]

Any news about main 444 16 intra and high throughput 444 16 intra?

[Ely]

Yeah, it would be nice to use x265 directly instead of using a pipe.

ffmpeg supports using x265 through "-vcodec libx265". It has to be compiled with the correct option "--enable-libx265" though.

[feisty2]

whatever clean-and-dark sources.

or just play with curves, pick another transfer, bt470 bg (L' = L^0.36 0 <= L <= 1) feels okay to me, it should kill the shit annoys you under 8bits precision.

[nandaku2]

is there an issue with --tu-intra-depth 2 (and tu-inter) and decoders? or just a specific version? using MeGUI version 1.5+21 (LigH). i'm getting blocks flying all over in both CCCP+Lav but also VLC 2.2.1

i get the crazy blocks if i do --preset slower, but not if i do --preset slower --tu-intra-depth 1 --tu-inter-depth 1

http://i1.minus.com/i62UkijzwKkGL.png

Something bad happening here. Can you please report this issue in our issue tracker (https://bitbucket.org/multicoreware/x265/issues) with exact commandlines and source (or mention a freely available clip) so that we can reproduce this at our end?

Thanks,

[LigH]

v1.5+21 is not quite a most recent version; testing "foreman" with v1.6+332 in all presets, no issues for all presets.

P.S.: Similar issues in the VideoHelp forum (http://forum.videohelp.com/threads/371670-What-is-the-reason-for-such-effects?p=2389378); Zathor, you may have to update x265 for MeGUI.

[foxyshadis]

The standard x265 builds only support raw YUV input (with and without y4m headers). You cannot directly input any compressed formats. You need to find a different program that can input png and output to a pipe readable by x265. (Look for ffmpeg, VapourSynth, AviSynth).
Example: ffmpeg -i %04d.png -f yuv4mpegpipe -pix_fmt 420p - | x265 - --y4m -o output.265
(watch out for the colors, not sure how ffmpeg handles them)

There are patched x265 builds but I don't know if they offer the same functionality as x264 regarding

x265 --y4m --colorprim bt601 --transfer bt601 - -o output.hevc

ffmpeg always converts using 601, so you have to flag that. If you want 709, you need:

ffmpeg -i "%1" -pix_fmt yuv420p16le -strict -1 -vf colormatrix=bt601:bt709 -vcodec rawvideo -f yuv4mpegpipe | x265 --y4m --colorprim bt709 --transfer bt709 - -o output.hevc

And if you want bt2020 with ffmpeg, you're plum out of luck. Kept in HBD so that the colormatrix operation doesn't lose much precision; x265 will dither it down.

ffmpeg is generally lousy at working with rgb and high bit depth formats. Imagemagick is lousy at working with yuv. Vapoursynth or Avisynth are generally your best option for converting with maximum quality.

[kolak]

Last ffmpeg versions (from 2.2 I think) can be forced to use Rec.709. Rec.601->Rec.709 is not optimal way.

You need to add this:
-vf scale=out_color_matrix=bt709 and your RGB sources will be converted through Rec.709.
There is small issue (very small red tint) for 8bit+ sources. Looks like this is related to conversion precision or some coefficients bug. Would be nice if someone can report it.

[foxyshadis]

-vf scale=out_color_matrix=bt709

Thanks, that's handy. I thought vf colormatrix was just shorthand for vf scale, but the debug output says scale options are applied to the initial conversion, whereas colormatrix is always a separate op. Good to know.

[kolak]

You can also control input colo matrix and black level.
Example:
"scale=in_range=full:in_color_matrix=bt601:out_range=tv:out_color_matrix=bt709"

Not sure how to avoid emoticons shortcuts (: out, with no space)

[sneaker_ger]

There's a "disable smilies in text" option when you post. (Need to "Go Advanced", though)

You can also control input colo matrix and black level.
Example:
"scale=in_range=full:in_color_matrix=bt601:out_range=tv:out_color_matrix=bt709"

[filler56789]

...
Not sure how to avoid emoticons shortcuts (: out, with no space)

By making the colons bold, for example;

:o ≠ :o

HTH :)

[kolak]

Thx, fixed.