Best settings to avoid bending in color gradients?

[Blu-rayM]

x264.exe --demuxer avs --bitrate 8000 --preset placebo --tune film --weightp 1 --nal-hrd vbr --vbv-maxrate 15000 --vbv-bufsize 15000 --level 4.1 --keyint 25 --b-pyramid strict --slices 4 --aud --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 -o X:\720p_8-15MBit_1pass.mp4 Z:\1080i-720p.25p.avs

So, I had another try over the night (see settings). Although placebo seem to make less problems in QuickTime its still not perfekt, and 1/2 pass is also not responsible, nor is ABR or --crf. In 30 minutes footage there are around 10 sudden grey destroyed images. Always partly, there are no full frames missing, but one see 2-3 frames with differet distortion in a row. Same footage (horribly) encoded by AME with profile High, Level 4.1 does not make problems in Quicktime.

Since the rendering takes so long and short pieces are no proof, that it will work in total footage, I have to overthink before next try. I will let out  

Code: [Select]

--b-pyramid strict --slices 4 --aud
in my next try, since this is not intended for Blu-ray. Any more hints about this?

Thanks a lot!

BTW - its x264 core:112 r1867 22bfd31

[nm]

Which version of QuickTime are you using?

[Blu-rayM]

I don't know exactly. I just downloded the free version 1-2 months ago for Win7. I do not even remember, if there was a 64bit version. I do not use QT, I just sometimes test with it... I will the version this evening.

[Sharktooth]

for the sake of mind sanity, do not use quicktime...

[Blu-rayM]

There is one problem: a lot of customers use MacOS and they use QuickTime. And even when I tell my customers to use VLC instead, they have customers as well who use QuickTime. So, although QuickTime gives awfull image quality (not only the destroyed frames) there is no way to simply avoid it.

[poisondeathray]

So, I had another try over the night (see settings). Although placebo seem to make less problems in QuickTime its still not perfekt, and 1/2 pass is also not responsible, nor is ABR or --crf. In 30 minutes footage there are around 10 sudden grey destroyed images. Always partly, there are no full frames missing, but one see 2-3 frames with differet distortion in a row. Same footage (horribly) encoded by AME with profile High, Level 4.1 does not make problems in Quicktime.

Since the rendering takes so long and short pieces are no proof, that it will work in total footage, I have to overthink before next try. I will let out  

Code: [Select]

--b-pyramid strict --slices 4 --aud
in my next try, since this is not intended for Blu-ray. Any more hints about this?

Thanks a lot!

BTW - its x264 core:112 r1867 22bfd31

Too many b-frames, stick to 3 . Disable b-pyramid and weightp

You should use mov container. Various versions of mp4box can be very "finicky" for quicktime. I'm not sure which muxer x264 uses. If you need mp4 container, use mp4muxer with quicktime compatiblity settings

Note - This still doesn't ensure compatiblity. If you need 100% compatibility, encode with quicktime pro (YUCK!). That's the tradeoff for using a crappy player

[sneaker]

Various versions of mp4box can be very "finicky" for quicktime. I'm not sure which muxer x264 uses.

The vanilla builds use GPAC (just like mp4box) and JEEB's patched builds use L-SMASH.

[Blu-rayM]

I am just doing a new rendertest and will report.
About the mp4: the really worst destroyment happened with a mp4 from x264 muxed by 0.4.5 with AAC audio. I had to use 0.4.5 32bit because 0.4.6 (32 and 64 bit) gives fatal "out of memory" errors when trying to open 2.2 Gig large mp4s from x264 on Win7 64bit 6GB RAM. This really seems to be a bug in mp4box since 0.4.5 is doing it without any hassle with the same files.
And yes, all my last tries were the mp4 by x264 without remuxing with audio. There were errors but by far fewer only.

Of course I will now try http://www.videohelp.com/tools/MP4Muxer since it promises QT support, although its rather old.
Thank you again, poisondeathray and thanks for all other hints too!
The fight ist not over yet

[Blu-rayM]

Ok, its MUCH better now, but there are still at least 2 occasions in 30 minutes footage. There is no difference in the containers, all behave the same in QT 7.6.8 - exactly at the same positions, exactly looking equal in the mp4 container from x264, mp4box or mp4muxer. In QuickTime there is always exactly one second faulty, starting with image one with sharp edge, then you can go 24 frames further and the error desolves till image 2, afterwards its "fresh" and clean without error. So this is exactly one second of a 25p video. In VLC this is not happening, nor it is loosing frames at that position (codec stastics).

http://img828.imageshack.us/i/quicktime1.jpg/
http://img806.imageshack.us/i/quicktime2.jpg/

My settings used:

x264.exe --demuxer avs --crf 14 --preset placebo --tune film --bframes 3 --weightp 0 --nal-hrd vbr --vbv-maxrate 15000 --vbv-bufsize 15000 --level 4.1 --keyint 25 --b-pyramid none --slices 4 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 -o X:\1080i-720p.25p.mp4 Z:\1080i-720p.25p1.avs

Ok, we came so far, maybe there is another hint to avoid the last two errors too...

[Blu-rayM]

So, after avoiding --slices 4 too even QuickTime was able to play those files, muxed with mp4box 0.4.5 - but not before having another massive problem with aac files rendered by AME. The same sound muxed in AME to mp4 works great, no more errors from QuickTime on Windows 7.

The fight is finally over, the quality is awesome (viewed in VLC ). If my x264 renderings are taken as 100% quality, the same footage rendered in AME with best settings is compared maybe 50-60%. I am sorry to tell that...

[poisondeathray]

are you saying --slices 0 "fixed" the remaining visual problems ? That's interesting because QTPro encodes using 8 slices

regarding aac and mp4box issues, there is a big thread at doom9 on that IIRC. As usual, some versions work better than others

[Blu-rayM]

I just can confirm, that after removing "--slices 4" from above mentioned settings the last remaining problems disappeared, in several videos. Maybe these problems were just somehow related (maybe some random delays happened while encoding because if this setting or anything similar) but yes, now its fine.

When putting the aac from AME into mp4box the audio played fine in VLC, but QT said something fatal like "sampling error" und did not even open those mp4-videos. When muxing the same audio within AME in mp4 and feeding that into mp4box the resulting mp4 plays 100% in QT. I have to stay with mp4box 0.4.5 till a possible version 0.4.7 fixes my errors with "out of memory". But, now its fine for me.

Thank you a lot!

[iggy]

I think IT's not that Placebo is particularly good。IT's that there is something wrong with your previous encoding。
Placebo only makes calculation more accurate。IT's result shouldn't be very diffreent from very slow.

I find a easy way to avoid banding without increasing too much filesize and encoding time.

Set psy-trellis between 0.03-0.1,which makes the gradients more “rough” and
set aq strengh between 1.1-1.5，which gives more bits to backgrounds such as gradients.(this will increase filesize reasonably)

[Blu-rayM]

Thank you for this hint, I will definetly try your recommendations!
Most problems occoured because of my initial misanderstandig how x264 works. I've tried 1pass, but 1 pass only without firstslowpass - so that is just false and bad. Now I go with --crf14 and --veryslow which works great and has only one run. The results are 500% better than those rendered with best settings in AME. The renderings takes around 5-6 hours for 30 minutes of footage on an i7/920 - so, a better CPU is next step