Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Video Encoding > MPEG-4 AVC / H.264

Reply
 
Thread Tools Search this Thread Display Modes
Old 7th May 2011, 22:22   #1  |  Link
mp3dom
Registered User
 
Join Date: Jul 2003
Location: Italy
Posts: 991
x264 and BD (part 2) - asking for suggestions

Ok, after my previous post made about six months ago I've re-run a test with the latest version of x264 (rev.1947) to see if improvements have made this encoder high-quality 'stable' for BD encoding. While I've seen some improvements, I still continue to have some 'old' problems that I cannot actually resolve. So I'm asking for both suggestions and wish this post can be useful to someone.
Source/encoded file can be provided to developers if they need it (the files are huge so I need some time to upload)
First of all, this is the command-line used:
Code:
x264.exe --profile high --preset veryslow --tune film --slow-firstpass --keyint 24 --bframes 3 --b-pyramid strict --open-gop --ref 3 --slices 4 --bitrate 37000 --vbv-maxrate 40000 --vbv-bufsize 30000
--weightp 1 --merange 32 --no-fast-pskip --no-dct-decimate --videoformat ntsc --colorprim bt709 --transfer bt709 --colormatrix bt709 --nal-hrd vbr --pic-struct --sar 1:1 --level 4.1 --bluray-compat
I think the parameters are quite good (quality-wise) and bitrate is very high (37 Mbps average). The average qp of the whole encode is near 10.
Source is japanese animation as it's the only footage that I'm working on.
The images are a closeup of the source, zoomed 2x and enhanced to show better the problem for those who have uncalibrated monitor.The images are divided in:
top left: original source
top right: original enhanced (brightness/contrast boosted)
bottom left: x264 original encoded
bottom right: x264 original encoded enhanced (boosted)


This frame is encoded as P frame by x264. There's a bad grain retention and also the black border (it's and edge) shows some artefact.


Here there's some bad grain retention on the lower edge of the orange line but the biggest problem here is the strange artefact that you can see pointed with the white arrow


All white arrows points to artefacts or not-so-good grain retention


Here there's no need to do an enhanced version as it's all visible. The frame was encoded as a B frame (but also previous/forward P/B frames shows the same problem). As you can see, there's some sort of 'ringing' around the contrast line. The image it's a white circle with a faded aura surrounded with black background. It's almost still for a small duration of time (about 10 frames). Also the gradient is visibly less smooth than original. The bitrate used for this frame is very low (there's a lot of black around and the circle is pure white, so it's quite normal) but some macroblocks here have a qp of 25 or more which I think is a bit too much.

Suggestions or requests?


P.S: I would like to not damage the thread with a 'war' between x264 and other pro-encoder.

Last edited by mp3dom; 7th May 2011 at 22:31.
mp3dom is offline   Reply With Quote
Old 7th May 2011, 23:07   #2  |  Link
Dark Shikari
x264 developer
 
Dark Shikari's Avatar
 
Join Date: Sep 2005
Posts: 8,690
Compression artifacts are marginally visible if you freeze-frame, boost the differences in Photoshop, and zoom in? Who would have thought?

x264's psy optimizations are optimized for the case of actually watching a video. If you're not actually watching the video, just encode an all-black screen or something.

We will never optimize x264, ever, for the case of "not actually watching the video". It is beyond pointless.

If you want every single pixel to be perfect even if you zoom in, how about not recompressing the video?

Last edited by Dark Shikari; 7th May 2011 at 23:10.
Dark Shikari is offline   Reply With Quote
Old 7th May 2011, 23:39   #3  |  Link
mp3dom
Registered User
 
Join Date: Jul 2003
Location: Italy
Posts: 991
The 4th screenshot can be visible during playback and, to some extent, even the 3rd because you can see like a 'strange noise' (there's motion as the closeup are a character's hairs that's moving). First two are not visible during playback. I don't expect to have the compressed frame exactly as the original (I'm not that insane) but considering the high bitrate (and the output media - blu-ray) I would thought to have more real "similarity" to the source. Would be disabling psy optimizations a best choice for my case?

Considering only the playback, at that bitrate, probably even the Apple H.264 encoder would be enough.
mp3dom is offline   Reply With Quote
Old 7th May 2011, 23:42   #4  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,950
Omg mp3dom i hope you didn't hurt yourself when you always push your head so heavy against the display :P even under perfect viewing condition you would never ever realize this blocking and in your pro encoder the blocks are gonna propagate @ different frames and how you want to finally compare that counting each block frame by frame pixel by pixle like you do it is crazy, i can give you an advise what you looking @ MSU made a nice metric for that would make your life easier
And yes trying --tune PSNR/SSIM could be a solution for you

Its 10 times more efficient calling your friend he should look @ that playing the pro encoder file playing the x264 and you know what hes gonna say ? "Sorry i concentrated on her Boobs"
__________________
all my compares are riddles so please try to decipher them yourselves :)

It is about Time

Join the Revolution NOW before it is to Late !

http://forum.doom9.org/showthread.php?t=168004

Last edited by CruNcher; 7th May 2011 at 23:53.
CruNcher is offline   Reply With Quote
Old 7th May 2011, 23:57   #5  |  Link
mp3dom
Registered User
 
Join Date: Jul 2003
Location: Italy
Posts: 991
I need to evaluate compression output made by different encoders so the only way I know is watching frame by frame with my eyes (not the whole movie, obviously, but some blocks of sequences made by 4-5 seconds so 120 consecutive frames) in "strategic" points (grain retention, blockiness and gradients smoothing during both still and moving parts). Watching consecutive frames I can see how the encoder distribute the bitrate across the I/P/B frames. If at that high bitrate an encoder output frames more similar to the source, I guess that, at that high bitrate, that encoder is better than another... Is this a wrong assumption (considering that I evaluate 4-5 consecutive gops and not a bunch of frames somewhere and sometimes)?

Quote:
Originally Posted by CruNcher View Post
Its 10 times more efficient calling your friend he should look @ that playing the pro encoder file playing the x264 and you know what hes gonna say ? "Sorry i concentrated on her Boobs"
You are probably right but anyway, at that high bitrate probably every AVC encoder out there can output a very good to transparent 'playback quality' but if I have 3-4 stream I should use the better.

Last edited by mp3dom; 8th May 2011 at 00:03.
mp3dom is offline   Reply With Quote
Old 8th May 2011, 00:17   #6  |  Link
CruNcher
Registered User
 
CruNcher's Avatar
 
Join Date: Apr 2002
Location: Germany
Posts: 4,950
Quote:
Originally Posted by mp3dom View Post
I need to evaluate compression output made by different encoders so the only way I know is watching frame by frame with my eyes (not the whole movie, obviously, but some blocks of sequences made by 4-5 seconds so 120 consecutive frames) in "strategic" points (grain retention, blockiness and gradients smoothing during both still and moving parts). Watching consecutive frames I can see how the encoder distribute the bitrate across the I/P/B frames. If at that high bitrate an encoder output frames more similar to the source, I guess that, at that high bitrate, that encoder is better than another... Is this a wrong assumption (considering that I evaluate 4-5 consecutive gops and not a bunch of frames somewhere and sometimes)?


You are probably right but anyway, at that high bitrate probably every AVC encoder out there can output a very good to transparent 'playback quality' but if I have 3-4 stream I should use the better.
even if it would be assuming that 1 of the encoders cost goes into the 10k and the other is @ 0 would void anything anyways in the Real World depending if you are a professional and have no problem investing that and even then other things would matter much more then some blocks here and their rated over 120 consecutive frames, and i thought i was picky when i constructively discussed in the early days about x264 vs xvid in terms of psy feeling or other visual problems

Btw Dark it would be cool if you could redo the Vendetta 720p low bitrate encode with todays x264 in 10 bit and showing of what has changed in real since then i guess that would interest a lot http://forum.doom9.org/showthread.php?t=129071
__________________
all my compares are riddles so please try to decipher them yourselves :)

It is about Time

Join the Revolution NOW before it is to Late !

http://forum.doom9.org/showthread.php?t=168004

Last edited by CruNcher; 8th May 2011 at 00:45.
CruNcher is offline   Reply With Quote
Old 8th May 2011, 00:34   #7  |  Link
kieranrk
Registered User
 
Join Date: Jun 2009
Location: London, United Kingdom
Posts: 713
One thing I must ask is why do you always seem to be encoding upscaled anime? It seems you are worried about maintaining what look to me like upscaling artefacts.
kieranrk is offline   Reply With Quote
Old 8th May 2011, 00:56   #8  |  Link
mp3dom
Registered User
 
Join Date: Jul 2003
Location: Italy
Posts: 991
I've zoomed the image 2x for better showing the problem. The source (the master file) is anyway 1080p and not an upscale. Internally (the resolution it was drawn) probably is not true 1080 but quite close. Real 1080p anime are quite rare, most of the times are intermediate resolutions upscaled to match 1080 (extra footage is often a plain upscale from 480i to 1080i)
mp3dom is offline   Reply With Quote
Old 9th May 2011, 10:03   #9  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,413
Really interessing discution:

Anyway your analyse is bad:

1) H264 is lossy codec. You will always see compressions artefects even at 40 Mbps and even for source like anime.
2) Grain retention in low constrat/luma area is not good for HVS simply because eyes can't see grain in these area. Good pre-precess is filtering this grain for these low contrast/luma area. Good psy optimistion for codec is not enconding grain in these low contrast/luma.
3) Your methodology to see these artefact is not good. You must use the good luma/contrat setting without brightness/contrast boost simply because your test break HVS rules (Human Visual System) and x264 psy optimisation.

Final word: x264 never encode with your suggestions simply because your suggestions break HVS common rules. Personnaly I don't want grain in sources with low luma/contrast (filtering), I don't want that encoder have good grain retentions in these area (bit loss for other most important area).

The good HSV way for low luma/constrat area is that: "luma/contrast filtering grain" for have "flat area", use lower quant (AQ psy optimisation) to have the best possible local quality in flat area because eyes see really well blocking in low luma/contrast area (HVS rules ... always). It's very a good tradeoff because use lower quant in flat area is not a "high bytes cost" ...
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9

Last edited by Sagittaire; 9th May 2011 at 10:27.
Sagittaire is offline   Reply With Quote
Old 9th May 2011, 11:36   #10  |  Link
mp3dom
Registered User
 
Join Date: Jul 2003
Location: Italy
Posts: 991
Quote:
Originally Posted by Sagittaire View Post
1) H264 is lossy codec. You will always see compressions artefects even at 40 Mbps and even for source like anime.
Nobody wants a lossless encode out of an AVC stream for BD. But at that high bitrate I would like more adherence to the original source not only in high frequencies, but also in low frequencies. There's a high discrepancy in x264 encodes (for what I've seen) in the fact that high frequencies have very low qp (very high quality) while dark areas or low frequencies get very high qp. While in general this works very good for low/medium bitrate (and for uncalibrated monitor, which are the majority), to me it's not so good for high bitrates. The amount of bitrate should be able to preserve also the dark areas. I would prefer to have a qp=6/7 in high frequencies (that is near lossless anyway) and qp=15-16 in low frequencies rather than qp=2 in high frequencies and qp=25 in low frequencies especially if qp25 in those parts is really visible.

Quote:
2) Grain retention in low constrat/luma area is not good for HVS simply because eyes can't see grain in these area. Good pre-precess is filtering this grain for these low contrast/luma area. Good psy optimistion for codec is not enconding grain in these low contrast/luma.
I've boosted the screenshots because:
1) A lot of monitor are - by default - uncalibrated. Generally they're always too dark, others have contrast boosted and hide these artefacts (not alls, I've seen monitors that actually boost the artefacts even more). The fact that they hide the problem doesn't mean that the problem doesn't exist. Boosting this will show the problem almost everywhere. I've practical example of encoders that at that high bitrate can provide quality as good as x264 in high frequencies and better management of dark areas/grain retention. If other encoders can, why x264 can't? Maybe - I think - it's only a matter of particular options... and this is the reason of this discussion... target the right options to let x264 acts in a different way with very high bitrates to be more close to the source.
2) A slice of image in a fullHD monitor (especially if the image is surrounded with white color or gray like in this forum) is difficult to see.
I can guarantee that in a Samsung LCD (my tvset) out of factory (default settings) and also a Dell monitor, it is very visible the artefacts so to me this is a problem as it's visible. Also, I would never pre-process a BD master/source unless we're speaking of blackbars that contains unnecessary noise or to be not real black). The goal of BDs is to be as close as possible to the source, not prefiltered to be encode-friendly. I also think it's wrong (this is my thought) to remove/flat noise in dark areas (it's also quite easy to remove details). Regarding psy-optimizations, the 4th screenshot have artefacts in this high contrast zone. I don't think it's a good result as it's visible in almost every monitor and can also be visible during the movie as it's not a very quick scene (I've seen it during playback).

Quote:
3) Your methodology for see these artefact is not good. You must use the good luma/contrat setting without brightness/contrast boosted simply because your test break HSV and x264 psy optimisation.
Maybe it's not the right methodology but with full screenshot (I mean 1080p) and a calibrated monitor it's all visible.

Quote:
Final word: x264 never encode with your suggestions simply because your suggestions break HVS common rules.
Personnaly I don't want grain in sources with low luma/contrast (filtering), I don't want that encoder have good grain retentions in these area (bit loss for other most important area).
I don't think I'm breaking anything, with proper calibrated monitor the artefacts are visible. Maybe x264 with psy-off handle in a better way the encode with high bitrates.
mp3dom is offline   Reply With Quote
Old 9th May 2011, 16:57   #11  |  Link
Sagittaire
Testeur de codecs
 
Sagittaire's Avatar
 
Join Date: May 2003
Location: France
Posts: 2,413
Quote:
Originally Posted by mp3dom View Post
Nobody wants a lossless encode out of an AVC stream for BD. But at that high bitrate I would like more adherence to the original source not only in high frequencies, but also in low frequencies. There's a high discrepancy in x264 encodes (for what I've seen) in the fact that high frequencies have very low qp (very high quality) while dark areas or low frequencies get very high qp. While in general this works very good for low/medium bitrate (and for uncalibrated monitor, which are the majority), to me it's not so good for high bitrates. The amount of bitrate should be able to preserve also the dark areas. I would prefer to have a qp=6/7 in high frequencies (that is near lossless anyway) and qp=15-16 in low frequencies rather than qp=2 in high frequencies and qp=25 in low frequencies especially if qp25 in those parts is really visible.
Well x264 don't make that. x264 use complexity (with controled psy correction) for AQ. Flat block use by definition lower quant (and higher quality). x264 never encode high frequency at q5 and low frenquency at q25 with AQ. Moreover dark area can have low and high frequency for block. There are scaling between frequency and complexity for block. AQ with Luma/contrast are typicaly psy optimisation.



Quote:
I've boosted the screenshots because:
1) A lot of monitor are - by default - uncalibrated. Generally they're always too dark, others have contrast boosted and hide these artefacts (not alls, I've seen monitors that actually boost the artefacts even more). The fact that they hide the problem doesn't mean that the problem doesn't exist. Boosting this will show the problem almost everywhere. I've practical example of encoders that at that high bitrate can provide quality as good as x264 in high frequencies and better management of dark areas/grain retention. If other encoders can, why x264 can't? Maybe - I think - it's only a matter of particular options... and this is the reason of this discussion... target the right options to let x264 acts in a different way with very high bitrates to be more close to the source.
2) A slice of image in a fullHD monitor (especially if the image is surrounded with white color or gray like in this forum) is difficult to see.
Well I don't see artefact in your screen without your extrem luma/contrast boost. And you use your extreme boost for your demonstration because it's usefull ... for your demonstration (if artefact are really visible, no necessary to use boost by definition ... but you use boost because without boost it's really hard te see differences ... isn't it?)


Quote:
I can guarantee that in a Samsung LCD (my tvset) out of factory (default settings) and also a Dell monitor, it is very visible the artefacts so to me this is a problem as it's visible. Also, I would never pre-process a BD master/source unless we're speaking of blackbars that contains unnecessary noise or to be not real black). The goal of BDs is to be as close as possible to the source, not prefiltered to be encode-friendly. I also think it's wrong (this is my thought) to remove/flat noise in dark areas (it's also quite easy to remove details). Regarding psy-optimizations, the 4th screenshot have artefacts in this high contrast zone. I don't think it's a good result as it's visible in almost every monitor and can also be visible during the movie as it's not a very quick scene (I've seen it during playback).
Well there are in the doom9 area many compressionist. And for me the best compressionist make the first HDDVD with VC1. And for these compressionist the pre-process is 90% of a good encoding work (speak about benwaggonner from MS about that). Perfect codec must (in HVS sense) make encoding like the source master ... but it's really not the case for compressionist ... simply because lossy codec 4/2/0 can't never make encoding like the maters source 4/4/4 or 4/2/2. Pre-filtering is here for degrade less important part of source (for my eyes) and privilegy the most important part of the source (always for may eyes) if the codec can't make perfect encoding and it's always the case for lossy codec. And it will be always like that ... for lossy codec.


Quote:
Maybe it's not the right methodology but with full screenshot (I mean 1080p) and a calibrated monitor it's all visible.
I have calibrated monitor and I don't see clearly yours artefacts. If users have monitor with your luma/constrast boost, i doubt seriousely that dct noise are problem for these users because they must simply change eyes ... ;-)


Quote:
I don't think I'm breaking anything, with proper calibrated monitor the artefacts are visible. Maybe x264 with psy-off handle in a better way the encode with high bitrates.
If the other codec make good job for your eyes, use simply the other codecs. Anyways encoding grain in dark part area will be always time loss (and bytes loss) for the pro ... it's like that.
__________________
Le Sagittaire ... ;-)

1- Ateme AVC or x264
2- VP7 or RV10 only for anime
3- XviD, DivX or WMV9

Last edited by Sagittaire; 9th May 2011 at 17:05.
Sagittaire is offline   Reply With Quote
Old 9th May 2011, 17:23   #12  |  Link
shon3i
BluRay Maniac
 
shon3i's Avatar
 
Join Date: Dec 2005
Posts: 2,426
Quote:
Originally Posted by Sagittaire
Well I don't see artefact in your screen without your extrem luma/contrast boost. And you use your extreme boost for your demonstration because it's usefull ... for your demonstration (if artefact are really visible, no necessary to use boost by definition ... but you use boost because without boost it's really hard te see differences ... isn't it?)
I believe is that because mp3dom have trained eye to spot this artifacts on picture, here boosted pictures demonstrate artifacts easily to others not for him. Like someone can hear something, that someone can't.
__________________
ChapterGen - manipulate with chapters in various i/o formats, with CLI support
Official website or Doom9 thread
shon3i is offline   Reply With Quote
Old 9th May 2011, 18:04   #13  |  Link
mp3dom
Registered User
 
Join Date: Jul 2003
Location: Italy
Posts: 991
Quote:
Originally Posted by Sagittaire View Post
x264 never encode high frequency at q5 and low frenquency at q25 with AQ. Moreover dark area can have low and high frequency for block. There are scaling between frequency and complexity for block. AQ with Luma/contrast are typicaly psy optimisation.
With the command line posted in first post it happends what I've said (probably not everytime but at least on the frame I've checked). Verified with StreamEye. In the 4th screenshot the zones with artefacts (and I cannot trust you if you say that you can't see that ringing) I have a qp>25 (some blocks in the contrast area have, if I remember correctly, a qp near 29).

Quote:
but you use boost because without boost it's really hard te see differences ... isn't it?)
No it isn't. Read my point #2 in previous post. I say again that 3rd and 4th screenshot artefacts are visible to me during playback but probably not for a casual viewer (who can have wrong calibrated equipment, or not a trained eye). But as a video compressionist my job is to have a real good encode without taking into account other variables like user experience, user trained eyes or user equipments.


Quote:
Perfect codec must (in HVS sense) make encoding like the source master ... but it's really not the case for compressionist ... simply because lossy codec 4/2/0 can't never make encoding like the maters source 4/4/4 or 4/2/2. Pre-filtering is here for degrade less important part of source (for my eyes) and privilegy the most important part of the source (always for may eyes) if the codec can't make perfect encoding and it's always thes case for lossy codec. And it will be always like that ... for lossy codec.
Preprocessing in the sense of dithering down a 10bit master to 8bit is needed and necessary, filtering to keep original color smoothing is another good choice to preserve the original intent of the author. Denoising a master to help the encoder, to me, is not a good choice. Just to know, do you cut some audio frequencies in a PCM file to help a Dolby encoder to output a lossy Ac3? Or do you apply filters that eliminate everything under a -40/-50 dB just because "it can't be heard"? I don't think so... and I don't think audio engineers do this.


Quote:
If the other codec make good job for your eyes, use simply the other codecs. Anyways encoding grain in dark part area will be always time loss (and bytes loss) for the pro ... it's like that.
Just to point out, the screenshots posted as a 'source' are in reality the output from another AVC encoder that evidently keep more details in dark areas. It's not the same as the real source (the 4th screenshot of the real source is better), but very close and I've decided to use it as a 'reference' for what I mean/would like to have from x264. It's not encoded by me (because I don't own that encoder) but by another studio of another country and another company (japanese animation are licensed for every country at different companies). That encode also starts in a 'worst' position than a general x264 encode because (accordingly to StreamEye) it was made with only 2 bframes and no 4x4 partitions so it's even more 'inefficient'. If another encoder can do that job, I think even x264 should do at least a similar job.
The x264 'engine' is really very good because it can find vectors/references/partitions and handle B frames in a very better/efficient way than any other AVC encoder. Efficiency that seems to not take account of dark areas. It's just that, to me, seems more 'enhanced' to provide good quality at low bitrate (something that any other AVC encoder can't provide) but it continues to work in the same manner even when the bitrate is very generous.

The question is: Is it possible, tuning parameters (which?), to obtain a result more close to the source even in dark areas? Or it's something that x264 is not designed for? For now I've tried to lower deadzones to 2, disabling mbtree, lowering aq-strength to 0.5 and lowering psy-rd. While the result is a bit better, it's not enough as 3rd and 4th screenshot continues to have that kind of artefacts.

Last edited by mp3dom; 9th May 2011 at 18:08.
mp3dom is offline   Reply With Quote
Old 9th May 2011, 18:41   #14  |  Link
Daiz
Registered User
 
Join Date: Jan 2008
Location: Finland
Posts: 68
A simple recommendation: If you don't want your low frequencies to go as high QPs as they currently do, why not just set --qpmax to something like 15-16?
__________________
Where did neuron1 go? | Doom10
Daiz is offline   Reply With Quote
Old 9th May 2011, 19:42   #15  |  Link
cyberbeing
Broadband Junkie
 
Join Date: Oct 2005
Posts: 1,833
Quote:
Originally Posted by mp3dom View Post
The question is: Is it possible, tuning parameters (which?), to obtain a result more close to the source even in dark areas? Or it's something that x264 is not designed for?
If Daiz's simple recommendation doesn't help, have you tried playing around with an OreAQ patched build?
OreAQ was originally a patch created by Seraphy to help tweak AQ for anime content based on luminance.

__________

VFRManic's recent builds have the OreAQ patch with AQDebug enabled:

http://vfrmaniac.fushizen.eu/x264/x2...OUS/1900-1999/

Code:
      --aq-mode <integer>     AQ method [1]
                                  - 0: Disabled
                                  - 1: OreAQ
                                  - 2: MixOre (experimental)
      --aq-strength <float>   Reduces blocking and blurring in bump and
                              clear-cut areas. [0.5]
                    <Up:Down> or <Up1:Down1:Up2:Down2:Up3:Down3:Up4:OtherStuff>
                              Set QP up/down strength.
      --aq-sensitivity <float> "Center" of AQ curve. [10.0]
                                  -  5: most QPs are raised
                                  - 10: good general-use sensitivity
                                  - 15: most QPs are lowered
      --aq-ifactor <Up:Down>  AQ strength factor of I-frames [1.0:1.0]
      --aq-pfactor <Up:Down>  AQ strength factor of P-frames [1.0:1.0]
      --aq-bfactor <Up:Down>  AQ strength factor of B-frames [1.0:1.0]
      --aq-boundary <int:int:int>   AQ boundary.
                                  fullrange=off: [192:64:24]
                                  fullrange=on : [205:56:9]
                                  #1: Bright-Middle
                                  #2: Middle-Dark
                                  #3: Dark-M.Dark
      --aq-debug <string>     Filename for AQ debug log ["(null)"]
Edit: oops, did --fullhelp on the wrong build.
__________

Astrataro has the OreAQ patch with AQDebug disabled:

https://astrataro.wordpress.com/category/encode/x264/

Code:
      --aq-mode <integer>     AQ method [1]
                                  - 0: Disabled
                                  - 1: OreAQ
                                  - 2: MixOre (experimental)
      --aq-strength <float>   Reduces blocking and blurring in bump and
                              clear-cut areas. [0.5]
                    <Up:Down> or <Up1:Down1:Up2:Down2:Up3:Down3:Up4:OtherStuff>
                              Set QP up/down strength.
      --aq-sensitivity <float> "Center" of AQ curve. [10.0]
                                  -  5: most QPs are raised
                                  - 10: good general-use sensitivity
                                  - 15: most QPs are lowered
      --aq-ifactor <Up:Down>  AQ strength factor of I-frames [1.0:1.0]
      --aq-pfactor <Up:Down>  AQ strength factor of P-frames [1.0:1.0]
      --aq-bfactor <Up:Down>  AQ strength factor of B-frames [1.0:1.0]
      --aq-boundary <int:int:int>   AQ boundary. 
                                  fullrange=off: [192:64:24]
                                  fullrange=on : [205:56:9]
                                  #1: Bright-Middle
                                  #2: Middle-Dark
                                  #3: Dark-M.Dark
__________


If you have time to do a lot of trial-and-error test encodes, you can likely achieve the results you want by playing with OreAQ. Add a bit of FGO and Fade_Compensate as well and you may be set.

Note: The last time I used OreAQ was literally 1000 x264 revisions ago, so I can't offer much help, and I'm unsure how well it melds with current builds and at such high bitrates.

Warning: Make sure to run any encodes through a stream checker to confirm it obeys your Bitrate and VBV targets, and the patch isn't breaking rate-control.

Last edited by cyberbeing; 10th May 2011 at 05:17.
cyberbeing is offline   Reply With Quote
Old 9th May 2011, 19:44   #16  |  Link
mp3dom
Registered User
 
Join Date: Jul 2003
Location: Italy
Posts: 991
Because qpmax affects both low/high frequencies. Bitrate then can be not enough to cover a high complex sequence at so low qp over time and there's potential risks to have problems with vbv.

cyberbeing: Well, thanks. I think this points to the right direction. I never known a similar patch so it's well accepted I'll try it to see how it can improve the encoding. Thanks again!

Last edited by mp3dom; 9th May 2011 at 19:47.
mp3dom is offline   Reply With Quote
Old 9th May 2011, 21:43   #17  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,178
I know solution- use Blu-code for this kind of sources- it has very good bitrate allocation on the actual frame. Even if it will be bit softer than x264, overall encoded file looks better- more equal quality.
x264 is not very good at high bitrates due its low bitrates optimisations. My tests showed exactly the same problem as yours on many different sources- not even anime. When it comes to source with gradients x264 is not the best choice.

Also fades are still very problematic as they were at the beginning.

I've done some test recently at 4Mbits and x264 was great in high motion, but terrible with fades and not that great with some low detailed scenes.


Andrew

Last edited by kolak; 9th May 2011 at 21:53.
kolak is offline   Reply With Quote
Old 9th May 2011, 22:14   #18  |  Link
mp3dom
Registered User
 
Join Date: Jul 2003
Location: Italy
Posts: 991
Thanks kolak. I'll investigate the patch a little to see if I can obtain some improvements. Blu-Code probably will be the latest attempt. I've already tried it and while it outputs near perfect quality from still to high motion scenes, it still suffer on huge complex scenes where x264 handle in a better way. Unfortunatly this source have some very complex scenes that I would like to keep as good as possible... If I'm "desperate" I can think of splitting the encoding in more parts... encode the majority with Blu-Code and the huge complex parts with x264 and then joining them at authoring stage. I'll see.
mp3dom is offline   Reply With Quote
Old 9th May 2011, 22:28   #19  |  Link
kolak
Registered User
 
Join Date: Nov 2004
Location: UK
Posts: 2,178
Yes - Blu-code seams to struggle a bit with some complex scenes, but nothing is perfect

Try CC-HDe than- it copes very well with complex scenes and you can add dithering and diffusion for 10 to 8 bit conversion

Complex scenes seams to be strong side of x264, but fades and "easy parts" not necessarily. It seams to "waste" additional bits, but I think it's due to its engine- it was not designed for high bitrates- again- nothing is perfect

Andrew
kolak is offline   Reply With Quote
Old 10th May 2011, 04:23   #20  |  Link
Blue_MiSfit
Derek Prestegard IRL
 
Blue_MiSfit's Avatar
 
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,301
Kolak, as usual you spew nonsense.

"x264 is not very good at high bitrates due its low bitrates optimisations"

"when it comes to source with gradients x264 is not the best choice"

"it was not designed for high bitrates"



Of course something like CC-HDe will probably give you a better end result for the obnoxiously picky cases like this, you can do manual pixel by pixel filtering and rate control through its GUI. A tool like this doesn't exist for x264, so you can't really make a fair comparison, now can you?

Best of luck, mp3dom. This looks like a very difficult case to optimize for, and I'm sure you're doing all this work for a very good reason. You are quite certain that the artifacts you describe are visible in motion, on a standard uncalibrated display, and are harder to swallow than the softness / inferior handling of complex scenes offered by a professional encoder... right?

x264 may not be the best tool for the job, but I'm glad you're giving it a try! Free is nice, huh?

Derek

Last edited by Blue_MiSfit; 10th May 2011 at 04:27.
Blue_MiSfit is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 20:40.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2017, vBulletin Solutions Inc.