x265 HEVC Encoder

[2themax]

Yes, open-gop is the issue. The reason the Panasonic UHD Verifier shows 27 frames is because 3 frames after the I frame refer to frames in the previous GOP. Can you test with --no-open-gop?

The UHD-BD documentation was not specific about enforcing closed GOPs.
Setting it to --no-open-gop did indeed fix the problem for now. The encode passes without any error.

[a5180007]

The reason the Panasonic UHD Verifier shows 27 frames is because 3 frames after the I frame refer to frames in the previous GOP.

Did you mean before the I frame?

[foxyshadis]

OpenGOP is allowed according to the white paper on the BluRay website. Chapter 3.2 lists GOP restrictions.
http://www.blu-raydisc.com/assets/Downloadablefile/BD-ROM_Part3_V3.0_WhitePaper_150724.pdf

Open GOP is allowed, but that just means any frames that are "open" still come off the total frames in the GOP. Still can't add up to more than 1 second of frames. I'm sure x265 will fix the accounting shortly.

[Motenai Yoda]

It's right that in x265, with preset medium and rdoq-level=2, is psy-rdoq 0.00?
The docs says it should be 1.0 and it isn't changed by preset

[Ma]

It's right that in x265, with preset medium and rdoq-level=2, is psy-rdoq 0.00?
The docs says it should be 1.0 and it isn't changed by preset

Yes, there is the difference.

In docs there is 1.0:
--psy-rdoq (http://x265.readthedocs.org/en/default/cli.html?highlight=psy-rdoq#cmdoption--psy-rdoq)

In source code there is 0.0:
void x265_param_default(x265_param* param) @ param.cpp (https://bitbucket.org/multicoreware/x265/src/5b01678f6fb4e89e23cd41295592a9aa5d51d4ba/source/common/param.cpp?at=default&fileviewer=file-view-default#param.cpp-189)

1.0 is assigned from preset 'slow' to 'placebo'. I don't know if it is OK.

[x265_Project]

Yes, there is the difference.

In docs there is 1.0:
--psy-rdoq (http://x265.readthedocs.org/en/default/cli.html?highlight=psy-rdoq#cmdoption--psy-rdoq)

In source code there is 0.0:
void x265_param_default(x265_param* param) @ param.cpp (https://bitbucket.org/multicoreware/x265/src/5b01678f6fb4e89e23cd41295592a9aa5d51d4ba/source/common/param.cpp?at=default&fileviewer=file-view-default#param.cpp-189)

1.0 is assigned from preset 'slow' to 'placebo'. I don't know if it is OK.
It's been a while, but if I recall correctly Psy-RDOQ only works with RD level 4 and above. Our preset documentation (http://x265.readthedocs.org/en/default/presets.html) matches the code in param.cpp.

[burfadel]

It's been a while, but if I recall correctly Psy-RDOQ only works with RD level 4 and above. Our preset documentation (http://x265.readthedocs.org/en/default/presets.html) matches the code in param.cpp.

So therefore there is a difference betwee RD 3 and 4, with 4 allowing Psy-RDOQ?

I am currently using:

--rd 4
--tu-intra-depth 3
--rdoq-level 1
--early-skip
--fast-intra
--b-intra
--tskip
--tskip-fast
--limit-modes
--aq-mode 3
--qg-size 16
--me star
--merange 25
--max-merge 3
--weightb
--bframes 6
--rc-lookahead 40
--ref 6

I've found using --me star to be effectively faster than --me umh, but provide better quality. psy-rdoq 1 does increase the file size a little, but visual quality wise it does seem to produce a better image, much in line with what using --rd 5 does but considerably faster, with a similar file size output. Well worth it I think.

--merange 25 is faster than the default. If the video is say, 480P, you wouldn't need as much --merange as you would with say, 1080P or 2160P. --merange 25 is great at 480P, and when you think of it, it makes sense. 25 at 480P covers the same distance as what 56.25 (so 57) does at 1080P. Maybe there should be an autoscaler in x265 to adjust this automatically based on resolution, like I suggested above.

--early-skip, --fast-intra, --tskip, --tskip-fast, --limit-modes all improve speed without being detrimental to quality, as far as I see it anyway :). In combination with the other settings encoding is both fast and high quality. I chose --tu-intra-depth 3 because it does seem to be a little more efficient without impacting on performance too much, likewise with --maxmerge 3. I chose --rc-lookahead as 40, I see it as a slightly beneficial, and I figure it make sense being the same as scenecut. --ref 6 and --bframes 6 is just what I chose. Nice balance of efficiency versus speed. For most content is seems using 5 bframes is most efficient in terms of the stats at the end showing consecutive b-frame usage. Yes, 5, so I chose 6 for that little extra :).

A little more controversial may be my use of --nr-intra 400 and --nr-inter 400. I didn't list those above, but I do use them. I use these because it seems to get rid of some low level noise that affects compressibility, but doesn't impede too much on the output picture. For the same file size, you can lower the CRF (keeping in mind decimal CRF is allowed), and get effectively the same file size output. The quality gained by the lower CRF overcomes any loss as a result of the noise reduction, at least in my opinion.

So, there are my settings. I get very fast compressing speed with them, and a high quality output at a decent file size.

[x265_Project]

So therefore there is a difference between RD 3 and 4, with 4 allowing Psy-RDOQ?

Yes. Confirmed.

From x265.h, line 973...
/* Strength of psycho-visual optimizations in quantization. Only has an effect in presets which use RDOQ (rd-levels 4 and 5). The value must be between 0 and 50, 1.0 is typical. Default 1.0 */
double psyRdoq;

We'll update the documentation (http://x265.readthedocs.org/en/default/cli.html#cmdoption--psy-rdoq)to clarify this.

[Motenai Yoda]

Yes. Confirmed.

From x265.h, line 973...
/* Strength of psycho-visual optimizations in quantization. Only has an effect in presets which use RDOQ (rd-levels 4 and 5). The value must be between 0 and 50, 1.0 is typical. Default 1.0 */
double psyRdoq;
But rd-levels 3 and 4 aren't the same? also if it isn't used why to put it at 0?

It's an year old thing 75c019f (https://bitbucket.org/multicoreware/x265/commits/75c019fe32f8296d176dce676129bc20c3c467a8)
3 RDO mode and split decisions, chroma residual used for sa8d
4 Currently same as 3

[x265_Project]

But rd-levels 3 and 4 aren't the same? also if it isn't used why to put it at 0?

I think this is another opportunity for improvement of our documentation. Rate-Distortion Optimized Quantization (RDOQ) isn't performed until RD-level 4. We can't psy optimize RDOQ until we start doing RDOQ.

[burfadel]

The documentation still says 4 is the same as 3. Funnily enough though, when I was playing around with the settings I originally chose --rd 5 and rd-refine, as the picture seems to retain some of the texture better. It made for slow encoding though, so I dropped it to 4 and tried psy-rdoq. I never actually tried to use psy-rdoq with rd 3. psy-rdoq I feel is a good thing to use, it seems to maintain picture texture a bit better. It doesn't make the flatter surfaces too smooth. It's more a visual thing, maybe psychological... it seems to be more noticeable in the picture than with PSNR or SSIM. I'm just glad I spent the time to refine my settings, I'm very happy with the output and speed of encoding with the settings I'm using now (as listed in my previous post).

[nandaku2]

Open GOP is allowed, but that just means any frames that are "open" still come off the total frames in the GOP. Still can't add up to more than 1 second of frames. I'm sure x265 will fix the accounting shortly.

I dont think we want to change the definition of GOPsize - which currently means distance between 2 consecutive I/IDR frames, to include number of "open" frames.

If the UHD-BD spec has such a distinction, the best thing to do is probably enforce no-open-gop, imho.

[nandaku2]

I think this is another opportunity for improvement of our documentation. Rate-Distortion Optimized Quantization (RDOQ) isn't performed until RD-level 4. We can't psy optimize RDOQ until we start doing RDOQ.

Fixed the comment in x265.h. Many moons ago, rd-level 4 was rd-level 3 + rdoq and rd-level 6 was rd-level 5 + rdoq. Later we separated rdoq-level from rd-level, so now rd-level 3=4 and 5=6. And of course, we dont want to break our users' scripts by cleaning this down to 4 rd-levels.

Psy-rdoq will be in effect if rdoq-level is non-zero. It doesnt depend on rd-level.

[Motenai Yoda]

Instead I think that comment and that assignment are some leftovers of the 1.3.

I can't find any selection about rdLevel >(=) 4, < 4, > 3 or <= 3
only < 3, >= 3, <= 4 or < 5

edit: preceded by nandaku

ps @x265_Project sorry the board was getting me a db error so I ended to send you an pm, I saw it only now.

[kamineko]

We have that as well. For anime contents basically you wish to encourage bits to be invested in the edge areas, and that can be done by tweaking psy and aq.


Will probably do another extensive test and post our suggestions here after v2.0. Our current parameters are updated with v1.9 stable.

Looking forward to your recommendations after 2.0! What would you use as current parameters for archival of anime content for SD and HD (Bluray)? I am looking for something which is good quality for a home theater setup and a seasoned viewer, but still reasonable in terms of time and storage demands.

I know that there are huge differences in source material; something like Fuujin Monogatari (http://i.imgur.com/SpVZRC8.jpg) from DVD is completely different to Ao no Exorcist - Movie (http://i.imgur.com/jVR1VLG.jpg) from the BluRay. And that's probably different to Western 3D animation from Pixar and Disney as well.

Not to mention rotoscoped stuff like Ajin or Aku no Hana.

Does any of this make a difference for your encoding? Any recommendations?

[jlpsvk]

this is x264:
http://s12.postimg.org/4r368zrl9/SW_x264.png

and this x265:
http://s8.postimg.org/sldo3qj51/SW_x265.png

No matter what I do, the transition on the banner (from red to black - highlighted) is smoother on x264. On x265 you the the squares after the close-up. What do you advice?

My settings:
--crf 22 --preset slow --output-depth 10 --tu-intra-depth 2 --rdoq-level 1 --qg-size 16 --ipratio 1.3 --pbratio 1.2 --max-merge 2 --rc-lookahead 60 --ref 3 --min-keyint 23 --keyint 240 --colorprim bt709 --colormatrix bt709 --transfer bt709 --deblock -3:-3 --psy-rdoq 5

Anyone?

[huhn]

hard to judge it is not the same frame.

[jlpsvk]

know it's not the same frame, but the difference is obvious...no matter the frame. :(

[LigH]

Several fixes regarding UHD-BD, dithering of different color depths, and documentation clarifications:

x265 1.9+125-40afead3177d (https://www.mediafire.com/download/v435ptuzuvnf12c/x265_1.9+125-40afead3177d.7z)

[burfadel]

I notice in the development log the patch:
[x265] [PATCH] analysis: introduce analysis refinement level for analysis save/load feature

There seems to be a mistake in it!

In the top part, it says:
Higher the value, Lesser the information stored/reused, Slower the encode. Default 5.

This is backed up in the table below it, which shows the default level of 5 just storing 'Lookahead information', with 4 storing additionally Intra and Inter modes, ref's, and mode 3 storing rec-amp additionally (level 2 and 1 same as 3).

However, down the bottom of the patch in the command line help part:
--analysis-refine-level <1..5>Level of information stored/reused in analysis save/load mode 1:least....5:most.

That is back to front to the information at the top of the patch. I assume the reason for not just using what would be '1' according to the table as the default is memory use? In any case, just thought I'd mention it since it could be easily overlooked.

[2themax]

Several fixes regarding UHD-BD, dithering of different color depths, and documentation clarifications:

x265 1.9+125-40afead3177d (https://www.mediafire.com/download/v435ptuzuvnf12c/x265_1.9+125-40afead3177d.7z)
Does it address open GOP for UHD-BD?

[Ma]

Does it address open GOP for UHD-BD?

Not yet. The latest opinion about this bug from nandaku2 (x265 boss) is in message:
http://forum.doom9.org/showthread.php?p=1763866#post1763866

[LigH]

Not yet, I believe. I don't remember a patch specific to changing the count of frames per GOP in an open-GOP setup. There was just a removed allowance for 1088 lines with cropping.

See yourself: x265 commit log (https://bitbucket.org/multicoreware/x265/commits/)

[LigH]

P.S.: Closed GOPs will get forced for UHD-BD compatibility (https://bitbucket.org/multicoreware/x265/commits/e7d937ad1ea341eeebd210188e08540ab6104fef), maybe until a more elaborate logic might be programmed for the open GOP case.

[x265_Project]

P.S.: Closed GOPs will get forced for UHD-BD compatibility (https://bitbucket.org/multicoreware/x265/commits/e7d937ad1ea341eeebd210188e08540ab6104fef), maybe until a more elaborate logic might be programmed for the open GOP case.

At this point, we don't see the benefit of a smaller GOP size with open GOP, versus a larger GOP size. Does anyone really think this is a necessary capability?

[LigH]

As far as I remember, closed GOPs have slight advantages also regarding "seeking everywhere" and supporting speed playback features, already in times of the DVD Video with MPEG-2, and also on Blu-ray with AVC. Even though closed GOPs may not be necessary, they may be useful, and they are probably quite usual in commercial productions. Compatibility already required a few trade-offs in compression efficiency, open GOPs will be a marginal addend in the whole sum.

[hajj_3]

PowerDVD 16 is out today. Anyone fancy comparing the h265 decoder with the one from v15? V16 does not support UHD bluray discs btw, we don't know whether support will be added in a patch or if it will come in v17.

[x265_Project]

PowerDVD 16 is out today. Anyone fancy comparing the h265 decoder with the one from v15? V16 does not support UHD bluray discs btw, we don't know whether support will be added in a patch or if it will come in v17.
It remains to be seen if the security requirements for UHD-BD will allow a PC software player application.

[LigH]

x265 1.9+140-34a3d35c5f97 (https://www.mediafire.com/download/t7819gofasbr955/x265_1.9+140-34a3d35c5f97.7z): UHD-BD compatibility forces closed GOPs; --limit-refs clarified to be on/off; and a bunch of fixes and speed-ups (ARM implementations don't matter for x86 platform)

[RainyDog]

Can anyone explain the effects of --tu-inter-depth and --tu-intra-depth in layman terms for me please?

I'm currently encoding old ish TV series from DVD whilst experimenting with some settings in the process. It's been a while since I last tried x265 and I'm pleasantly surprised by what speeds I can get on my i7 3770k with a bit of settings juggling.

But I've just stumbled across that increasing both --tu-inter-depth and --tu-intra-depth from 1 to 2 causes a 15% reduction in bitrate with all other settings left the same. Is really that much of an efficiency gain or is it actually having a negative impact somewhere? The DVD's are PAL 720x576 so is resolution a factor? Perhaps 1 is best for SD, 2 for HD and 3 is for 4k? Going from 2 to 3 barely has any effect but the reduction in bitrate and file size when increasing from 1 to 2 is quite alarming!

Speed doesn't seem much different when set to 1, 2 or 3 but that might be because it's chugging along at a lower bitrate when set to 2 or 3.

Main settings I've settled on otherwise (for 576p resolution) are preset medium but with the following tweaks :-

--CRF 21 --ctu 16 --max-tu-size 8 --qg-size 16 --early-skip --b-intra --limitmodes --weightb --me star --merange 25 --max-merge 3 --subme 3 --ref 5 --bframes 5 --rc-lookahead 40

Thanks.

[benwaggoner]

Can anyone explain the effects of --tu-inter-depth and --tu-intra-depth in layman terms for me please?

I'm currently encoding old ish TV series from DVD whilst experimenting with some settings in the process. It's been a while since I last tried x265 and I'm pleasantly surprised by what speeds I can get on my i7 3770k with a bit of settings juggling.

But I've just stumbled across that increasing both --tu-inter-depth and --tu-intra-depth from 1 to 2 causes a 15% reduction in bitrate with all other settings left the same. Is really that much of an efficiency gain or is it actually having a negative impact somewhere? The DVD's are PAL 720x576 so is resolution a factor? Perhaps 1 is best for SD, 2 for HD and 3 is for 4k? Going from 2 to 3 barely has any effect but the reduction in bitrate and file size when increasing from 1 to 2 is quite alarming!

Speed doesn't seem much different when set to 1, 2 or 3 but that might be because it's chugging along at a lower bitrate when set to 2 or 3.

Main settings I've settled on otherwise (for 576p resolution) are preset medium but with the following tweaks :-

--CRF 21 --ctu 16 --max-tu-size 8 --qg-size 16 --early-skip --b-intra --limitmodes --weightb --me star --merange 25 --max-merge 3 --subme 3 --ref 5 --bframes 5 --rc-lookahead 40

Thanks.
Given a --max-tu-size 8 I don't know what --tu-*-depth can really do, and am surprised it would have any impact. From 8x8 it can only really go down one level to 4x4. Although if it's coming from a max cu-size of 32x32, to get to 8x8 you'd need to go down several levels to get to that size. Perhaps the tu-depth modes start from max TU size?

That's a pretty complex command line with some unusual settings. Perhaps try --preset slower --crf 18? A lower CRF plus more standard settings may give a good quality/size balance. If it's grainy source, maybe add in --tune grain.

[RainyDog]

Given a --max-tu-size 8 I don't know what --tu-*-depth can really do, and am surprised it would have any impact. From 8x8 it can only really go down one level to 4x4. Although if it's coming from a max cu-size of 32x32, to get to 8x8 you'd need to go down several levels to get to that size. Perhaps the tu-depth modes start from max TU size?

Thanks for the response. I'll have another play around with them again, perhaps increase intra and not inter and visa versa. And compare all the resulting encodes by eye. I was just taken back by the file size reduction from only changing those two settings. Too good to be true, didn't seem right at all.

That's a pretty complex command line with some unusual settings. Perhaps try --preset slower --crf 18? A lower CRF plus more standard settings may give a good quality/size balance. If it's grainy source, maybe add in --tune grain.

Not really from what I can gather. It's all pretty much based on what burfadel and littlepox have been recommending over the past few pages with a couple of other tweaks. --max-tu-size 16 seems to be the way to go for 1080p encodes at present so --max-tu-size 8 makes sense for 480-576p resolutions.

[burfadel]

I'm still a little confused about RD 3 and 4. Are they supposed to be the same or not?

The outputs for RD 3 and 4 are NOT the same consistently. In theory, if they were the same the only difference should be the info part of the output, with one showing RD 3 and the other 4. This is not the case, the outputs are actually different. I normally have RDOQ on level 1, but I disabled it for this comparison. Regardless of whether it is on or off, the output is different between RD 3 and 4. All settings are identical apart from RD 3 and 4. Also, the results are consistent across encoding the same file and same settings (just to show it's not a memory error or errata causing the difference):

RD 3:
x265 [info]: frame I: 15, Avg QP:18.01 kb/s: 10311.83
x265 [info]: frame P: 272, Avg QP:19.71 kb/s: 2785.46
x265 [info]: frame B: 923, Avg QP:26.51 kb/s: 384.35
x265 [info]: Weighted P-Frames: Y:2.6% UV:2.2%
x265 [info]: Weighted B-Frames: Y:1.1% UV:1.1%
x265 [info]: consecutive B-frames: 9.1% 2.4% 3.8% 49.8% 15.7% 15.7% 3.5%
encoded 1210 frames in 38.71s (31.26 fps), 1047.17 kb/s, Avg QP:24.87

RD 4:
x265 [info]: frame I: 15, Avg QP:18.01 kb/s: 10324.29
x265 [info]: frame P: 272, Avg QP:19.71 kb/s: 2787.77
x265 [info]: frame B: 923, Avg QP:26.49 kb/s: 385.29
x265 [info]: Weighted P-Frames: Y:2.6% UV:2.2%
x265 [info]: Weighted B-Frames: Y:1.1% UV:1.1%
x265 [info]: consecutive B-frames: 9.1% 2.4% 3.8% 49.8% 15.7% 15.7% 3.5%
encoded 1210 frames in 38.21s (31.67 fps), 1048.56 kb/s, Avg QP:24.86

They are similar, but NOT identical. This is using the settings I listed a few days ago, except for not using RDOQ which I normally have on. Since that was said to be the difference at one point, I disabled it to show the difference is elsewhere.

If they are meant to be the same, there is obviously a bug somewhere in x265. Something is definitely being done differently between RD 3 and 4!

The version used is:
x265 [info]: HEVC encoder version 1.9+140-34a3d35c5f97

[Ma]

I'm still a little confused about RD 3 and 4. Are they supposed to be the same or not?

They are not the same. There is only one difference in source code:
https://bitbucket.org/multicoreware/x265/src/34a3d35c5f97c7ecf76bbb3311a9bbb66db0d695/source/encoder/search.cpp?at=default&fileviewer=file-view-default#search.cpp-1479
-- for '--rd 4' maxCandCount has bigger value.

I don't know if they supposed to be the same.

[burfadel]

Yes. Confirmed.

From x265.h, line 973...
/* Strength of psycho-visual optimizations in quantization. Only has an effect in presets which use RDOQ (rd-levels 4 and 5). The value must be between 0 and 50, 1.0 is typical. Default 1.0 */
double psyRdoq;

We'll update the documentation (http://x265.readthedocs.org/en/default/cli.html#cmdoption--psy-rdoq)to clarify this.

But rd-levels 3 and 4 aren't the same? also if it isn't used why to put it at 0?

It's an year old thing 75c019f (https://bitbucket.org/multicoreware/x265/commits/75c019fe32f8296d176dce676129bc20c3c467a8)

I think this is another opportunity for improvement of our documentation. Rate-Distortion Optimized Quantization (RDOQ) isn't performed until RD-level 4. We can't psy optimize RDOQ until we start doing RDOQ.

Fixed the comment in x265.h. Many moons ago, rd-level 4 was rd-level 3 + rdoq and rd-level 6 was rd-level 5 + rdoq. Later we separated rdoq-level from rd-level, so now rd-level 3=4 and 5=6. And of course, we dont want to break our users' scripts by cleaning this down to 4 rd-levels.

Psy-rdoq will be in effect if rdoq-level is non-zero. It doesnt depend on rd-level.

So the consensus was that it came back to RD level 4 being the same as 3. Since it isn't, then the information should be further clarified.

From the x265 code you linked, this comment:
Find the top maxCandCount candidate modes with cost within 25% of best or among the most probable modes. maxCandCount is derived from the rdLevel and depth. In general we want to try more modes at slower RD levels and at higher depths

So, it makes sense in that RD 4 has a different output to RD 3, as more modes would have been tried. In theory therefore, 4 should be more efficient than 3, which I believe is the case (albeit slight). The speed difference for me when averaged out over different sections is non-existent, or at least not measurable, so RD 4 will remain my choice :).

[Motenai Yoda]

Well with --rd 4 it return a pretty identical stream, maybe some not deterministic stuff?

x265 [info]: frame I: 19, Avg QP:21.97 kb/s: 20434.61 PSNR Mean: Y:42.274 U:44.137 V:47.052 SSIM Mean: 0.957082 (13.674dB)
x265 [info]: frame P: 421, Avg QP:23.05 kb/s: 13604.57 PSNR Mean: Y:42.211 U:43.094 V:46.043 SSIM Mean: 0.962831 (14.298dB)
x265 [info]: frame B: 1706, Avg QP:26.91 kb/s: 2479.44 PSNR Mean: Y:40.630 U:42.025 V:45.616 SSIM Mean: 0.953919 (13.365dB)
x265 [info]: Weighted P-Frames: Y:34.7% UV:28.5%
x265 [info]: consecutive B-frames: 6.4% 2.3% 3.2% 26.1% 17.5% 38.6% 4.1% 1.6% 0.2%

encoded 2146 frames in 523.56s (4.10 fps), 4820.92 kb/s, Avg QP:26.11, Global PSNR: 41.712, SSIM Mean Y: 0.9556955 (13.536 dB)

x265 [info]: frame I: 19, Avg QP:21.97 kb/s: 20421.66 PSNR Mean: Y:42.276 U:44.138 V:47.054 SSIM Mean: 0.957075 (13.673dB)
x265 [info]: frame P: 421, Avg QP:23.05 kb/s: 13604.11 PSNR Mean: Y:42.212 U:43.092 V:46.043 SSIM Mean: 0.962820 (14.297dB)
x265 [info]: frame B: 1706, Avg QP:26.89 kb/s: 2480.82 PSNR Mean: Y:40.630 U:42.024 V:45.616 SSIM Mean: 0.953914 (13.364dB)
x265 [info]: Weighted P-Frames: Y:34.7% UV:28.5%
x265 [info]: consecutive B-frames: 6.4% 2.3% 3.2% 26.1% 17.5% 38.6% 4.1% 1.6% 0.2%

encoded 2146 frames in 518.16s (4.14 fps), 4821.82 kb/s, Avg QP:26.10, Global PSNR: 41.712, SSIM Mean Y: 0.9556887 (13.535 dB)

[burfadel]

Yes, very, very similar but not the same. It would also vary depending on content.

[x265_Project]

We'll be in Las Vegas next week for the 2016 NAB Show. I'll be giving a talk on HEVC Encoding on Monday, and we'll have a demo suite set up. If you're going and want to meet up, please send me a message.

Tom

nandaku2 and pradeeprama optimizing our live 4K encoding demo...
https://www.facebook.com/x265project/photos/a.1413021475581600.1073741826.1395701047313643/1691877084362703/?type=3&theater

[Magik Mark]

Hi there!

Is there any professional software that is using this project? May we know there company name so we could evaluate on how they are applying this technology to their product

Thanks a lot


Sent from my iPhone using Tapatalk

[x265_Project]

Hi there!
Is there any professional software that is using this project? May we know there company name so we could evaluate on how they are applying this technology to their product

In addition to FFMPEG, VLC, Handbrake, StaxRip, MeGUI, and many other open source software applications, x265 powers commercial solutions from leading encoder vendors like Telestream, BBright, Sorenson, Pegasys, and many others (most of which are confidential at this time), and many leading streaming video services and cloud encoding services.

[Magik Mark]

In addition to FFMPEG, VLC, Handbrake, StaxRip, MeGUI, and many other open source software applications, x265 powers commercial solutions from leading encoder vendors like Telestream, BBright, Sorenson, Pegasys, and many others (most of which are confidential at this time), and many leading streaming video services and cloud encoding services.



Thank you for this. Tried Sovenson. Unfortunately, they don't update their hevc feature. Lacks a lot of features

Can you recommend a professional software. Similar to squeeze desktop pro that uses all the features of this project

Thanks

[JohnLai]

In addition to FFMPEG, VLC, Handbrake, StaxRip, MeGUI, and many other open source software applications, x265 powers commercial solutions from leading encoder vendors like Telestream, BBright, Sorenson, Pegasys, and many others (most of which are confidential at this time), and many leading streaming video services and cloud encoding services.

Interesting........what are commercial features not offered by opensource software other than Graphical User Interface?

[fauxreaper]

https://bitbucket.org/multicoreware/x265/issues/214/ghosting-artefacts-even-with-low-crf-when

Can other people test --no-cutree to see if they find less ghosting on their encodes?

[Ma]

https://bitbucket.org/multicoreware/x265/issues/214/ghosting-artefacts-even-with-low-crf-when

Can other people test --no-cutree to see if they find less ghosting on their encodes?

Yes, it is much better with --no-cutree (almost OK).

[kolak]

Interesting........what are commercial features not offered by opensource software other than Graphical User Interface?

None...

It's more about things which you can do with this software. I don't think x265 engine itself is any better.

[stax76]

while running an automated test to find out if StaxRip needs to be updated I found out there are switches not listed under --help

--bframe-bias
--cbqpoffs
--chromaloc
--colormatrix
--cplxblur
--crf-max
--crf-min
--crqpoffs
--dither
--hash
--interlace
--ipratio
--lookahead-slices
--lossless
--nr-inter
--nr-intra
--pbratio
--qblur
--qcomp
--qp
--qpstep
--sao-non-deblock
--temporal-mvp
--tskip
--tskip-fast
--y4m

[sneaker_ger]

Second to last sentence when using --help:
Use --log-level full --help for a full listing

[benwaggoner]

Second to last sentence when using --help:
And better yet, the only good codec documentation that has ever existed:

http://x265.readthedocs.org/en/default/

[James Freeman]

Hi, I'm new at this.

Should I start from --preset slower (or slow?), --crf 18, as suggested by benwaggoner and test from there?
The resulting bitrate in average is 10,000 kb/s (3840x2160, 10bit 25fps), and looks good to me.
I can see Slower adds sao deblocking at the end, is it beneficial?

Is there any important settings I should be aware of for a casual user?
I saw --tune grain, if the video is from a film.

[birdie]

You should almost always choose the slowest encoding preset you can bear (aside from "placebo" which is called this way for a reason).