x265 HEVC Encoder

[microchip8]

It is certainly an interesting solution. Visually, it looks better as star motion. There isn't discoloration and less banding. I'm waiting for the correction presets and adjust the decoder LAV.
My suggestion tune grain:
--input-csp i422 --input-depth 10 --output-depth 10 --preset veryslow --crf 28 --me sea --aq-mode 0 --no-cutree --ipratio 1.0 --pbratio 1.5 --qpstep 1 --sao --psy-rd 4.0 --psy-rdoq 10.0 --no-rskip
http://i68.tinypic.com/5bpbh0.png
--input-csp i422 --input-depth 10 --output-depth 10 --preset veryslow --crf 28 --me star --aq-mode 0 --no-cutree --ipratio 1.0 --pbratio 1.1 --qpstep 1 --no-sao --psy-rd 4.0 --psy-rdoq 10.0 --no-rskip
http://i66.tinypic.com/207vrt1.png

EDIT: I use codec https://builds.x265.eu/x265-64bit-10bit-2016-11-30.exe
On the codec 10bit of this web page are the other results.
http://msystem.waw.pl/x265/x265-2.1+64-e44b7b5_gcc62.7z
EDIT2: I use decoder LAV http://tmod.nmm-hd.org/LAVFilters/old/LAVFilters-0.68.1-35-av1_test7-git-r3785(ed499ca).7z with MPC-HC
I am not satisfied with the visual quality of the video decoder http://www.videohelp.com/download/LAVFilters-0.68.1-45.exe

why you use --sao on the first but disable it on the second? Why pbratio of 1.5 on the first but 1.1 on the second?

[Jamaika]

There is no reasonable good response.
The problem of the quality of my dissatisfaction relates to frames B.
So for that particular codec visually better for me it was the pbratio 1.5.
From my investigation I found that adding sao will not impair the quality of the video. Only convert film lasts longer.
I couldn't improve sao and pbratio. The film had anyway visually better quality.
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : @L4.1@High
Codec ID : hvc1
Codec ID/Info : High Efficiency Video Coding
Duration : 1 min 2 s
Source duration : 1 min 2 s
Bit rate : 4 278 kb/s
Maximum bit rate : 8 589 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 (29970/1000) FPS
Color space : YUV
Chroma subsampling : 4:2:2
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.069
Stream size : 31.7 MiB (96%)
Source stream size : 33.0 MiB (100%)
Encoded date : UTC 2016-11-30 17:45:01
Tagged date : UTC 2016-11-30 17:45:01
Color range : Full
Color primaries : BT.2020
Transfer characteristics : BT.2020
Matrix coefficients : BT.2020 non-constant

ffmpeg.exe -loglevel verbose -i "yabadu20.avi" -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=rgb:in_range=full:out_color_matrix=bt2020_ncl:out_range=full,format=yuv422p10le -strict -1 - |
x265.exe --y4m --input-csp i422 --input-depth 10 --output-depth 10 --preset veryslow --crf 28 --fps 29.970 --keyint 60 --no-info --no-open-gop --no-hrd --high-tier --me sea --aq-mode 0 --no-cutree --ipratio 1.0
--pbratio 1.5 --qpstep 1 --sao --psy-rd 4.0 --psy-rdoq 10.0 --no-rskip --vbv-bufsize 40000 --vbv-maxrate 40000 --colormatrix bt2020nc --colorprim bt2020 --transfer bt2020-10 --limit-ref 0 --range full --output "x265_422p10le_crf28.h265" -

[microchip8]

it's not a fair comparison, then. You should use exact same options for both, only for the first one --me sea and for the second one --me star. It doesn't matter what you're dissatisfied with since we're comparing the "raw motion estimation" and everything else should be the same to make a fair comparison. Also keep in mind that --sao will blur and smooth and I suspect that is why the first (with --sao enabled) doesn't have such banding like the second with --sao off

[CruNcher]

I am not satisfied with the visual quality of the video decoder http://www.videohelp.com/download/LAVFilters-0.68.1-45.exe

Please specify especially for H.264 or H.265 their shouldn't be virtually any decoding differences

[Jamaika]

it's not a fair comparison, then. You should use exact same options for both, only for the first one --me sea and for the second one --me star. It doesn't matter what you're dissatisfied with since we're comparing the "raw motion estimation" and everything else should be the same to make a fair comparison. Also keep in mind that --sao will blur and smooth and I suspect that is why the first (with --sao enabled) doesn't have such banding like the second with --sao off
What was I thinking?
http://forum.doom9.org/showthread.php?p=1788180#post1788180

[microchip8]

What was I thinking?
http://forum.doom9.org/showthread.php?p=1788180#post1788180

it doesn't matter what you were thinking. As I said, if you fairly want to compare two different MEs, the only thing that should differ is the MEs themselves. No other options should be touched, regardless if you think this or that doesn't look good so let's go tweak a bit but leave the other out

[Jamaika]

Now added the two films with the same parameters with me star and sea. You can see the differences in the pictures sendspace.

[Barough]

x265 v2.1+64-e44b7b50f24c (http://www69.zippyshare.com/v/mUKK5NVp/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[Selur]

Anyone please visualize them!
-> @LigH: see http://forum.doom9.org/showthread.php?p=693742 for diamond, hex, umh, exhaustive
or
diamond, hex: http://www.ijser.org/paper/OVERVIEW-OF-MOTION-ESTIMATION-IN-VIDEO-COMPRESSION.html
star, diamond; http://www.ntu.edu.sg/home/ekkma/1_Publications_files/A%20NEW%20STAR%20SEARCH%20ALGORITHM%20FOR%20FAST%20BLOCK%20MATCHING,%20International%20Workshop%20on%20Very%20Low%20Bit%20Rate%20Video%20Coding%20(VLBV'98),%20Urbana,%20Illinois,%20USA,%208-9%20October%201998,%20pp.%20173%20-%20176..PDF
umh: http://www.cnblogs.com/TaigaCon/p/3788984.html
No clue how to visualize something like sea,... (would probably need some animation or multiple images for an example case)

[LigH]

Knowing that SEA means "Successive Elimination Algorithm", I found some links to scientific papers. It appears to be parallelizable rather easily, having a tree structure.

One brief summary at IEEE Xplore (http://ieeexplore.ieee.org/abstract/document/1367351/).

Possible display: eSilicon Labs HEVC slide, images 79 and 93 of 159 (http://www.slideshare.net/VinayagamMariappan1/video-codecs-62801463)? Links to single images (with descriptions) are below the slide.
_

In general, it will be important to understand that the search for the optimal motion vector will usually start in the neighborhood of the last known motion vector of each (block / macroblock / coding unit ?), assuming a usually continuous linear motion per scene. In case of a next P frame, that would probably be a repeated last P frame MV. In case of a B frame, that would probably be the fraction of the last P frame MV, in relation to its position in between.

[filler56789]

x265.exe v. 2.1+66

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2469269&viewfull=1#post2469269

[Barough]

x265 v2.1+66-b2d360143d96 (http://www2.zippyshare.com/v/lxB6AgDb/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[filler56789]

x265 v. 2.1+69

http://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2469617&viewfull=1#post2469617

[LigH]

x265 2.1+69-c97c64ab8b8e (https://www.mediafire.com/file/p18wa7lm9tdbaiw/x265_2.1+69-c97c64ab8b8e.7z)

As mentioned above: SEA motion search implemented, several fixes and optimizations in addition.

[Majorlag]

x265 is coming together rather well. I have finally decided to switch over from x264,

Only one thing is still bothering me, and it only started recently. x265_2.1+59 seemed to be a great improvement over previous builds in my encodes, but in +59 and +69, the encoding settings show stats-file= location. x265_2.1+36 and below did not seem to show as much detail. I know about the --no-info, but was wondering if there is an option to turn off only stats-file= information from the encodes.

Keep up the Great work.

[LoRd_MuldeR]

I know about the --no-info, but was wondering if there is an option to turn off only stats-file= information from the encodes.

Judging from the code, doesn't look so:
char *x265_param2string(x265_param* p, int padx, int pady)
{
[...]
if (p->rc.rateControlMode == X265_RC_ABR || p->rc.rateControlMode == X265_RC_CRF)
{
[...]
if (p->rc.bStatRead || p->rc.bStatWrite)
s += sprintf(s, " stats-file=%s", p->rc.statFileName);

(If RC mode is either ABR or CRF and if a stats file is read or written, then the stats file location will be logged)

[aymanalz]

What is the general opinion on SAO now? Does it still blur too much, or cause much loss of detail? Is it generally recommended to be used in most cases?

[gnol009]

Hello guys. Here my cmd line settings:

D:\Encode\x264\avs4x26x --x26x-binary x265.exe 2.avs --bitrate 9000 --pass 1 --stats ".stats" --bframes 8 --aq-strength 0.9 --b-intra --no-amp --no-strong-intra-smoothing --no-sao -o NUL 2> pass12.log

D:\Encode\x264\avs4x26x --x26x-binary x265.exe 2.avs --bitrate 9000 --pass 2 --stats ".stats" --preset slower --ctu 32 --no-amp --aq-mode 3 --deblock -3:-3 --cbqpoffs -3 --crqpoffs -3 --aq-strength 0.9 --rd 4 --psy-rd 4.0 --psy-rdoq 10.0 --rc-lookahead 80 --qcomp 0.65 --no-strong-intra-smoothing --no-sao --ipratio 1.3 --pbratio 1.2 -o "T3.hevc" 2> pass22.log

And here media info encode setting:

x265 2.1+69-c97c64ab8b8e:[Windows][GCC 6.2.0][64 bit] 8bit
Encoding settings : cpuid=1050111 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x800 / interlace=0 / total-frames=2129 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / 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=8 / b-adapt=2 / b-pyramid / bframe-bias=35 / rc-lookahead=20 / lookahead-slices=4 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=2 / subme=3 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=5 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=3.00 / psy-rdoq=10.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=-3 / crqpoffs=-3 / rc=abr / bitrate=9000 / qcomp=0.65 / qpstep=4 / stats-write=0 / stats-read=2 / stats-file=.stats / cplxblur=20.0 / qblur=0.5 / ipratio=1.35 / pbratio=1.25 / aq-mode=3 / aq-strength=0.90 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / 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

Does anyone know why media info show rc=abr?

[Boulder]

Because you are doing a 2-pass encode which means ABR.

[Ma]

[...] if there is an option to turn off only stats-file= information from the encodes.

Like LoRd_MuldeR wrote, there isn't, but all OpenSource projects have one super option -- you can change what you want.

If you don't want to modify source code by yourself, you can download modified and compiled version: www.msystem.waw.pl/x265/x265-2.1+69-c97c64a_Win34-no-stats.7z

Inside the archive there is diff file from original sources and Windows binaries compiled by VS 2017 (and GCC 5/6/7 with names x265gccN.exe).

[sneaker_ger]

I don't think it is a good idea. It has the potential to leak personal information, e.g. if your Windows user name equals your real name and the stats file is somewhere in your user directory. Some GUIs might have their working directory there so you wouldn't even notice. I also wonder if it could lead to problems with long path names. I vaguely remember a program crashing when the custom SEI became too long.

Question:
Why stats-read=2? Is there a "1"?

[Ma]

Why stats-read=2? Is there a "1"?

No, it is 0 or 2, see source:
OPT("pass")
{
int pass = x265_clip3(0, 3, atoi(value));
p->rc.bStatWrite = pass & 1;
p->rc.bStatRead = pass & 2;
}

For pass 2 and pass 3 it is '2', for pass 1 and no pass it is '0'.

[x265_Project]

x265 is coming together rather well. I have finally decided to switch over from x264,

Only one thing is still bothering me, and it only started recently. x265_2.1+59 seemed to be a great improvement over previous builds in my encodes, but in +59 and +69, the encoding settings show stats-file= location. x265_2.1+36 and below did not seem to show as much detail. I know about the --no-info, but was wondering if there is an option to turn off only stats-file= information from the encodes.

Keep up the Great work.

Thanks for your feedback. I agree that we shouldn't write the stats file info... it's a potential privacy issue, and it isn't really useful a part of the info. I'll ask the developer who made the last patch to revert this.

Tom

[x265_Project]

Hello guys. Here my cmd line settings:

D:\Encode\x264\avs4x26x --x26x-binary x265.exe 2.avs --bitrate 9000 --pass 1 --stats ".stats" --bframes 8 --aq-strength 0.9 --b-intra --no-amp --no-strong-intra-smoothing --no-sao -o NUL 2> pass12.log

D:\Encode\x264\avs4x26x --x26x-binary x265.exe 2.avs --bitrate 9000 --pass 2 --stats ".stats" --preset slower --ctu 32 --no-amp --aq-mode 3 --deblock -3:-3 --cbqpoffs -3 --crqpoffs -3 --aq-strength 0.9 --rd 4 --psy-rd 4.0 --psy-rdoq 10.0 --rc-lookahead 80 --qcomp 0.65 --no-strong-intra-smoothing --no-sao --ipratio 1.3 --pbratio 1.2 -o "T3.hevc" 2> pass22.log

And here media info encode setting:

x265 2.1+69-c97c64ab8b8e:[Windows][GCC 6.2.0][64 bit] 8bit
Encoding settings : cpuid=1050111 / frame-threads=3 / numa-pools=8 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x800 / interlace=0 / total-frames=2129 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / 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=8 / b-adapt=2 / b-pyramid / bframe-bias=35 / rc-lookahead=20 / lookahead-slices=4 / scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / no-strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=2 / subme=3 / merange=57 / temporal-mvp / weightp / weightb / no-analyze-src-pics / deblock=-3:-3 / no-sao / no-sao-non-deblock / rd=5 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=3.00 / psy-rdoq=10.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=-3 / crqpoffs=-3 / rc=abr / bitrate=9000 / qcomp=0.65 / qpstep=4 / stats-write=0 / stats-read=2 / stats-file=.stats / cplxblur=20.0 / qblur=0.5 / ipratio=1.35 / pbratio=1.25 / aq-mode=3 / aq-strength=0.90 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=255 / 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

Does anyone know why media info show rc=abr?

When you use the --bitrate command, you're engaging x265's ABR (Average Bit Rate) rate control mode, as opposed to constant QP or CRF rate control, which are fundamentally different.

[Selur]

Btw. is it just me or are other users also experiencing problems when trying to multiplex x265 encoded content with mp4box ? (see: https://bitbucket.org/multicoreware/x265/issues/309/mp4box-incompatibility)

[Jamaika]

Btw. is it just me or are other users also experiencing problems when trying to multiplex x265 encoded content with mp4box ? (see: https://bitbucket.org/multicoreware/x265/issues/309/mp4box-incompatibility)
Maybe high time to give yourself a peace of MP4Box.

[Ajvar]

Knowing that SEA means "Successive Elimination Algorithm", I found some links to scientific papers. It appears to be parallelizable rather easily, having a tree structure.

Possible display: eSilicon Labs HEVC slide, images 79 and 93 of 159 (http://www.slideshare.net/VinayagamMariappan1/video-codecs-62801463)? Links to single images (with descriptions) are below the slide.

SEA is "lossless" searching method with "compression".
Exhaustive = 8x8 square = 64 searching points and 196 sp for 14x14.
SEA = 8+9+9 = 26 sp (27 if analize starting pixel in center) while fully covering same 14x14 square. Pretty easy to get once you look at page 79. 3 steps search: 4 pixel long, then 2, then 1.

[LigH]

So it is indeed quite similar to UMH: Progressive precision, narrowing down to the optimum in several passes.
__

P.S.:

I hope I understood them all good enough to display them correctly and comprehensibly... added to the thread Motion Search Method (http://forum.doom9.org/showthread.php?p=1789660#post1789660) (sorry for necro, but there is the optimal place).

[NikosD]

Just a quick bench using latest StaxRip x64 v1.4.0.0 which has x265 v2.1+69 inside, this time in 10bit HEVC.

So, using the default settings of Medium preset on the same source I got these results:

Core i3-4170
494.20s (1.01 fps)

Core i5-2400
524.81s (0.95 fps)

A Haswell Core i3 at 3.7GHz with 8GB DDR3-1600MHz-CL9 which is a 2C/4T CPU (~2C + ~40%) is a little faster than a Sandybridge Core i5 at 3.2GHz (using Turbo) with 12GB DDR3-1333MHz-CL9 which is a 4C/4T CPU, both under the same OS (Win 10 x64 latest) using significantly less power consumption (35W vs 54W measured consuption).

Impressive.

Of course in a few months a new star will be born - AMD RyZen 8C/16T CPU - which according to the yesterday's Live Show using Handbrake, is a tad faster than Broadwell-E Core i7-6900K.

This is even more impressive when you see that RyZen has 95W TDP and the Core i7-6900K has 140W TDP.

[Magik Mark]

Does anyone knows which version of x265 is being used by adobe media encoder 2017?


Sent from my iPhone using Tapatalk

[sneaker_ger]

A Haswell Core i3 at 3.7GHz with 12GB DDR3-1333MHz-CL9 which is a 2C/4T CPU (~2C + ~40%)
40% is probably an over-estimate but AVX 2.0 also plays a big role for x265. It is the combination of higher clock, higher IPC and AVX 2.0 plus the HT making up a bit for 2 less cores.

[sneaker_ger]

Does anyone knows which version of x265 is being used by adobe media encoder 2017?
Do they use x265 at all? "Adobe" is listed as a reference on the Mainconcept website.

[NikosD]

40% is probably an over-estimate but AVX 2.0 also plays a big role for x265. It is the combination of higher clock, higher IPC and AVX 2.0 plus the HT making a bit up for 2 less cores.

Exactly.
This is why I posted the results in order to show the big difference of AVX2.

Your post revealed that I wrote the memory configuration reversed, so I corrected RAM configuration.
The 12GB DDR3-1333MHz is for Sandy of course and 8GB DDR3-1600MHz is for Haswell.

The main question, one of a few important actually, is how come RyZen with half AVX2 speed of Haswell and onwards CPUs can match Broadwell-E in HandBrake ?

I haven't seen the details of the benchmarks used in the live show of RyZen but I think it could be x264 after all.

Or RyZen has some secret weapons.

[nevcairiel]

Or they used open-source software for benchmarks so they could write specifically optimized versions first, they didn't exactly elaborate on any of the numbers, just showed them fully without background. Independent reviews is when it'll be interesting.

PS:
The handbrake demo in AMDs presentation used x264, not x265 (ie. they said the ipod target or something like that, which is h264). Not sure how huge AVX2 is for x264.

[NikosD]

I think their secret lies in this:

"Moreover, AMD claims to have plenty of processing power left on tap, thanks to a host of efficiency tweaks it's dubbed SenseMI (Machine Intelligence). The first is "Pure Power," which is a set of temperature, clock speed, and voltage sensors that promise more efficient power delivery to the CPU. "Precision Boost" takes that information and uses it to adjust the clock speed on-the-fly "without halts or queue drains" in small 25MHz increments.

This ties into "Extended Frequency Range" (XFR), which AMD claims will boost the clock speed of Ryzen outside of the (as yet unspecified) typical range if a user has suitably robust cooling. Those running big air coolers, all-in-one liquid coolers, or full watercooling loops will apparently see a big improvement compared to a stock cooler. The process is entirely automated, so even those without any overclocking skills can gain a performance boost. That said, fully manual overclocking is still supported for power users.

The final two tweaks—"Neural Net Prediction" and "Smart Prefetch"—help to shuffle data through the CPU more effectively. AMD claims there's a "true artificial network" and "learning algorithms" inside Ryzen that are able to predict future decisions, pre-load instructions, and learn application data access patterns in order to improve performance. That's aided by a beefy 4MB of L2 cache and 16MB of L3 cache.

[x265_Project]

Do they use x265 at all?

They don't.

[LigH]

x265 2.1+70-78e1e1354a25 (https://www.mediafire.com/file/2dkjjg82gi2t7wi/x265_2.1+70-78e1e1354a25.7z) – "merge with stable" build; prepare for v2.2 "soon™"!

[Barough]

x265 v2.1+71-e8152da7aa0e (http://www79.zippyshare.com/v/jazWkifH/file.html) (MSYS/MinGW, GCC 6.2.0, 32 & 64bit 8/10/12bit multilib EXEs)

[CruNcher]

llittle oftopic: Anyone found the Bitstream that was used for the Handbrake Transcoding Demo SU talked about making publicly available on AMD.com which destination was best.mp4 ;) ?

[dipje]

Btw. is it just me or are other users also experiencing problems when trying to multiplex x265 encoded content with mp4box ? (see: https://bitbucket.org/multicoreware/x265/issues/309/mp4box-incompatibility)

Did a 10bit 4:2:0 test with the latest LigH build. Works just fine here.

As I read that bug-report page it's likely an interplay between your x265 settings and mp4box having an issue with it. If you use 'normal' command line parameters it appears there is no issue

[Selur]

@dipje: from the issue tracke, the current state is that you can either use '--opt-qp-pps --opt-ref-list-length-pps' or '--repeat-headers' - but not both at the same time - if you want to use MP4Box.
So, yes. Depending on your settings you might never encounter this problem, but that is probably true for most of the bugs in source code out there. :D

[dipje]

Just don't use any of those 3 switches. You have a reason for really wanting them ?

[brumsky]

llittle oftopic: Anyone found the Bitstream that was used for the Handbrake Transcoding Demo SU talked about making publicly available on AMD.com which destination was best.mp4 ;) ?

Sure haven't, they even said we'd be able to download it and to run the test... If you find it please share it!

[Selur]

You have a reason for really wanting them ?
--opt-qp-pps --opt-ref-list-length-pps are enabled by default in newer builds and they give a small compression gain,...

[dipje]

Later than that latest ligh build ? It was the one prepping for 2.2... It was .70, your report is from before that.
Or are they enabled by default if you go towards veryslow or placebo presets or something ?

[Selur]

These two options ( '--opt-qp-pps' and '--opt-ref-list-length-pps') are enabled by default since 2016-10-17 (304116f4cd41bc4fd610d5b16c6f447a50b8df02). :)
(btw. the problem is on a good way to get resolved, see bug tracker)

[filler56789]

What to expect from a team (namely: GPAC) which still refuses to support VC-1 and DTS in the MP4 container?

Only more rationalization, more lame excuses, more lies.

[sneaker_ger]

GPAC refused to accept your VC-1 and DTS patches?

[dipje]

@selur still weird that I don't have any problems at all and according to what you're saying I should have it as well.

[Selur]

@dijpe: Not weird since it also only happens with some sources. A few users of Hybrid mentioned the problem to me and I couldn't reproduce it until one of them shared a sample with me that allowed me to reproduce the issue and share it with the x265&mp4box devs which are now really active. :D
Personally I'm pretty pleased with the general feedback I get as user from those two development teams.