x265 HEVC Encoder

[x265_Project]

Seems that next-gen HEVC has been researched for some time: https://forum.doom9.org/showthread.php?t=174245
I wonder if this time, it'll be viable to extend x265 to support the new format instead of starting from scratch (or from the reference encoder), or if the differences will be too big again.

Anything is possible with enough time, money and motivation. The question of whether to start with the reference or with x265 depends on your software development philosophy. We like to use an agile software development methodology, which stresses the need to always have a stable build that works. With a new coding standard, the reference encoder gives you a stable build that works (can encode valid bitstreams for that standard). So we would likely start there, and then slowly replace every piece of the reference encoder with our own code, just as we did with x265.

[Midzuki]

x265.exe 2.2+26-d1f6d9b8d6be

Add filler bits when frame bits < vbv target in strict-cbr

http://www.mediafire.com/file/j1ouckq9j70wss2/x265_2.2+26-d1f6d9b8d6be.7z

[cojj]

is it a bug? when I set --high-tier but not --level-idc, it still encodes in main tier... :(

According to the documentation:
"high-tier allows the support of high tier at that level. The encoder will first attempt to encode at the specified level, main tier first, turning on high tier only if necessary and available at that level."

Pretty self-explanatory => even if you set the flag, it will attempt main tier first and only use high-tier if necessary.

[burfadel]

Thanks for making that comparison burfadel. Actually the focus of SEA is to make FULL faster but we cannot expect it to be faster than other motion search algorithms like HEX/STAR.

That makes sense :).*STAR seems the most efficient,*it would be interesting to know whether it could be improved further.

[LigH]

x265 2.2+29-2f075fe8d4c5 (https://www.mediafire.com/file/8r5k5wmg1o65lkl/x265_2.2+29-2f075fe8d4c5.7z)

--complex-analysis <0..4.0> Strength of complex analysis, 0 to disable. Default 0.0

Increases the RD-level at points where the bitrate drops due to vbv. The number of CUs for which the RD is reconfigured is determined based on the strength. Strength 1 gives the best FPS, strength 4 gives the best SSIM. Strength 0 switches this feature off. Default: 0.

Effective for RD levels 4 and below.

A developers' functionality test runs with strength 1.53, FYI.

[burfadel]

x265 2.2+29-2f075fe8d4c5 (https://www.mediafire.com/file/8r5k5wmg1o65lkl/x265_2.2+29-2f075fe8d4c5.7z)

--complex-analysis <0..4.0> Strength of complex analysis, 0 to disable. Default 0.0

A developers' functionality test runs with strength 1.53, FYI.

You need to update your build, looks like the patches were resubmitted due to bugs and your build uses the old patches.

I also guess that for non restricted VBV like normal encoding with ABR, the function serves little use. I wonder whether it could be adopted to apply based on complexity rather than stating actual numbers, which would vary from encode to encode. For instance, a particular video might have scenes where there is low complexity, and there is plentiful use of P and B frames. There could be points in the video where the complexity increases such that fewer P and B frame could be utilised, resulting in a higher bitrate. When this occurs a higher complex-analysis seting can be used, 0.5 (variable strength) could be used there and scales upwards further with higher complexity. The setting would therefore be the scaling rate, such that a lower setting would be more constrained in the scaling, and not a fixed rate, based on perceived complexity of the current run of frames. This would make it useful for normal use and not a per-encode use that is required with the existing code due to stating VBV limitations that varies with content, complexity, and resolution.

I realise this isn't the purpose of it spefically, it's just an interesting concept that could be repurposed. Just an idea :).

[LigH]

How do I? TortoiseHg Workbench does not report any changes since. The commit log on bitbucket (https://bitbucket.org/multicoreware/x265/commits/all) neither.

[burfadel]

Probably not committed to the development branch yet, patches are here:

https://patches.videolan.org/project/x265-devel/list/

[x265_Project]

You need to update your build, looks like the patches were resubmitted due to bugs and your build uses the old patches.

I also guess that for non restricted VBV like normal encoding with ABR, the function serves little use. I wonder whether it could be adopted to apply based on complexity rather than stating actual numbers, which would vary from encode to encode. For instance, a particular video might have scenes where there is low complexity, and there is plentiful use of P and B frames. There could be points in the video where the complexity increases such that fewer P and B frame could be utilised, resulting in a higher bitrate. When this occurs a higher complex-analysis seting can be used, 0.5 (variable strength) could be used there and scales upwards further with higher complexity. The setting would therefore be the scaling rate, such that a lower setting would be more constrained in the scaling, and not a fixed rate, based on perceived complexity of the current run of frames. This would make it useful for normal use and not a per-encode use that is required with the existing code due to stating VBV limitations that varies with content, complexity, and resolution.

I realise this isn't the purpose of it spefically, it's just an interesting concept that could be repurposed. Just an idea :).
Sure, we can extend this technique to wider applications. This initial function was developed for those who use "capped VBR" rate control (CRF, with VBV). In this scenario, quality is constant until you reach a place where VBV kicks in to enforce decoder parameters. In these places, quality will take a dip. To counteract that, we allow x265 to dynamically increase encoding efficiency in these areas (similar to using a slower, higher quality performance preset). But yes, the concept could be extended to general ABR or CRF encoding.

[x265_Project]

Increases the RD-level at points where the bitrate drops due to vbv. The number of CUs for which the RD is reconfigured is determined based on the strength. Strength 1 gives the best FPS, strength 4 gives the best SSIM. Strength 0 switches this feature off. Default: 0.

Effective for RD levels 4 and below.


We probably should have said "Increases the RD level at points where quality drops due to VBV rate control enforcement." I'll ask our team to improve the documentation.

[Selur]

Effective for RD levels 4 and below.
+
if (m_param->complexAnalysis && (!bIsVbv || !p->rc.aqMode || p->rdLevel > 4))
{

p->complexAnalysis = 0;

x265_log(p, X265_LOG_WARNING, "Complex-analysis disabled, requires RD > 4, VBV and aq-mode enabled\n");

}

=> 'requires RD > 4' should be 'requires RD <= 4'

[Motenai Yoda]

+
if (m_param->complexAnalysis && (!bIsVbv || !p->rc.aqMode || p->rdLevel > 4))
{

p->complexAnalysis = 0;

x265_log(p, X265_LOG_WARNING, "Complex-analysis disabled, requires RD > 4, VBV and aq-mode enabled\n");

}

=> 'requires RD > 4' should be 'requires RD <= 4'
more "Effective for RD levels 4 and below." should be "Effective for RD levels 5 and over. "

[Selur]

@MontenaiYoda: the code I posted disables complexAnalysis when rdLevel > 4, so "Effective for RD levels 5 and over. " seems strange to me.

Cu Selur

[LigH]

I'd agree to Selur's opinion, it seems to match the documentation: complex analysis "Increases the RD level at points where quality drops due to VBV rate control enforcement", therefore it should be more effective when it was initially rather low. It compensates a bit of the loss in fast presets.

[Motenai Yoda]

@MontenaiYoda: the code I posted disables complexAnalysis when rdLevel > 4, so "Effective for RD levels 5 and over. " seems strange to me.

Cu Selur

KK I misread 0 as 1

[MonoS]

Hi, i do my encode with a command line like this
vspipe.exe -y script.vpy - | ffmpeg.exe -i - -c:v libx265 -preset veryslow -crf 22 ...
Often my script produce a 16bit output due to scaling or denoising, is it best to dithering the input in vapoursynth, pass the clip undithered as i'm doing or use the parameter --dither of x265 in the command line?
If i should dither it on the script side, what kind of dither is it best for this kind of parameters, if i'm not mistaken ordered dither should be the best when reaching for low bitrate target in every case
rect=0:amp=0:cutree=0:early-skip=0:limit-refs=3:aq-mode=3:limit-modes=1:level-idc=4:me=2:fast-intra=1:max-merge=3:rd=4:rdoq-level=0:psy-rd=1.1:aq-strength=1.9:deblock=-1,-1

Thanks for the attention

[Midzuki]

x265 2.2+30-fa52b516f5ff

complexAnalysis: clean up

http://www.mediafire.com/file/6vj4jym5p37dojn/x265_2.2+30-fa52b516f5ff.7z

[Magik Mark]

Is there a way to convert bt2020 to bt709 color matrix?

[Barough]

x265 v2.2+30-fa52b516f5ff (http://ge.tt/2bFZbai2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

[LigH]

x265 2.2+30-fa52b516f5ff (https://www.mediafire.com/file/9g689q9w9jwyhny/x265_2.2+30-fa52b516f5ff.7z) (GCC 6.2.0)

I hope XhmikosR will release updates MSYS packs...

[benwaggoner]

Is there a way to convert bt2020 to bt709 color matrix?
Not with x265. And not well without some high-end tone mapping technologies.

[Midzuki]

x265 2.2+30-fa52b516f5ff (https://www.mediafire.com/file/9g689q9w9jwyhny/x265_2.2+30-fa52b516f5ff.7z) (GCC 6.2.0)

I hope XhmikosR will release updates MSYS packs...

You can safely replace GCC 6.2 with the GCC 6.3 build compiled by nevcairiel:

https://files.1f0.de/mingw/

OR go the MSYS2 way...

Word about MPC-HC was in a dire need of developers was published back in '12. (https://mpc-hc.org/2012/09/24/open-call-for-contributors/)
At the moment only XhmikosR and kasper93 are semi active, you know ... LIFE has happened and not everyone has spare time anymore. Official statement will be drafted and published on MPC-HC's website when the time is right and when there are news to report.

So, perhaps XhmikosR will release a new MSYS1 package only when GCC 7 is out...

[youli]

Hi! Is anybody knows, how to display graphic chart of bitrate distribution for H.265 stream? I mean, just like "Bitrate Viewer" for H.264:

http://s020.radikal.ru/i706/1702/04/71f32da53278.png

[LigH]

Did you try whether this Bitrate Viewer fails when you have HEVC multiplexed in a supported container? It may just not support a raw video stream as long as there is no matching source filter.

An alternative may be to let x265 write a verbose CSV log (csv-log-level > 0), import it into a spreadsheet calculator, sort it to display order (that's a bit tricky e.g. in Excel alone), and let this draw a graph.

[birdie]

Hi! Is anybody knows, how to display graphic chart of bitrate distribution for H.265 stream? I mean, just like "Bitrate Viewer" for H.264:

http://s020.radikal.ru/i706/1702/04/71f32da53278.png

https://github.com/zeroepoch/plotbitrate

[youli]

LigH, ApTeM thanks a lot for your advices, but.. it will difficult ways for me.

In the both cases for AVC and HEVC I use mkv container. With AVC in mkv "Bitrate Viewer" works perfect, but with HEVC in mkv I got error "Codec not found".
http://s018.radikal.ru/i503/1702/bb/824ec218c590.png
LAV Filters 0.69 was installed.

[LigH]

Oh, I think I remember that this Bitrate Viewer (http://www.videohelp.com/software/Bitrate-Viewer-2) was built upon some ffmpeg version which is quite outdated today... It will not use LAV Filters. No source available. No longer developed.

Here (https://forum.doom9.org/showthread.php?p=1718367#post1718367) was the forum thread with my old complaint... The author updated only a Mac OS X version, but not a Windows version.

You will find some more tools there, but they are command line tools, not so user friendly without mouse support.

[youli]

Oh, thanks! I used CheckBitrate from https://onedrive.live.com/?authkey=%21AKcPpJfIHBiTBk0&id=6BDD4375AC8933C6%214230&cid=6BDD4375AC8933C6 and got csv-file.
Chart it in Excel
http://s008.radikal.ru/i303/1702/08/231533c8ea9d.png

[x265_Project]

Did you try whether this Bitrate Viewer fails when you have HEVC multiplexed in a supported container? It may just not support a raw video stream as long as there is no matching source filter.

An alternative may be to let x265 write a verbose CSV log (csv-log-level > 0), import it into a spreadsheet calculator, sort it to display order (that's a bit tricky e.g. in Excel alone), and let this draw a graph.

No need to sort in display order. The decoder is going to have to decode in decode order, which is the real bit rate.

[davidsama]

2.2+31-2014112 avx2 version https://tinyvpn.net/a/c/b/acbdfccb48760b159389f78919834ebc.7z

[CruNcher]

Uhhh

http://blog.beamr.com/blog/2016/12/13/before-you-evaluate-x265-read-this/

"a why our encoder is better craftsmanship kind of press release"

of course coming from the Vice President of Marketing

[MonoS]

Uhhh

http://blog.beamr.com/blog/2016/12/13/before-you-evaluate-x265-read-this/

"a why our encoder is better kind of press release"

Basically, we are better because we have patents, proprietary algorithm and sell our product for K$, x265 sucks because doesn't care about broadcaster and can't use patented software.

Interesting point of view.

[Midzuki]

Uhhh

http://blog.beamr.com/blog/2016/12/13/before-you-evaluate-x265-read-this/

"a why our encoder is better craftsmanship kind of press release"

Very-interesting :)

[CruNcher]

Basically, we are better because we have patents, proprietary algorithm and sell our product for K$, x265 sucks because doesn't care about broadcaster and can't use patented software.

Interesting point of view.

Yeah when he was at VUDU he surely wrote releases like "why x264 is better then proprietary software"

though he just tried to protect nothing else he knows exactly that most of those things are either already existing internally somewhere or being worked on as he spoke out that's called fear.

This is also funny as hell


"One note, we are aware that x265 supports these features via FFMPEG. However in the case that a user is not able to use FFMPEG, the fact that V.265 supports them directly is a benefit."


Who in the industry would employ people on the tech team not able to use FFMPEG for resizing some input :D

[x265_Project]

Very-interesting :)
Mark's first draft was so full of factual errors, I had to write to them. Then they posted this "corrected" version, which is still full of errors, and lots of unsubstantiated claims.

I just find the title kind of funny. "Before you evaluate x265"... as if there is a chance that anyone interested in evaluating HEVC encoder software libraries won't include x265 in their evaluation.

We're honored to be the gold standard by which all other HEVC encoders are compared. x265 is open and available for all to evaluate. If other encoders are truly better, why don't they make their encoder available publicly, so that anyone could run a test and publish the results?

[CruNcher]

Hehe or become at least part in the MSU evaluation ;)
else bog bog booog pick bog pick boooog bog ;)

And you absolutely right

"Before you evaluate x265, read this!"

he took his course in manipulation but i guess his writing charisma wont even subvert the dumbest decision makers in totally blindly buying his product and believing everything written and then you really have to ask the question who is he actually targeting ;)

the same old Vanguard with a new Name trimmed for the Visual Perception era by the Beamr PQ IP (BBCQ) ontop going against the likes of V-Nova in the Future ;)

[Barough]

x265 v2.2+31-20141129537b (http://ge.tt/1ngZ3hi2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

32-bit
x265 [info]: HEVC encoder version 2.2+31-20141129537b
x265 [info]: build info [Windows][GCC 6.3.0][32 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

64-bit
x265 [info]: HEVC encoder version 2.2+31-20141129537b
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

[littlepox]

Uhhh

http://blog.beamr.com/blog/2016/12/13/before-you-evaluate-x265-read-this/

"a why our encoder is better craftsmanship kind of press release"

of course coming from the Vice President of Marketing

A short summary on this article for doom9 users:

Our encoder produces something like s***, however we can solve a lot of problems you will never come across to or you can easily solve by yourself.

[Midzuki]

x265.exe 2.2+33-0729b3a4a0cc

cli: Enable new --hdr option to force signaling HDR parameters

Useful when there is a desire to signal --max-cll 0,0 in the bitstream.


http://www.mediafire.com/file/mce2ct21oc5a1v0/x265_2.2+33-0729b3a4a0cc.7z

[Barough]

x265 v2.2+33-0729b3a4a0cc (http://ge.tt/9B6Zxji2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

32-bit
x265 [info]: HEVC encoder version 2.2+33-0729b3a4a0cc
x265 [info]: build info [Windows][GCC 6.3.0][32 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

64-bit
x265 [info]: HEVC encoder version 2.2+33-0729b3a4a0cc
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

[CruNcher]

A short summary on this article for doom9 users:

Our encoder produces something like s***, however we can solve a lot of problems you will never come across to or you can easily solve by yourself.

Easily solve nahh actually partly they are solved already in a Framework by Multicorewave themselves called UHDkit ;)

Some are very specific and many are fighting here against the excellence of Ateme and that's a hard bread to beat Intel is on it's way todo that ;)

Though most are really unusable for AVG users though when we talk about Live Game streaming then it looks a little different and also AVG consumer could benefit from it but overall the complexity would need even those to build very beefy systems to even come into the direction to need them at all ;)

Different tuning scenario with different requirements with a very big focus on latency and multiple stream transmission stability and performance (resilience).


Multicorewave extensions it as the commercial part of the Encoder inside UHDkit a normal Strategy obviously our Beamr Marketing Vice President loses no word about it which is crazy it would be a viable attack vector for him.

[LigH]

x265 2.2+35-fe2f2dd96f8c (https://www.mediafire.com/file/n9eg73nqeswwlz6/x265_2.2%2B35-fe2f2dd96f8c.7z)

--complex-analysis is now --dynamic-rd, and you can now manually control HDR SEI packets

[Barough]

x265 v2.2+36-9b975fec584a (http://ge.tt/53eOnki2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

32-bit
x265 [info]: HEVC encoder version 2.2+36-9b975fec584a
x265 [info]: build info [Windows][GCC 6.3.0][32 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

64-bit
x265 [info]: HEVC encoder version 2.2+36-9b975fec584a
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

[LigH]

Why do you never summarize the difference to the previous version, Barough? Shall every user check the commit log on their own?

Meh. Let's dump the v2.2+35 I just uploaded; v2.2+36 is a merge with stable.
_

OK, slight issue: "tip" is in the "stable" branch here, not in the "default" branch. My update script always updates to the last commit in the "default" branch, if not specified otherwise, so missed the merge...

Once again.
_

x265 2.2+36-9b975fec584a (https://www.mediafire.com/file/m4sp9c3b2uiihk4/x265_2.2+36-9b975fec584a.7z)

[nakTT]

x265 v2.2+36-9b975fec584a (http://ge.tt/53eOnki2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

32-bit
x265 [info]: HEVC encoder version 2.2+36-9b975fec584a
x265 [info]: build info [Windows][GCC 6.3.0][32 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

64-bit
x265 [info]: HEVC encoder version 2.2+36-9b975fec584a
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

Thanks for the update. The executable size is smaller than other builds but it works.:thanks:

[Midzuki]

Thanks for the update. The executable size is smaller than other builds but it works.:thanks:

Barough applies UPX upon x265.exe, there is no sorcery involved :D

[LigH]

That may produce smaller individual files; but to compress several very similar files in a tight archive for a smaller download, it may be better not to pre-compress them, so that archivers can find more identical parts between different files. 7-zip is quite good at that with large dictionary sizes... After unpacking the archive, you may decide on your own whether it is useful to UPX either EXE.

[FlipFlops2001]

http://msystem.waw.pl/x265/

Builds using MS Visual Studio 2017, GCC 6.3 and GCC 7.0 include: AVX2, AVX, SSSE3 or SSE2fast (or below) SIMD dedicated support.

Current version as of this posting: x265-2.2+35-fe2f2dd.

New CLI: --hdr, --no-hdr; used in conjunction with --max-cll. Currently running an encode using --hdr. Has anybody tried this yet?

x265 command line options documented @: http://x265.readthedocs.io/en/default/cli.html

These following parameters have been working very well for me:
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : @L3.1@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 43 min 45 s
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Writing library : x265 2.2+35-fe2f2dd96f8c:[Windows][MSVC 1910][64 bit] 10bit
Encoding settings : cpuid=1050111 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / pme / no-psnr / no-ssim / log-level=2 / input-csp=2 / input-res=1280x720 / interlace=0 / total-frames=62946 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=5 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=23 / keyint=250 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=40 / lookahead-slices=4 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=1 / dynamic-rd=0.00 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=5 / limit-refs=3 / no-limit-modes / me=3 / subme=4 / merange=57 / temporal-mvp / weightp / no-weightb / analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=1.50 / psy-rdoq=1.50 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=3 / crqpoffs=3 / rc=crf / crf=24.5 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=3 / aq-strength=1.50 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=1 / overscan=0 / videoformat=5 / range=1 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / aq-motion / hdr
Language : English
Default : Yes
Forced : No
Color range : Full

Any suggestions?

[Barough]

@LigH

That's a simple answer. When ever i run the 'media-autobuild_suite' and it gives me new EXE's so do i just share 'em. The only time i look into the changes etc. is when im about to use 'em myself.

[LigH]

That may mean that you publish even new builds when they don't change the code at all (e.g. only update the documentation)... this would be too often for my taste. :)