FGO better than PSY-RDO?

[dotBL0t]

Almost same encoding settings but...

x264 - core 65 r999 cc51047 (2pass - 807kbps - psy 1.0:0.0):

http://img505.imageshack.us/img505/9950/shot0004wp3.png


x264 - core 59 r859 ce13bb6 (2pass - 807kbps - fgo 10):

http://img267.imageshack.us/img267/9929/shot0006pj1.png

Imho there's no doubt that the second shot is far better than the first one.

What do you think about it? :confused:

[Dark Shikari]

Single-frame comparisons show nothing especially in such a case, since we have no idea of the quantizers of the frames, or frametypes, or anything of the sort.

If one frame is larger another and looks better, for example, it proves nothing--that's assumed to be the case, for obvious reasons. Same with P-frames and B-frames; the former generally look better due to being higher quantizer. Same with I-frames vs other frame types.

The top frame in particular looks like it has a much higher quantizer than the lower frame.

[dotBL0t]

Yes, i know it, but believe me: it reflects the overall quality of both encodings.

[Dark Shikari]

Yes, i know it, but believe me: it reflects the overall quality of both encodings.Perhaps you can be useful and post a pair of .h264 streams instead of complaining? Use Mediafire if you need a host.

[dotBL0t]

Hey DS please calm down...I'm not complaining about anything, I just made an observation after 6 full encodings of the movie. Here are the clips but I don't think theyll be useful because the same scene has been treated differently in both encodings and (as you suspected) more bitrate (better quantization) was given to the fgo clip by the encoder (11mb vs 9mb).

Here they are:
http://www.files.to/get/425319/e02k00v1t1
http://www.files.to/get/425320/ha4uey04s2

Maybe, I can try to encode only that particular scene with both versions of x264 and with the same bitrate to have a better idea on how they face the challenge.

Cheers!

[Dark Shikari]

The clips differ far more dramatically than just psy-RD vs FGO; the newer one uses far more B-frames, for example. The FGO clip also uses much weaker deblocking, and thus has a bit more detail. I wonder why? :p

I would suspect if I had a glance at your x264 settings for each encode (not visible to me because you clipped the segments out from a larger stream), there would be other differences...

If you want a reasonable comparison, you'll have to use similar settings in every regard on both clips. I would suspect that if both were equal, the difference would be much less.

[dotBL0t]

mmmm, very strange...tonight i will start the Nth encode to be sure at 100% to use the same settings of the one used on the fgo clip and i will post the results. See you tomorrow! Stay tuned! :devil: :p

[Avenger007]

(not visible to me because you clipped the segments out from a larger stream)
I know this is way off topic but is there a way to include the settings in each segment header? Would a hex editor work?
Also, do h264 streams have a footer where an arbitrary amount of data can be appended (and viewed by regular media info programs like MediaInfo)?

[akupenguin]

I know this is way off topic but is there a way to include the settings in each segment header? Would a hex editor work?
Also, do h264 streams have a footer where an arbitrary amount of data can be appended (and viewed by regular media info programs like MediaInfo)?
Yes, userdata sei can go anywhere in the stream (well not in the middle of another NAL, of course), and can contain arbitrary data. Yes, you can copy it with a hexeditor.

[dotBL0t]

Well, it seems that I may have messed up something in the psy encode I posted early. Here's the new clip taken from the new encode. It's far better than the first one, but imho fgo clip is still better.

http://www.files.to/get/426115/t3gkea2rg0

set OUTPUT="THE_INCREDiBLE_HULK_fgo.mp4"
set INPUT="THE_INCREDiBLE_HULK.avs"
set STATS="THE_INCREDiBLE_HULK_fgo.stats"

x264-fgo.exe --pass 1 --bitrate 807 --stats %STATS% --level 4.1 --bframes 3 --b-pyramid --direct auto --filter -2,-1 --subme 1 --partitions none --me dia --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output NUL %INPUT% --aq-strength 1.0 --aq-mode 2

x264-fgo.exe --pass 2 --bitrate 807 --stats %STATS% --level 4.1 --ref 5 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 6 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output %OUTPUT%$ %INPUT% --aq-strength 1.0 --aq-mode 2 --fgo 10

AVS_INPUT="THE_INCREDIBLE_HULK.avs"
STATS="THE_INCREDIBLE_HULK_psy.stats"
OUTPUT="HULK_psy.mp4"
RESOLUTION="576x240"
BITRATE="807"

##########PASS1##############
wine avs2yuv.exe -raw "$AVS_INPUT" -o - | x264 --pass 1 --bitrate $BITRATE --stats $STATS --level 4.1 --bframes 3 --b-pyramid --direct auto --filter -2,-1 --subme 1 --partitions none --me dia --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output /dev/null - $RESOLUTION --aq-strength 1.0 --aq-mode 2
#############################

##########PASS2##############
wine avs2yuv.exe -raw "$AVS_INPUT" -o - | x264 --pass 2 --bitrate $BITRATE --stats $STATS --level 4.1 --ref 5 --mixed-refs --bframes 3 --b-pyramid --weightb --direct auto --filter -2,-1 --subme 6 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim --output $OUTPUT - $RESOLUTION --aq-strength 1.0 --aq-mode 2 --psy-rd 1.0:0.0
#############################

[Dark Shikari]

You're technically still not using the same settings, since new subme7 == old subme6 + brdo. This means psy-RD isn't being applied to B-frames.

Looking through it, psy looks better than FGO in terms of sharpness, while FGO keeps the finest grain better, which is completely unsurprising given how the metrics work. Overall, some frames look better with one, while others look better with the other. I'm not sure what the winner is, but I'd say its psy-RD simply because when two videos have roughly similar visual quality and one is 2MB smaller, I'm going to be biased towards the smaller one.

[dotBL0t]

You're technically still not using the same settings, since new subme7 == old subme6 + brdo.
LMAO DS...you're damn right...10000th encode on it's way. Stay still tuned!!! ;)

Looking through it, psy looks better than FGO in terms of sharpness and clarity, while FGO keeps the finest grain better, which is completely unsurprising given how the metrics work.

Since they work differently, couldn't it be a good a idea to preserve also the --fgo options in new x264 releases? Anyone will be able to chose the best option that fits his needs this way.

[Sagekilla]

We're going to need to introduce a --lsd switch soon with all the psychovisual enhancements :)

[dotBL0t]

Encoding finished!

Here's the clip with subme=7:

http://www.files.to/get/426639/i7lz3d1hdt

And here you can find another comparison between the two encodes taken from another scene:

http://www.files.to/get/426637/13gv834xzp
http://www.files.to/get/426638/4oxu81r7bj

I still visually prefer the fgo one, and as I asked before:
Since they work differently, couldn't it be a good a idea to preserve also the --fgo options in new x264 releases? Anyone will be able to chose the best option that fits his needs this way.

[Terranigma]

More grain doesn't inherently mean that it's better. How about comparing your fgo encode to the source. You may be surprised to find your encodes with more grain than the actual source, and we want transparency right? Not artificial grain.
If you want a grainy encode with the svn builds, then increase the strength of psy-trellis. By default it's disabled. I bet if you change it, to say, --psy-rd 1.0:1.0, you'll be more pleased with the results of the psy-rd encode.


And what's with the settings being removed? I mean, if you want us to compare, how do we know you're not using higher quality settings for the fgo sample? What, we're supposed to take your word on it?

[Ramir Gonzales]

Just a non-biased opinion, but I find the FGO better looking.
It seems more detailed especially when the girl sits on the bench while the guy sees her from the tree.

[shon3i]

@dotBL0t, i notice same thing, and looks like FGO keeps original grain, while PsyRDO always add grain, to hide artifacting in compression, usual cheat for human visual system, thats why called "Psy".

aslo you can always download updated FGO bulds from here http://www.esnips.com/web/VFRmaniac-Softwares

x264 core:65 r999_EXPERIMENTAL (built by muken, the VFR maniac)
Syntax: x264 [options] -o outfile infile [widthxheight]

Infile can be raw YUV 4:2:0 (in which case resolution is required),
or YUV4MPEG 4:2:0 (*.y4m),
or AVI or Avisynth if compiled with AVIS support (yes).
Outfile type is selected by filename:
.264 -> Raw bytestream
.mkv -> Matroska
.mp4 -> MP4 if compiled with GPAC support (yes)

Options:

-h, --help List the more commonly used options
--longhelp List all options

Frame-type options:

-I, --keyint <integer> Maximum GOP size [250]
-i, --min-keyint <integer> Minimum GOP size [25]
--scenecut <integer> How aggressively to insert extra I-frames [40]
--pre-scenecut Faster, less precise scenecut detection.
Required and implied by multi-threading.
-b, --bframes <integer> Number of B-frames between I and P [0]
--b-adapt Adaptive B-frame decision method [1]
Higher values may lower threading efficiency.
- 0: Disabled
- 1: Fast
- 2: Optimal (slow with high --bframes)
--b-bias <integer> Influences how often B-frames are used [0]
--b-pyramid Keep some B-frames as references
--no-cabac Disable CABAC
-r, --ref <integer> Number of reference frames [1]
--no-deblock Disable loop filter
-f, --deblock <alpha:beta> Loop filter AlphaC0 and Beta parameters [0:0]
--max-slicesize <integer> Limit the size of each slice (in bytes) (0 => u
nlimited)
--mb-slicesize <integer> Limit the size of each slice (in MacroBlocks) (0
=> unlimited)
--no-mv-inter-slices Prohibits any mv prediction between slices
--interlaced Enable pure-interlaced mode (tff)
--tff Alias for --interlaced
--bff Enable pure-interlaced mode (bff)

Ratecontrol:

-q, --qp <integer> Set QP (0=lossless) [26]
-B, --bitrate <integer> Set bitrate (kbit/s)
--crf <float> Quality-based VBR (nominal QP)
--vbv-maxrate <integer> Max local bitrate (kbit/s) [0]
--vbv-bufsize <integer> Enable CBR and set size of the VBV buffer (kbit) [
0]
--vbv-init <float> Initial VBV buffer occupancy [0.9]
--qpmin <integer> Set min QP [10]
--qpmax <integer> Set max QP [51]
--qpstep <integer> Set max QP step [4]
--ratetol <float> Allowed variance of average bitrate [1.0]
--ipratio <float> QP factor between I and P [1.40]
--pbratio <float> QP factor between P and B [1.30]
--chroma-qp-offset <integer> QP difference between chroma and luma [0]
--aq-mode <integer> AQ method [1]
- 0: Disabled
- 1: Static AQ sensitivity
- 2: Fast auto AQ sensitivity
- 3: Slow auto AQ sensitivity
--aq-metric <integer> The metric used for AQ [0]
- 0: Original VAQ (complexity mask)
- 1: Modified VAQ ver. 0 (BM ver. 0)
- 2: Modified VAQ ver. 1 (BM ver. 1)
--aq-strength <float> Reduces blocking and blurring in flat and
textured areas. [1.0]
- 0.5: weak AQ
- 1.5: strong AQ
--aq-sensitivity <float> "Center" of AQ curve. [10.0]
- 5: most QPs are raised
- 10: good general-use sensitivity
- 15: most QPs are lowered
--aq2-strength <float> Use 2nd AQ (Haali's AQ) algorithm for support. [0
.0]
0.0: no 2nd AQ
1.1: strong 2nd AQ
--aq2-sensitivity <float> "Flatness" threshold to trigger 2nd AQ [15.0]
5: applies to almost all blocks
22: only flat blocks
--aq-debug <string> Filename for AQ debug log ["x264_aq_debug.aq"]
--fgo <int> Activates Film Grain Optimization. [0]
- 5: weak FGO
- 15: strong FGO

-p, --pass <1|2|3> Enable multipass ratecontrol
- 1: First pass, creates stats file
- 2: Last pass, does not overwrite stats file
- 3: Nth pass, overwrites stats file
--stats <string> Filename for 2 pass stats ["x264_2pass.log"]
--qcomp <float> QP curve compression: 0.0 => CBR, 1.0 => CQP [0.60
]
--cplxblur <float> Reduce fluctuations in QP (before curve compressio
n) [20.0]
--qblur <float> Reduce fluctuations in QP (after curve compression
) [0.5]
--zones <zone0>/<zone1>/... Tweak the bitrate of some regions of the vide
o
Each zone is of the form
<start frame>,<end frame>,<option>
where <option> is either
q=<integer> (force QP)
or b=<float> (bitrate multiplier)
--qpfile <string> Force frametypes and QPs
--aq-cssim <float> Force all macroblocks to this SSIM

Analysis:

-A, --partitions <string> Partitions to consider ["p8x8,b8x8,i8x8,i4x4"]
- p8x8, p4x4, b8x8, i8x8, i4x4
- none, all
(p4x4 requires p8x8. i8x8 requires --8x8dct.)
--direct <string> Direct MV prediction mode ["spatial"]
- none, spatial, temporal, auto
--direct-8x8 <-1|0|1> Direct prediction size [1]
- 0: 4x4
- 1: 8x8
- -1: smallest possible according to level
-w, --weightb Weighted prediction for B-frames
--me <string> Integer pixel motion estimation method ["hex"]
- dia: diamond search, radius 1 (fast)
- hex: hexagonal search, radius 2
- umh: uneven multi-hexagon search
- imh: improved multi-hexagon search
- esa: exhaustive search
- tesa: hadamard exhaustive search (slow)
--merange <integer> Maximum motion vector search range [16]
--mvrange <integer> Maximum motion vector length [-1 (auto)]
--mvrange-thread <int> Minimum buffer between threads [-1 (auto)]
-m, --subme <integer> Subpixel motion estimation and mode decision [6]
- 1: SAD mode decision, one qpel iteration
- 2: SATD mode decision
- 3-5: Progressively more qpel
- 6: RD mode decision for I/P-frames
- 7: RD mode decision for all frames
- 8: RD refinement for I/P-frames
- 9: RD refinement for all frames
--me-prepass Run an ME prepass on predictors. Requires subme 3
or higher.
--psy-rd Strength of psychovisual optimization ["1.0:0.0"]
#1: RD (requires subme>=6)
#2: Trellis (requires trellis, experimental)
--mixed-refs Decide references on a per partition basis
--no-chroma-me Ignore chroma in motion estimation
--lowpass Enables adaptive lowpass filter
-8, --8x8dct Adaptive spatial transform size
-t, --trellis <integer> Trellis RD quantization. Requires CABAC. [0]
- 0: disabled
- 1: enabled only on the final encode of a MB
- 2: enabled on all mode decisions
--qns Quantizer noise shaping. Requires trellis
--no-fast-pskip Disables early SKIP detection on P-frames
--fast-ref-search Uses faster ME algorithms on older reference frame
s. [1]
- 0: disabled
- 1: normal (minimal quality loss)
- 2: aggressive (greater speed gain and qualit
y loss)
--no-dct-decimate Disables coefficient thresholding on P-frames
--nr <integer> Noise reduction [0]

--deadzone-inter <int> Set the size of the inter luma quantization deadzo
ne [21]
--deadzone-intra <int> Set the size of the intra luma quantization deadzo
ne [11]
Deadzones should be in the range 0 - 32.
--cqm <string> Preset quant matrices ["flat"]
- jvt, flat
--cqmfile <string> Read custom quant matrices from a JM-compatible fi
le
Overrides any other --cqm* options.
--cqm4 <list> Set all 4x4 quant matrices
Takes a comma-separated list of 16 integers.
--cqm8 <list> Set all 8x8 quant matrices
Takes a comma-separated list of 64 integers.
--cqm4i, --cqm4p, --cqm8i, --cqm8p
Set both luma and chroma quant matrices
--cqm4iy, --cqm4ic, --cqm4py, --cqm4pc
Set individual quant matrices

Video Usability Info (Annex E):
The VUI settings are not used by the encoder but are merely suggestions to
the playback equipment. See doc/vui.txt for details. Use at your own risk.

--overscan <string> Specify crop overscan setting ["undef"]
- undef, show, crop
--videoformat <string> Specify video format ["undef"]
- component, pal, ntsc, secam, mac, undef
--fullrange <string> Specify full range samples setting ["off"]
- off, on
--colorprim <string> Specify color primaries ["undef"]
- undef, bt709, bt470m, bt470bg
smpte170m, smpte240m, film
--transfer <string> Specify transfer characteristics ["undef"]
- undef, bt709, bt470m, bt470bg, linear,
log100, log316, smpte170m, smpte240m
--colormatrix <string> Specify color matrix setting ["undef"]
- undef, bt709, fcc, bt470bg
smpte170m, smpte240m, GBR, YCgCo
--chromaloc <integer> Specify chroma sample location (0 to 5) [0]

Input/Output:

-o, --output Specify output file
--sar width:height Specify Sample Aspect Ratio
--fps <float|rational> Specify framerate
--seek <integer> First frame to encode
--frames <integer> Maximum number of frames to encode
--level <string> Specify level (as defined by Annex A)

-v, --verbose Print stats for each frame
--progress Show a progress indicator while encoding
--quiet Quiet Mode
--no-psnr Disable PSNR computation
--no-ssim Disable SSIM computation
--threads <integer> Parallel encoding
--threads-boost <integer> Tune priority for encoding threads [0]
-2: LOWEST
-1: BELOW_NORMAL
0: NORMAL
1: ABOVE_NORMAL
2: HIGHEST
--thread-queue <integer> Number of delay frames for thread sync
--thread-input Run Avisynth in its own thread
--thread-input-boost <integer> Tune priority for input thread (Values as i
n 'threads-boost') [0]
--non-deterministic Slightly improve quality of SMP, at the cost of re
peatability
--asm <integer> Override CPU detection
--no-asm Disable all CPU optimizations
--visualize Show MB types overlayed on the encoded video
--dump-yuv <string> Save reconstructed frames
--sps-id <integer> Set SPS and PPS id numbers [0]
--aud Use access unit delimiters
--no-opts Disable writing options in SEI
--no-b-delay Eliminate initial delay for B-frames in MP4
--timescale <integer> Specify timescale
--tcfile <string> Force timestamps
--nal-hrd Use NAL HRD parameters
--pulldown <integer> Use 3:2 pulldown
- 32: TBT,BT,BTB,BT pattern
- 64: triple,double *recommended for 720p

[dotBL0t]

And what's with the settings being removed? I mean, if you want us to compare, how do we know you're not using higher quality settings for the fgo sample? What, we're supposed to take your word on it?

Settings are removed because of the the clips were trimmed with mkvcreator from the whole movie. The settings stored in the video stream can be easily modified with an hexeditor, so, If I have ever wanted to cheat, it would have been better for me to do something like that rather than delete all of them. :rolleyes:

Sorry if my english is not correct...

@shon3i

Could it be possible to have only the patch to be applied to the sources from git? I'm using linux and I always compile x264 from sources for my encodings

Found it on the rar with all the other patches...

P.S.
I found a scene where psy is far better than fgo. Upload is on it's way...

EDIT:

Here it is:

http://www.files.to/get/426723/53vr7px18k
http://www.files.to/get/426724/bqgeen6hj7

[Terranigma]

Settings are removed because of the the clips were trimmed with mkvcreator from the whole movie.

Then wouldn't it be more appropriate to trim a portion of the movie through avisynth, then encode? I think so. :)

[mikeytown2]

So does this mean that x264 is the first H.264 encoder to support Film Grain Modeling? FGO is Film Grain Optimization right?
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Software_encoder_feature_comparison

[Dark Shikari]

So does this mean that x264 is the first H.264 encoder to support Film Grain Modeling? FGO is Film Grain Optimization right?
http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Software_encoder_feature_comparisonNo, FGO is "film grain optimization", which is completely unrelated to FGM.

And no, there are encoders which support FGM; it was part of the HD DVD standard.

[smok3]

there are encoders which support FGM; it was part of the HD DVD standard.
anything available to mortals? (but then one would need a decoder as well :))

[mikeytown2]

I think the better question is what is Film Grain Modeling and does it have the potential to be better then PSY-RDO/FGO. Just because it's an option doesn't always mean its a good one.

[shon3i]

FGM is post process filter, and work like for example ffdshow noise filter, but with some instructions based on scene. In encoding, encoder write grain info into bitstream, and FGM compactible decoder, read FGM info and reconstruct grain pattern, where encoder tell to do that

So adding grain to whole movie in ffdshow, maybe not look good, but add grain on good positions can be usefull, so FGM is probably "good one".

[smok3]

what i hope it does is that encoder doesn't have to waste bits on random grain encoding, as grain can be visually losslessly represented with a math model (a good approximation of the original hopefully). (similar to something like SBR in audio?)

[Gabriel_Bouvigne]

(similar to something like SBR in audio?)
I'd rather say similar to PNS in audio.

[shon3i]

I'd rather say similar to PNS in audio.
Exactly, good comparation.

[Tack]

FGM is post process filter, and work like for example ffdshow noise filter
Really? Wouldn't it be much more effective for FGM to be in-loop?

[LoRd_MuldeR]

Really? Wouldn't it be much more effective for FGM to be in-loop?

AFAIK the FGM works with randomness, so the encoder cannot know how the decoded/processed frame will look like in advance.

Hence loop is not possible. I might be mistaken...

[akupenguin]

You don't want FGM in-loop, that would contaminate the inter prediction. FGM works be separating the video into "signal" and "noise", where signal is denoised and can be effectively inter-predicted, and noise is independent for each frame and is just parameterized as output of a random number generator. The noise part can only hurt prediction of the signal if you include it in the inter prediction.