unabled to remove VBV buffer underflow error in x264

[survivant001]

I have a movie that I'm unabled to remove the buffer underflow. I'm playing with the values of keyint, vbv buffer, and still get the warnings.


I been able to get it to work before. I had to change keyint 300 -> 14 and that solve the problem, but it was with --me dia. Now I want it with a better quality.

here my command line (target = PS3)

x264.exe --pass 2 --bitrate 7304 --stats "D:\DVD-convertion\converting\temp
\.stats" --progress --keyint 13 --bframes 3 --qpmin 6 --qpmax 51 --mixed-refs --
trellis 1 --ref 3 --filter 0,0 --subme 6 --direct auto --vbv-bufsize 12000 --vbv
-maxrate 30000 --me dia --level 4.1 --weightb --b-rdo --bime --analyse p8x8,b8x8
,i8x8 --8x8dct --threads auto --thread-input --aud --nal-hrd --sar 1:1 --me-prep
ass --output "D:\DVD-convertion\converting\temp\movie.264" "D:\DVD-convertion\co
nverting\temp\movie.avs"
avis [info]: 1280x720 @ 23.98 fps (109920 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 3DNow!
x264 [warning]: VBV underflow (-88222 bits)fps, eta 1:00:26
x264 [warning]: VBV underflow (-174023 bits)
x264 [warning]: VBV underflow (-300841 bits)
x264 [warning]: VBV underflow (-347007 bits)
x264 [warning]: VBV underflow (-434375 bits)
x264 [warning]: VBV underflow (-335487 bits)
x264 [warning]: VBV underflow (-287279 bits)
x264 [warning]: VBV underflow (-247295 bits)
x264 [warning]: VBV underflow (-190943 bits)
x264 [warning]: VBV underflow (-327135 bits)
x264 [warning]: VBV underflow (-20599 bits)
x264 [warning]: VBV underflow (-151985 bits)ps, eta 0:47:57
x264 [warning]: VBV underflow (-422655 bits)
x264 [warning]: VBV underflow (-450639 bits)
x264 [info]: slice I:9604 Avg QP: 8.45 size:129537 PSNR Mean Y:56.20 U:59.23
V:59.88 Avg:56.94 Global:55.85
x264 [info]: slice P:75994 Avg QP: 9.54 size: 32881 PSNR Mean Y:54.11 U:57.23
V:57.91 Avg:54.89 Global:54.11
x264 [info]: slice B:24322 Avg QP:10.93 size: 17369 PSNR Mean Y:53.37 U:56.39
V:57.10 Avg:54.12 Global:53.21
x264 [info]: mb I I16..4: 38.5% 14.0% 47.5%
x264 [info]: mb P I16..4: 11.7% 3.0% 0.0% P16..4: 36.8% 4.4% 3.3% 0.0% 0
.0% skip:40.7%
x264 [info]: mb B I16..4: 1.9% 0.9% 0.0% B16..8: 24.9% 2.5% 4.4% direct:
3.4% skip:62.0%
x264 [info]: 8x8 transform intra:17.9% inter:21.4%
x264 [info]: direct mvs spatial:95.6% temporal:4.4%
x264 [info]: ref P 88.5% 7.7% 3.8%
x264 [info]: ref B 93.0% 7.0%
x264 [info]: SSIM Mean Y:0.9976536
x264 [info]: PSNR Mean Y:54.127 U:57.215 V:57.902 Avg:54.899 Global:54.018 kb/s:

[Dark Shikari]

Is the x264 version you're using patched with the "2pass VBV" patch? Without it, 2pass doesn't correctly respect VBV restrictions.

[woah!]

--qcomp 0.5 or lower it until you dont get the errors. on some 1080p encodes i do i have to use qcomp 0 to stop the errors but the encode always looks very good.

[Dark Shikari]

--qcomp 0.5 or lower it until you dont get the errors. on some 1080p encodes i do i have to use qcomp 0 to stop the errors but the encode always looks very good.This makes sense, because qcomp raises QP in complex scenes--something that is normally useful to improve overall quality but in VBV mode its even more useful to prevent overflows.

One major note is that a different algorithm (a much more aggressive one) is used to avoid VBV underflows in the case that VBV Maxrate < 2*Average Bitrate.

[Atak_Snajpera]

@Dark Shikari
I have question regarding --keyint. Default value is 250 but Bluray standard forces us to use --keyint 24..25..30 and so on ( for 23.976,25,29.97...) So basically at least every second encoder must put keyframe. My question is: How much do we loose in terms of quality if we don't use default a lot higher value (250) ?

[survivant001]

i'm using x264 build (http://forum.doom9.org/showthread.ph...45#post1095545)

x264_aq_var.48.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.4.MatMaul.diff
http://mailman.videolan.org/pipermai...ry/004015.html
x264_hrd_pulldown.04_interlace.diff
- HRD and pulldown for HD compatibility, updated patch for interlacing
http://forum.doom9.org/showthread.ph...19#post1047919

[Dark Shikari]

@Dark Shikari
I have question regarding --keyint. Default value is 250 but Bluray standard forces us to use --keyint 24..25..30 and so on ( for 23.976,25,29.97...) So basically at least every second encoder must put keyframe. My question is: How much do we loose in terms of quality if we don't use default a lot higher value (250) ?Depends on the source and how you're encoding.

If you're doing full grain retention, you're losing almost nothing. If you're not retaining grain, you could easily be losing 10%, 20%, 50% efficiency or more depending on the source and the scene.

[survivant001]

One major note is that a different algorithm (a much more aggressive one) is used to avoid VBV underflows in the case that VBV Maxrate < 2*Average Bitrate.

but in my case a have bitrate = 7300 (2*7300 = 14600)

I started with vbv max = 26000
now I'm trying vbv max : 35000 and keyint = 13

What is the cause of the underflows ? a error in the code ? just trying to figure which setting to tweak

[Atak_Snajpera]

Depends on the source and how you're encoding.

My settings for PAL movies (mainly 720p) with default AQ
--level 4.1 --sar 1:1 --aud --nal-hrd --vbv-bufsize 9000 --vbv-maxrate 25000 --min-keyint 1 --keyint 25 --filter 0,0 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "video.264"

What do you think?

[survivant001]

I found a previous post from Sagitaire. for 1080p source.

--keyint 14 --min-keyint 2
compatibility with scenarist

--vbv-maxrate 24000 --vbv-bufsize 14745 --qcomp 0.50
better vbv compliancy

--ipratio 1.10 --pbratio 1.10
default value for Iframe is too high for short GOP at 14 and I choose low ratio with rdo drop for high quality bframe (good for grain retention).

is it still accurate for the latest build with all the patch ?

[survivant001]

My settings for PAL movies with default AQ
--level 4.1 --sar 1:1 --aud --nal-hrd --vbv-bufsize 9000 --vbv-maxrate 25000 --min-keyint 1 --keyint 25 --filter 0,0 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "video.264"

What do you think?

and what will happen if you add --me-prepass ?

[Dark Shikari]

and what will happen if you add --me-prepass ?Unrelated... if it affects the problem at all it'll just be pure coincidence.

[survivant001]

Unrelated... if it affects the problem at all it'll just be pure coincidence.

sorry I was out of context. Effectively, it won't fix the underflows. It was more a general question. What will be the result if it's add to the command line of Ajak ?

and what do you think of the Sagitaire comments ? (2 previous posts)

[survivant001]

is it possible to run x264 in a debug mode and give you the log to help you debugging it ?

[Dark Shikari]

is it possible to run x264 in a debug mode and give you the log to help you debugging it ?Use -v commandline option.

[CruNcher]

@Dark Shikari
i experience strange in the middle of the frame blocking (seems to happen on some i-frames only) useing the default settings of your New AQ 0.48 --aq-strength 0.5 --aq-sensitivity 13 in combination with CRF and VBV highering the sensitivity or lowering the strength gets rid of this also useing --aq-sensitivity 0.

http://s4.directupload.net/images/080210/jxuwehhb.png

it looks like the frame want more bits but your aq denies it :(

[Dark Shikari]

@Dark Shikari
i experience strange in the middle of the frame blocking (seems to happen on some i-frames only) useing the default settings of your New AQ 0.48 --aq-strength 0.5 --aq-sensitivity 13 in combination with CRF and VBV highering the sensitivity or lowering the strength gets rid of this also useing --aq-sensitivity 0.I have encountered this also, though it occurs both with and without AQ. I have been working on the 1pass VBV algorithm in an attempt to fix this at least for 1pass purposes.

The reason for this problem that you encountered is likely that VBV attempts to predict the size of frames before encoding them, but ignores the effect of AQ when doing so. Since it is far too aggressive in attempting to change the size of I-frames, it then proceeds to raise the quantizer of the I-frame in the row-based MBRC. However, due to a bug, or should I say an unintended consequence of akupenguin's code (which has been fixed in my patch), it then doesn't lower the quantizer back down.

I am not sure how this extends to 2pass. I would have assumed that 2pass VBV, with pengvado's 2pass VBV patch, wouldn't have the issue.

[survivant001]

Use -v commandline option.

thansk. but How can I output the stdout into a logfile ?

if I try x264.... -v >> log.txt

it doesn't work.. keep printing in the command prompt.

[Dark Shikari]

thansk. but How can I output the stdout into a logfile ?

if I try x264.... -v >> log.txt

it doesn't work.. keep printing in the command prompt.

x264 -v 2> log.txt

[CruNcher]

I see so the problem is a general vbv crf one and yeah without your aq i have the same problems when --threads is forced on 3 instead of being set automatic (or manualy to 2) dunno what this has todo with it but it's really happening :). I also have a little oftop question about your AQ and how it interacts with non default deadzone settings any problems that could occour their known, especialy with low bitrate encoding situations?.

[Dark Shikari]

I see so the problem is a general vbv crf oneWhat appears to be going on is, with or without AQ, Pengvado's code mispredicts the sizes of I-frames... sometimes. The hack I have come up with in my 1-pass VBV patch is to simply avoid running the row-based MBRC on I-frames whenever it is possible to do so. This doesn't address the root problem, but it works.

[CruNcher]

Nasty hack so, but hey if it works visually who cares, you remember me of Radek (the copy & paste genius also known as Syskin) somehow hehe ;) <- that's a compliment

[Dark Shikari]

Nasty hack so, but hey if it works visually who cares, you remember me of Radek (the copy & paste genius also known as Syskin) somehow hehe ;) <- that's a complimentHere's the patch (http://pastebin.com/f4f4d47ea), if you're interested, complete with debug printfs and some not-very-well-tested code. It includes changes for how P, B, and I-frame quants are handled in 1-pass VBV mode (not sure how much applies to other modes) and a change to how quantizers are scaled based on VBV fullness.

[CruNcher]

Thx Dark gonna test it also something else which i think is interesting visually look how the deblocking behaves here :)

standard deblocking
http://s4.directupload.net/images/080210/jxuwehhb.png

no deblocking
http://s5.directupload.net/images/080210/xp2dvmbg.png

i find it strange that it blurs even non blocky areas, don't you too?

could this maybe be the reason why subjectively Atemes H.264 implementation looks sharper? (different adaptive aproach or thresholds maybe?)

Subjectively the bottom looks much better (more near to the Mpeg-2 source) and it gives the whole thing a complete different Look & Feel (the thing i hate the most since moving from ASP and thought wouldn't be possible with H.264 but seeing the Ateme results i was baffeled they look exactly like the bottom just for the whole encode and with better deblocking in those areas that really should be deblocked visually, so in that extreme case the middle area of blocks only :)
Im sure X264 can get to that state very soon with some modifications it really needs those crisper look & feel with good deblocking without destroying the overall source crispness and these results are Main Profile (--partitions p8x8,b8x8,i4x4) you see above. Im sure the result @ the bottom is also thanks to your magnificient AQ doing it's work there, but in combo with deblocking it seems to get destroyed :(

And tough it blurs everything (i thought blurring means data reduction) the size is even bigger then the non deblocked (weired)

[Dark Shikari]

Subjectively the bottom looks much better (more near to the Mpeg-2 source) and it gives the whole thing a complete different Look & Feel (the thing i hate the most since moving from ASP and thought wouldn't be possible with H.264 but seeing the Ateme results i was baffeled they look exactly like the bottom just for the whole encode and with better deblocking in those areas that really should be deblocked visually, so in that extreme case the middle area of blocks only :)
Im sure X264 can get to that state very soon with some modifications it really needs those crisper look & feel with good deblocking without destroying the overall source crispness and these results are Main Profile (--partitions p8x8,b8x8,i4x4) you see above. Im sure the result @ the bottom is also thanks to your magnificient AQ doing it's work there, but in combo with deblocking it seems to get destroyed :(

And tough it blurs everything (i thought blurring means data reduction) the size is even bigger then the non deblocked (weired)Look at the quants... it has absolutely nothing to do with deblocking... :rolleyes:

What's going on is the row-based MBRC is raising the quantizer far too much in the middle of the frame. Simple as that. This is a bug. The deblocking is stronger there because the quantizer is higher. Simple as that.

You have a tendency to analyze problems starting with the wrong assumptions and, not surprisingly, get completely the wrong answers. Grab yourself a stream analyzer.

[CruNcher]

i know it's maybe strange to analyse this (the visual perceptable effect of the inloop deblocker in combination with your AQ) with a bug as the couse, but it works perfectly this way (especialy with the heavy blocking in the middle perfect test example and hard to get (if almost impossible) to get under real conditions) see deblock -2:-2 results in the highest SSIM of 0.9849859 1275.95 kb/s and deblock -3:-3 in the subjectively sharpest result, tough slightly lower SSIM of 0.9846287 1279.62 kb/s


Source (Mpeg-2)
http://s5.directupload.net/images/080211/62l4kfpu.png

standard deblock (lowest SSIM and subjectively worst result)
http://s6.directupload.net/images/080211/axjtv5ug.png

--deblock -2:-2
http://s4.directupload.net/images/080211/6mmol6wl.png

--deblock -3:-3
http://s5.directupload.net/images/080211/975gjon7.png

i don't need a stream analyzer for visually analyzeing stuff ;)
-4:-4, -5:-5 and -6:-6 seem to just waste bits for no real subjective perceptable improvement anymore

[Dark Shikari]

i know it's maybe strange to analyse this with a bug as the couse, but it works perfectly this way (especialy with the heavy blocking in the middle) see deblock -2:-2 results in the highest SSIM of 0.9849859 1275.95 kb/s and deblock -3:-3 in the subjectively sharpest result, tough slightly lower SSIM of 0.9846287 1279.62 kb/s


Source (Mpeg-2)
http://s5.directupload.net/images/080211/62l4kfpu.png

standard deblock (lowest SSIM and subjectively worst result)
http://s6.directupload.net/images/080211/axjtv5ug.png

--deblock -2:-2
http://s4.directupload.net/images/080211/6mmol6wl.png

--deblock -3:-3
http://s5.directupload.net/images/080211/975gjon7.png

i don't need a stream analyzer for visually analyzeing stuff ;)You are analyzing a frame that looks bad because of a bug in x264.

You are trying to compensate for a bug in the code by varying the commandline options. This does not work. Please stop before I start laughing uncontrollably.

(different adaptive aproach or thresholds maybe?)There is no such thing as "adaptive deblocking." H.264 deblocking is a standardized process that must act the same in all decoders and encoders.

[CruNcher]

Atemes Encoder has a deblock matrix as a file that it can use, i beta tested it and i came up with this adaptive deblocking idea to the devs in the beta testing period

# adaptive deblocking offset for P frame
-6, -6, -6, -6, -6, -6,
-6, -6, -6, -6, -6, -6,
-6, -6, -6, -6, -6, -6,
-6, -6, -6, -6, -6, -6,
-6, -5, -5, -4, -4, -3,
-3, -3, -2, -2, -2, -1,
-1, -1, -1, -1, 0, 0,
0, 0, 0, 0, 0, 0,
0, 0, 1, 1

# adaptive deblocking offset for B frame
-6, -6, -6, -6, -6, -6,
-6, -6, -6, -6, -6, -6,
-6, -6, -6, -6, -6, -6,
-6, -6, -6, -6, -6, -6,
-6, -5, -5, -4, -4, -3,
-3, -3, -2, -2, -2, -1,
-1, -1, -1, -1, 0, 0,
0, 0, 0, 0, 0, 0,
0, 0, 1, 1

# adaptive deblocking offset for I frame
-6, -6, -6, -6, -6, -6,
-6, -6, -6, -6, -6, -6,
-6, -6, -6, -6, -6, -6,
-6, -6, -6, -6, -6, -6,
-6, -5, -5, -4, -4, -3,
-3, -3, -2, -2, -2, -1,
-1, -1, -1, -1, 0, 0,
0, 0, 0, 0, 0, 0,
0, 0, 1, 1

[Dark Shikari]

Atemes Encoder has a deblock matrix as a file that it can use, i beta tested it and i came up with this adaptive deblocking idea to the devs in the beta testing periodThere are only three types of adaptive deblocking with H.264:

1. Adaptively choosing the deblocking parameters on a per-frame basis.

2. Adaptively modifying the DCT coefficients to gain maximum benefit from deblocking.

3. Adaptively changing quantizers to change the amount by which a block is deblocked.

The filter itself cannot be changed.

[CruNcher]

Did i say that they changed the filter itself i just said they made it very efficient nothing else and you don't need to belive me but i know what i see.

[Dark Shikari]

i know what i see.Considering your repeated posts confusing a bug in x264's VBV MBRC with a deblocking issue, obviously you don't.

[CruNcher]

Where did i wrote that it's maybe the case in your imagination, i just said that this bug is a very nice example to see the inloop deblocker and it's side effects in action, because it's almost impossible to get such a extreme example (such concentrated blocking in 1 area). And you can really well see how the inloop deblocker affects the sharpness of the entire encode (Look & Feel) i just try to help you with my Visual Experience and give you feedback i gave you the Grain Feedback you did the Grainoptimizer i was there and watched your firsts AQ steps i gave feedback (it made no matter to me even that people warned me as they saw your reactions to that to continue) i just try to help X264 Visual Quality with this not it's Mathematical Efficiency. I can just tell you that what you have achived now with your AQ Ateme Engineers including Laurent Aimar achived almost 2 years ago with their Encoder Visualy, you have no idea. So please stay on the Ground you do great work indeed but please try to be more respectfull.

[Dark Shikari]

I can just tell you that what you have achived now with your AQ Ateme Engineers including Laurent Aimar achived almost 2 years ago with their Encoder Visualy you have no idea.2 years ago? It took them that long?

MPEG-2 encoders have had complexity masks of a similar level for almost a decade, AFAIK. Complexity masking isn't exactly a new idea.

[CruNcher]

Wait my sense of time is a little unsync 3 years ago actually, but anyways i don't see why to further discuss this and spaming this thread with oftopic stuff.
So everyone in the room calm down and concentrate on the important stuff and that would be improving X264 :), i stated my points whether you look into it when you're finished with the other stuff is up to you alone. Peace

[Gabriel_Bouvigne]

vbv underflow:
Right now, VBV level is not tracked when encoding a frame, but only after/before the frame. The more encoding threads, the more concurrent frames, leading to imprecision accumulation.
Reducing the number of encoding threads helps a lot. (but still, unless there is vbv tracking when encoding frames, compliance is just a "best effort").

side note: the 2 pass vbv patch has been slightly updated.

[Dark Shikari]

vbv underflow:
Right now, VBV level is not tracked when encoding a frame, but only after/before the frame. The more encoding threads, the more concurrent frames, leading to imprecision accumulation.
Reducing the number of encoding threads helps a lot. (but still, unless there is vbv tracking when encoding frames, compliance is just a "best effort").

side note: the 2 pass vbv patch has been slightly updated.Incorrect. When VBV maxrate is < 2 * bitrate, the row-based ratecontrol is activated, which tracks VBV after each row of each frame.

[Gabriel_Bouvigne]

Within 2nd pass??

[Dark Shikari]

Within 2nd pass??Apparently not, as I just realized. Oddly enough its 1pass only.

[survivant001]

here are my output log with "-v"

x264 [debug]: frame=83143 QP=23.00 NAL=3 Slice:I Poc:0 I:3600 P:0 SKIP:0 size=213615 bytes SSIM Y:0.99088
x264 [debug]: frame=83144 QP=22.98 NAL=2 Slice:P Poc:2 I:2254 P:1326 SKIP:20 size=198400 bytes SSIM Y:0.99155
x264 [debug]: frame=83145 QP=23.02 NAL=2 Slice:P Poc:4 I:2147 P:1435 SKIP:18 size=200254 bytes SSIM Y:0.99143
x264 [debug]: frame=83146 QP=23.14 NAL=2 Slice:P Poc:6 I:2171 P:1405 SKIP:24 size=198691 bytes SSIM Y:0.99102
x264 [warning]: VBV underflow (-323361 bits)
x264 [debug]: frame=83147 QP=23.04 NAL=2 Slice:P Poc:8 I:2141 P:1426 SKIP:33 size=199462 bytes SSIM Y:0.99124
x264 [warning]: VBV underflow (-277095 bits)
x264 [debug]: frame=83148 QP=24.07 NAL=2 Slice:P Poc:10 I:2321 P:1247 SKIP:32 size=191043 bytes SSIM Y:0.98865
x264 [warning]: VBV underflow (-304455 bits)
x264 [debug]: frame=83149 QP=23.93 NAL=3 Slice:I Poc:0 I:3600 P:0 SKIP:0 size=194463 bytes SSIM Y:0.98849
x264 [warning]: VBV underflow (-293719 bits)
x264 [debug]: frame=83150 QP=22.82 NAL=2 Slice:P Poc:2 I:2564 P:1017 SKIP:19 size=193121 bytes SSIM Y:0.99091
x264 [warning]: VBV underflow (-100023 bits)
x264 [debug]: frame=83151 QP=23.60 NAL=2 Slice:P Poc:4 I:2566 P:1005 SKIP:29 size=168909 bytes SSIM Y:0.98832
x264 [warning]: VBV underflow (-51183 bits)
x264 [debug]: frame=83152 QP=23.53 NAL=2 Slice:P Poc:6 I:2665 P:910 SKIP:25 size=162804 bytes SSIM Y:0.98859
x264 [debug]: frame=83153 QP=23.27 NAL=2 Slice:P Poc:8 I:2770 P:800 SKIP:30 size=154727 bytes SSIM Y:0.98868
x264 [warning]: VBV underflow (-192790 bits)
x264 [debug]: frame=83154 QP=22.39 NAL=3 Slice:I Poc:0 I:3600 P:0 SKIP:0 size=182184 bytes SSIM Y:0.99139

here the complete log
http://www.mediafire.com/?efoxcfj0mem

using this command line

"D:\DVD-tools\tools\AutoMKV095_NORIP\exe\encoder\x264.exe" --pass 2 --bitrate 7304 --stats "D:\DVD-convertion\converting\temp\.stats" --progress --keyint 14 --min-keyint 2 --bframes 3 --qpmin 5 --qpmax 51 --mixed-refs --trellis 1 --ref 3 --filter 0,0 --subme 6 --direct auto --vbv-bufsize 14745 --vbv-maxrate 30000 --me dia --level 4.1 --weightb --b-rdo --bime --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --threads auto --thread-input --aud --nal-hrd --sar 1:1 --me-prepass --qcomp 0.40 --ipratio 1.10 --pbratio 1.10 --no-psnr --output "D:\DVD-convertion\converting\temp\movie.264" "D:\DVD-convertion\converting\temp\movie.avs" -v 2>pass_verbose.txt

[Sharktooth]

--qpmin 5? looking for troubles...

[survivant001]

--qpmin 5? looking for troubles...

is it that the problem ? I try higher values, but didn't fix it, but it was before I add --qcomp 0.50

I can try again..

--qpmin 7 is ok ?

the truth is the command line was generated by automkv, and buzzwq change the default value 10 to 5.

when I first got the bufferunderflows, I had qmin10, but the output target always stop at 3gigs instead of 4 even if I higher the bitrate. I look at the qp and the most important % was at 10, so I lower it to 7 and got a 4 gigs file. but it I fixed the bufferunderflows problem I was using --me dia (for testing).

not I'm trying to get the same thing but with a higher quality --me uhm

any help will be appreciated

[Gabriel_Bouvigne]

I'd say reducing the number of encoding threads will reduce the risk of vbv underflow (but will slow down encoding)

[akupenguin]

Atemes Encoder has a deblock matrix
btw, "matrix" is the wrong name for that. Unlike a quantization matrix, Ateme's thingy is not 2 dimensional. It's a list.
It's not even content-adaptive, they just use a different offset for different qp, so that deblock strength scales faster than quant strength.

[survivant001]

@Gabriel_Bouvigne

I,ll trust you with that.. I'll try a test tonight, but I found it hard to believe it's a thread related problem, but I didn't look into the code, and I'm sure that I won't understand anything :)

so I should try : --threads 1 ?

I have a AMD 6000+ 64 bits (dual core) (if that's something to do with the treading value)

[Gabriel_Bouvigne]

Sure, the "core" of the problem is not thread-related. But 2nd pass RC (when using vbv) will try to recover from errors once a frame is encoded. So when you add threads, you are encoding more frames at once without allowing RC to recover between them. That's just the way it is right now.

[CruNcher]

I see so the problem is a general vbv crf one and yeah without your aq i have the same problems when --threads is forced on 3 instead of being set automatic (or manualy to 2) dunno what this has todo with it but it's really happening :). I also have a little oftop question about your AQ and how it interacts with non default deadzone settings any problems that could occour their known, especialy with low bitrate encoding situations?.

@akupenguin
yeah a list then that doesn't change that they do something visually different here ;)

@Gabriel_Bouvigne
Could this have something todo with this experience of mine or do you think that's pure coincidence??

[Dark Shikari]

"D:\DVD-tools\tools\AutoMKV095_NORIP\exe\encoder\x264.exe" --pass 2 --bitrate 7304 --stats "D:\DVD-convertion\converting\temp\.stats" --progress --keyint 14 --min-keyint 2 --bframes 3 --qpmin 5 --qpmax 51 --mixed-refs --trellis 1 --ref 3 --filter 0,0 --subme 6 --direct auto --vbv-bufsize 14745 --vbv-maxrate 30000 --me dia --level 4.1 --weightb --b-rdo --bime --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --threads auto --thread-input --aud --nal-hrd --sar 1:1 --me-prepass --qcomp 0.40 --ipratio 1.10 --pbratio 1.10 --no-psnr --output "D:\DVD-convertion\converting\temp\movie.264" "D:\DVD-convertion\converting\temp\movie.avs" -v 2>pass_verbose.txt

You're using --me dia with all those slow settings?

Uh... why? :p

[CruNcher]

btw, "matrix" is the wrong name for that. Unlike a quantization matrix, Ateme's thingy is not 2 dimensional. It's a list.
It's not even content-adaptive, they just use a different offset for different qp, so that deblock strength scales faster than quant strength.

I know Aku i came up with this idea and it worked very well visually if correctly tuned,tough this was a long time ago and im not sure if they still use this anymore or something even better (more efficient to make the output resamble the subjective sharpness of the source) now :) (actually im quiet sure they do as the last time i saw an Ateme encode that didn't use -adaptdbk it looked so clear and sharp even without it and standard inloop deblocking settings i was amazed and yes in a average low bitrate situation that normaly would call the inloop deblocker to smooth everything like their is no tommorow what --deblock 0 actually also does in X264 with the sourounding non blocked area of a frame)
Also im sure many users that use Atemes Encoder nowdays can Visually confirm this Sharpness (it's very easy to realize if you compare it with other implementations like mainconcept or are used to this blurry results virtualy every implementation produces with standard deblocking) (even Nero Digital should show it as core 1.4 was allready that improved Visually) :)
My beta testing and Visual improvement sugestions where for core 1.0.x those days (also alot of bugs especialy with b-frames back then :D)

[shon3i]

Also im sure many users that use Atemes Encoder nowdays can Visually confirm this Sharpness (it's very easy to realize if you compare it with other implementations like mainconcept or are used to this blurry results virtualy every implementation produces with standard deblocking) (even Nero Digital should show it as core 1.4 was allready that improved Visually)
My beta testing and Visual improvement sugestions where for core 1.0.x those days (also alot of bugs especialy with b-frames back then )I confirm! I use Ateme and Elecard encoders almost every day. And x264 i use very rarely, i give a new try when new biger improvement out like AQ now, to see what quality i can await.

Elecard's -1:-1 are comparable by sharpnes (with less blocking) like x264's -2:-3 or even -3:-3

Ateme's -2 is very sharp, like source and comparable with elecard's -2:-1, but ateme leave much less blocking than elecard IMHO. Elecard golden mean is -1:-1 or -2.

Ateme -2 is perfect for all footage.

And what to say for x264, realy -2:-2 give much blokness, and -1:-1 are smooth, kill grain, and i can't find middle even with -2:-1 or -1:-2 or other

[survivant001]

"D:\DVD-tools\tools\AutoMKV095_NORIP\exe\encoder\x264.exe" --pass 2 --bitrate 7304 --stats "D:\DVD-convertion\converting\temp\.stats" --progress --keyint 14 --min-keyint 2 --bframes 3 --qpmin 5 --qpmax 51 --mixed-refs --trellis 1 --ref 3 --filter 0,0 --subme 6 --direct auto --vbv-bufsize 14745 --vbv-maxrate 30000 --me dia --level 4.1 --weightb --b-rdo --bime --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --threads auto --thread-input --aud --nal-hrd --sar 1:1 --me-prepass --qcomp 0.40 --ipratio 1.10 --pbratio 1.10 --no-psnr --output "D:\DVD-convertion\converting\temp\movie.264" "D:\DVD-convertion\converting\temp\movie.avs" -v 2>pass_verbose.txt

You're using --me dia with all those slow settings?

Uh... why? :p

not exactly with the same parameters :)

here I working command line

x264.exe --pass 2 --bitrate 7200 --stats ".stats" --progress --keyint 14 --bframes 3 --qpmin 7 --qpmax 51 --mixed-refs --trellis 1 --ref 3 --filter 0,0 --subme 6 --direct auto --vbv-bufsize 12000 --vbv-maxrate 26000 --me dia --level 4.1 --weightb --b-rdo --bime --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --threads auto --thread-input --aud --nal-hrd --sar 1:1 --output "movie.264" "movie.avs"

I'll try with thread 1, keyint 7, qcomp 0.50, qpmin 7

"x264.exe" --pass 2 --bitrate 7304 --stats ".stats" --progress --keyint 14 --min-keyint 2 --bframes 3 --qpmin 7 --qpmax 51 --mixed-refs --trellis 1 --ref 3 --filter 0,0 --subme 6 --direct auto --vbv-bufsize 14745 --vbv-maxrate 30000 --me umh --level 4.1 --weightb --b-rdo --bime --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --threads 1 --thread-input --aud --nal-hrd --sar 1:1 --me-prepass --qcomp 0.50 --ipratio 1.10 --pbratio 1.10 --no-psnr --output "D:\DVD-convertion\converting\temp\movie.264" "D:\DVD-convertion\converting\temp\movie.avs" -v 2>pass_verbose_050.txt


I'll continue to post information. about my tests.

oh ya.. I just finish a pass with qcomp=0.35, with thread auto,qpmin 5 and it failed.

will be information tomorrow..

[survivant001]

we have a winner

"x264.exe" --pass 2 --bitrate 7304 --stats ".stats" --progress --keyint 14 --min-keyint 2 --bframes 3 --qpmin 7 --qpmax 51 --mixed-refs --trellis 1 --ref 3 --filter 0,0 --subme 6 --direct auto --vbv-bufsize 14745 --vbv-maxrate 30000 --me umh --level 4.1 --weightb --b-rdo --bime --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --threads 1 --thread-input --aud --nal-hrd --sar 1:1 --me-prepass --qcomp 0.50 --ipratio 1.10 --pbratio 1.10 --no-psnr --output "D:\DVD-convertion\converting\temp\movie.264" "D:\DVD-convertion\converting\temp\movie.avs" -v 2>pass_verbose_050.txt

[Atak_Snajpera]

Why are you so happy ? ( --threads 1 --keyint 14 --min-keyint 2 ... )

[survivant001]

@Atak_Snajpera

why.. because I been able to get it to work. That was the first step.. after that is to be able to get it to work with settings that are more meanfull.

Now I'm trying a test with keyint 24
.

if the vbv buffer can be avoid just by using 1 thread, I'll stick to that until the bug is fix.

I don't need speed, just reability.. I start the encoding at night.. and I'm working all day.. so if I takes 12 hours instead of 8.. fine with me. I just don't want to reencode the movie twice.

and I didn't try to mux it with Scenarist.. will try that later.. hope that all the settings doesn't break the compatibility.

[shon3i]

Why are you so happy ? ( --threads 1 --keyint 14 --min-keyint 2 ... )
--keyint 18 --min-keyint 1 are safer and better compatability with scenarist and hw standalone's.

[Atak_Snajpera]

--level 4.1 --sar 1:1 --aud --nal-hrd --vbv-bufsize 14000 --vbv-maxrate 25000 --filter 0,0 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "video.264"

+ TSRemux BluRay Structure and PS3 plays without any problem. Tested with high bitrates in 1920x1080 :)

[tymoxa]

shon3i
Can you (please) provide an "Ateme digital encoder" profile for Blu-Ray?

[shon3i]

shon3i
Can you (please) provide an "Ateme digital encoder" profile for Blu-Ray?
Here :) (http://tom.niko.users.sbb.co.yu/BluRay.cfx)

[survivant001]

--level 4.1 --sar 1:1 --aud --nal-hrd --vbv-bufsize 14000 --vbv-maxrate 25000 --filter 0,0 --ref 3 --mixed-refs --bframes 3 --b-rdo --bime --weightb --direct auto --subme 6 --trellis 1 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "video.264"

+ TSRemux BluRay Structure and PS3 plays without any problem. Tested with high bitrates in 1920x1080 :)

but your command line doesn't always work :)

ok.. I did a new test.. keyint 25 and it pass.. I 'll use your command line, but with thread 1, if that pass... the problem will be confirm to be in x264 (threading problem)

[survivant001]

with 1 thread.. I been able to encode my movie without error. and no tweaking

"x264.exe" --pass 2 --bitrate 7304 --stats ".stats" --progress --bframes 3 --qpmin 7 --qpmax 51 --mixed-refs --trellis 1 --ref 3 --filter 0,0 --subme 6 --direct auto --vbv-bufsize 14745 --vbv-maxrate 26000 --me umh --level 4.1 --weightb --b-rdo --bime --analyse p8x8,b8x8,i4x4,i8x8 -
-8x8dct --threads 1 --thread-input --aud --nal-hrd --sar 1:1 --me-prepass --output "movie.264" "movie.avs"
avis [info]: 1280x720 @ 23.98 fps (109920 frames)
x264 [info]: using SAR=1/1
x264 [info]: using cpu capabilities: MMX MMXEXT SSE SSE2 SSE3 3DNow!
x264 [info]: slice I:1496 Avg QP: 7.79 size:122392 PSNR Mean Y:60.39 U:63.96
V:64.73 Avg:61.15 Global:59.44
x264 [info]: slice P:82354 Avg QP: 8.19 size: 41625 PSNR Mean Y:55.95 U:58.52
V:59.12 Avg:56.61 Global:54.73
x264 [info]: slice B:26070 Avg QP: 9.25 size: 21212 PSNR Mean Y:54.60 U:57.29
V:57.91 Avg:55.28 Global:54.37
x264 [info]: mb I I16..4: 39.6% 3.5% 57.0%
x264 [info]: mb P I16..4: 9.5% 1.1% 4.5% P16..4: 44.2% 3.8% 3.3% 0.0% 0
.0% skip:33.7%
x264 [info]: mb B I16..4: 1.3% 0.2% 1.4% B16..8: 21.7% 2.2% 3.9% direct:
2.9% skip:66.4%
x264 [info]: 8x8 transform intra:6.7% inter:17.6%
x264 [info]: direct mvs spatial:96.4% temporal:3.6%
x264 [info]: ref P 89.6% 6.6% 3.8%
x264 [info]: ref B 91.7% 8.3%
x264 [info]: SSIM Mean Y:0.9981233
x264 [info]: PSNR Mean Y:55.686 U:58.306 V:58.912 Avg:56.356 Global:54.684 kb/s:
7266.26

encoded 109920 frames, 3.44 fps, 7270.29 kb/s

[Atak_Snajpera]

Mission accomplished survivant001 :)

3.44 fps for one core ... Nice! Let me guess you have CPU@3GHz?

[survivant001]

don't laugh.. :)

I have a AMD 6000+ 64 bit on XP64bit

at first, I used a command line --qcomp 0.50 --ipratio 1.10 --pbratio 1.10.. (it was by error.. I wanted to use the smallest command line possible).. I did 1.9fps with theses setting.. I tough that x264 was stalled.

I hope that we will have a vbv patch for more than 1 thread..

the truth, I,ll continue to use --thread auto.. and when I'll obtain VBV underflow, I will start again with --thread 1

it's the best compromise

[Atak_Snajpera]

and when I'll obtain VBV underflow, I will start again with --thread 1

Is this a problem? Does your PS3 refuse to play movies with that error?

[survivant001]

with a buffer underflow error, I won't be able to mux it in Scenarist or Encore CS3.

I'm confident that it will play if I use tsmuxer. but what I want is to be able to add chapters and subtitle. that'w why I wil use Scenarist and create a AVCHD. (not sure if I can put substitle and chapters in a m2ts without the avchd..just the movie.m2ts file)

[jphan]

whenever I transcoding HD Mpeg files to x264 files with CLI, There is no vbv uderflows in x264 Cli encoder. But if I see these files with Elecard buffer analyser, There are so many bufferunderflows.
What is the main reason?

any help will be appreciated.

[Sagittaire]

whenever I transcoding HD Mpeg files to x264 files with CLI, There is no vbv uderflows in x264 Cli encoder. But if I see these files with Elecard buffer analyser, There are so many bufferunderflows.
What is the main reason?

any help will be appreciated.


- you use crf mode
- you use AQ from Dark Shikari patch
- you use average bitrate close to max bitrate with high qcomp

... etc etc

[jphan]

I did not use crf. and using r721 with AQ_RDRC_0.45 patch + x264_hrd_pulldown.04 (mp4 output, pthreads)-downed at http://www.mediafire.com/?brjqdtu1zy4

--bitrate 5000 --progress --keyint 15 --bframes 3 --qpmin 9 --qpmax 48 --no-psnr no-ssim merange 32 --mixed-refs --trellis 2 --ref 4 --filter 0,0 --subme 7 --direct auto --vbv-bufsize 5000 --vbv-maxrate 5000 --me umh --level 4.1 --weightb --b-rdo --bime --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --threads auto --thread-input --aud --nal-hrd --qcomp 0.0 --mvrange 512 --ipratio 1.8 --pbratio 1.2 --scenecut -1 --ratetol 0.0


I want to make streamable cbr files for STB network.

[survivant001]

try with thread 1 that fix my problem

[jphan]

I read about "tread" to solve the "underflow". I am using penryn 4core. The transcoding speed will be down. The main problem is that There is no vbv uderflows during transcoding with x264 Cli encoder. But There are so many buffer underflows, If I see that file with elecard buffer analyser.

Is there any difference beween two mechanism of analysing?

[Dark Shikari]

I read about "tread" to solve the "underflow". I am using penryn 4core. The transcoding speed will be down. The main problem is that There is no vbv uderflows during transcoding with x264 Cli encoder. But There are so many buffer underflows, If I see that file with elecard buffer analyser.

Is there any difference beween two mechanism of analysing?Are you sure the Elecard buffer analyzer is using the same buffer size, the same initial buffer occupancy, and the same maxrate?

[jphan]

Shikari....I am sure......

[asarian]

While encoding "The Matrix" (HD DVD, RipBot264), I keep seeing errors like these:

[x264] Warning: VBV underflow (-129124 bits)

So, are these Video Buffer Verifier errors serious? I mean, should I abort the encoding and change a setting? I was told I can pretty much ignore this warning. So, I'll do that.

Still, I wonder whether there's something I can do to avoid it? Seems like it's running out of bitrate somewhere (which, presumably, goes at the expense of quality, right?). I use CQ and a CRF of 18. I also thought you couldn't set a max bitrate of CRF, but then again, I'm very new to all of this, so maybe there's a setting I can crank up anyway. :)

[Dark Shikari]

While encoding "The Matrix" (HD DVD, RipBot264), I keep seeing errors like these:

[x264] Warning: VBV underflow (-129124 bits)

So, are these Video Buffer Verifier errors serious? I mean, should I abort the encoding and change a setting? I was told I can pretty much ignore this warning. So, I'll do that.

Still, I wonder whether there's something I can do to avoid it? Seems like it's running out of bitrate somewhere (which, presumably, goes at the expense of quality, right?). I use CQ and a CRF of 18. I also thought you couldn't set a max bitrate of CRF, but then again, I'm very new to all of this, so maybe there's a setting I can crank up anyway. :)VBV is far more effective and accurate in 2pass mode. If you need to use VBV, I strongly recommend 2pass instead of CRF.

[asarian]

VBV is far more effective and accurate in 2pass mode. If you need to use VBV, I strongly recommend 2pass instead of CRF.

Thanks for your answer.

Well, I don't 'need' VBV per se, it just comes with the way RipBot264 does things when I use CQ and CRF 18. :)

Pardon my daftness in the matter, but I thought CRF would give me the best quality, as opposed to 2-pass; right?

See, what I'd like is the very best quality (as I'm converting VC-1 -> AVC, to make it streamable on my PS3). So, I don't mind filesize. But I still like to get rid over the underflow errors.

So, is there a 2-pass configuration that you can recommend that will give me the same quality as CRF = 18? Or is that simply not achievable?

Thanks.

[Dark Shikari]

Pardon my daftness in the matter, but I thought CRF would give me the best quality, as opposed to 2-pass; right?No, they're basically equivalent.
See, what I'd like is the very best quality (as I'm converting VC-1 -> AVC, to make it streamable on my PS3). So, I don't mind filesize. But I still like to get rid over the underflow errors.

So, is there a 2-pass configuration that you can recommend that will give me the same quality as CRF = 18? Or is that simply not achievable?

Thanks.For streaming, just pick a nice high bitrate and a max bitrate/bufsize that goes with your playback device.