x264 and BD (part 2) - asking for suggestions

[mp3dom]

Ok, after my previous post made about six months ago (http://forum.doom9.org/showthread.php?p=1458884#post1458884) 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:

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)

http://i51.tinypic.com/b4i0w6.png
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.

http://i55.tinypic.com/23w16hs.png
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

http://i56.tinypic.com/30nkj0j.png
All white arrows points to artefacts or not-so-good grain retention

http://i55.tinypic.com/33cw1ef.png
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?
:thanks:

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

[Dark Shikari]

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?

[mp3dom]

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.

[CruNcher]

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" ;)

[mp3dom]

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)?

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.

[CruNcher]

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 ;)

[kieranrk]

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.

[mp3dom]

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)

[Sagittaire]

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" ...

[mp3dom]

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.


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).


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.


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.

[Sagittaire]

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.



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?)


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.


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 ... ;-)


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.

[shon3i]

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.

[mp3dom]

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).


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.



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.



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.

[Daiz]

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?

[cyberbeing]

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/x264_DANGEROUS/1900-1999/

--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/

--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.

[mp3dom]

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!

[kolak]

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

[mp3dom]

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.

[kolak]

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

[Blue_MiSfit]

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"

http://files.sharenator.com/lol_face_Your_MumMom_Jokes-s274x280-119842-535.jpg

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

[Sagittaire]

In this case desactive simply AQ ...

[kolak]

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"



Why we don't we have all studios (at leas small ones) using x264- it has been long time since it's BD complaint?
Answer- it does not give real advantage in case of BD production and even if it's free it does not change fact that it misses many features (+ it's relatively slow), which are essential for authoring studios, so there is no that big interest in using it (before even judging quality).

If x264 would have special high bitrate mode these artefacts would not be there- it's way good enough to avoid them, but it needs some optimisation for high bitrates.
Yes- gradients, low level details areas are week points of x264.


Andrew

[kolak]

I've done yet another try: quite grainy film source encoded at 35Mbit (38Mbit max), 2 pass BD pressets, with very slow first pass. It was done at about 5fps (on 12 core machine with HT at 99% of all cores) and does look very good, except exactly the same problem as mp3dom described.
Whole frame will look very good, but it has places where details gets flatten and changed into blocks- there is really no reason for this at 35Mbs. There is also still big gap in quality between B and rest of frames (I assume this can be tweaked). This was not anime, but grainy film source.


Andrew

[mp3dom]

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.
The reason is... to have the maximum quality available.


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?

No, I need to clarify. The weakest point of an encoder like Blu-Code (have you never tried/seen it in action or seen its output quality?) is in very complex area. Something really uncommon on real-life sources or live films, but can be 'common' in japanese animation where some long-scenes are completely unrelated each others, so motion estimation is really huge and a difficult task. In those cases, the smoothing or even blocking is visible compared to the source. The smooth fortunately is not too strong, because the encoder have an 'adaptive' automatic deblocking but I like anyway to not have smoothness or blocking at all :). In all the other cases (normal or quite complex scenes, gradation, fades, grain retention etc) I find the output of Blu-Code the same or more visually pleasant (it depends by scenes) than the x264 output (especially on fades and gradients in both static and dynamic scenes, I find the output of Blu-Code better than any other AVC encoder). I'm always referring to a high bitrate output.


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

To make long story short and simple, actually I work in a (small) company that doesn't made BD as a 'service' (for any other company) but made and sell its own BD (like, I think, Criterion do, just to give the idea). This means that it's hard to have access to a 50K$ encoder even if it's the best in the world. The fact that I'm still giving a try to x264 is because I see the 'potentials' of the encoder in the BD field (at low datarate is already known and personally tested to be the best and I'm already using it) and can probably match, with some modifications, what actually I think is the best encoder - but that I can't affort right now - for BD at high bitrate (CC-HDe). The screenshots that I've posted in the first thread comes from CC-HDe (I know it because every encoder has its own 'pattern' easy to spot). Even CC-HDe is not perfect anyway. Gradients and fades IMHO are better managed by Blu-Code but the output of CC-HDe is anyway acceptable enough (it doesn't produce aberrations/blocking during fades or gradients) and very complex scenes have the same quality as x264.

[CruNcher]

(I know it because every encoder has its own 'pattern' easy to spot).
That is something wow i mean ok i believe it's possible between different codec types but between the same i wouldn't buy it that you can detect from which specific H.264 Encoder a output frame comes from no way, i guess you rather meant you can see which one it came from by deep analyzing it visually against the other, that i would believe again :D

Scaling from 0->100 and somewhere not losing efficiency inside the same codebase is nothing easy and seeing that x264 was mostly optimized visually with low bitrate and the hell with freedom from all restrictions in mind over the years i can follow your and kolaks problems on the blu-ray situation somewhat, and you really tried every possible combination of x264 settings that have todo with compression for quality and you don't get happy @ least with how it looks @ high bitrate i mean their are a lot of options and ranges for possible tweaking high bitrate from the defaults visually ?

[mp3dom]

Yes, I mean you can detect the encoder based on analyze (StreamEye is enough), not by single screenshot or while watching the movie.

[kolak]

mp3dom- there are some improvements coming to CC-HDe.
There is quite a lot to improve, but it was all suspended due to MVC encoder.

The best is to have Blu-code, CC-HDe and x264 :)
Very stable grain and overall image look is very strong point of Blu-code.

I wish x264 gets tweaked for high bitrates encodes.


Andrew

[kolak]

Yes, I mean you can detect the encoder based on analyze (StreamEye is enough), not by single screenshot or while watching the movie.

You can tell even by the look quite often- if you use encoder for long you can see its patterns :)


Andrew

[posdnya]

Yes, I mean you can detect the encoder based on analyze (StreamEye is enough), not by single screenshot or while watching the movie.

Could you make three screenshots from StreamEye - macroblock types, quantizers, and macroblock size. And frame itself, of course.
Or better just give a few meg of the encoded stream containing problem frames. No more then 200 :-) - then evaluation version could be used to check it.

If there is problem with encoding, it will be evident, doesn't matter what's the nature - too high quantizers (not sure) or some problems with intra predicted blocks in P-frame (more likely)