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. |
7th May 2011, 22:22 | #1 | Link |
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
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 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. |
7th May 2011, 23:07 | #2 | Link |
x264 developer
Join Date: Sep 2005
Posts: 8,666
|
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?
__________________
Follow x264 development progress | akupenguin quotes | x264 git status ffmpeg and x264-related consulting/coding contracts | Doom10 Last edited by Dark Shikari; 7th May 2011 at 23:10. |
7th May 2011, 23:39 | #3 | Link |
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
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. |
7th May 2011, 23:42 | #4 | Link |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
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. |
7th May 2011, 23:57 | #5 | Link |
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
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. Last edited by mp3dom; 8th May 2011 at 00:03. |
8th May 2011, 00:17 | #6 | Link | |
Registered User
Join Date: Apr 2002
Location: Germany
Posts: 4,926
|
Quote:
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. |
|
8th May 2011, 00:56 | #8 | Link |
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
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)
|
9th May 2011, 10:03 | #9 | Link |
Testeur de codecs
Join Date: May 2003
Location: France
Posts: 2,484
|
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. |
9th May 2011, 11:36 | #10 | Link | ||||
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
Quote:
Quote:
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:
Quote:
|
||||
9th May 2011, 16:57 | #11 | Link | |||||
Testeur de codecs
Join Date: May 2003
Location: France
Posts: 2,484
|
Quote:
Quote:
Quote:
Quote:
Quote:
__________________
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. |
|||||
9th May 2011, 17:23 | #12 | Link | |
BluRay Maniac
Join Date: Dec 2005
Posts: 2,419
|
Quote:
__________________
ChapterGen - manipulate with chapters in various i/o formats, with CLI support Official website or Doom9 thread |
|
9th May 2011, 18:04 | #13 | Link | ||||
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
Quote:
Quote:
Quote:
Quote:
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. |
||||
9th May 2011, 19:42 | #15 | Link | |
Broadband Junkie
Join Date: Oct 2005
Posts: 1,859
|
Quote:
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)"] __________ 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. |
|
9th May 2011, 19:44 | #16 | Link |
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
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. |
9th May 2011, 21:43 | #17 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
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. |
9th May 2011, 22:14 | #18 | Link |
Registered User
Join Date: Jul 2003
Location: Italy
Posts: 1,135
|
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.
|
9th May 2011, 22:28 | #19 | Link |
Registered User
Join Date: Nov 2004
Location: Poland
Posts: 2,843
|
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 |
10th May 2011, 04:23 | #20 | Link |
Derek Prestegard IRL
Join Date: Nov 2003
Location: Los Angeles
Posts: 5,989
|
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
__________________
These are all my personal statements, not those of my employer :) Last edited by Blue_MiSfit; 10th May 2011 at 04:27. |
Thread Tools | Search this Thread |
Display Modes | |
|
|