tmpgenc x264 compared to ffmpeg x264

[secondplace]

i've been playing around with tmpgenc and i noticed a significant difference between my ffmpeg files and the tmpgenc files in how the GOP's are filled.

https://image.ibb.co/gV8dmV/tmpgencvsffmpeg.png

i've attached a screenshot to show the difference. the top is ffmpeg and the bottom is tmpgenc.
i also tested this with x264 and results are similar to ffmpeg and far away from tmpgenc.

video is 1920x1080px, 25fps
ffmpeg x264 settings are the following: preset 'very slow', refs 5, keyint 100, keyintmin 51, bitrate 3500k, maxrate 10000k, bufsize 1120k
and VBR 2pass encoding.

i also matched all the ffmpeg x264 settings to the tmpgenc settings. those where: refs 4, subme 9, chroma_qp_offset -4, lookahead_threads 1, bframes 2, b_pyramid 0, weightp 0, nal_hrd vbr
i left 'slices' out since it has to do with the image being split up not the GOP's

i also exported the quantization matrix from tmpgenc and tested it with x264 and ffmpeg but it didn't help either.
by changing the custom quantization matrix in tmpenc the files still turn out like in the screenshot.

i also tested every single setting in the tmpgenc advanced tab to see if i can basically break the output and make it look like ffmpeg but that did not work either.

how does tmpgenc control the GOP's to achieve that result and not have the frames peak as it happens in ffmpeg. it feels like the bits are distributed way more even within the GOP's and not with the high peaks as it happens in ffmpeg. also tmpgenc really seems to consider the maxrate where as ffmpeg seems to ignore it.
also if i split the maxrate and buffer in half to turn the average bitrate into a (fake) max bitrate in ffmpeg it does not give me those results.

how much does the peaking matter in terms of decoding and streaming the videos? is it irrelevant as long the GOP's are are the same size!? my CPU usage at least is identical by playing the files.

does tmpgenc have a custom x264 build to achieve this?

[Taurus]

Please use a filehoster to share your picture.
Attachment approval can take days and a mod has to look over it before it is shown in this thread.
Thank you.
For what it's worth:
Did not know that tmpgenc can encode to x264.
Thought it was a mpeg2 encoder only:confused:.
Maybe you are referring to tmpgenc mastering works or authoring works.
So yes, both programs have some safety belts against overshooting at bitrate spikes,
because for bluray or avchd on dvd it needs some restrictions.
But I'm out, tested this a long time ago, don't know how they manage it today.

[secondplace]

thx for the advice taurus. done!

i was testing their premiere plugin since i don't always want to use a frameserver or output to a lossless codec first, instead go straight to h264.

>both programs have some safety belts against overshooting at bitrate spikes
i can see that. they have a checkbox for 'adjust the stream structure for blue-ray' however, on and off it results same as the screenshot above. and distributes the bitrate evenly.

[Taurus]

If you can upload a small sample, say your 1524 frames, I will take a look at it.
I think in tmpgenc they matched the vbr control to more agressive against vbv maxbitrate and vbv maxbuffersize.
But I can be wrong, just speculating.
Dont know anything about what the guys and girls over at Pegasys are doing.
Cheers

[secondplace]

i found out what caused it.
tmpgenc settings use their own parameter for the buffer (for whatever reason). so when i put in 1120 as i used in ffmpeg it just calculated something completely different in the background. and when i matched the tmpgenc settings to match the ffmpeg buffer it started to look like the ffmpeg output in the screenshot.

after playing around with the settings some more it turns out the way i am calculating the bufsize creates a too high value to keep the spikes below the maxrate. it also has to do with the combination between the bframes and the bufsize. the bframes need to be at 2 (always) and the bufsize around 420 (in this specific case).

i always thought the bufsize is calculated the following way: bitrate*8/framerate
i'll now be using: bitrate*3/framerate
is there something like a correct math for the bufsize?

[poisondeathray]

Bitrate analyzer isn't really the right tool to look at this . It doesn't take into account the current state of buffer at any point in time. You'd need to use a buffer analyzer

eg. you can have an enormous peak, but if it's buffered, it will have no impact on playback . But if you have insufficient buffer, then you can have buffer underrun and playback problems

[secondplace]

Bitrate analyzer isn't really the right tool to look at this . It doesn't take into account the current state of buffer at any point in time. You'd need to use a buffer analyzer

wish i had one. streameye and codevisa are both about 2500$
what software would you suggest instead?