x265 HEVC Encoder

[Boulder]

With grainy content, x265 tends to use plenty of B-frames compared to clean ones. I've always found this a bit odd, and I don't know the reason for the behaviour. Just encode any old crispy B/W movie and it's double digits for the 10 consecutive B-frames stat.

[Boulder]

Something I've noticed while testing --limit-refs and --limit-modes a bit: --no-limit-modes increases the effect of --amp quite a lot, based on what --csv-log-level 2 shows. I'd even say that without --no-limit-modes, it really makes no sense enabling --amp. I don't know if --limit-refs should affect the partition decisions at all, but --limit-refs 1 produced noticably bigger amounts of amp partitions compared to 3 and 0 in this one test of mine.

[Boulder]

Originally Posted by jpsdr

I can see how to add on my mod branch version these features request. I must say that i said to myself at almost the begining that having a log of the the edgeIntensity and brightnessIntensity could be very interesting. And if there is the hysteresis, the current choice also. But had no idea how to add this.

Have you had the chance to look at this (adding AQ-mode and that other SBRC related data to the csv log)? I was thinking of maybe doing some peeking on the code this weekend but as I'm not a coder, it takes time

[jpsdr]

Not realy, and for the very short glimpse i have made, it doesn't seem easy (or my glimpse was bad). And, unfortunately for you, as it's not a feature i'm interesting on, i'm not realy interesting in spending a lot of time for this...

[Boulder]

Originally Posted by jpsdr

Not realy, and for the very short glimpse i have made, it doesn't seem easy (or my glimpse was bad). And, unfortunately for you, as it's not a feature i'm interesting on, i'm not realy interesting in spending a lot of time for this...

Hmm.. I can affect what to write in the csv file, but I cannot figure out how to get the chosen variable value output there

[benwaggoner]

Originally Posted by Boulder

Something I've noticed while testing --limit-refs and --limit-modes a bit: --no-limit-modes increases the effect of --amp quite a lot, based on what --csv-log-level 2 shows. I'd even say that without --no-limit-modes, it really makes no sense enabling --amp. I don't know if --limit-refs should affect the partition decisions at all, but --limit-refs 1 produced noticably bigger amounts of amp partitions compared to 3 and 0 in this one test of mine.

The behavior certainly makes sense. --limit-modes (and --limit-refs) are early-exit optimizations that less aggressively check --amp and --rect opportunities in order really reduce the speed impact of those modes. Those limits mean that amp and rect will mostly get used where they provide a more obvious benefit. In theory (and apparently practice), while you get fewer of those CU types, the ones you'll get are the ones with the biggest benefit, so the speed/quality tradeoff is better.

When trying to juggle a bunch of settings for optimal quality@perf, it's really a combination of things. I'd generally expect an --amp --rect --limit-modes --limit-refs to yield better net results in less time that just using --amp OR --rect with --no-limit-*. Similarly --tskip without --tskip-fast or --tu-inter- and -intra-depth 4 without --limit-tu 4 can slow things down to much. Better to get 75% of the value of the features in 25% of the time than none of the benefits at all.

These all tend to be pretty content specific (high detail, low noise, sharp edges), so leaving them on by default without --limit* options can waste a whole lot of power & time without material benefit for the majority of GOPs.

[LigH]

Attention:

Patches for a "BBAQ" feature with configuration files are being proposed; prepare for their commitment soon™...

[Boulder]

Originally Posted by LigH

Attention:

Patches for a "BBAQ" feature with configuration files are being proposed; prepare for their commitment soon™...

I have to ask - what is BBAQ?

[LigH]

It is related to "Scene Cut Aware QP", could not yet spot an explanation for the acronym though...

File containing scenecut-aware-qp mode, window duration and offsets settings required for the masking. Works only with --pass 2

[vpupkind]

Originally Posted by LigH

It is related to "Scene Cut Aware QP", could not yet spot an explanation for the acronym though...

Bidirectional Boundary Aware Quantization, if I'm not mistaken

[jpsdr]

For those interested, i've made a new build of my mod version.

[LeXXuz]

Originally Posted by jpsdr

For those interested, i've made a new build of my mod version.

Always. And thx for the 8bit version btw.

[James_b]

Hi Guys!
Does anyone know if i get better picture quality whith HEVC than HuffYUV? I think about from a video editor, both set at 100% (lowest compression). This is for max out before Youtube conversion sets in.

Some say VP9 gives better dynamic and colors than AVC but is there something like this in above?

Thank's for any advice!

[xxxxx]

Is there a program I can see the size of the frames in a video?

[excellentswordfight]

Originally Posted by James_b

Hi Guys!
Does anyone know if i get better picture quality whith HEVC than HuffYUV? I think about from a video editor, both set at 100% (lowest compression). This is for max out before Youtube conversion sets in.

Some say VP9 gives better dynamic and colors than AVC but is there something like this in above?

Thank's for any advice!

HuffYUV is a lossless codec, so nothing will get you better picture quality. HEVC in lossless mode can although give you the same at a lower filesize but will be alot slower, but I doubt any NLE have a lossless mode for HEVC implemented.

[jpsdr]

Originally Posted by James_b

Does anyone know if i get better picture quality whith HEVC than HuffYUV?

If you're looking for a lossless codec, HuffYUV is a little old and not always supported, and slow.
Choose UTVideo or MagicYUV, they're the best lossless codec i know, fast and efficient (doesn't mean it doesn't exist others lossless codec even better).

[LigH]

Originally Posted by xxxxx

Is there a program I can see the size of the frames in a video?

Such tools, in general, are called "Bitrate Viewer". Not all of them support every source format, though. And please better learn what a GOP is and why the size of I, P, and B frames differs much more than the quality.

[LigH]

Just committed:

Pushed BBAQ 3 patches to master branch

[LigH]

I need advice ... I have a shell script which is supposed to update my local copy of x265 when an update is available. This used to work flawlessly before. But now a vi opens, trying to create a text file explaining the reason for a merge. So I guess there is a flaw in my git command, and I do not understand the concept of git good enough to tell apart the meaning of many similar terms in the heap of options... How do I avoid asking back? I do not even want to commit anything on the git server, only update my local copy.

#!/bin/sh
git -C /build/x265_git-git fetch -v --progress origin
git -C /build/x265_git-git pull -v --no-rebase --progress origin "${1:-master}"

The desired result is: If I submit a commit hash as parameter to this script, it shall be synced with that specific commit, else it shall be updated to the latest commit of the master branch.
_

PS: Maybe I should try to source /build/media-suite_helper.sh and then try to use do_vcs "https://bitbucket.org/multicoreware/x265_git.git"; but there is also a patch related to cmake library paths with L vs. l, maybe that one interfers.

[LigH]

New upload: x265 3.5+74-1ec26b9f6

[Windows][GCC 12.2.0][32/32XP/64 bit] 8bit+10bit+12bit

News since v3.5+70:

--scenecut-qp-config <file>   File containing scenecut-aware-qp mode, window duration and offsets settings required for the masking. Works only with --pass 2

I guess we need a sample file to know how it works...