Ugly fades.

[shon3i]

I never saw that ugly fades in x264. I use buld 1046 from MeGUI Auto Updater and these settings

--pass 2 --bitrate 5381 --stats ".stats" --level 4 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 3 --b-adapt 2 --weightb --direct auto --deblock -3:-3 --subme 9 --trellis 2 --psy-rd 1.0:1.0 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 8000 --vbv-maxrate 15000 --me umh --merange 32 --threads 6 --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input" --sar 1:1 --mvrange 511 --aud --nal-hrd without turbo activated.

Source

http://thumbnails3.imagebam.com/2066/a621d020651005.gif (http://www.imagebam.com/image/a621d020651005)

x264

http://thumbnails6.imagebam.com/2066/a927e420651006.gif (http://www.imagebam.com/image/a927e420651006)

I aslo tryed to use zone at begining with quantizer @ 10 but not helped much

Source is Austin Powers 2 Blu-ray, target 1080p BD5 :)

[Atak_Snajpera]

Why do you use maxbitarte 15000? Level 4.0 allows 25000! What happens if you remove --keyint 24 --min-keyint 1 ?

[shon3i]

Why do you use maxbitarte 15000? Level 4.0 allows 25000! What happens if you remove --keyint 24 --min-keyint 1 ?
Why do you use maxbitarte 15000? Level 4.0 allows 25000!Because i follow BD (BD-5) standard and not H264 :) anyway there is no point for higher max bitrate or buffer.

http://thumbnails13.imagebam.com/2066/236c6820651721.gif (http://www.imagebam.com/image/236c6820651721)

What happens if you remove --keyint 24 --min-keyint 1 I will test soon, thanks for suggestion.

btw i just finished encoding same scene with MC encoder, and no problems :)

[Dark Shikari]

Post an output stream.

Also, does the problem disappear if you don't use threads, or if you use this build (http://www.mediafire.com/download.php?cugmzznrmzz)?

[Terranigma]

I only noticed artifacts like the one you mentioned, shon3i, when I used vbv on a source before. try without vbv.

[Sagittaire]

I never saw that ugly fades in x264. I use buld 1046 from MeGUI Auto Updater and these settings

without turbo activated.

Source

http://thumbnails3.imagebam.com/2066/a621d020651005.gif (http://www.imagebam.com/image/a621d020651005)

x264

http://thumbnails6.imagebam.com/2066/a927e420651006.gif (http://www.imagebam.com/image/a927e420651006)

I aslo tryed to use zone at begining with quantizer @ 10 but not helped much

Source is Austin Powers 2 Blu-ray, target 1080p BD5 :)


Well fade is particular part for H264 ...

Try without --b-adapt 2 or --weightb. Fade is really particular problem for x264.

[Dark Shikari]

Well fade is particular part for H264 ...

Try without --b-adapt 2 or --weightb. Fade is really particular problem for x264.B-adapt 2 and weightb improve fades, not make them worse.

The problem here has nothing to do with H.264 or x264 in general, or even fades in general, but rather just that the frame quantizer is being shot up to QP51 by something (probably VBV).

[Sagittaire]

B-adapt 2 and weightb improve fades, not make them worse.


Well certainely bitrate efficiency but certainely not for the quality. All the other H264 encoder make history better job for fade (Ateme for exemple) with native WPred support for Pframe. For my BD encoding I must often use zone option for improve bitrate in fade part.

[Dark Shikari]

Well certainely bitrate efficiency but certainely not for the quality.Higher bitrate efficiency inherently means higher quality, if anything due to the fact that qcomp will lower quality more in the highest bitrate areas.All the other H264 encoder make history better job for fade (Ateme for exemple) with native WPred support for Pframe.All other H.264 encoders? Not in my experience, remember, almost all H.264 encoders suck. Though certainly one would expect the ones that make proper use of weighted P-frame prediction to do better.For my BD encoding I must often use zone option for improve bitrate in fade part.You could just set qcomp to 1.0 instead.

[shon3i]

Post an output stream.Here is (http://srbokuz.users.sbb.co.yu/vbv/chapter-0291.264)

but rather just that the frame quantizer is being shot up to QP51 by something (probably VBV). Yes it is VBV :( when is disabled fade is normal. What to do?? I mean i must use VBV, i aslo tryed to change to -vbv-buffersize 30000 -vbv-maxrate 33000 (by original Blu-Ray specs) to saw what should except from some normal values, and thig is same :(

[Terranigma]

I knew I was right.. and Sagittaire, blocking in fades really isn't a problem anymore, and if so, one could always opt to use a cqm, but you can see that I haven't even recommended that to him. The only time to use a cqm for fading, is if one chooses to use noob settings.

[Sagittaire]

Here is (http://srbokuz.users.sbb.co.yu/vbv/chapter-0291.264)

Yes it is VBV :( when is disabled fade is normal. What to do?? I mean i must use VBV, i aslo tryed to change to -vbv-buffersize 30000 -vbv-maxrate 33000 (by original Blu-Ray specs) to saw what should except from some normal values, and thig is same :(

Try with crf mode ...

[Fishman0919]

Wouldn't the Max bitrate for BD-5 be around 30000?

The max data transfer rate for DVD is about 11000. BD-5 has a spin speed of 3x's... so max would/should be about 33000.... account for audio.... about 30000

[Dark Shikari]

Yes it is VBV :( when is disabled fade is normal. What to do?? I mean i must use VBV, i aslo tryed to change to -vbv-buffersize 30000 -vbv-maxrate 33000 (by original Blu-Ray specs) to saw what should except from some normal values, and thig is same :(Did you follow my instructions and try both without threads, and with threads+the build I posted for you?

[shon3i]

Try with crf mode ...
Not helped :( only solution i found is to encode this first 300 frames with Mainconcept Encoder, and whole chapter now look good.

@Dark Shikari, can you do something about this? I remember when elecard encoder haved same issue in some of first versions of converter studio, and i reported it to Mutek, and they are soloved very quickly :)

[Blue_MiSfit]

I smell something familiar here...

[shon3i]

Did you follow my instructions and try both without threads, and with threads+the build I posted for you?
I tryed without --threads 6 option and leave on default, but is same ugly fade. I didnt tryed with you build because don't contain hrd-nal patch :)

[Dark Shikari]

I tryed without --threads 6 option and leave on default, but is same ugly fade. I didnt tryed with you build because don't contain hrd-nal patch :)What does the NAL-HRD patch have to do with anything? It has nothing to do with the actual encoding process, and certainly nothing to do with VBV. Again, I told you to test that build: that means you should test it, not complain about why you can't when you obviously can.

Also, if it turns out that build doesn't fix the problem, I'm going to need from you the smallest possible source segment and associated x264 build and x264 settings that replicate the problem.

[shon3i]

I can't do anything if you ignore every single post I make in this thread. I am less inclined to care about peoples' encoding problems if they refuse to read my posts when I'm trying to solve the problem.
I don't get it, it works with you build and --threads 6 :D, Sorry for ignoring you post :)

What does the NAL-HRD patch have to do with anything? I need it for BD compatability. I know that nal-hrd don't have anything in encoding, but VBV without NAL is usless

[Dark Shikari]

I don't get it, it works with you build and --threads 6 :D, Sorry for ignoring you post :)It works? As in, there is no VBV issue, and all problems are solved?

[LoRd_MuldeR]

I don't get it, it works with you build and --threads 6 :D, Sorry for ignoring you post :)

Obviously he included a fix in his build that is not in the official git yet and he asked you to test it in order to see whether it helps or not ...

[shon3i]

It works? As in, there is no VBV issue, and all problems are solved?
Correct, so how much i have wait to get new build nal-hdr patched :D

[Dark Shikari]

Correct, so how much i have wait to get new build nal-hdr patched :DSo it is that problem... I'm psychic, eh? :D

So, the problem here is that while I have a fix for the problem, it's a bit of a hack and not a fix for the actual underlying problem. But it works, so... :sly:

here's your build (http://www.mediafire.com/?3nozdw0ozn1).

[shon3i]

Thanks :)

btw here is problematic source clip if you need future testings

Source (VC-1) (http://srbokuz.users.sbb.co.yu/vbv/source.mkv)

[MasterNobody]

Dark Shikari
As I understand this bug is coursed by the misprediction of frame size (probably B-frames) in VBV (in function predict_size) so that predicted size becomes greater than vbv-bufsize. But I didn't find any good solution to fix this misprediction.

[Dark Shikari]

Dark Shikari
As I understand this bug is coursed by the misprediction of frame size (probably B-frames) in VBV (in function predict_size) so that predicted size becomes greater than vbv-bufsize. But I didn't find any good solution to fix this misprediction.Yes, I know that. A fix will go in soon.

[CruNcher]

so if that issues now gets fixed X264 VBV would be finally once for all stable also with multithreading (it seems somehow to be the last issue from all the reports) ?

[asarian]

Odd. I reencoded this Blu-Ray too, and got worried after reading this thread. Turns out 'x264 core:65 r1028M', which I used on my Vmware machine, did a perfect job. However, it seems 'x264 core:65 r1029M', which I use on my desktop machine, produces the same ugly fade.

I wouldn't even presume to guess what might cause it, but I just thought I let the powers that be know.

[Dark Shikari]

Odd. I reencoded this Blu-Ray too, and got worried after reading this thread. Turns out 'x264 core:65 r1028M', which I used on my Vmware machine, did a perfect job. However, it seems 'x264 core:65 r1029M', which I use on my desktop machine, produces the same ugly fade.There was no change that could have affected things in either of those revisions: I suspect the "M" might have more to do with it...

[asarian]

There was no change that could have affected things in either of those revisions: I suspect the "M" might have more to do with it...

I don't understand, they're both "M", right? (though, granted, I have no idea what the M stands for). The reencoded Blu-Ray is fine, but the sample posted here, which I tried with r1029M is messed up too.

[Dark Shikari]

I don't understand, they're both "M", right?M means modified, meaning that it isn't an official build and anything one could possibly imagine could have been done to it between the official source code and you.

[asarian]

M means modified, meaning that it isn't an official build and anything one could possibly imagine could have been done to it between the official source code and you.

Okay, thanks for explaining. These x264 versions came with RipBot264.

[LoRd_MuldeR]

Okay, thanks for explaining. These x264 versions came with RipBot264.

Try to reproduce the behavior with "unpatched" builds from here:
http://x264.nl/x264/

[asarian]

Try to reproduce the behavior with "unpatched" builds from here:
http://x264.nl/x264/

revision1057 produces the exact same, faulty rendering (tested inside RipBot264).

I'm nonetheless very confused now, because when I try and reencode the same sample, using 'x264 core:65 r1028M' again. on my desktop now, I get the same messed-up result. That's quite bewildering, of course. So, I'll have to examine my Vmware machine now (which also has 'x264 core:65 r1028M') to see what could be possibly different in that environment (maybe different ffdshow version?).

This is gonna take a bit of sorting out. Because the Blu-Ray I encoded on my Vmware machine definitely did a flawless fade. So, I'm kinda baffled.

[LoRd_MuldeR]

revision1057 produces the exact same, faulty rendering (tested inside RipBot264).

I'm nonetheless very confused now, because when I try and reencode the same sample, using 'x264 core:65 r1028M' again. on my desktop now, I get the same messed-up result. That's quite bewildering, of course. So, I'll have to examine my Vmware machine now (which also has 'x264 core:65 r1028M') to see what could be possibly different in that environment (maybe different ffdshow version?).

This is gonna take a bit of sorting out. Because the Blu-Ray I encoded on my Vmware machine definitely did a flawless fade. So, I'm kinda baffled.

Before you do any more encoding tests, make sure that the problem isn't in the source you feed into x264. Especially make sure the problem is not on the decoder side!

Also: Did you use 100% identical x264 parameters for your tests? You probably can't reproduce certain behavior if params have changed...

[asarian]

Before you do any more encoding tests, make sure that the problem isn't in the source you feed into x264. Especially make sure the problem is not on the decoder side!

Also: Did you use 100% identical x264 parameters for your tests? You probably can't reproduce certain behavior if params have changed...

For the original source I used the Blu-Ray I encoded myself (which went perfectly); it seems to go wrong on the sample.mkv posted above. I assume that's also a sample from the same Blu-Ray, but I may just wind up clipping that scene myself again.

Yes, I use the same x264 parameters:

--crf 16 --sar 1:1 --level 4.1 --aud --nal-hrd --vbv-bufsize 35000 --vbv-maxrate 35000 --filter 0,0 --ref 3 --b-pyramid --mixed-refs --bframes 3 --b-adapt 2 --weightb --no-fast-pskip --direct auto --subme 9 --trellis 1 --partitions all --8x8dct --me tesa --threads auto --thread-input --progress --no-psnr --no-ssim

Sans the --nal-hrd for the unpatched version.

[nm]

Yes, I use the same x264 parameters:

--crf 16 --sar 1:1 --level 4.1 --aud --nal-hrd --vbv-bufsize 35000 --vbv-maxrate 35000 --filter 0,0 --ref 3 --b-pyramid --mixed-refs --bframes 3 --b-adapt 2 --weightb --no-fast-pskip --direct auto --subme 9 --trellis 1 --partitions all --8x8dct --me tesa --threads auto --thread-input --progress --no-psnr --no-ssim
Do both environments have the same number of processors/cores and does x264 use the same number of threads in both cases? Threading may very well trigger the problem, so you should try setting the number of threads to 1 manually and then try 2 or 3 to see if there is a difference.

[Dark Shikari]

Do both environments have the same number of processors/cores and does x264 use the same number of threads in both cases? Threading may very well trigger the problem, so you should try setting the number of threads to 1 manually and then try 2 or 3 to see if there is a difference.Also note that VBV problems can in fact be nondeterministic with threads...

[shon3i]

@asarian, did you try with Dark Shikari modified build? http://www.mediafire.com/?3nozdw0ozn1, at least helped to me :) but with this buld i have little different problem :) now. I tryed to encode Austin Powers 1 BD and i get big undersize :) target size 4.2GB, i get 3.3GB with this build. I reencode with lastest 1057 form MeGUI, and i get prefered size??

[Gabriel_Bouvigne]

This is gonna take a bit of sorting out. Because the Blu-Ray I encoded on my Vmware machine definitely did a flawless fade. So, I'm kinda baffled.
It is likely because the number of threads used is lower within VMWare. The more threads, the more likely this problem will occur.

If you want to check it, you could explicitly specify the number of threads (--threads xxx instead of --threads auto)

[asarian]

Do both environments have the same number of processors/cores and does x264 use the same number of threads in both cases? Threading may very well trigger the problem, so you should try setting the number of threads to 1 manually and then try 2 or 3 to see if there is a difference.

Good call. :) No, the XP Vmware box only has 2 vCPU's, as opposed to my desktop machine, which has a quadcore.

And indeed, as you predicted, setting threads up to 4 on the quadcore makes the issue go away; but above that, like 5 or 6, and the problem returned again.

[asarian]

@asarian, did you try with Dark Shikari modified build? http://www.mediafire.com/?3nozdw0ozn1, at least helped to me :) but with this buld i have little different problem :) now. I tryed to encode Austin Powers 1 BD and i get big undersize :) target size 4.2GB, i get 3.3GB with this build. I reencode with lastest 1057 form MeGUI, and i get prefered size??

Yep, using 'x264 core:65 r1051+1' solves the issue! :) It doesn't have the built-in nal-hrd patch, but since I stream my reencoded discs from a media server anyway, I might as well do without it.

And thanks, Dark Shikari for the quick fix; you're the man! :)

EDIT: Actually, 'x264 core:65 r1051+1' does have the nal-hrd patch; so, even better. :)

[asarian]

@asarian, did you try with Dark Shikari modified build? http://www.mediafire.com/?3nozdw0ozn1, at least helped to me :) but with this buld i have little different problem :) now. I tryed to encode Austin Powers 1 BD and i get big undersize :) target size 4.2GB, i get 3.3GB with this build. I reencode with lastest 1057 form MeGUI, and i get prefered size??

Okay, pending this latest issue you report, I'll hold off on doing any major jobs with this version until we get word from Dark Shikari that it's safe.

[moviefan]

I have the same problem with a really ugly fade-in from black... The picture is completely messed up, extremely blocky, no details at all. Is there a way to encode the fade-in better?

[asarian]

I have the same problem with a really ugly fade-in from black... The picture is completely messed up, extremely blocky, no details at all. Is there a way to encode the fade-in better?

Regret to say, x264.1069M still has the same issue.

It was solved (with a makeshift solution) in a custom x264.1057M Dark Shikari posted, but apparently this change hasn't made it to the latest x264 version, it seems.

[moviefan]

Dark Shikari's patched x264 does not work for me. The fade scene still lacks a lot of detail, is blocky and looks ugly... Even using zones, I am not able to achieve a good looking picture. Any suggestions?

[nm]

Dark Shikari's patched x264 does not work for me. The fade scene still lacks a lot of detail, is blocky and looks ugly... Even using zones, I am not able to achieve a good looking picture. Any suggestions?Post a sample clip and encoding parameters so that we can duplicate the problem.

[moviefan]

sample clip: http://www.mediafire.com/?sharekey=508d6798bcda1276d2db6fb9a8902bda

My x264 settings are:

"path to x264.exe\x264.exe" --threads auto --thread-input --progress --no-psnr --no-ssim "%IN_TITLE%.AVS" --stats "%IN_TITLE%.stats" --output NUL --pass 1 --bitrate %IN_BITRATE% --vbv-bufsize 30000 --vbv-maxrate 24000 --level 4.1 --keyint 24 --min-keyint 1 --nal-hrd --aud --sar 1:1 --bframes 3 --b-adapt 2 --b-pyramid --weightb --ref 3 --mixed-refs --no-fast-pskip --ipratio 1.2 --pbratio 1.2 --direct auto --subme 2 --trellis 2 --psy-rd 0.8:0.8 --partitions none --me dia --merange 24 --mvrange 511 --aq-strength 1.0

"path to x264.exe\x264.exe" --threads auto --thread-input --progress --no-psnr --no-ssim "%IN_TITLE%.AVS" --stats "%IN_TITLE%.stats" --output "%IN_TITLE%.264" --pass 2 --bitrate %IN_BITRATE% --vbv-bufsize 30000 --vbv-maxrate 24000 --level 4.1 --keyint 24 --min-keyint 1 --nal-hrd --aud --sar 1:1 --bframes 3 --b-pyramid --weightb --ref 3 --mixed-refs --no-fast-pskip --ipratio 1.2 --pbratio 1.2 --direct auto --subme 9 --trellis 2 --psy-rd 0.8:0.8 --partitions all --8x8dct --me umh --merange 24 --mvrange 511 --aq-strength 1.0

[asarian]

Any suggestions?

Other than not letting threads go > 4 (see above), regrettably no. Dark Shikari is the man: only he can ultimately truly fix it. :)

But a sample would be nice, yes. Btw, did you also get the ugly fading with the Austin Powers sample posted in this thread? Dark Shikari's patch worked for that sample (here, at least).

[asarian]

sample clip: http://www.mediafire.com/?sharekey=508d6798bcda1276d2db6fb9a8902bda

Seems to go just fine here with Dark Shikari's patched version. :) (on a quadcore, with 6 threads).