Psy RDO: Official testing thread (version 0.6 out!) [Archive]

Dark Shikari

31st May 2008, 19:04

Psychovisually optimized rate-distortion optimization

Experimental Patch: Psy RD 0.6 (updated for r950) (http://pastebin.com/m645aae89)
Build: r937, version 0.6 (http://www.mediafire.com/?rhacap8ja1e)

Version 0.6 changes:

1. Psy trellis (adjustable separately on commandline) included and on by default.
2. Automatically adjust chroma QP offset to compensate for the higher quants psy RD/trellis result in.
3. Psy trellis allows trellis=1 now.

Version 0.3-0.5 changes:

1. Much faster, by caching half the SATDs that need to be done.
2. Warn the user if trellis 1 is enabled--and disable trellis--if psy RD is on.
3. Psy RD strength is now a decimal value with default 1.0. Don't touch it unless you have good reason.
4. Psy RD strength now automatically scales based on quantizer. This is done internally--the "strength" is a multiplier to this internal value.

How to use it:

Its on by default. Adjust the strength with --psy-rd. That's it.

How it works (simply): the human eye doesn't just want the image to look similar to the original, it wants the image to have similar complexity. Therefore, we would rather see a somewhat distorted but still detailed block than a non-distorted but completely blurred block. The result is a bias towards a detailed and/or grainy output image, a bit like xvid except that its actual detail rather than ugly blocking.

How it works (full explanation): read the comment in the patch.

gav1577

31st May 2008, 19:21

If it isn't obvious already, this is going to destroy your PSNR and SSIM.

Great work Dark Shikari is the above anything to worry about ? i am a noob when it comes x264

Dark Shikari

31st May 2008, 19:22

Great work Dark Shikari is the above anything to worry about ? i am a noob when it comes x264It only matters if you think that numbers are more important than how the video actually looks. :p

Sagittaire

31st May 2008, 19:28

Only 84 lines for the patch ... ?

gav1577

31st May 2008, 19:30

Ha ha the picture is more important IMHO. is there any cmd switch
for this patch or is automatically activated with certain settings ?
Thanks nevermind you just edited and answered my question thanks :)

Dark Shikari

31st May 2008, 19:32

Ha ha the picture is more important IMHO. is there any cmd switch
for this patch or is automatically activated with certain settings ?
ThanksIts on by default any time you're using RDO. As such this is a patch for testing purposes and not for something to apply to every modified build out there, since you can't turn it off ;)Only 84 lines for the patch ... ?Yup, and a large portion is comments ;)

As you can tell the code is heavily macroed to reduce duplication; unwrapped it'd be another dozen lines or two. But overall the patch isn't too complicated; I'm only changing how x264 views "distortion" in RDO.

guada2

31st May 2008, 19:44

"Dark is a photoshop fgox264 .
Very god job.

Some questions:

- at what bitrate is it useful?
- is it compatible with grain opt on quickly scene?

desta

31st May 2008, 19:58

Me and my "2pass encode" questions again.... Would there be a worthwhile benefit in enabling this for both passes, or would just the 2nd pass suffice?

Sagittaire

31st May 2008, 20:06

Me and my "2pass encode" questions again.... Would there be a worthwhile benefit in enabling this for both passes, or would just the 2nd pass suffice?

And as always ... no. Because first pass is just a statistical reference for 2nd pass Rate Control. Very fine first pass (crf mode with same setting with close bitrate) will produce marginal better overall quality (it's just Rate Control optimisation).

desta

31st May 2008, 21:26

And as always ... no. Because first pass is just a statistical reference for 2nd pass Rate Control. Very fine first pass (crf mode with same setting with close bitrate) will produce marginal better overall quality (it's just Rate Control optimisation).
It wasn't exactly a ridiculous question though either. We know AQ needs to be the same for both passes to work, and other settings need to be similar or the same to do their job properly. I have also had instances where using similar settings in both passes have made for a better encode, especially when using FGO, which this patch is to replace....

http://forum.doom9.org/showthread.php?p=1143777#post1143777

Adub

31st May 2008, 22:05

Damn DS!! You rule!! Keep the awesome quality patches coming!!

TheRyuu

31st May 2008, 22:12

- at what bitrate is it useful?
- is it compatible with grain opt on quickly scene?

1.) Any
2.) It is intended to replace fgo or at least 'should' replace it. (hope that answers your question since I do not understand it fully)

Gabriel_Bouvigne

31st May 2008, 23:03

Nitpicking: this is not really similar to "perceptual entropy", but quite similar to the "dropout prevention" used by several encoders (exemple: 3gpp HE-AACv2 reference encoder).

Dark Shikari

31st May 2008, 23:14

Nitpicking: this is not really similar to "perceptual entropy", but quite similar to the "dropout prevention" used by several encoders (exemple: 3gpp HE-AACv2 reference encoder).Explain?

techouse

1st June 2008, 00:05

I <3 Dark

Gabriel_Bouvigne

1st June 2008, 00:09

PE is a kind of rough complexity estimation of the frame done at early stage, and is usually done on a less granular scale. It is usually (PE is mainly a concept rather than a specific metric) not used within the RD/quantization stage. On the other hand, dropout prevention is something (usually enabled at low bitrates) that tries to preserve power per subband, even if the individual frequency bins are different, in order to avoid holes within the spectrum.

A simple dropout prevention scheme is described there:
http://www.3gpp.org/ftp/Specs/archive/26_series/26.403/26403-700.zip
section 5.6.1.1.2 "Avoidance of spectral holes"

techouse

1st June 2008, 00:33

http://techouse.project357.com/builds/x264_x86_r859_psy_rdo_techouse.7z

Source: x264 r859 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_2pass_vbv.9.diff

x264_fix_win_stdin.diff

x264.gaussian.cplxblur.01.diff

x264_hrd_pulldown.04_interlace.diff

x264_me-prepass_DeathTheSheep.diff

x264_progress.diff

x264_psy_rdo.diff (this patch is STILL IN TESTING but it pretty much replaces FGO; please test how it compares to FGO using my older build "x264_x86_r859_progress_techouse")

x264_rd-optimze_DeathTheSheep.diff

Please check http://forum.doom9.org/showthread.php?t=130364 and http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog for more info

Compiled by techouse on June 1st 2008, 01:21:49 CEST with GCC-4.3.0 on Windows Vista Business SP-1 32-bit.

Commandline used: ./configure&&make

Platform: X86
System: MINGW
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

IgorC

1st June 2008, 08:53

Dark Shikari

1st June 2008, 09:03

Some undesirable results:

With psy RDO
http://rapidshare.com/files/119246172/3xrdo_RDO.mp4.html

Without psy RDO
http://rapidshare.com/files/119247136/3_pass_NoRDO.mp4.html

Settings for 3 passes:
x264.exe --threads 3 --pass 3 --progress --stats "x264_stat.log" --qcomp 0.75 --bframes 3 --bime --weightb --subme 7 --keyint 500 --ref 16 --trellis 2 --mixed-refs --8x8dct --partitions all --b-rdo --direct auto --b-pyramid --bitrate 800 --no-fast-pskip --me umh --merange 16 --deblock -1:-1 --me-prepass -o 3xrdo.mp4 Ma.avs

If source is needed I can upload it later.Undesirable? The psy-RDO version looks a hell of a lot better (overall) to me. There's a little bit of increased ringing but the overall detail retention is an order of magnitude better.

A random example:

http://i31.tinypic.com/3355ssw.png

http://i30.tinypic.com/35jhwyd.png

Notice the vastly decreased blocking on the chest and the increased graininess in the background--plus of course the obvious, the face.

IgorC

1st June 2008, 09:05

Too much ringing and artifacts for my eyes

Dark Shikari

1st June 2008, 09:11

Too much ringing and artifacts for my eyesWell the non-psy-RDO version has far too much blurring for my eyes. The facial texture is completely flattened and there's blocking all over the place.

The slight ringing increase is because Psy-RD moved more bits to the background of the frame, forcing the quantizer up a little bit. If you don't like the bit distribution differential between the characters and the background, you could try lowering AQ strength, since both AQ and psy-RD are, in this case, moving around bits.

Sagittaire

1st June 2008, 09:29

Dark Shikari

1st June 2008, 09:36

Well I make test on Casino Royal (really grainy movie) and the old FGO produce really better result for the grain retention (--fgo 5 --trelli 2 vs --trelli 2). It's particuraly true for the very fine grain. If you want sample it's possible.Sure, toss a sample. There are two potential reasons why FGO could beat the current psy RD:

1. FGO uses an overlapped transform (2x2 SATD) while psy RD uses non-overlapped.

2. FGO uses a much smaller transform.

The former gets very slow for large transforms, so isn't very practical for this situation IMO. The latter issue is likely the same reason that FGO does worse than nothing on many sources; its aimed towards a very specific kind of "detail" rather than complexity in general.

Anyways, upload the source, I'm interested.

Edit: Oh, another possible issue is that FGO lowers B-frame quantizers and adjusts RD thresholds, which this doesn't (yet). Thus comparisons could potentially get misleading when trying to compare just the RD metric alone.

ToS_Maverick

1st June 2008, 09:47

Dark Shikari

1st June 2008, 09:53

how does Psy RDO work together with AQ, and especially with NO AQ?
how much is the grain retention depenend on the AQ with this patch?

i will definitely test this in the next days, when i got some time!I haven't tested much with regard to AQ; I've just been leaving it on default.

I assume its still probably a good idea to do so :p

Sagittaire

1st June 2008, 12:53

Anyways, upload the source, I'm interested.

Edit: Oh, another possible issue is that FGO lowers B-frame quantizers and adjusts RD thresholds, which this doesn't (yet). Thus comparisons could potentially get misleading when trying to compare just the RD metric alone.

Source is uncompressed FFV1 file ...

Here the sample:
- New psy mode
http://jfl1974.free.fr/upload/Sample_psy_01.mkv

- Old FGO mode
http://jfl1974.free.fr/upload/Sample_FGO_01.mkv

Yes it's perhaps bframe problem because in low motion scene grain retention is really good for FGO and grain retention is really better for PSY RDO in high motion scene. Anyway for HVS I think that grain retention for low motion part is really more important than grain retention in high motion part.

Here my profil for FGO encoding ...

@REM -----------------------------------------------------------
@REM
@REM Profil BluRay 1080p23.976 extra high quality
@REM
@REM -----------------------------------------------------------

@REM Source file name (suffit de mettre la source ici)
set E_SRC=Lossless.avs

@REM Set of quality (ici la qualité 1-50)
set E_BR=22

@REM Set of max bitrate (ici le bitrate max)
set MAX_BR=20000

@REM Set of Buffer (ici le buffer)
set BUF_BR=30000

@REM Set credit (frame de début du générique)
set CRE_FR=201560

@REM Set end credit (frame de fin du générique)
set END_FR=207442

@REM Profil

x264.exe --threads auto --thread-input --keyint 24 --min-keyint 1 --crf %E_BR% --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --mvrange 511 --level 4.1
--bframe 3 --b-pyramid --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -2:-2 --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct
--me "umh" --subme 7 --trellis 2 --no-fast-pskip --no-dct-decimate --aud --nal-hrd --sar 1:1 --cqmfile Sagittaire.cfg --aq-strength 1.00 --aq-mode 2 --fgo 5
--zone %CRE_FR%,%END_FR%,b=0.33 --progress -o 1080p_Q1.264 %E_SRC%

pause

sysKin

1st June 2008, 16:35

+#define DC_COEFS_MB(block,src,stride)\
+ dc_coefs[block][0] = h->pixf.sad[PIXEL_16x16]( zero, 0, src[0], stride ) >> 1;\
+ dc_coefs[block][1] = h->pixf.sad[PIXEL_8x8] ( zero, 0, src[1], stride ) >> 1;\
+ dc_coefs[block][2] = h->pixf.sad[PIXEL_8x8] ( zero, 0, src[2], stride ) >> 1;

Shouldn't that be stride/2 for chroma planes?

Dark Shikari

1st June 2008, 17:07

Shouldn't that be stride/2 for chroma planes?No, because x264 uses constant stride for macroblock analysis.

Dark Shikari

1st June 2008, 17:31

Source is uncompressed FFV1 file ...

Here the sample:
- New psy mode
http://jfl1974.free.fr/upload/Sample_psy_01.mkv

- Old FGO mode
http://jfl1974.free.fr/upload/Sample_FGO_01.mkvI can hardly tell the difference between then, but psy looks slightly better to me in the flattest areas (textures on the characters, etc).

Your test is a bit screwed up because you didn't use the same video clip for both though, so I suspect ratecontrol allocated bits somewhat differently ;)

I think its probably better to test psy RDO at low bitrates, because at high the differences are so slight that nobody is going to notice it anyways.

If there is a clear case that old FGO beats psy RDO, we want it to be very blatantly obvious so I can try to find the source of the issue.

MfA

1st June 2008, 18:04

Too much ringing and artifacts for my eyes
I don't particularly care for the overall effect either.

In theory the skin effect is nice ... but the problem with that is that apart from adding some texture it adds a spurious line to his neck. Structured artifacts are a complete no go IMO.

Dark Shikari

1st June 2008, 18:08

In theory the skin effect is nice ... but the problem with that is that apart from adding some texture it adds a spurious line to his neck. Structured artifacts are a complete no go IMO.Line? If you're looking at what I'm looking at, that's an artifact of AQ, not psy-RD, and exists on both...

Yoshiyuki Blade

1st June 2008, 18:30

The quality gain on Neo's black shirt stands out the most in the comparison. I'm really eager to see the results in anime (gonna try various bitrates), but since I'm in vietnam on vacation, I just have a lappy to test this out on ;_;. What can I expect on animated material where there's rarely any dark details on dark objects, or noise?

I knew I'd find myself wanting to tinker with encodes even while overseas lol.

Adub

1st June 2008, 18:51

Truthfully, I rather prefer the second picture, honestly. The jaggies introduced along all of the edges are making my eyes bleed. If this can be fixed by lowering aq, then great! But frankly, I will take something over the jaggies. Sorry DS.

asdfsauce

1st June 2008, 18:53

Dear God, that rapidshare capcha is the worst! Why do people use that site? It's horrible.. (no offense)

Sorry, so um, the Psy RDO screen for those matrix clips is the top one? To me that looks the best. There may be more artifacts but it doesn't have that artificial airbrushed look that I dislike most about h.264. It's all about seeing the forest through the trees. :)

MfA

1st June 2008, 18:56

Line? If you're looking at what I'm looking at, that's an artifact of AQ, not psy-RD, and exists on both...
I'm talking about the line in the small light area at the bottom of his neck, I can't see it in the other picture ... he also seems to have grown a scar on his forehead.
http://i278.photobucket.com/albums/kk105/_MfA_/head.png

PS. I have got to be honest though ... I have to either zoom in or reduce my resolution to see it clearly :)

Dark Shikari

1st June 2008, 19:02

It appears we're now getting down into the true danger of psy optimizations... not everyone agrees on the concept of "better" :p

MfA

1st June 2008, 19:12

How about a settable cut off for the frequencies considered in either dimension? Excluding lower frequencies would probably help prevent structured artifacts.

Dark Shikari

1st June 2008, 19:14

How about a settable cut off for the frequencies considered in either dimension? Excluding lower frequencies would probably help prevent structured artifacts.Excluding lower frequencies would completely ruin the effect though; in many of my test encodes there was an enormous benefit from the lower frequencies, especially in "300" at lower bitrates, but really in anything where the bitrate isn't high enough to flawlessly keep grain. I also suspect the dither-keeping effect depends strongly on lower frequencies.

I'd say the low frequencies are actually the primary reason that this beats FGO in many cases.

Structured artifacts aren't a large problem if they're small and don't stay between frames. Plus, trellis should usually handle getting rid of them anyways; at least it does in my experience.

Adub

1st June 2008, 19:33

New picture for people to compare based on IgorC's provided files.

Psy RDO is on top, "regular" is on bottom.
http://i34.photobucket.com/albums/d125/Merlin7777/rdovsnordo-1.png

The more noticeable part is around his figure.

Dark Shikari

1st June 2008, 19:39

The main issue just seems to be that psy RDO moves more bits to the background in order to keep the grain, losing bits elsewhere.

In almost all the cases I've tested, this results in a dramatic improvement (even in the areas that lose bits), but this is a particularly high contract situation, so it ends up ringing a bit more.

Of course, I prefer ringing to blurring, but that's just me.

MfA

1st June 2008, 19:43

Small moving objects as focal points in a scene seem pretty much worst case scenario for this method.

Dark Shikari

1st June 2008, 19:45

Small moving objects as focal points in a scene seem pretty much worst case scenario for this method.Which is somewhat odd, because the research actually shows that moving objects should be worse quality than they currently are (e.g. motion-based adaptive quantization).

akupenguin

1st June 2008, 19:47

Which is somewhat odd, because the research actually shows that moving objects should be worse quality than they currently are (e.g. motion-based adaptive quantization).
Not if they're the focus. Then you track that one object and the rest of the frame counts as moving.

Dark Shikari

1st June 2008, 19:52

Not if they're the focus. Then you track that one object and the rest of the frame counts as moving.Hmm, true. Of course, its hard to make an algorithm that decides what is the "focus" of the scene... :p

Dark Shikari

1st June 2008, 20:24

New patch. Updates:

1. Ignores chroma. This speeds things up and didn't seem to change things visually at all. Even if we used chroma, it should probably be weighted a lot lower anyways.

2. Raises B-RDO threshold.

3. Now available as a commandline option (--rdcmp).

jethro

1st June 2008, 20:32

Nice discussion. The differences between what people consider to be better might be due to their displays (because i don't think our eyes differ this much). For example, in x264 encodes I don't see much ringing on my monitor but i definitely see blurring and ugly smearing of details (esp without VAQ). This new RD seems to make pictures more 'dirty' which is similar in effect to dct noise mentioned in xvid encodes. Of course, there are also preferences but I can't believe displays aren't a factor.

Truthfully, I rather prefer the second picture, honestly. The jaggies introduced along all of the edges are making my eyes bleed. If this can be fixed by lowering aq, then great! But frankly, I will take something over the jaggies. Sorry DS.
Yes, the jaggies come from VAQ. I noticed that default AQ 1.0 seems too strong for low resolutions as object edges get few bits. I often find myself using AQ 0.5-0.7 for something like 720x304. For HD res actually AQ 1.0 is fine and AQ 0.5 gets blocky.

EDIT: I'd like to add that I also prefer details over artifacts:)

Dark Shikari

1st June 2008, 20:54

Here's a really dramatic example of Psy RDO's effectiveness:

No Psy RDO (http://www.mediafire.com/?wtlmwi021zh)

Psy RDO (http://www.mediafire.com/?acuumi1sino)

Atak_Snajpera

1st June 2008, 21:12

Screenshots from frame 600

PSY ON
http://img519.imageshack.us/img519/3011/psygb2.th.png (http://img519.imageshack.us/my.php?image=psygb2.png)

PSY OFF
http://img204.imageshack.us/img204/7977/nopsytg8.th.png (http://img204.imageshack.us/my.php?image=nopsytg8.png)

IgorC

1st June 2008, 22:23

I think it also depends of resolution. My sample had dvd resolution while new psy rdo maybe more optimized for HD. Artifacts look different for HD and DVD. And of course it depends of display and other conditions of watching samples.

Sagittaire

1st June 2008, 22:42

Edit: Oh, another possible issue is that FGO lowers B-frame quantizers and adjusts RD thresholds, which this doesn't (yet). Thus comparisons could potentially get misleading when trying to compare just the RD metric alone.

After size analyse I think that it's simply a different complexity analysis. For really grainy picture (with really fine grain) fgo mode will use really more bit than psy mode.

http://jfl1974.free.fr/upload/1080p_3.264_020491.jpg (http://jfl1974.free.fr/upload/1080p_3.264_020491.png) vs http://jfl1974.free.fr/upload/1080p_Q1.264_020491.jpg (http://jfl1974.free.fr/upload/1080p_Q1.264_020491.png) vs http://jfl1974.free.fr/upload/Casino_MCCLI_BD9.264_020489.jpg (http://jfl1974.free.fr/upload/Casino_MCCLI_BD9.264_020489.png)

PSY vs FGO vs Elecard

31 832 vs 64 267 vs 63 751 bits (all frame are Pframe)

And here FGO produce by far the best quality ...

Razorholt

1st June 2008, 23:03

After size analyse I think that it's simply a different complexity analysis. For really grainy picture (with really fine grain) fgo mode will use really more bit than psy mode.

http://jfl1974.free.fr/upload/1080p_3.264_020491.jpg (http://jfl1974.free.fr/upload/1080p_3.264_020491.png) vs http://jfl1974.free.fr/upload/1080p_Q1.264_020491.jpg (http://jfl1974.free.fr/upload/1080p_Q1.264_020491.png) vs http://jfl1974.free.fr/upload/Casino_MCCLI_BD9.264_020489.jpg (http://jfl1974.free.fr/upload/Casino_MCCLI_BD9.264_020489.png)

PSY vs FGO vs Elecard

31 832 vs 64 267 vs 63 751 bits

And here FGO produce by far the best quality ...

How about the original frame? How many bits?

Adub

1st June 2008, 23:09

I agree. FGO does seem to come out better here.

Dark Shikari

1st June 2008, 23:11

I agree. FGO does seem to come out better here.Given that its frame size is double that of psy RDO, how am I not surprised? :p

If its a B-frame, you can compensate for that by setting pbratio lower... that's what FGO does anyways and its probably wrong to put anything into mainline x264 that changes settings like that when the user should be in control of it.

If it isn't, maybe you didn't use the same bitrate for the two clips...?

Also, note that here, the Elecard frame isn't even the same frame of the video...

Sagittaire

1st June 2008, 23:11

How about the original frame? How many bits?

Source is FFV1 master ...

Sagittaire

1st June 2008, 23:15

Given that its frame size is double that of psy RDO, how am I not surprised? :p

Yes not surprising for quality. The surprise come from decision. Here FGO seem make better choice than PSY mode. It's a really complexe frame with very fine but visible grain (grain on blue sky)

If its a B-frame, you can compensate for that by setting pbratio lower... that's what FGO does anyways and its probably wrong to put anything into mainline x264 that changes settings like that when the user should be in control of it.

Only Pframe here.

If it isn't, maybe you didn't use the same bitrate for the two clips...?

6900 Kbps for overall bitrate (more than 200 000 frames).

Also, note that here, the Elecard frame isn't even the same frame of the video...

yes because it's bframe for Elecard. Anyway all the Pframe for the encoded sequence are the same size with equivalent grain complexity for picture source. So the comparison is correct here.

Razorholt

1st June 2008, 23:16

Source is FFV1 master ...

Thanks Sagittaire. I just wanted to find out whether PSY was actually increasing the size of the video, as FGO does.

Dark Shikari

1st June 2008, 23:16

Yes not surprising for quality. The surprise come from decision. Here FGO seem make better choice than PSY mode. It's a really complexe frame with very fine but visible grain (grain on blue sky)I'm proposing that FGO has absolutely nothing to do with the double-size frame and that there has been user error here, such as comparing B-frames with different pbratio or encoding with different bitrates. Especially since the clips you posted earlier were not even of the same video clip, I don't exactly trust that you've done everything right here...

Sagittaire

1st June 2008, 23:29

ToS_Maverick

2nd June 2008, 01:48

about the frequencies and the quantization...

that sounds like Psy RDO works somehow like a custom matrix? I understand that a matrix uses fixed values, but it goes into the same direction, be more "kind" to the lower frequencies, to avoid blocking, preserving a good "look"...

Sagittaire

2nd June 2008, 08:10

I'm proposing that FGO has absolutely nothing to do with the double-size frame and that there has been user error here, such as comparing B-frames with different pbratio or encoding with different bitrates. Especially since the clips you posted earlier were not even of the same video clip, I don't exactly trust that you've done everything right here...

Well I find the problem ... it's a Rate Control problem between first and second pass. With the same final bitrate crf mode produce really better result.

2 pass mode with fast first pass:

x264.exe --threads 3 --thread-input --keyint 24 --min-keyint 2 --vbv-maxrate 20000 --vbv-bufsize 30000 --mvrange 511 --level 4.1 --bframe 3 --b-pyramid --bime --weightb --ref 1 --mixed-refs --direct auto --deblock -2:-2 --bitrate 6900 --pass 1 --stats "casino.log" --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct --me "hex" --subme 5 --trellis 0 --aq-mode 0 --aq-strength 0.00 --aud --nal-hrd --sar 1:1 --cqmfile Sagittaire.cfg --progress -o NUL Lossless.avs

And after I use always the same casino.log stat for all the encoding.

x264.exe --threads 3 --thread-input --keyint 24 --min-keyint 1 --vbv-maxrate 20000 --vbv-bufsize 30000 --mvrange 511 --level 4.1 --bframe 3 --b-pyramid --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -2:-2 --bitrate 6900 --pass 2 --stats "casino.log" --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct --me "umh" --subme 7 --trellis 2 --aq-mode 2 --aq-strength 1.00 --no-fast-pskip --no-dct-decimate --aud --nal-hrd --sar 1:1 --cqmfile Sagittaire.cfg --zone 201560,207442,b=0.33 --progress -o 1080p_3.264 Lossless.avs

Quality mode:

x264.exe --threads auto --thread-input --keyint 24 --min-keyint 1 --crf %E_BR% --vbv-maxrate %MAX_BR% --vbv-bufsize %BUF_BR% --mvrange 511 --level 4.1 --bframe 3 --b-pyramid --b-rdo --bime --weightb --ref 3 --mixed-refs --direct auto --deblock -2:-2 --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct --me "umh" --subme 7 --trellis 2 --no-fast-pskip --no-dct-decimate --aud --nal-hrd --sar 1:1 --cqmfile Sagittaire.cfg --aq-strength 1.00 --aq-mode 2 --zone %CRE_FR%,%END_FR%,b=0.33 --progress -o 1080p_Q1.264 %E_SRC%

With 2 pass encoding and exactly the same setting than crf mode (and same final bitrate) I have completely different Rate Control (for example 31 832 bits vs 70 926 bits for frame 20 491). VAQ + PSY seem imply major modification in RC between first and second pass. It's perhaps necessary to use VAQ and PSY in first pass too ... ???

Dark Shikari

2nd June 2008, 08:11

With 2 pass encoding and exactly the same setting than crf mode (and same final bitrate) I have completely different Rate Control (for example 31 832 bits vs 70 926 bits for frame 20 491). VAQ + PSY seem imply major modification in RC between first and second pass. It's perhaps necessary to use VAQ and PSY in first pass too ... ???No, its really mainly VAQ. Its always been the case that AQ should be on in the first pass.

elguaxo

2nd June 2008, 15:58

thanks Dark Shikari! this looks very promising. :)

Dark Shikari

2nd June 2008, 21:45

Here's a really dramatic test, Touhou as always: Linkage (http://mirror05.x264.nl/Dark/psy/)

And another one, from World in Conflict, with FGO vs Psy RDO: Linkage (http://imk.cx/junk/a2a_3mbit.html)

gav1577

2nd June 2008, 22:18

New patch. Updates:

3. Now available as a commandline option (--rdcmp).

Does this mean the patch now disabled by default and the switch above will activate it ? :confused:

Dark Shikari

2nd June 2008, 22:29

Does this mean the patch now disabled by default and the switch above will activate it ? :confused:Nope, still on by default. It can now be switched on and off.

TheRyuu

2nd June 2008, 22:33

http://forum.doom9.org/showthread.php?p=1145012#post1145012

mahsah

3rd June 2008, 02:49

Tried using Psy RDO on a movie that I had processed with MVdegrain3, limitedsharpenfaster, and gradfun2db to see how it did with the dithering (the original grain was very distracting). Encoded at 2 pass 1500 kbps, base cmdline:

--pass 2 --bitrate 1500 --stats ".stats" --deadzone-inter 10 --deadzone-intra 10 --ref 5 --mixed-refs --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 7 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh

Original:
http://img88.imageshack.us/img88/4760/origfo3.png
Default Command line:
http://img88.imageshack.us/img88/2306/defaultqj2.png
--fgo 10
http://img508.imageshack.us/img508/5979/fgocj7.png
Psy RDO
http://img209.imageshack.us/img209/4286/psyru0.png

gav1577

3rd June 2008, 03:23

Thanks Dark Shikari & Wizboy11

desta

3rd June 2008, 06:25

Regarding trellis; I was led to believe that trellis=2 was generally a bad thing. Has that changed now because of the way psy rdo interacts with it, or is it still advisable to avoid it if possible?

Obviously with trellis=1 being advised against with psy rdo, would that mean deadzones are the safest bet?

Dark Shikari

3rd June 2008, 07:40

Regarding trellis; I was led to believe that trellis=2 was generally a bad thing. Has that changed now because of the way psy rdo interacts with it, or is it still advisable to avoid it if possible?Trellis 2 is not a bad thing at all with psy RD; the problem before was that it encouraged blurring because RD would often prefer blurrier modes, and trellis would generate blurrier modes. But now, RD prefers *less* blurry modes.

desta

3rd June 2008, 10:18

That's good to know, thanks. :)

techouse

3rd June 2008, 13:36

So was anyone able to fix the me-prepass patch so that it can work with psy_rdo 0.22?

Sagittaire

3rd June 2008, 13:42

So was anyone able to fix the me-prepass patch so that it can work with psy_rdo 0.22?

This patch is not really usefull for the quality. Use too many patch is not very good too.

DeathTheSheep

3rd June 2008, 18:07

"This patch is not really useful for the quality." --
I'd have to disagree with you there, Sagittaire. ;)

Anyway, for myself, visually speaking, this psy RDO seems to do a fairly decent job at knocking the blurriness down and retaining detail, even if this detail isn't theoretically "exact." :p I can live with the scars on Neo, too--the motion of subsequent frames minimizes that effect anyway. In the context of real viewing, one is not likely to pause, zoom in, and analyze Neo's face carefully for evidence of distortion, but rather to watch the video at normal speed and notice instead the obvious decrease in blurring and ugly blocking.

Episodio1

3rd June 2008, 19:12

"...and notice instead the obvious decrease in blurring and ugly blocking."

That's it. Thanks a lot. :)

SquallMX

4th June 2008, 02:10

Dark Shikari you´re the best, the decrease in blurring is amazing, especially for low/mid bitrates:

Original:
http://www.imagenchile.com/img/f4cd0243a7c650a489cb7a8f8940faf4/tOriginal2.png (http://www.imagenchile.com/view.php?img=f4cd0243a7c650a489cb7a8f8940faf4)
http://www.imagenchile.com/img/df7ac70a0dbb75d5d320667cdf414385/tOriginal3.png (http://www.imagenchile.com/view.php?img=df7ac70a0dbb75d5d320667cdf414385)

No PSY:
1-Pass:
Job commandline: "D:\Archivos de programa\megui\tools\x264\x264.exe" --pass 1 --bitrate 3308 --stats "F:\Archivos de Programa\WatchHDTV\Ok" --level 4.1 --keyint 240 --min-keyint 24 --bframes 2 --b-pyramid --filter -2,-1 --subme 1 --partitions none --qpmax 40 --vbv-maxrate 24000 --me dia --merange 12 --threads auto --thread-input --sar 1:1 --progress --no-psnr --output NUL "F:\Archivos de Programa\WatchHDTV\Pantera.avs"
2-Pass:
Job commandline: "D:\Archivos de programa\megui\tools\x264\x264.exe" --pass 2 --bitrate 3308 --stats "F:\Archivos de Programa\WatchHDTV\Ok" --level 4.1 --keyint 240 --min-keyint 24 --ref 2 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --bime --weightb --filter -2,-1 --trellis 1 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmax 40 --vbv-maxrate 24000 --merange 12 --threads auto --thread-input --sar 1:1 --progress --no-psnr --output "F:\Archivos de Programa\WatchHDTV\Pantera.mp4" "F:\Archivos de Programa\WatchHDTV\Pantera.avs"

http://www.imagenchile.com/img/01f206edf0afe92996e13e05915f908f/tNoPSY2.png (http://www.imagenchile.com/view.php?img=01f206edf0afe92996e13e05915f908f)
http://www.imagenchile.com/img/10c3bf4f88c1189b0baee4a43535ffe2/tNoPSY3.png (http://www.imagenchile.com/view.php?img=10c3bf4f88c1189b0baee4a43535ffe2)

SSIM Mean Y:0.9884279

PSY:
1-Pass:
Job commandline: "D:\Archivos de programa\megui\tools\x264\x264.exe" --pass 1 --bitrate 3308 --stats "F:\Archivos de Programa\WatchHDTV\Ok" --level 4.1 --keyint 240 --min-keyint 24 --bframes 2 --b-pyramid --filter -2,-1 --subme 1 --partitions none --qpmax 40 --vbv-maxrate 24000 --me dia --merange 12 --threads auto --thread-input --sar 1:1 --progress --no-psnr --output NUL "F:\Archivos de Programa\WatchHDTV\Pantera.avs"

2-Pass:
Job commandline: "D:\Archivos de programa\megui\tools\x264\x264.exe" --pass 2 --bitrate 3308 --stats "F:\Archivos de Programa\WatchHDTV\Ok" --level 4.1 --keyint 240 --min-keyint 24 --ref 2 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 6 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmax 40 --vbv-maxrate 24000 --merange 12 --threads auto --thread-input --sar 1:1 --progress --no-psnr --output "F:\Archivos de Programa\WatchHDTV\Panterapsy.mp4" "F:\Archivos de Programa\WatchHDTV\Pantera.avs"

SSIM Mean Y:0.9867381

http://www.imagenchile.com/img/9ee4bb79390adbba92e8feb5e09b05d9/tPSY2.png (http://www.imagenchile.com/view.php?img=9ee4bb79390adbba92e8feb5e09b05d9)
http://www.imagenchile.com/img/a1afb43073ac41cbb252630dd456de16/tPSY3.png (http://www.imagenchile.com/view.php?img=a1afb43073ac41cbb252630dd456de16)

:thanks:

bokonon

4th June 2008, 11:29

@SquallMX

Please let me know what build you are using to test with....

is there a switch to turn it off even when using --subme 7 and -b-rdo ?

nevermind:
x264.869.modified.exe (http://www.mediafire.com/?xb4ittdi0nz)
(alt DL link (http://www.zshare.net/download/130689194e58f8bb/))

x264 Rev. 869 Modified Patch Build
Avis Input, mp4 output, pthreads config.

Built with GCC 3.4.5, make fprofiled, and statically linked pthreads. (means no pthreads.dll required in x264 directory)

Patches:
x264_gxRC.diff
x264.gaussian.cplxblur.01.diff
x264_hrd_pulldown.04_interlace.diff
x264_me-prepass_DeathTheSheep.01.diff
x264_progress.diff
x264_psyRDO_0.22.diff

The x264_fix_win_stdin.diff patch has been committed into the git so that has been left out.

Notes:
See the psyRDO thread (http://forum.doom9.org/showthread.php?t=138293) on usage of it although I briefly explained it in an above post.
Option: --rdcmp
Usage:
--rdcmp psy (psy rdo)
--rdcmp ssd (regular)
Psy RDO is on by default. at subme levels 6 and 7. 7 + b-rdo is best.
Read psyRDO thread for more info regarding it.

me-prepass:
Use --me-prepass flag to activate, off by default
Runs a half-pel search at a slight speed cost to improve quality with any --me mode.

x264_gxRC.diff:
Activated at subme levels 6 and 7, basically increases quality at little to no speed reduction.

x264_progress.diff:
Adds a little progress thingy at the top of the x264 window. Neat feature.

techouse

5th June 2008, 02:02

This patch is not really usefull for the quality. Use too many patch is not very good too.

I fixed the me-prepass patch! However, has to be applied after the psy_rdo patch.

DOWNLOAD: http://pastebin.com/f62aea32f

Razorholt

5th June 2008, 20:42

I fixed the me-prepass patch!

Is it REALLY worth it? Maybe Wizboy or Bobor can try and compile an x264 version with the fixed me-prepass patch for us to test? :D

Thanks,
- Dan

Stakiman

5th June 2008, 23:10

After various tests I came to a conclusion that this patch is extremely useful for grain keeping. Thanks DarkShikari for the creation of it! Here are some screens from my tests. The B-frame is not very good but the P-frames are amazing. Without PSY_RDO or FGO this would look without grain.

Source vs Encode
http://achumpatoxford.com/u/files/55/91f5e19f819733ed60b9a1ca0afbf85d_thumb.png (http://achumpatoxford.com/u/files/55/91f5e19f819733ed60b9a1ca0afbf85d.png) http://achumpatoxford.com/u/files/55/f98863cbe31c1c5746d499a6829c6a6b_thumb.png (http://achumpatoxford.com/u/files/55/f98863cbe31c1c5746d499a6829c6a6b.png)
http://achumpatoxford.com/u/files/55/Hooligans/1e58e93cf20dc267827da6e35825406b_thumb.png (http://achumpatoxford.com/u/files/55/Hooligans/1e58e93cf20dc267827da6e35825406b.png) http://achumpatoxford.com/u/files/55/Hooligans/9f640acd8ef5d6bf40174a73db308fad_thumb.png (http://achumpatoxford.com/u/files/55/Hooligans/9f640acd8ef5d6bf40174a73db308fad.png)
http://achumpatoxford.com/u/files/55/Hooligans/2359e169adb5b49f13e7338767688f4a_thumb.png (http://achumpatoxford.com/u/files/55/Hooligans/2359e169adb5b49f13e7338767688f4a.png) http://achumpatoxford.com/u/files/55/Hooligans/fba38548db1cae551d3f8f1740647ccc_thumb.png (http://achumpatoxford.com/u/files/55/Hooligans/fba38548db1cae551d3f8f1740647ccc.png)
http://achumpatoxford.com/u/files/55/Hooligans/7cfac15056f601d220f80662875580ac_thumb.png (http://achumpatoxford.com/u/files/55/Hooligans/7cfac15056f601d220f80662875580ac.png) http://achumpatoxford.com/u/files/55/Hooligans/a5a283e3ee9e086bf95e96946444378e_thumb.png (http://achumpatoxford.com/u/files/55/Hooligans/a5a283e3ee9e086bf95e96946444378e.png)
http://achumpatoxford.com/u/files/55/Hooligans/225571282676a5ae36fc3d7411fa977b_thumb.png (http://achumpatoxford.com/u/files/55/Hooligans/225571282676a5ae36fc3d7411fa977b.png) http://achumpatoxford.com/u/files/55/Hooligans/9091d938bb984850b4fab48fdd63e980_thumb.png (http://achumpatoxford.com/u/files/55/Hooligans/9091d938bb984850b4fab48fdd63e980.png)

mahsah

6th June 2008, 02:49

How do you think this would work on anime? Could it be used with gradfun2db to hide DCT blocks?

Dark Shikari

6th June 2008, 02:50

How do you think this would work on anime? Could it be used with gradfun2db to hide DCT blocks?Yes, in my experience so far it is incredibly good at keeping the dither that gradbun2db introduces as long as you give it enough bitrate (while without, regular x264 will generally butcher banding even at absurdly high bitrates).

desta

6th June 2008, 03:13

Dark Shikari

6th June 2008, 03:18

I've tried it on quite a bit of animated material now, and have got to say I'm very impressed.

Would I be right in assuming that although psy rdo is activated by default at >subme 6, it's optimised to process an image based on how grainy/noisy it is, including fine texture/detail, etc (in other words good on clean, grainy, or mixed footage)... whereas fgo by nature assumes a source is grainy/noisy, and could therefore be detrimental to a source that has both clean and grainy scenes?Both psy RDO and FGO attempt to make the output have the same <metric> as the input. But you are sort of correct, the metric used by psy RDO will generally be more friendly towards all types of complexity, not merely grain.

desta

6th June 2008, 03:23

Dark Shikari

6th June 2008, 03:25

Brilliant, thanks. I know you said the object of psy rdo was to eventually replace fgo. Is that likely soon? Would you consider it to be more efficient than fgo already, or do you think they both still have their place?I think its more efficient, but I haven't done enough testing.

One thing I may see is if I can combine the two; Psy RD uses a 4x4 and 8x8 transform for comparison, while FGO uses a 2x2. Maybe I could combine all three transforms? :p

gav1577

6th June 2008, 04:10

I think its more efficient, but I haven't done enough testing.

One thing I may see is if I can combine the two; Psy RD uses a 4x4 and 8x8 transform for comparison, while FGO uses a 2x2. Maybe I could combine all three transforms? :p

Wow that would be neat would love to test that one out :p

Yoshiyuki Blade

6th June 2008, 04:13

With these visual improvements (VAQ and Psy RDO), I wonder if CQMs still have a large impact on image quality. I always have Sharktooth's AVC CQM on, even with animated material, but I haven't tried without it yet. Encoding a full length animated episode is incredibly slow on my lappy. You think CQMs will still remain significant at this stage (given a reasonably high bitrate/resolution)?

Dark Shikari

6th June 2008, 04:20

shae

7th June 2008, 01:18

I've never really personally liked CQMs, for many reasons.Like what?

Dark Shikari

7th June 2008, 01:27

Like what?
1) When you're actually trying to keep fine detail, they butcher it.
2) They skew x264's lambda values.
3) They confuse RDO.
4) They confuse trellis even more than they confuse RDO.
5) Prestige, especially, does some really bizarre things.

ToS_Maverick

7th June 2008, 01:48

sry for hijacking this thread, but why is x264 so not-suited for CQMs? do other encoders work better with them?

Dark Shikari

7th June 2008, 01:53

sry for hijacking this thread, but why is x264 so not-suited for CQMs? do other encoders work better with them?It isn't that x264 isn't suited for use with CQMs; nothing of the sort.

First, on the topic of RDO, you can intentionally make CQMs so that RD-wise, the inter matrix will always be favorable (for example), and so inter blocks are nearly always used when in RD mode.

However, the creator of the CQM might not have intended this; for example, the CQM might have been intended for an encoder that didn't use RDO, and therefore would not have taken into account the CQM when making its decision. I strongly suspect Prestige is this sort of CQM.

With trellis, trellis simply does not take into account CQM weights when working. I've found doing so actually reduces visual quality, unless I made a mistake in my patch--go figure.

techouse

8th June 2008, 01:01

Is it REALLY worth it? Maybe Wizboy or Bobor can try and compile an x264 version with the fixed me-prepass patch for us to test? :D

Thanks,
- Dan
Just Check out my site http://x264.tk :rolleyes:

x264_x86_r871_techouse (http://techouse.project357.com/builds/x264_x86_r871_techouse.7z)

Source: x264 r871 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_hrd_pulldown.04_interlace.diff

x264_me-prepass_DeathTheSheep_techouse_fix.diff (http://pastebin.com/f62aea32f)

x264_progress.diff

x264_psy_rdo_0.22.diff

Please check http://forum.doom9.org/showthread.php?t=130364 and http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog for more info

Compiled by techouse on June 6th 2008, 03:13:38 CEST with GCC-4.3.0 on Windows Vista Ultimate SP-1 32-bit.

Commandline used: ./configure&&make fprofiled

Platform: X86
System: MINGW
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

desta

8th June 2008, 06:55

Just Check out my site http://x264.tk :rolleyes:

x264_x86_r871_techouse (http://techouse.project357.com/builds/x264_x86_r871_techouse.7z)
http://forum.doom9.org/showthread.php?p=1146886#post1146886

shae

12th June 2008, 21:18

1) When you're actually trying to keep fine detail, they butcher it.Well, doesn't that depend on the QM and is exactly what CQM are for, to allow you to fine tune what's kept and what's not?

2) They skew x264's lambda values.
3) They confuse RDO.
4) They confuse trellis even more than they confuse RDO.Wouldn't that be implementation specific? It may conflict with other features currently, but in an ideal AVC encoder it should just add flexibility.

5) Prestige, especially, does some really bizarre things.Just extreme values leading to extreme results, no?

LoRd_MuldeR

12th June 2008, 21:22

Wouldn't that be implementation specific? It may conflict with other features currently, but in an ideal AVC encoder it should just add flexibility.

I'd say an ideal AVC encoder wouldn't need any special CQM to workaround it's visual problems :p

Also I think features like VAQ, FGO and Psy RDO do exactly what people tried to achieve with CQM's before, only in a more sophisticated and more general way.
IMO it's always better to resolve the cause of the problem itself instead of fighting the symptom of the problem...

foxyshadis

13th June 2008, 01:59

An ideal AVC encoder would vary the quant matrix per frame to completely maximize RD. ;) That's one of those exponentially hard problems though, unless someone comes up with a good way to quickly test whether a CQM benefit outweighs its size every frame.

Blue_MiSfit

13th June 2008, 02:32

I had an idea for something similar back in the Xvid days, but it would have been very time consuming, and required a lot of user interaction. Here's how I saw it:

1) Take a movie, and split it into comp-test style chunks
2) Encode this multiple times with different CQMs
3) Show the compressionist the individual chunks, with the ability to flip between versions easily, stackhorizontal, interleave, whatever.
4) Allow the compressionist to pick a "top 3" or something for each chunk
5) Tally the votes, and pick a CQM for the movie.

I wish I could code, or I would have cobbled this together just out of curiosity.

But back on topic - I'm a huge fan of PsyRDO. It's improved almost every single thing I've thrown at it.

~MiSfit

Razorholt

13th June 2008, 03:05

I'm a huge fan of PsyRDO. It's improved almost every single thing I've thrown at it.
Are you using Trellis 2 ?

Ranguvar

13th June 2008, 16:52

Are you using Trellis 2 ?

Why? Does it help, or hurt PsyRDO?

Razorholt

13th June 2008, 17:00

Trellis 1 probably is not the best idea with this because that means the quantization that x264 chooses is not the quantization that psy RDO looked at in mode decision. Therefore, unless its demonstrated that this isn't a real issue, deadzones or trellis 2 are probably a better idea.
Trellis 2 is not a bad thing at all with psy RD; the problem before was that it encouraged blurring because RD would often prefer blurrier modes, and trellis would generate blurrier modes. But now, RD prefers *less* blurry modes.
Trellis 2 sharpen the picture. What settings you had? Trellis 1 or were you using deadzones?

gav1577

13th June 2008, 20:26

I find low deadzones usually inter 6 intra 6 work great for me :)

Blue_MiSfit

13th June 2008, 21:23

Yes I am using Trellis 2, and SubME 7, when I can afford the speed hit.

I did Princess Mononoke the other day, a nice high quality soft-telecined DVD9 source.

I did a very light script with light fft3dgpu(sigma=1), Toon() and gradfun2db(1.8). Then I encoded into Psy-RDO'd CRF19 with Multi-Hex SubME 7, Trellis 2, 16 refs, all the usual bells and whistles. It came out to 1.2 GB. That's really impressive to me :)

Muxing the original english and japanese 5.1ch AC3s, plus an english SRT netted a file size of just under 2gb. 9gb -> 2gb with utterly transparent quality (I actually preferred my version due to the denoise / warpsharp / line darkening / dithering). Now THAT's impressive.

Heck, the encoding only took a few hours. I think I was getting ~15fps on my Q6600 @ 3 GHz :D

~MiSfit

TheRyuu

13th June 2008, 21:38

Why? Does it help, or hurt PsyRDO?

Trellis 2 generally provides the best result of the different possible options you can use. I consider using trellis 2 to just be 'smarter' then using deadzones with it which does make sense.

I think people need to break out of the mentality that trellis is bad for keeping grain when isn't anymore with psy RDO. (no idea of anyone has this mentality to begin with... just making comments)

LoRd_MuldeR

13th June 2008, 23:57

Question: I see a lot of people talking about "using deadzones" :confused:

Aren't deazones always there? If you don't set them explicitly, they will simply default to "deadzone=21,11", right?

Dark Shikari

14th June 2008, 00:04

Question: I see a lot of people talking about "using deadzones" :confused:

Aren't deazones always there? If you don't set them explicitly, they will simply default to "deadzone=21,11", right?"Using deadzones" means not using trellis.

LoRd_MuldeR

14th June 2008, 00:08

"Using deadzones" means not using trellis.

I see. thx.

MasterNobody

14th June 2008, 00:27

Probably deadzones are used even with trellis=2 because trellis is used only for luma plane compression, and not used for chroma planes.
/* no trellis; it doesn't seem to help chroma noticeably */

Dark Shikari

14th June 2008, 00:47

Probably deadzones are used even with trellis=2 because trellis is used only for luma plane compression, and not used for chroma planes.This is correct.

Also note that deadzones are used for RDO when trellis=1, and even in trellis=2, deadzones are used for B-frames unless b-rdo is enabled. Finally, even if RDO is on all frametypes, deadzones are still used for fast P-skip decision.

gav1577

15th June 2008, 23:54

Are there any advantages in using trelis 2 over low deadzones Qualitywise with bitrates up to and above 4000kbps ? :)

TheRyuu

16th June 2008, 05:02

Are there any advantages in using trelis 2 over low deadzones Qualitywise with bitrates up to and above 4000kbps ? :)

In my opinion, using trellis 2 will always provide a better looking result then using deadzones simply because it is smarter then deadzones. More so at lower bitrates, but I've seen it seems to consistantly look better any a number of bitrates I have tried.

Although you should always do the testing and decide for yourself as I am no expert on the matter. :p

bokonon

16th June 2008, 09:21

This is correct.

Also note that deadzones are used for RDO when trellis=1, and even in trellis=2, deadzones are used for B-frames unless b-rdo is enabled. Finally, even if RDO is on all frametypes, deadzones are still used for fast P-skip decision.

Would a combination of --trellis 2 and low deadzones (6, 4) work favorably? OR would it work better with default deadzones (21, 11)

Irakli

16th June 2008, 13:44

Would a combination of --trellis 2 and low deadzones (6, 4) work favorably? OR would it work better with default deadzones (21, 11)

No, modify deadzones if and only if trellis is off. So, either use trellis 2 with default deadzones or modify deadzones if trellis is off.

gav1577

16th June 2008, 15:34

In my opinion, using trellis 2 will always provide a better looking result then using deadzones simply because it is smarter then deadzones. More so at lower bitrates, but I've seen it seems to consistantly look better any a number of bitrates I have tried.

Although you should always do the testing and decide for yourself as I am no expert on the matter. :p

Thanks for the reply will try some clips trellis 2 and see if there is any increase in quality the only thing about trellis 2 is i find it slows things down quite a bit :p

Dark Shikari

17th June 2008, 18:54

Here's an encode of part of the original clip that inspired psy RDO in the first place (http://mirror05.x264.nl/Dark/Flash/concertclip.html). The flashing lights, the flat but gradient-filled background areas--all of them contrive to make encoding a nightmare for x264.

yesgrey

17th June 2008, 20:18

Blue_MiSfit

17th June 2008, 21:08

I want to try this patch. I am thinking in using Megui with the DXVA-HD-HQ profile with trellis 2 and subme 7. The bitrate used will be 16000 or 22000 kbps. Will it be worth it? or due to the high bitrate the effect will be negligible... even using trellis 2 and subme 7 the encoded file will be DXVA compatible?
For using this is enough substituting the x264.exe by the patched one in megui directory, right?

Yep :) All you have to do is enable Sub ME >=6, and use MeGUI's preferences to select the patched .exe.

At that bitrate, subme7 will likely be totally unnecessary (guessing). It boosts the effectiveness of Psy-RDO, but is a lot slower as well.

You might try plain old FGO too, instead of Psy-RDO.

Just out of curiousity, why target a specific bitrate? CRF mode is wonderful :D

~MiSfit

yesgrey

17th June 2008, 23:22

Just out of curiousity, why target a specific bitrate? CRF mode is wonderful :D

Because I want a specific target file size to put in dvds.

:thanks:

bkman

20th June 2008, 16:02

Hi Dark Shikari,

A couple of observations from testing the psyRDO.

1.) It works noticeably better if employed in the first pass also.
2.) The picture seems to degrade much quicker between I-frames, making for a much more noticeable transition on a mid-scene keyframe.

Any ideas?

Dark Shikari

20th June 2008, 16:06

2.) The picture seems to degrade much quicker between I-frames, making for a much more noticeable transition on a mid-scene keyframe. This is an interesting claim, because psy RDO as a whole is much much more effective on non-I-frames, because there it can use previous frames to get detail/texture, while on I-frames it can't. From my testing I've noticed that I-frames tend to benefit less than P-frames, rather than vice versa.

Razorholt

20th June 2008, 16:22

Does it mean that by adding more P-frames it will improve the quality?

bkman

20th June 2008, 16:22

To describe what I'm seeing, it's like the scene gets grainier and grainier, and then BAM I-frame, and its clear again. Doesn't happen all of the time though.

I haven't compared to an encode without psyRDO as of yet, but I've never seen x264 exhibit this sort of behaviour previously at reasonably high bitrates. It's like old DivX or something.

Dark Shikari

20th June 2008, 16:25

To describe what I'm seeing, it's like the scene gets grainier and grainier, and then BAM I-frame, and its clear again. Doesn't happen all of the time though.Hmm, that is not at all surprising; the I-frame can't nearly express the kind of fine detail/graininess the psy RDO retains in P-frames.

bkman

20th June 2008, 16:33

Dark Shikari

20th June 2008, 16:38

I don't think you quite understand... in some scenes it becomes increasingly inaccurate (loses coherence) the longer it goes without an I-frame. Then the I-frame seems to restore accuracy for another while.If by "accuracy" you mean "smoothness," yes. Psy RDO tends to promote graininess, fine detail, and at low bitrates a bit of "lumpiness" rather than a pure attempt to approximate the source as best as possible. The I-frame makes things "smooth" again.
It makes for noticeable and unwanted "jumps" in quality during the same scene. Seems like a bug of some sort.A bug is a mistake in implementing an algorithm; this is not a mistake (but obviously a potential consequence of the chosen algorithm).

This is the problem when people ask for x264 to be more like Xvid; they get the exact same problems Xvid had.

Possible ideas on how to solve this--maybe try using --deadzone-intra 0 --deadzone-inter 20 or something like that? Or use a CQM.

bkman

20th June 2008, 16:45

If by "accuracy" you mean "smoothness," yes. Psy RDO tends to promote graininess, fine detail, and at low bitrates a bit of "lumpiness" rather than a pure attempt to approximate the source as best as possible. The I-frame makes things "smooth" again.
A bug is a mistake in implementing an algorithm; this is not a mistake (but obviously a potential consequence of the chosen algorithm).

This is the problem when people ask for x264 to be more like Xvid; they get the exact same problems Xvid had.

If the source frames are smooth, then yes accuracy = smoothness. I notice that in general psyRDO promotes grainyness that wasn't in the original source-- an effect that I don't mind for the most part-- but when it causes these noticeable jumps mid-scene then it becomes unusable. Which is a real shame because I think it has a lot of advantages in detail retention.

So if it is not a mistake in the implementation, would it be possible to modify the algorithm to alleviate this issue?

Edit: Here's a sample to illustrate what I'm talking about. Pay attention to the hand.

http://www.mediafire.com/?jqrhgdlw3de

akupenguin

20th June 2008, 16:56

To describe what I'm seeing, it's like the scene gets grainier and grainier, and then BAM I-frame, and its clear again.
So don't put I-frames in the middle of a scene.

bkman

20th June 2008, 16:59

So don't put I-frames in the middle of a scene.

Um.. I don't decide where to place the I-frames... x264's (your) rate control does.

If there are some settings I should tweak, then let me know.

Dark Shikari

20th June 2008, 17:03

Potential way to resolve this (and many other related issues known collectively as "I-frame flashing"):

1. Encode I-frame as P-frame.
2. Re-encode the frame as an I-frame, except targeting the appearance of the encoded P-frame as the "target image" rather than the original source.

This would probably eliminate all forms of I-frame flashing in cases in which I-frames are placed in the middle of a scene.

And if you think creatively, this can actually be done without breaking threading.
Um.. I don't decide where to place the I-frames... x264's (your) rate control does.

If there are some settings I should tweak, then let me know.Raise --keyint.

Sagittaire

20th June 2008, 17:14

Um.. I don't decide where to place the I-frames... x264's (your) rate control does.

If there are some settings I should tweak, then let me know.

- Change the sensivity for scene cut
or
- change the max key frame interval
or
- change the ratio for Iframe.

Short GOP like BD/HDDVD profil mean more Iframe without scene-cut ... I use ratio at 1.10 for better temporal quality (keyframe popup) and better efficiency.

Sharktooth

20th June 2008, 17:28

DS solution is a general solution that will work on any GOP size.
However those i frames on the middle of a scene can be "detected" (consecutive frames exceed the key-frame interval) and re-encoded as D_S said. while I frames placed for scene change can be encoded as usual.

Dark Shikari

20th June 2008, 17:34

bkman

20th June 2008, 17:56

Potential way to resolve this (and many other related issues known collectively as "I-frame flashing"):

1. Encode I-frame as P-frame.
2. Re-encode the frame as an I-frame, except targeting the appearance of the encoded P-frame as the "target image" rather than the original source.

This would probably eliminate all forms of I-frame flashing in cases in which I-frames are placed in the middle of a scene.

And if you think creatively, this can actually be done without breaking threading.
Raise --keyint.

But, and just judging by the sample I posted, isn't the main problem that in some scenes psyRDO deviates from the source too much over time? And this is why the I-frame infusion looks so out of place--because as you say the psy optimisation affects I-frames less.

Ideally what we'd want is a psy optimisation that stays closer in look to the source-- smooth when it is smooth, and grainy/detailed when its detailed.

Underground78

20th June 2008, 18:01

isn't the main problem that in some scenes psyRDO deviates from the source too much over time?

Maybe you should post the source too ... :p

Dark Shikari

20th June 2008, 18:02

Ideally what we'd want is a psy optimisation that stays closer in look to the source-- smooth when it is smooth, and grainy/detailed when its detailed.But that's what psy RDO does; it penalizes both more complexity than the source and less complexity than the source.

One potential issue may be that it weights high frequencies no different from low frequencies, which may be a problem.

bkman

20th June 2008, 18:07

But that's what psy RDO does; it penalizes both more complexity than the source and less complexity than the source.

One potential issue may be that it weights high frequencies no different from low frequencies, which may be a problem.

Well it doesn't quite seem to be working as expected.

Hang on, I'll see what I can do about getting a small sample of that scene in the source up, though I'm afraid it won't be too helpful for replicating the problem without the full source.

Dark Shikari

20th June 2008, 18:13

Hang on, I'll see what I can do about getting a small sample of that scene in the source up, though I'm afraid it won't be too helpful for replicating the problem without the full source.A few-hundred frame sample is plenty (just the source version of what you gave me for the encoded clip).

bkman

20th June 2008, 18:18

75MB ffv1.
Might take about an hour, heh.

One thing to note is that I'm not exactly using a low bitrate for this encode. The metrics, QP (about 17 avg), and overall look indicate that it is sufficient.

Edit:
Here we go: http://www.mediafire.com/?yc9ttqc1m9d
Sorry its not exactly the same frames.

For some reason this level of discontinuity only happens a few times in the encode.

Razorholt

21st June 2008, 22:21

@DS: Do you recommend we still use VAQ2.0 with PsyRDO? Is it causing any conflicts anywhere?

Thanks
- Dan

desta

23rd June 2008, 06:03

I can actually appreciate what bkman is saying, to an extent. Although I think psy rdo is brilliant, I have had encodes that have suffered because of it - mainly anime, where it introduces mosquito-like noise and some other artifacts, which were too prominent to ignore. I tried lowering the aq, but it didn't really help. Infact I tried lots of things to eliminate the problem, but the only thing that actually put a stop to it was to turn psy rdo off. Unfortunately that meant I traded in one bunch of artifacts for another (mosquito noise & ringing - to - banding & blocking). Catch 22.

Dark Shikari

23rd June 2008, 06:17

I'll do some testing on that source this week; one major question I have to resolve is whether its simply psy RDO being weighted too highly or whether the algorithm itself needs tweaking.

By the way, have you tried without such a low deblocking strength? Its possible that might be part of the problem.

MfA

23rd June 2008, 14:30

Dark Shikari

23rd June 2008, 14:50

Would it be possible to force a couple of B-frames which use the next I-frame as a reference? It would gradually smooth out the difference.Yes, that's called openGOP, and its one possibility for helping avoid this sort of issue.

Sagittaire

23rd June 2008, 15:04

Would it be possible to force a couple of B-frames which use the next I-frame as a reference? It would gradually smooth out the difference.

PS. low frequency components (especially the ones with high anisotropy) don't encode fine detail.

Will default setting bframe are really overquantized. Moreover with longgop Iframe are generaly scene cut.

Gabriel_Bouvigne

23rd June 2008, 18:03

Dark Shikari

23rd June 2008, 18:30

Now here's something interesting: I just encoded that test sample that was posted earlier at 1500kbps--and there was no I-frame flash at all, nor the texture smudging. It looked basically flawless.

What settings did you use for encoding it? Since you gave me a clip of a longer h264 file, the x264 header wasn't included.

bkman

23rd June 2008, 22:17

Settings used were:

--pass 2 --bitrate 1800 --stats "G:\Encoding\Dune\hfyu_dune.stats" --level 4.1 --keyint 240 --min-keyint 24 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -3,0 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --merange 24 --threads auto --thread-input --sar 1:1 --progress --no-dct-decimate

First pass used the same settings. Anything else you need to determine the issue, let me know.

LoRd_MuldeR

23rd June 2008, 22:28

"--filter -3,0" sounds a bit harsh to me. What happens if you remove "--filter" ???

Atak_Snajpera

23rd June 2008, 23:55

--keyint 240 --min-keyint 24
Why????????

--filter -3,0
whyyyyy?????

LoRd_MuldeR

24th June 2008, 00:05

--keyint 240 --min-keyint 24 Why????????

Well, I think the "rule of thumb" says: min-keyint = fps, max-keyint = 10 * fps.

But I also think you can safely raise max-keyint much higher and trust in the scene-cut detection...

survivant001

24th June 2008, 00:48

LoRd_MuldeR

24th June 2008, 01:05

Question.

when I mux into m2ts and I press ff and the PS3.. it takes few sec (could take 1-2 min) before the video start fast forwarding. is it because we use the default min-keyint value ?

ps. I don't have this problem when I mux into mp4 (I can take the same output for the both tests)

i'm using the default setting for ripbot.

This question is off-topic :rolleyes:

But I think although a large key-frame interval might slowdown seeking, the problem is the m2ts (transport stream) container here.
As the name implies, a "transport" stream is intended for broadcast/streaming, not for local playback. Therefore seeking is not easily possible in those streams.
Maybe the player has to start at the very beginning and hunt trough the stream frame-by-frame until the desired position is reached...

MasterNobody

24th June 2008, 01:14

bkman

24th June 2008, 02:34

Why????????

whyyyyy?????

1.) As Mulder says, it's a common rule of thumb. I've had no reason to deviate from it as yet and its good for consistent seeking through the movie.

2.) It looks good. Higher deblocking strengths kill detail too much.

LoRd_MuldeR

24th June 2008, 03:07

1.) As Mulder says, it's a common rule of thumb. I've had no reason to deviate from it as yet and its good for consistent seeking through the movie.

2.) It looks good. Higher deblocking strengths kill detail too much.

to 1) As said before, raise max-keyint in order to give x264 more freedom for deciding the optimal I-Frame position.

to 2) Using such extreme deblocking filter settings provokes artifacts! VAQ + Psy-RDO will already keep more details, so you shouldn't need to touch the deblocking settings.

Dark Shikari

24th June 2008, 03:49

Dark Shikari
I think there is bug in ssd_plane function of Psy RDO patch. First, dc_coefs for sa8d must be equal not sad/2 but sad/4 (otherwise (sa8d - dc_coefs) would be most of the time negative). Second, abs function must be used in ADD_ABS_SATD macros and not only in result calculation of ssd_plane function because signs of satd and sa8d differences may be opposite.
Here is fixed (in my opinion) patch: http://stashbox.org/144987/x264_psy_rdo.r889.diffHmm, good point. I'll look over this in a bit.

I'm not sure about the SATD/SA8D absolute value issue; its possible that if one is higher and the other is lower we want psy RDO to have them cancel. I think this may have actually been my original intent though I'm not 100% sure.

shae

26th June 2008, 23:08

An ideal AVC encoder would vary the quant matrix per frame to completely maximize RD. ;)Is this, unlike in ASP, compliant to the standard?

Perhaps something less radical would be possible, like using 2-3 QM sets for closeup/(mid/)longshot.

Mr VacBob

27th June 2008, 01:29

I don't know if optimizing the QM is really useful when you have AQ+trellis. Especially if you add QNS on top of that, there's already more than enough ways to mess with coefficients.

akupenguin

27th June 2008, 08:35

Is this, unlike in ASP, compliant to the standard?
According to the H.264 standard alone: Yes.
According to the H.264 standard plus restrictions on the headers required by certain containers such as mkv and mp4: Yes with limitations (no more than 256 different sets of QMs over the course of the movie).
It takes a certain number of bits to write down a new QM, so you'd probably want to limit yourself to a finite number even if it weren't for the container limits.
... which is still far more than ASP. Even non-compliant XviD only switched between 2 QMs.

Blue_MiSfit

27th June 2008, 09:52

Problem here...

I encoded L4yer Cake last night - it's a ~18GB (video only) MPEG-2 BluRay Source. I encoded to CRF20 using Psy-RDO:

--[NoImage] Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.877.modified.exe" --crf 19 --level 4.1 --ref 4 --mixed-refs
--bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -1,-1 --subme 6 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8
--8x8dct --vbv-maxrate 1500 --me umh --threads auto --thread-input --sar 1:1 --progress --no-psnr --no-ssim
--output "I:\BluRay Rips\L4yer Cake\l4yer.mp4" "I:\BluRay Rips\L4yer Cake\l4yer.avs"
--[Information] [6/26/2008 2:41:16 AM] Encoding started
--[NoImage] Standard output stream
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1920x1080 @ 23.98 fps (151604 frames)
---[NoImage] x264 [info]: using SAR=1/1
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [warning]: VBV maxrate specified, but no bufsize.
---[NoImage] mp4 [info]: initial delay 2002 (scale 24000)
---[NoImage] x264 [info]: slice I:1380 Avg QP:14.83 size:156543
---[NoImage] x264 [info]: slice P:61988 Avg QP:18.49 size: 83390
---[NoImage] x264 [info]: slice B:88236 Avg QP:20.50 size: 38383
---[NoImage] x264 [info]: mb I I16..4: 25.0% 66.8% 8.2%
---[NoImage] x264 [info]: mb P I16..4: 0.7% 4.3% 0.4% P16..4: 31.4% 21.0% 14.1% 0.0% 0.0% skip:28.0%
---[NoImage] x264 [info]: mb B I16..4: 0.1% 0.2% 0.0% B16..8: 48.1% 1.0% 4.4% direct: 8.2% skip:38.0%
---[NoImage] x264 [info]: 8x8 transform intra:75.5% inter:64.4%
---[NoImage] x264 [info]: direct mvs spatial:98.9% temporal:1.1%
---[NoImage] x264 [info]: ref P 54.7% 21.8% 14.5% 9.0%
---[NoImage] x264 [info]: ref B 66.1% 25.4% 8.5%
---[NoImage] x264 [info]: kb/s:11098.2
---[NoImage] encoded 151604 frames, 4.32 fps, 11098.94 kb/s
--[Information] Final statistics
---[NoImage] Desired video bitrate: 19 kbit/s
---[NoImage] Obtained video bitrate (approximate: 11101 kbit/s
--[Information] [6/26/2008 12:26:30 PM] Job completed
--[Information] [6/26/2008 12:26:30 PM] Postprocessing

And this is what happened to the intro (the rest of the movie looks _fantastic_)
http://www.mediafire.com/?n2mdbjxjmfn
(2MB)

Fail :( The fade in breaks up horribly and looks quite wrong.

Ideas? The VBV thing was ignored I think - I don't know how that snuck its way into my profile... ;)

Just in case - I will go ahead and re-encode WITHOUT any VBV.

I think it was totally the VBV... According to DGAVCIndex, the average bitrate for the fade in is ~ 500kbit. That's not good! Perhaps VBV dutifully tried, realized its life's work was meaningless, and gave up! :P

~MiSfit

DarkZell666

27th June 2008, 12:27

---[NoImage] Desired video bitrate: 19 kbit/s
... what the ... !? :confused:

Avenger007

27th June 2008, 13:15

---[NoImage] Desired video bitrate: 19 kbit/s

... what the ... !? :confused:
It's the CRF value, quite normal. :)

DarkZell666

27th June 2008, 14:57

It's the CRF value, quite normal. :)

It does say this doesn't it ? :
Desired video bitrate: 19 kbit/s

Never mind the "19" ... XD
It's not an x264-related quirk though, I admit :)

The thing is, I first though it was x264 misinterpreting the crf as bitrate (which would have surely been found out by now anyway), so I supposed that could have been the cause of Blue_Misfit's problem, but reading the log a second time allowed me to understand it was MeGUI playing tricks on me again :P

Ranguvar

27th June 2008, 19:39

There's a setting that can affect the quality of the beginning of the video in x264 :)

VBV Initial Buffer (--vbv-init), it defaults to 0.9. Higher values cause more bitrate in the beginning of the video, lower causes lower bitrate in the beginning.

PlazzTT

27th June 2008, 20:37

Blue_MiSfit

27th June 2008, 23:21

Thing is - I didnt even want VBV - since I'm doing a CRF encode :)

I think somehow my profiles got goofed up (copied a profile with VBV and modified it for CRF without looking at the VBV settings). At any rate, I'm re-encoding the file as we speak, and im 99% sure the problem will go away then ;)

~MiSfit

qyqgpower

28th June 2008, 17:25

I have also noticed the I frame flashing issue with Psy RDO turned on, especially at low bitrate. Because frames before the I frame was so badly encoded.
It seems that P/B frames keep losing details when there's no good I frame to reference, e.g. a fade-in scene.
In my opinion. "referencing" to some already badly encoded (washed out "details") P/B frames is meaningless or even would lead to worse result.

http://www.mediafire.com/?z3j5dmuj2nm

elguaxo

28th June 2008, 17:45

could you encode and share the same sample at the same bitrate without PSY RDO?

menlvd

28th June 2008, 22:49

could you encode and share the same sample at the same bitrate without PSY RDO?
and putting cmd line for both encoded files

bkman

30th June 2008, 06:49

burfadel

30th June 2008, 08:25

Maybe optimising the way changes by AQ and PSY go on top of other changes will resolve that issue... So when you have one P?B frame then the next, does the second p/B-frame build AQ and psy on top of the first? What you could do is keep track of a certain number of P/B frames, then for the following p-frame make changes based on the original first and not the aq/psy modded frame.

Blue_MiSfit

30th June 2008, 18:54

I'll do that this evening - sorry for the delay. I re-encoded without VBV, and the problem persisted (I think) :(!

I will do some comparisons with and without PRDO and see if the issue goes away.. Details forthcoming...

~MiSfit

Blue_MiSfit

1st July 2008, 07:52

Uh oh...

http://www.mediafire.com/?zjzzeytcwto

PRDO enabled - artifacts.
PRDO disabled - no artifacts.

Command line with PRDO:

Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.877.modified.exe" --crf 19 --level 4.1 --ref 4 --mixed-refs --bframes 16 --b-pyramid
--b-rdo --bime --weightb --direct auto --filter -1,-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 "I:\BluRay Rips\L4yer Cake\PRDO Tests\PRDO Enabled (Sub-ME 6).mp4" "I:\BluRay Rips\L4yer Cake\l4yer.avs"

Command line WITHOUT PRDO

"C:\Program Files (x86)\megui\tools\x264\x264.877.modified.exe" --crf 19 --level 4.1 --ref 4 --mixed-refs --bframes 16 --b-pyramid
--bime --weightb --direct auto --filter -1,-1 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto
--thread-input --sar 1:1 --progress --no-psnr --no-ssim --output "I:\BluRay Rips\L4yer Cake\VAQ Tests\No VAQ.mp4" "I:\BluRay Rips\L4yer Cake\l4yer.avs"

:confused:

~MiSfit

Dark Shikari

1st July 2008, 14:26

Looks like you're using a build from before the bugfix (http://git.videolan.org/?p=x264.git;a=commit;h=2389de25ff7fe6f84c9c885578c0fbaa6b656f4a) that dealt with that. Its not a bug in Psy RDO--rather its a bug that Psy RDO tends to reveal since its extremely unlikely otherwise.

J_Darnley

1st July 2008, 14:44

Well it might not appear in the good clip because RDO has been disabled completely in it (--subme 6 and --b-rdo have been removed) . If you want to disable psyRDO then use --rdcmp ssd.

I need to find a good clip to test psyRDO, FGO and VAQ2 on. Problem is I can't think of a scene that might show a clear benefit.

ToS_Maverick

1st July 2008, 23:03

check this (from dark shikari's blog):
http://x264dev.multimedia.cx/?p=14

Blue_MiSfit

1st July 2008, 23:33

Interesting. Is there a more recent patched build with PsyRDO that I can use?

edit:

NM - I saw that the build posted on the OP has been updated :) I will double check tonight that this resolves the issue ;)

~MiSfit

mahsah

4th July 2008, 21:26

Anyone know what settings/bitrate would be good for retaining dither in anime? I'm currently using the AE-maxquality profile in megui, but it doesn't keep as much dither as is needed to hide all of the banding/dct blocks...

wyti

4th July 2008, 22:05

it's impossible to say what bitrate because like in real time content, the bitrate needed varie between animes...
try crf mode if you don't care about the final size of your encode (try crf 20 and use lower or higher values to get what you want).
for the settings you can do better but you will need to increase merange or use esa (or tesa) wich ar really slow, so try to increase bitrate.

mahsah

4th July 2008, 22:09

Well even with CRF 18 it is throwing out way too much dither...

wyti

4th July 2008, 22:12

have you try to lower deblocking value ? AE-maxquality use 1,1 (stronger than normal) because there is no very fine détails on anime, try to lower the deblocking value to -2,-1 (maybe you will have blocking, but you may retain more dither)

mahsah

4th July 2008, 23:07

With lower deblocking settings (or even higher ones), even at CRF of 1 it still tosses away the dither...

Dark Shikari

4th July 2008, 23:18

With lower deblocking settings (or even higher ones), even at CRF of 1 it still tosses away the dither...Are you sure then that the dither even exists upon x264 receiving the input!?

It would be difficult to avoid retaining dither when using psy RDO; I have never seen banding at any sane bitrate with it.

mahsah

4th July 2008, 23:27

It does exist. I can post a short lossless huffyuv clip (or whatever Megui makes during its rendering pass) and upload it, if you want.

EDIT:
http://miscstorage.nfshost.com/test.avi

There it is (please don't download it frivolously). Very short clip, but keep an eye on his red cape; it has some bad banding/blocking that gradfun2db covers up fairly well, but x264 does not.

wyti

5th July 2008, 00:29

I don't know where do you see a problem.
With this commande line :
program --crf 18.0 --ref 16 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --direct auto --filter -2,-1 --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input"
(it's AE maxquality with crf 18 and deblocking at -2,-1)
have you updated your megui x264 version ? (At this time, it's the jarod patched version 895)

mahsah

5th July 2008, 00:39

I was actually using the one in the first post of this thread -- Jarod's patched version 895 doesn't have Psy RDO in it, does it?

EDIT: I can clearly see a problem, but then again I have an LCD. Still, the problem is nearly gone in the original. First is the same clip I uploaded, 2nd is the most recent build on MeGUI's auto updater, 3rd is the one from the start of this thread. All using the above command line.

http://miscstorage.nfshost.com/huff.png
http://miscstorage.nfshost.com/noRDO.png
http://miscstorage.nfshost.com/RDO.png

ToS_Maverick

5th July 2008, 03:05

I'm sorry, I cannot see a problem.

I'm sensitive to blocking in x264 but this seems to be a VERY minor problem, but that's just me.

Dark Shikari

5th July 2008, 03:18

I don't see any issues there at all... the encode looks basically transparent to the original.

Well, actually, I do see an issue... that you're watching Gurren Lagann!

/hides

mahsah

5th July 2008, 04:07

Huh. Guess it must just be my LCD then. Sorry to bug you about it.

And yes, it is Gurren-Lagann :)

CruNcher

7th July 2008, 07:34

WOW there im away sometime and what happens Dark brings the next HVS improvement and this time it really blasts (in Motion even more) :)

http://s1.directupload.net/file/d/1483/od2hf88f_png.htm (no RD = 40 fps)
http://s1.directupload.net/file/d/1483/xzu76qjy_png.htm (old RD = 30 fps)
http://s1.directupload.net/file/d/1483/r8vhwmp3_png.htm (Darks Psy RD = 29 fps, it seems deblocking needs to be adapted, AQ useless now non usage could speedup more without Visual difference?)

Since i was away X264 performance improved +6 fps now practicaly Psy RD comes for free (almost) :D (you really gave RD for Film Source a reason to live thx Dark another time superb work)

PS: It's a Live Retranscode of Ben Waggoners heavy compressed (2mbit) VC-1 Encode :) (x264 puts it to shame)

lexor

7th July 2008, 15:17

Huh. Guess it must just be my LCD then. Sorry to bug you about it.

And yes, it is Gurren-Lagann :)

Actually I think I see what you mean if I pump the brightness a bit. But I think it shouldn't be visible in normal viewing, so if you do see it I'm inclined to think that the calorimetry of your LCD is wacked, or you have one the cheaper panels, like me, and if you not looking at it from the "correct" angle everything is uber bright (or dark, depending on the angle).

burfadel

7th July 2008, 15:40

Lower the brightness and gamma and up the contrast through the control panel for your graphics driver, you generally don't have to do it much to make them look a lot better!

lexor

7th July 2008, 17:13

Lower the brightness and gamma and up the contrast through the control panel for your graphics driver, you generally don't have to do it much to make them look a lot better!

Doing it in drivers is not a good idea, using levels (either in ffdshow, mpc shader or avisynth) to do the 0-255 -> 16-235 conversion is the cleaner way.

burfadel

8th July 2008, 03:45

Thats true! I did think of that, but I thought since the problem is with the monitor and not the player that having a blanket correction may be better for picture quality in general, not just the video :) since the adjustments through the driver have different results than the adjustments on the monitor itself.

Inventive Software

8th July 2008, 05:09

So hows the VAQ2+PsyRDO combo going Dark? Any thoughts on how this particular patch (PsyRDO) could be improved?

Blue_MiSfit

8th July 2008, 06:08

Sorry to keep anyone waiting...

I re-encoded the beginning of L4yer Cake with bob0r's patched 901 build (including PsyRDO), and the issue with the fade-in to the sony logo has been resolved.

:)

~MiSfit

Dark Shikari

11th July 2008, 16:32

Updated to version 0.4, considerable changes. See post for details. Psy RD strength is now adjustable!

elguaxo

11th July 2008, 16:50

4. Automatically lower AQ strength slightly when psy RDO is enabled.
by how much is it lowered? Does this still apply if AQ strength is in the commandline, let's say --aq-strength 1.2.

Thanks!

Dark Shikari

11th July 2008, 16:53

by how much is it lowered? Does this still apply if AQ strength is in the commandline, let's say --aq-strength 1.2.Yes, its still lowered if you specify it explicitly, much like AQ raises qcomp even if you specify qcomp explicitly.

Its lowered by log(psy RDO strength+1)/3.0. So for the default strength, it lowers AQ by 0.25 or so. This formula is completely arbitrary and just meant to scale the amount by which AQ is lowered slightly based on psy RDO strength.

Razorholt

11th July 2008, 17:24

The link to the build is not valid... :(

fields_g

11th July 2008, 17:30

Thanks for giving me something to play around with this weekend! I feel like I'm missing something basic though...

2. Warn the user if trellis 1 is enabled--and disable trellis--if psy RD is on.

Trellis 2 is not a bad thing at all with psy RD; the problem before was that it encouraged blurring because RD would often prefer blurrier modes, and trellis would generate blurrier modes. But now, RD prefers *less* blurry modes.

I get that trellis 1 is bad and warning is thrown, but wonder what you mean by "--and disable trellis--if psy RD is on". You should use trellis 2, right? By the comment, it seems to say that you override trellis to 0 if psy RD is used ALWAYS. Clarify for me please!

Dark Shikari

11th July 2008, 17:36

By the comment, it seems to say that you override trellis to 0 if psy RD is used ALWAYS. Clarify for me please!I override trellis 1 to set it to zero, if psy RD is on.

I should probably update the patch so that it doesn't complain if RD is off entirely.

If the link to the build is down, blame jarod/b0bor.

0.5 will be coming soon; I am currently doing analysis in order to create a "lambda table" for psy RD, to vary its strength based on quantizer.

fields_g

11th July 2008, 17:49

Makes sense. Thanks!

fields_g

11th July 2008, 18:33

Is the Win32 build only GIT rev 906 + PsyRD 0.4? Or are there other patches in there also?

bob0r

11th July 2008, 20:13

git 906 + psy rdo 0.4

Dark Shikari

12th July 2008, 06:31

Version 0.5 is up.

Blue_MiSfit

12th July 2008, 06:50

Nice :) He kept good on his word - attaboy dark_shikari !

It's going on those encoder first thing monday!

~MiSfit

Comatose

12th July 2008, 07:59

That was fast =)
Will version 1 be the one to be committed?

skystrife

12th July 2008, 08:12

http://forum.doom9.org/showthread.php?p=1158143#post1158143
^-- win32 build with psyRDO 0.5 applied, if you're interested.

ACrowley

12th July 2008, 08:55

Is psyRDO enabled by default with RDO+subme 7 ?

LaTo

12th July 2008, 10:46

I get a much smaller bitrate with new psy-rdo in CRF mode:

Build: x264 v886 psy-rdo 0.22
Size: 414mo

Cmd:
start /low /b /wait x264.886.psyrdo.exe --crf 18 --keyint 300 --min-keyint 30 --ref 6 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions all --8x8dct --ipratio 1.3 --qcomp 0.8 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --aq-strength 1.0 --rdcmp psy --output "psy-test.mp4" "test.avs"

Log:
avis [info]: 1280x720 @ 29.97 fps (9009 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 PHADD SSE4 Cache64
mp4 [info]: initial delay 667334 (scale 10000000)
x264 [info]: slice I:398 Avg QP:13.18 size: 5688100:00
x264 [info]: slice P:7782 Avg QP:15.43 size: 49859
x264 [info]: slice B:829 Avg QP:19.05 size: 28502
x264 [info]: mb I I16..4: 23.1% 53.5% 23.3%
x264 [info]: mb P I16..4: 4.2% 10.9% 4.8% P16..4: 36.9% 22.2% 15.9% 0.3% 0
.2% skip: 4.7%
x264 [info]: mb B I16..4: 0.1% 0.3% 0.1% B16..8: 41.7% 3.2% 9.7% direct:
15.0% skip:29.9%
x264 [info]: 8x8 transform intra:54.5% inter:59.9%
x264 [info]: direct mvs spatial:98.1% temporal:1.9%
x264 [info]: ref P 51.3% 16.4% 12.7% 7.1% 6.2% 6.3%
x264 [info]: ref B 75.5% 10.5% 7.0% 3.5% 3.4%
x264 [info]: kb/s:11557.4

encoded 9009 frames, 1.99 fps, 11557.63 kb/s

Build: x264 v910 psy-rdo 0.5
Size: 351mo

Cmd:
start /low /b /wait x264.910.psyrdo5.exe --crf 18 --keyint 300 --min-keyint 30 --ref 6 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions all --8x8dct --ipratio 1.3 --qcomp 0.8 --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --aq-strength 1.0 --psy-rd 1.0 --output "newpsy5-test.mp4" "test.avs"

Log:
avis [info]: 1280x720 @ 29.97 fps (9009 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 PHADD SSE4 Cache64
mp4 [info]: initial delay 667334 (scale 10000000)
x264 [info]: slice I:389 Avg QP:13.27 size: 4596900:00
x264 [info]: slice P:7672 Avg QP:15.54 size: 42965
x264 [info]: slice B:948 Avg QP:19.65 size: 22399
x264 [info]: mb I I16..4: 28.2% 57.8% 13.9%
x264 [info]: mb P I16..4: 5.8% 18.2% 3.3% P16..4: 38.4% 19.3% 9.8% 0.2% 0
.1% skip: 4.9%
x264 [info]: mb B I16..4: 0.2% 0.9% 0.2% B16..8: 39.6% 2.9% 4.4% direct:
13.1% skip:38.8% L0:36.1% L1:47.7% BI:16.2%
x264 [info]: 8x8 transform intra:65.3% inter:65.4%
x264 [info]: direct mvs spatial:97.8% temporal:2.2%
x264 [info]: ref P L0 54.0% 16.2% 12.0% 6.7% 5.6% 5.5%
x264 [info]: ref B L0 75.1% 10.0% 7.8% 3.9% 3.2%
x264 [info]: ref B L1 99.3% 0.7%
x264 [info]: kb/s:9813.5

encoded 9009 frames, 1.95 fps, 9813.65 kb/s

why? :confused:

CruNcher

12th July 2008, 11:14

why? :confused:

Because it's efficiency improved over time :)

cogman

12th July 2008, 15:17

I get a much smaller bitrate with new psy-rdo in CRF mode:

Build: x264 v886 psy-rdo 0.22
Size: 414mo

Build: x264 v910 psy-rdo 0.5
Size: 351mo

why? :confused:

Has quality dropped? No? Then quit complaining :P. My guess is because it manages the bitrate even better.

RickA

12th July 2008, 17:18

You are a great one Dark Shikari. Thanks for all your work.

Cheers,
Rick

wata

12th July 2008, 17:40

i am using megui latest x264 build 901 which use psy-rdo 0.22
so trellis should be set to 0 or 2?

currently using the following command to encode all my video, spot any setting wrong?

program --crf 19.0 --ref 5 --mixed-refs --no-fast-pskip --bframes 16 --b-pyramid --b-rdo --bime --weightb --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input"

Dark Shikari

12th July 2008, 17:42

i am using megui latest x264 build 901 which use psy-rdo 0.22
so trellis should be set to 0 or 2?2 is better but a lot slower. Its a tradeoff.

ajp_anton

12th July 2008, 23:45

Been trying to encode a DVD with insane grain. Psy 0.3 needed 2300 kbit/s to look somewhat close to the source. Psy 0.5 looks almost identical to the source at 2100 kbit/s!

skystrife

12th July 2008, 23:48

Is psyRDO enabled by default with RDO+subme 7 ?

How to use it:

Its on by default.

So... in other words, yes it is. You could have gathered that much though. =P

Inventive Software

12th July 2008, 23:59

How long am I gonna have to hold off to encode my DVDs, eh? :p

Comatose

13th July 2008, 04:37

Been trying to encode a DVD with insane grain. Psy 0.3 needed 2300 kbit/s to look somewhat close to the source. Psy 0.5 looks almost identical to the source at 2100 kbit/s!
Awesome work, Dark Shikari!

Any chance for some comparison screenshots, anton?

turbojet

14th July 2008, 08:42

Was there an issue found with psyRDO and trellis 1?
Or was there something added since 0.3 that definitely won't work with trellis 1?

I know it was never recommended to use trellis 1 with psyRDO (due to trellis 1 nature?) but I was getting noticably better quality over deadzones (even lower ones) with a very minimal speed hit. I never found any artifacts with it. I couldn't find enough of a difference between trellis 1 and trellis 2 to justify the <1 vs 2-2.5 fps 1080p on a 3800+ But I do notice enough of a quality difference between deadzones and trellis 2 in 0.5 to maybe take the <1 fps plunge or revert back to 0.3 until I get a better computer.

However if I can get the benefits I saw with trellis 1 along with the nice compression gain of 0.5 with no noticable quality difference so far, it would be much appreciated, unless there's some flaw.

DarkZell666

14th July 2008, 09:49

I override trellis 1 to set it to zero, if psy RD is on.
I think that answers your question ;)

turbojet

14th July 2008, 09:57

Ya I'm aware it switches off in 0.5 but what I'm asking is why was this change made?

I notice some people using trellis 1 in this thread, dark shikari not suggesting its use until more info is found (from old first post), and no issues found...

J_Darnley

14th July 2008, 13:11

[2008-07-12 16:53] <jarod> in case people ask me: why cant trellis 1 be used?
[2008-07-12 16:56] <Dark_Shikari> With trellis 1, during RDO, when picking the best mode to use, regular deadzone quantizer is used--trellis is only used in the final encode. This is for speed reasons--trellis is slow.
[2008-07-12 16:56] <Dark_Shikari> This is fine with regular RDO, because trellis and regular RDO optimize for the exact same thing
[2008-07-12 16:57] <Dark_Shikari> but with Psy RDO, Psy RDO is optimizing for something totally different than trellis is optimizing for
[2008-07-12 16:57] <jarod> what happens when you do use trellis 1?
[2008-07-12 16:57] <Dark_Shikari> so the shortcut of doing deadzone quant during RDO, and trellis only on the final encode, no longer works
[2008-07-12 16:57] <Dark_Shikari> no, trellis 1 isn't used.
[2008-07-12 16:57] <Dark_Shikari> trellis 2 showed to be consistently best
[2008-07-12 16:57] <jarod> x264 [warning]: psy RD is not compatible with trellis=1; use 0 or 2.
[2008-07-12 16:58] <jarod> x264 [warning]: psy RD is not compatible with trellis=1; use 0 or 2. [using trellis=0 now]
[2008-07-12 17:02] <jarod> ok, so its a feature, trellis 1 can never work with psy rd
[2008-07-12 17:03] <jarod> 2: trellis 1 = used by rules and many profile defaults
[2008-07-12 17:04] <jarod> whats better? psyrd+trellis2 or psyrd+trellis0 ratio speed/quality ? (going by your tests)
[2008-07-12 17:04] <Dark_Shikari> trellis 2 is always fuckslow
[2008-07-12 17:05] <jarod> if you encode 20fps on pass2, how much will trellis2 slow it down compared to 0?
[2008-07-12 17:06] <Dark_Shikari> anyways I'd rather people use psy rdo + trellis 0 than psy rd + trellis 1
[2008-07-12 17:07] <Dark_Shikari> and dropping trellis will give them the speed boost they need to not complain about psy RD... ;)

Snowknight26

15th July 2008, 04:14

[2008-07-12 17:06] <Dark_Shikari> anyways I'd rather people use psy rdo + trellis 0 than psy rd + trellis 1

But since 1 is overridden to 0....

I hope he meant 2 instead of 1.

Dark Shikari

15th July 2008, 04:32

But since 1 is overridden to 0....

I hope he meant 2 instead of 1.No, I didn't mean 2. 1 is overridden to zero--the reason being my above quote ;)

LoRd_MuldeR

15th July 2008, 11:13

But since 1 is overridden to 0....

I hope he meant 2 instead of 1.

Psy RDO + Trellis=1 simply is a bad combination. Therefore Psy RDO + Trellis=1 will be lowered to Trellis=0 and a warning is put out.
Nevertheless Psy RDO + Trellis=2 still is the recommended combination for maximum quality! But Trellis=2 is significant slower than Trellis=0 or Trellis=1.
So people that intentionally set up Psy RDO + Trellis=1 probably don't want their Trellis setting raised to Trellis=2 (major speed loss).

Yoshiyuki Blade

16th July 2008, 03:39

Here's a test clip with default psy-rd (v0.5). Not easy on the hardware: http://www.mediafire.com/?bfniddwmvrn

How does it look to you guys?

EDIT: I just noticed that you can actually see the illuminated rough surface texture on my LCD (its not glossy). x264 can certainly preserve the finer details!

Atak_Snajpera

16th July 2008, 12:26

eeee. At 16Mbps everything will look good :) Try to use 8 Mbps instead.

rhester72

17th July 2008, 04:02

Stupid question: Does PsyRDO require CABAC? (If so, why?)

Rodney

Dark Shikari

17th July 2008, 04:10

Stupid question: Does PsyRDO require CABAC?nope.

cogman

17th July 2008, 21:45

Another dumb question, I have copied the patch from pastebin (the text box on the bottom). What command are you guys using to apply the patch? I tried patch but it informed me that the file is only full of garbage.

I can't use a build because I am using linux, but I have some grainy videos that I really would like to test this on.

LoRd_MuldeR

17th July 2008, 21:47

I think "patch -p1 <file.diff" called from the x264 directory should to the job.

Dark Shikari

17th July 2008, 21:52

Click the "download" link on Pastebin instead of copying.

Also, you may have to use dos2unix.

cogman

17th July 2008, 22:19

all right, got the patch applied and I am running an encode now. I've seen a short clip and so far it looks good. Thanks for the help

Wow, I haven't finished encoding yet, but the differences are already pretty noticeable. Ill get some screen shots up in a moment.

First, no psy (http://i253.photobucket.com/albums/hh50/cogman10/firstnopsy.png)
First, psy (http://i253.photobucket.com/albums/hh50/cogman10/firstpsy.png)

Second, no psy (http://i253.photobucket.com/albums/hh50/cogman10/secondnopsy.png)
Second, psy (http://i253.photobucket.com/albums/hh50/cogman10/secondpsy.png)

Third, no psy (http://i253.photobucket.com/albums/hh50/cogman10/thirdnopsy.png)
Third, psy (http://i253.photobucket.com/albums/hh50/cogman10/thirdpsy.png)

As you can see, there is a big difference in grainy video. However, the size size did increase in this case from 261.1 -> 272.6 MB

Heres my encoding settings used on both versions (Git 913)

x264 test.y4m -o S01Ep19old.264 --no-psnr --no-ssim --threads auto --no-fast-pskip -t 2 --mixed-refs --me tesa -w --direct auto -A all --crf 20.0 -r 6 -m 7 -b 16 --b-pyramid --progress --b-rdo

Selur

18th July 2008, 23:58

However, the size size did increase in this case from 261.1 -> 227.6 MB
Where is the typo? Did you mean decrease or should 227.6 mean 272.6 ? ;)

TheRyuu

19th July 2008, 05:41

Where is the typo? Did you mean decrease or should 227.6 mean 272.6 ? ;)

Well then his tests are invalid I would think.
They are not at the same bitrate and therefor non-comparable. That is, if the size increase.

If it decreased the same still holds true but no one would care ;)

bkman

19th July 2008, 05:46

v0.5 still suffers from serious artefacting issues. Will have samples up to illustrate what I mean later.

Edit: After further testing it seems that the artefacts might be related to a bug with x264 and some low deblocking settings (-3:0), as I see some (different) artefacts with the fgo build too. Problem doesn't seem to occur at 0:0 deblocking settings. Will do some further testing.

Update: -2:-1 seems to be safe to use as well, and gives sharper results than 0:0.

DarkZell666

19th July 2008, 08:25

rhester72

19th July 2008, 15:21

@cogman : you used CRF, and you're like the Nth person to compare Psy and NonPsy using CRF, and it has been said N times already that CRF shouldn't be used to compare Psy and NonPsy. 2-pass should be used to compare Psy and NonPsy !.

What is your source for this? I rewalked this entire thread and can find no such claim. In fact, that would largely reduce the value of PsyRDO in the first place!

Rodney

LoRd_MuldeR

19th July 2008, 15:33

It justs says that you cannot test Psy RDO in CRF mode, you can use Psy RDO in CRF mode of course!

If you test PsyRDO versus Non-PsyRDO in CRF mode, you will get two files of different size as your result most likely ;)
Quality of files of different size cannot be compared, the test would be useless. 2-Pass avoids that.

Audionut

19th July 2008, 15:34

What is your source for this?

The developers of x264. It's been said many times before as DarkZell666 has pointed out.

Keep searching!!!

jeffy

19th July 2008, 15:43

What is your source for this? Rodney

I think this is the source, akupenguin, aimed at FGO (and the posts following this one):
http://forum.doom9.org/showthread.php?p=1129955#post1129955

cogman

19th July 2008, 15:50

@cogman : you used CRF, and you're like the Nth person to compare Psy and NonPsy using CRF, and it has been said N times already that CRF shouldn't be used to compare Psy and NonPsy. 2-pass should be used to compare Psy and NonPsy !.

Wow, sorry about the bold and colors, your effort for posting the screenshots _is_ appreciated, but it isn't as valuable as you intended :rolleyes:

You actually noticed by yourself that there was a flaw :
If the filesize is different by such a large amount, there's no way your eyes can judge if the bits moved around by psyrdo were well spent.

THE Question : Would pushing the bitrate up by the same amount without using psyrdo have the same effect or not ? (and we've done a full circle, now we're back to comparing two files with the same bitrate : one with psyrdo, one without).

If you want your tests to be valuable, use 2-pass ;)

I disagree. I believe the test results are valid. First, it is clear that Psy-Rdo is at very least the cause of the bitrate increase. This data is useful for anyone that does a CRF encode, It was stated earlier in this thread that people's filesize decreased with getting better quality, I just gave an example where filesize increased (grainy video)

Because we know that psy-rdo cause the increase in bitrate, it is safe to assume that at the same crf setting it will always (ok, not everything has been tested, but it look like it will) give better results, but not always give smaller file-sizes.

Now, I do get your point, but I hope you understand mine. I use CRF to get similar quality across encodes, not similar bitrates. I doubt (in fact Im sure) that I am not the only one. It is safe to say the Psy-rdo is giving better quality per value of CRF

And to those earlier, yes it was a typo, the increase was about 10 mb. not huge but big enough to make some differences (I do doubt that it was enough to give the quality increase that I saw)

Sharktooth

19th July 2008, 15:58

no, CRF is not a valid test for psy-RDO.
if you like CRF, that doesnt mean everyone uses it, and it doesnt mean it should be exclusively and universally used to optimize the encoder.

LoRd_MuldeR

19th July 2008, 16:05

@cogman:

What if Psy-RDO produces better quality at same CRF, but produces a bigger file at the same time?
How do you want to decide whether Psy-RDO is actually better? The increase in quality might be due to the increase in size...
No, to test Psy-RDO you must use 2-Pass, even if you use CRF later ...

cogman

19th July 2008, 16:06

nO, CRF is not a valid test for psy-RDO.
if you like CRF, that doesnt mean everyone uses it, and it doesnt mean it should be exclusively and universally used to optimize the encoder.

I realize that it isn't, and I realized that not everyone uses it. But again, my point was to show that with grainy video at a given crf value you will see a higher bitrate due to psy-RDO, though the video will look better.

Thats it. Im not trying to say that psy-Rdo optimized bitrate useage or anything to the sort. My message was for the most part to other CRF users "Beware, you may see bigger files as a result" Thats it.

Sharktooth

19th July 2008, 16:09

read the Lord MuldeR comment.
it's also quite natural to have a bigger filesize. the more details the encoder keeps (lowering the quntizer), the higher the needed bits.
That also alter the final rate factor... so it's perfectly normal.

Dark Shikari

19th July 2008, 16:11

My message was for the most part to other CRF users "Beware, you may see bigger files as a result" Thats it.This is inherent in the psy RDO algorithm, which lowers the mathematical coding efficiency--thus raising quantizers at the same bitrate. Since CRF will have the roughly the same quantizers no matter what settings you use, this means the bitrate will rise.

bkman

21st July 2008, 12:32

I've actually noticed the Quants being unusually low using PsyRDO 0.5.

Btw Dark Shikari, my testing shows that the previous bug with the algorithm seems to have been fixed. And with the improvements in 0.5 besides its truly an amazing difference. Between AQ and Psy ROD, congrats on finally making x264 behave admirably no matter the characteristics of the source! It's great work and really simplifies the encoding process.

Now we just need a quality metric that will reflect the visual benefit of your psy algorithm, as SSIM doesn't seem to cut it anymore :P

SilentTweak

21st July 2008, 23:48

LoRd_MuldeR

21st July 2008, 23:50

I've tried skimming through all 13 pages but I'm still a bit confused about a few things, if someone could answer these with a simple answer that'd be great:

1. Is psyRDO always on if I'm using the patch builded in this thread?
2. If so, is it okay to use 2-pass encode profiles or is it only for CFR?

Just some stuff people have been posting in the last few replies made things really confusing.

1. Psy RDO is on by default (with default strength), but only if you use a x264 build with "Psy RDO" patch
2. It works with 2-Pass as well as with CRF, but it will make your files a bit bigger in CRF mode

The comment that Psy RDO has to be used with 2-Pass mode was only for testing Psy RDO against no Psy RDO.
That's because if you want to compare the quality of two encodes, they need to have the same size...

If you just want to use Psy RDO for your regular encodes then CRF is 100% fine :)

SilentTweak

22nd July 2008, 00:00

Thanks for the quick reply Mulder :)

Sharktooth

22nd July 2008, 01:46

also, it may sound obvious but it's better to be specific, PsyRDO works only in RDO modes (subme>=6)

SilentTweak

22nd July 2008, 05:54

also, it may sound obvious but it's better to be specific, PsyRDO works only in RDO modes (subme>=6)

Okay well my profile uses subme=7 so I should be okay right? Also, are there any disadvantages to using this at low bitrates? Like 400kbps for SD res.

smok3

22nd July 2008, 07:56

my try
insane, psyrdo should be default;
http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/bbb_insane-x640y352.mp4
(in this sample: it seems to me as if the backgrounds have some decent texture now, but the foregrounds are over-sharpened, but i can be imagining things)

will try the same later with disabled psyrdo.

Sharktooth

22nd July 2008, 11:19

it looks damn good to me being a 480kbps encode.
try with deblock 0,0 or -1,0 or 0,-1 if you think its too sharp.

ncahammer

22nd July 2008, 16:19

1. Psy RDO is on by default (with default strength), but only if you use a x264 build with "Psy RDO" patch
2. It works with 2-Pass as well as with CRF, but it will make your files a bit bigger in CRF mode
If I use a non-psy x264 build a crf 18 will give me (most of the times) a transparent encode. Using this bitrate (or close to this) I could do a 2-pass encode with acceptable results.

Which method will give me a valid metric of source's compressibility when using a "Psy RDO" build ?

1) Should I raise crf to 20 ?
2) Should I somehow disable psy when doing this crf encode ?
3) Do a 1st pass with an expected bitrate and check QP of the log or .stats and then do 2st pass increasing or decreasing the bitrate ?

LoRd_MuldeR

22nd July 2008, 16:27

Simply use the same CRF value that you used without Psy RDO, e.g. CRF 18 ;)
If you are not happy with the result, then lower the CRF. If you want to save some bits, then raise the CRF and check whether the result is still acceptable or not.

IMHO doing a CRF encode, taking the resulting average bitrate and re-encoding the video in 2-Pass mode is nonsense and a waste of time.
Your second encode (2-Pass) would look no different from the first one (CRF). At least the difference would be negligible.
It was said several times that a 2-Pass and a CRF encode of the same (average) bitrate look almost identical. Only with CRF you cannot predict the filesize in advance.

If you want to achieve a certain level of quality, then use CRF. If you need to hit a certain target filesize then use 2-Pass. That's it.

ncahammer

22nd July 2008, 17:22

If you want to achieve a certain level of quality, then use CRF. If you need to hit a certain target filesize then use 2-Pass. That's it.
I don't want neither.
I don't want to waste bitrate or quality or media.
For example the problem is find out how many episodes of a series do fit in a DVD5, with a transparent (or close to it) quality and then encode targeting the DVD5 size or to align the encoded size of a movie to a DVD5/4 units.

Anyway, back on topic, I already do what you suggested on non-Psy builds, but it seems that I cannot balance it on "psy Rdo" builds. I don't have a starting point and numbers don't mean much any more. Must be something I am missing.

Thanks

LoRd_MuldeR

22nd July 2008, 17:27

Find out which CRF value still gives acceptable quality for you. Then encode all your episodes with that CRF value.
Finally put as many episodes on the disc, as fit on the disc. That's it...

Sharktooth

26th July 2008, 12:17

line 273 please add:
\n after Does nothing at subme < 6.

bob0r

26th July 2008, 12:27

line 273 please add:
\n after Does nothing at subme < 6.

Dark has already fixed this "internally".
Also the 1.00000 value is fixed to 1.0 i guess.

Dark Shikari

26th July 2008, 15:31

line 273 please add:
\n after Does nothing at subme < 6.I have a couple minor fixes of the sort in my internal code tree--no point in releasing a new version for that yet.

Revgen

27th July 2008, 11:09

Is "Turbo" in MeGUI a good option to use with PsyRDO?

Will it affect the quality significantly? Some posts here mention that settings need to be the same on both passes.

Sharktooth

27th July 2008, 15:12

Turbo option just speeds up the first pass.
it does it using different (lower) settings than the second pass. that means a very slight final quality loss but a huge gain in first pass speed.

smok3

27th July 2008, 18:48

Sharktooth; looking at the insane profile, isn't trellis disabled there by default? (with psyrdo version of x264 i mean)?

LoRd_MuldeR

27th July 2008, 18:52

Only Trellis=1 is disabled when Psy RDO is on, Trellis=2 works just fine with Psy RDO ...

Vit

29th July 2008, 13:37

Sharktooth

29th July 2008, 13:42

why did you use min-keyint 1 and keyint 24, only 2 b-frames, filter -2,-2, VBV limits, etc?
however look at the comparisons (http://mirror05.x264.nl/Dark/website/compare.html) x264 is way better than commercial encoders.

Vit

29th July 2008, 13:58

however look at the comparisons (http://mirror05.x264.nl/Dark/website/compare.html) x264 is way better than commercial encoders.

Laughing out loud. That's perfect argument

Sharktooth

29th July 2008, 14:01

Manao

29th July 2008, 14:55

Sharktooth : VBV & gop restriction come probably from Bluray constraints, so he can't avoid them. And imho, you're overreacting (and that's an understatement)

Vit : I don't remember Bluray preventing you from using 3 bframes in a row. And VBV bufsize, iirc, is half a second, thus 15000, not 45000.

Dark Shikari

29th July 2008, 14:58

I've encoded full STEM clip at 15 MBits/s using this patch and Sonic CineVision 2.6. Sonic's encode is consistently better, am I doing something wrong or commercial encoders are not as crappy as some x264 apologists claim?

Here's the command line:
x264.910.modified.exe --pass 1 --fps 23.976 --bitrate 15000 --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --bime --weightb --filter -2,-2 --subme 6 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 45000 --vbv-maxrate 30000 --threads auto --thread-input --progress --no-dct-decimate --output "f:\stem_x264.264" "F:\Source Files\StEM_full.yuv" 1920x1080 --aq-mode 2

Second's pass settings are the same, but with --pass 2. I can post some pictures if anyone is interestedSo basically:

1. You use awful settings and wonder why the output sucks (sorry folks, but I'm not going to make x264 compensate for user stupidity here).
2. Instead of asking "how can I make these settings better", you start whining about "x264 apologists"...

Now, if what you actually meant was "How can I improve the quality of my output" and you just mistyped, try this instead:

x264.910.modified.exe --pass 1 --fps 23.976 --bitrate 15000 --level 4.1 --ref 4 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --me umh --mixed-refs --bime --weightb --filter -2,-2 --subme 7 --b-rdo --8x8dct --threads auto --progress --no-dct-decimate --output "f:\stem_x264.264" "F:\Source Files\StEM_full.yuv" 1920x1080

15 megabit 1080p is a rather bad place to compare at though, given that any decent encoder should be able to basically give transparency, and if you can't pick out the details between two encodes without using a microscope, its hard to compare them.

cogman

29th July 2008, 15:05

laugh whenever you want. you're a n00b and not even able to set up an encoder correctly and you're still talkin? get out or learn something before speaking.
and, yes, it's a fair comparison made by competent ppl, not incompetent ppl like you.
x264 also won the last doom9 codec comparison... so better SEARCH before speaking as per forum rules.
if you came here for insulting the devs hard work then you're NOT welcome.

now now, be careful lest you violate rule #4

Though, VIT Sharktooth is right, x264 when given the proper settings is a miracle worker. Try the settings that he gave you and see if there is any improvement.

DarkZell666

29th July 2008, 15:09

- Any screenshots and the details of the settings you used in CineVision to share ? :)
- CineVision isn't the only commercial encoder out there, so maybe you are right and it might well be better than other commercial encoders, but those have indeed been proven weaker than x264, you can't deny it. But the former also needs proving with pictures or samples :)

I've encoded full STEM clip at 15 MBits/s using this patch and Sonic CineVision 2.6. Sonic's encode is consistently better, am I doing something wrong or commercial encoders are not as crappy as some x264 apologists claim?

Here's the command line:
x264.910.modified.exe --pass 1 --fps 23.976 --bitrate 15000 --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 2 --b-pyramid --bime --weightb --filter -2,-2 --subme 6 --analyse p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 45000 --vbv-maxrate 30000 --threads auto --thread-input --progress --no-dct-decimate --output "f:\stem_x264.264" "F:\Source Files\StEM_full.yuv" 1920x1080 --aq-mode 2

Second's pass settings are the same, but with --pass 2. I can post some pictures if anyone is interested

smok3

29th July 2008, 15:24

I think Vit is targeting bluray? (--keyint 24)

Dethis

29th July 2008, 16:59

I think Vit is targeting bluray? (--keyint 24)

If so, he should set
vbv-baffsize 30000 (1 sec),
vbv-maxrate up to the smaller among 40000 or 48000 minus the required bitrate by the sound tracks subtitles etc.

Sharktooth

30th July 2008, 02:01

he could also use 3 bframes (it's ok with blu-ray and could give a major boost in quality), eliminate --no-dct-decimate (that often results in bigger filesize hence worse quality for a bitrate based RC) and --no-fast-pskip, higher the deblocking (-2,-2 often means blocks), -b-rdo and -me umh are missing but he used other useless slow options (like --no-fast-pskip or --no-dct-decimation), --aq-mode 2 is redundant since it's the default, also the VBV paramaters are completely wrong... that shows he is incompetent (so my comment even if may sound a bit harsh is not an offense, it's just the reality). He shown he doesnt know anything about x264 coz he set the options almost randomly and he is still offending ppl and destructively criticizing x264 and the devs work without even asking if he was doing something wrong...
he joined the forum on march 2007 so he had all the time to document himself but obviously he didnt. He made 3 posts of which 2, in this thread, contain insults and are plain provocations...
IMHO if he keeps that behaviour he better find another place.

OT: anyone knows the AVC-HD exact vbv-buffsize?

Manao

30th July 2008, 05:45

He never criticized x264. You're criticizing his options, yet --no-fast-pskip / --no-dct-decimate / --filter -2:-2 were still advised by Dark_Shikari. He didn't use subme 7 / b-rdo / umh (he stopped at subme 6 / hex ) but it's still a coherent choice.

In the end, though the number of bframes / vbv-bufsize seem off, they may probably have been set to match those used in Sonic CineVision, in order to make a fair comparison.

And, on a side note, if 7 years ago I had received such a welcome on doom9, I would never have bothered.

Dark Shikari

30th July 2008, 05:47

And, on a side note, if 7 years ago I had received such a welcome on doom9, I would never have bothered.The reason he got such an icy response was not because of the complaint about x264 quality, but rather because of the phrase "x264 apologists"; it is quite reasonable to interpret this as an attack, a troll, or both.

If you used such inflammatory and loaded language, you wouldn't have been welcomed here either. Fortunately, you're much more mature than that and I would never expect anything of that sort from you.

I do agree that most people here were far too sharp in their reaction; there seems to be a tendency for people to see others overreact, and interpret that as a signal that they can overreact too. It generally is a good idea to assume good faith at least initially, which most people seem to forget...

foxyshadis

30th July 2008, 05:50

Sagittaire

30th July 2008, 08:12

Well just my 2 cents.

1) BR and AVCHD specifications
- HP@4.1 specification with limitation
- Buffer max for 1080p24: 30 000 bits
- Max bitrate at 40 Mbps for BR and 30 Mbps for AVCHD
- 4,3 for p,b frame reference, 3 pyramidal bframe imply 3,2 ref for p,b. Use 2 bframes with 4,3 ref is better for software compatibility.
- Max gop at 24 with IDR
- WPred
- FGM is not supported

2) At 15 Mbps you have not transparence with 42" and higher screen. From my experience x264 with good patch is by far better than Mainconcept SDK (cinevision) but only at low/medium bitrate.
x264 produce really impressive result in [6-8] MBps interval for 1080p24 content.

@REM -----------------------------------------------------------
@REM
@REM Profil BluRay 1080p23.976 extra high quality
@REM
@REM -----------------------------------------------------------

@REM Source file name (suffit de mettre la source ici)
set E_SRC=Lossless.avs

@REM Set of quality (ici la qualité 1-50)
set E_BR=21.3

@REM Set of max bitrate (ici le bitrate max)
set MAX_BR=40000

@REM Set of Buffer (ici le buffer)
set BUF_BR=30000

@REM Set credit (frame de début du générique)
set CRE_FR=201560

@REM Set end credit (frame de fin du générique)
set END_FR=207442

@REM Profil

x264.exe --threads auto --thread-input --keyint 24 --min-keyint 1 --crf %E_BR% --vbv-maxrate %MAX_BR%
--vbv-bufsize %BUF_BR% --mvrange 511 --level 4.1 --bframe 3 --b-pyramid --b-rdo --bime --weightb --ref 3
--mixed-refs --direct auto --deblock -2:-2 --ipratio 1.10 --pbratio 1.10 --partitions "all" --8x8dct --me "umh"
--subme 7 --trellis 2 --no-fast-pskip --no-dct-decimate --aud --nal-hrd --sar 1:1 --cqmfile Sagittaire.cfg
--psy-rd 1.0 --zone %CRE_FR%,%END_FR%,b=0.33 --progress --pass 1 --stats "stat.log" -o 1080p_Q1.264 %E_SRC%

pause

smok3

30th July 2008, 10:07

Sagittaire, what range of CRF values do you usually use? (%E_BR%), any special reason for 21.3?

Sharktooth

30th July 2008, 12:55

Sharktooth: Calm down. You get way too riled up when anyone posts something provocative, and start flinging insults, instead of putting them in their place by calmly pointing out what's wrong. You'll end up suspended for rule 4 if you don't stop reacting angrily.
i am calm, i did not offend or insulted anyone.
what may sound an offence is a mere constatation of facts.
btw trust me, you dont want to see me angry.

bob0r

30th July 2008, 15:57

..
btw trust me, you dont want to see me angry.

Trust me aswell, i once trew a blu-ray disc at Shark "Zangief" Tooth's head..... i couldn't walk/speak/blink my eyes/go to the rest room for 5 months.

Sagittaire

30th July 2008, 16:22

Sagittaire, what range of CRF values do you usually use? (%E_BR%), any special reason for 21.3?

I make comparison with DarkNight uncompressed source.
x264 produce simply 12 Mbps at 21.3 for this encoding.
In this test x264 with psyrdo patch is a real killer.

chainring

30th July 2008, 20:52

He never criticized x264. You're criticizing his options, yet --no-fast-pskip / --no-dct-decimate / --filter -2:-2 were still advised by Dark_Shikari. He didn't use subme 7 / b-rdo / umh (he stopped at subme 6 / hex ) but it's still a coherent choice.
Argh, my head is hurting! I've tried keeping up with all the patch threads, the current version thread, and now I see, what seems to be, conflicting info on --no-fast-pskip / --no-dct-decimate / --filter -2:-2.

So, for a person using build 920, psyRDO on (default), trellis 2 (don't care about speed loss), and using CRF; what is the correct application of these settings? I've now seen Sharktooth say --no-fast-pskip and --no-dct-decimate are bad. I've seen Dark_Shikari say to just go with default filter values (0:0). Now, there's conflicting info in what I've quoted from Manao.

Any help?

BTW, here's my commandline as it stands now.
--crf 20.0 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --subme 7 --trellis 2 --partitions p8x8,b8x8,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"

Dark Shikari

30th July 2008, 20:59

Argh, my head is hurting! I've tried keeping up with all the patch threads, the current version thread, and now I see, what seems to be, conflicting info on --no-fast-pskip / --no-dct-decimate / --filter -2:-2.

So, for a person using build 920, psyRDO on (default), trellis 2 (don't care about speed loss), and using CRF; what is the correct application of these settings? I've now seen Sharktooth say --no-fast-pskip and --no-dct-decimate are bad. I've seen Dark_Shikari say to just go with default filter values (0:0). Now, there's conflicting info in what I've quoted from Manao.

Any help?

BTW, here's my commandline as it stands now.
--crf 20.0 --ref 5 --mixed-refs --no-fast-pskip --bframes 3 --b-pyramid --b-rdo --bime --weightb --subme 7 --trellis 2 --partitions p8x8,b8x8,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input"--no-fast-pskip is not going to hurt quality. It might not help a lot, but it doesn't hurt.

Manao

30th July 2008, 21:05

I never given any settings on this thread. I just compared Vit's initial settings from those advised by Dark_Shikari and pointed out settings that were present in both, yet subject to polemic : no-fast-pskip, no-dct-decimate, filter -2:-2.

I don't know whether no-fast-pskip and no-dct-decimate ought to be used or not (instinctively, i'd say the first is good, and so is the second if trellis 1/2 is used). As for filter, between -3:-3 and 1:1, it's imho a subjective matter.

chainring

31st July 2008, 17:33

Hi Manao,

Thank you for the reply!

I wasn't meaning to imply YOU were giving the settings, per se, but just quoting what you were in turn quoting.

I never given any settings on this thread. I just compared Vit's initial settings from those advised by Dark_Shikari and pointed out settings that were present in both, yet subject to polemic : no-fast-pskip, no-dct-decimate, filter -2:-2.

I don't know whether no-fast-pskip and no-dct-decimate ought to be used or not (instinctively, i'd say the first is good, and so is the second if trellis 1/2 is used). As for filter, between -3:-3 and 1:1, it's imho a subjective matter.

CruNcher

31st July 2008, 19:48

Sharktooth

31st July 2008, 19:51

he used wrong settings for x264. you cant compare speed and quality of 2 different encoders if you cant set up them (or at least one of them).

CruNcher

31st July 2008, 19:54

it's only important that the G4 Encoder settings where of the same nature then the X264 settings, tough we dont know what the Cinevision 2.6 settings where if they where equal you could very well compare it :) especialy the decission side of things b-frame decission, partition decission, scenecut and b-pyramid decission is very important here. Compression/Complexity wise i agree Vit his settings aren't as effective as Sagittaire but to call them wrong hmm sure in terms of BD profile there way of too to what you normaly would use but it doesnt matter in his comparision he did with Cinevision 2.6 in this case for this very special Film source. :)

Sharktooth

31st July 2008, 20:02

he said cinevision was constantly better (subjective, without pics or clips) so probably he used much different settings and we also dont know anything about the source and cinevision settings.
he just came here, trolled and gone away.
he just didnt contributed in any way to the discussion, so, for what concerns me, he could even not post at all.

CruNcher

31st July 2008, 20:15

he said cinevision was constantly better (subjective, without pics or clips) so probebly he used much different settings and we also dont know anything about the source and cinevision settings.
he just came here, trolled and gone away.
he just didnt contributed in any way to the discussion, so, for what concerns me, he could even not post at all.

Yes i agree his behaviour for what seems to be a Professional Post House Encoder is a little weired indeed, but it doesn't mean his experience was wrong, tough i would thrust Sagittaire 1000x times more ;)

@Sagittaire
I hope we gonna see a Cinevision 2.6 vs latest X264 GIT and X264 GIT + Psy RD Blu-Ray restricted Film Source comparission from you in the future :)

Sagittaire

31st July 2008, 22:06

@Sagittaire
I hope we gonna see a Cinevision 2.6 vs latest X264 GIT and X264 GIT + Psy RD Blu-Ray restricted Film Source comparission from you in the future :)

1) Well from Mutek (Elecard SDK enginer): "there are not quality gain for G4 but only speed optimisation"
http://forum.doom9.org/showthread.php?p=1149767#post1149767

2) Moreover you can't use all the insane SDK setting in cinevision 2.5 and certainely not in cinevision 2.6 too. Cinevision is pro gui for high bitrate encoding. Certainely better here to use Reference or Converter for have the insane setting.

3) Psy RD patch for x264 is a real killer. Certainely the best patch that I have ever seen for x264. RDO for bframe decision don't make very higher quality like I expected but some small optimisation produce big improuvement at the end.

CruNcher

1st August 2008, 00:31

1) Well from Mutek (Elecard SDK enginer): "there are not quality gain for G4 but only speed optimisation"
http://forum.doom9.org/showthread.php?p=1149767#post1149767

2) Moreover you can't use all the insane SDK setting in cinevision 2.5 and certainely not in cinevision 2.6 too. Cinevision is pro gui for high bitrate encoding. Certainely better here to use Reference or Converter for have the insane setting.

3) Psy RD patch for x264 is a real killer. Certainely the best patch that I have ever seen for x264. RDO for bframe decision don't make very higher quality like I expected but some small optimisation produce big improuvement at the end.

So you experience tells you --b-rdo and it's resulting 20% speed lose can be saved now when useing psy-rd alone (visualy) ? that's great news :) seeing that RD is allready faster then some month ago :D and saving the 20% from --b-rdo without much of a subjecive visual quality lose that's really a big win and also what my subjective tests are indicating (tough im still testing) :)
And no it wasn't my intention to compare Insane settings vs cinevision non setable settings it was my intention to compare the decissions and the speed/quality difference if the're any for a Blu-Ray Framework @ exactly those High Bitrates and gop restrictions :)

Dark Shikari

1st August 2008, 00:35

So you experience tells you --b-rdo and it's resulting 20% speed lose can be saved now when useing psy-rd alone (visualy) ? that's great news :) seeing that RD is allready faster then some month ago :D and saving the 20% from --b-rdo without much of a subjecive visual quality lose that's really a big win and also what my subjective tests are indicating (tough im still testing) :)I'm pretty sure he's talking about --b-adapt 2, not --b-rdo...

jult

2nd August 2008, 13:09

3. Psy RD strength is now a decimal value with default 1.0. Don't touch it unless you have good reason.
4. Psy RD strength now automatically scales based on quantizer. This is done internally--the "strength" is a multiplier to this internal value.
So, if I use CRF, does --psy-rd still pick the right scale? (I generally prefer crf over some static rate target.)
If not, what would you recommend over this with a very sharp 1280x720 HD camcorder source?
x264.exe --crf 22 --keyint 200 --min-keyint 25 --no-fast-pskip --no-dct-decimate --no-psnr --no-ssim
--subme 6 --ref 9 --mixed-refs --bframes 5 --b-pyramid --b-rdo --bime --weightb --direct auto
--filter -2,-1 --psy-rd --analyse all --8x8dct --me umh
--threads auto --thread-input --progress --output "%%~na.h264" "%%a"
Thanks in advance!

LoRd_MuldeR

2nd August 2008, 13:35

Psy RDO works just fine with CRF mode! It will scale automatically, based on the quantizer.
The "--psy-rd" option will be multiplied to the internal scaling factor, so don't touch this value!
(...unless you have a very good reason to do so)

jult

2nd August 2008, 14:01

OK, tnx. I just discovered though that both --psy-rdo and --hadamard were unknown commands to the x264 modified rev. 928 from x264.nl. Seems this patch is not included (yet)?

LoRd_MuldeR

2nd August 2008, 14:09

OK, tnx. I just discovered though that both --psy-rdo and --hadamard were unknown commands to the x264 modified rev. 928 from x264.nl. Seems this patch is not included (yet)?

I don't know what "--hadamard" is supposed to do, but it's not an official x264 option. There only is "--me tesa" as mentioned in the other thread.
And "Psy RDO" is not in the official x264 git yet, it's available as a patch! Patched builds can be found in this thread, as always:

Current Patches, Where to get them, How they affect speed/output (http://forum.doom9.org/showpost.php?p=1165193&postcount=615)

Sharktooth

2nd August 2008, 14:51

--psy-rd and only available in patched/modified builds... --hadamard does not exists.

jult

2nd August 2008, 16:17

--psy-rd and only available in patched/modified builds...
I had the latest modified build, but I used --psy-rdo instead of --psy-rd. (Why the o was omitted is beyond me..)

chainring

2nd August 2008, 16:32

If you have one of the builds from here (http://forum.doom9.org/showthread.php?t=130364), then psyRDO is included and on by default. Go to the end of the thread. Or, if you're using meGUI and updating from the development servers, it's updating to a version with psyRDO.

Sharktooth

3rd August 2008, 15:41

I had the latest modified build, but I used --psy-rdo instead of --psy-rd. (Why the o was omitted is beyond me..)
the option is --psy-rd... not --psy-rdo... the "o" stands for optimization(s), it was omitted to make the option shorter (...i think...).

also --no-fast-pskip may not help (it doesnt help much if at all) but it will consistently slow down the encoder. is it worth it? IMHO only for insane settings.

Avenger007

5th August 2008, 05:56

So what's there left to do before Psy RDO is committed to git?

All the clips I've tested show that Psy RDO retains more detail even though SSIM is slightly lower. The lower SSIM seems to be as a result of the detail not being exactly like the original but it's still close enough that it looks legit.

Dark Shikari

5th August 2008, 08:30

So what's there left to do before Psy RDO is committed to git?Psy trellis (http://i36.tinypic.com/ickyz9.png) (regular trellis (http://i36.tinypic.com/2dsfhur.png))

G_M_C

5th August 2008, 08:47

Psy trellis (http://i36.tinypic.com/ickyz9.png) (regular trellis (http://i36.tinypic.com/2dsfhur.png))

Hmmm, i find the difference only marginal; Switching between the two makes the psy-trellis just an tat sharper, and the rest of the difference seems only to be the grain beeing different. I doubt if it was really clearly noticable with real moving images, as opposed to static screenshots.

Avenger007

5th August 2008, 08:55

Psy trellis (http://i36.tinypic.com/ickyz9.png) (regular trellis (http://i36.tinypic.com/2dsfhur.png))
Does that mean there's nothing left to do? Because Psy trellis looks more detailed and less blurred than regular trellis.

G_M_C

5th August 2008, 08:58

Does that mean there's nothing left to do? Because Psy trellis looks more detailed and less blurred than regular trellis.

I have the feeling that the "standard trellis"-image is not blurred, but the psy-trellis is sharpened (and i'm no fan of sharpening).

Dark Shikari

5th August 2008, 09:06

Does that mean there's nothing left to do? Because Psy trellis looks more detailed and less blurred than regular trellis.No, my point is that "standard trellis" is "psy RD + --trellis 2" and "psy trellis" is an unreleased algorithm that I have yet to perfect ;)

Neither is blurred or sharpened.

DarkZell666

5th August 2008, 09:11

Hmmm, i find the difference only marginal; Switching between the two makes the psy-trellis just an tat sharper, and the rest of the difference seems only to be the grain beeing different. I doubt if it was really clearly noticable with real moving images, as opposed to static screenshots.

I find the psy trellis potentially closer to the source than the regular trellis, too bad :p (the regular trellis screenshot shows detail loss, which seems to be "recovered" by the psy-trellis version).

Dark Shikari, could you post the source frame so everyone can see ? ;)

Dark Shikari

5th August 2008, 09:15

Source (http://i37.tinypic.com/6r6680.png)

I think I accidentally used the wrong color conversion matrix or something, so ignore the slightly off colors.

CruNcher

5th August 2008, 09:37

what for a QP is this frame and how would the regular trellis look like without deblocking ?

Soichiro

5th August 2008, 13:25

DarkZell666

5th August 2008, 14:26

I think the old version actually looks closer to the original, but the new version (with psy trellis) actually seems to look better than the original (less ugly blocking and jagged edges). Though I've never been a fan of film grain to begin with, so maybe it's just my preference. :p

:confused: That's not what I see, are you sure you didn't swap tabs in FF when comparing ? That has happened to me a couple of times already :D.

Ok, I'll compare again in different viewing conditions, I have too much light around me here ATM, but my vote goes to Psy-Trellis (aka. --trellis 3 ? :p)

elguaxo

5th August 2008, 14:29

my vote goes to psy-trellis

+1 :)

Sharktooth

5th August 2008, 14:43

the first picture looks more detailed to me too.

refulgentis

5th August 2008, 14:43

that's scary, I can see differences between the source and regular trellis, or regular trellis and psy trellis, but between psy trellis and the source I see absolutely no difference.

Sharktooth

5th August 2008, 14:45

there's indeed a difference... but it's not so visible.

LoRd_MuldeR

5th August 2008, 14:59

I wouldn't go without Psy RDO nowadays... :)

tetsuo55

5th August 2008, 15:48

These Psy optimisations are getting better and better!

Do you think there are more area's that you can psy-improve?

Warpman

5th August 2008, 19:47

These Psy optimisations are getting better and better!

Do you think there are more area's that you can psy-improve?

nothing is perfect so there is always room for improvements nearly everywhere...

there was a development thread here updated by DS with some things that could be done... try the search

Avenger007

5th August 2008, 21:11

No, my point is that "standard trellis" is "psy RD + --trellis 2" and "psy trellis" is an unreleased algorithm that I have yet to perfect ;)
Wow! :D
The complexity difference between "psy trellis" and "standard trellis" looks just like the complexity difference between psy RD and no psy RD in my test clips.

I have a batch of encodes to do and after seeing "psy trellis" I think I'll wait until it is "perfected" before I start encoding them. :)

yesgrey

5th August 2008, 23:55

between psy trellis and the source I see absolutely no difference.

Look at the neck and at the bottom left corner of the image. The differences are very subtle...

I also prefer the psy trellis, the difference to the standard is easilly noticed!

Great work! :thanks:

I am also waiting for doing some conversions...

Dark Shikari

6th August 2008, 00:31

Sharktooth

6th August 2008, 00:46

same as for bframes patch. it never went into megui auto-update.

LoRd_MuldeR

6th August 2008, 01:52

Psy-RD + psy-trellis patch prototype (http://pastebin.com/f3e048abf).

changes:

1) automatically lower chroma QP offset with psy-rd and psy-trellis in order to compensate for higher overall quantizer for chroma quality
2) prototype psy trellis, not optimized at the moment
3) various cosmetics/etc
4) remove restriction against trellis 1, since psy trellis is now in

Please do not go around stuffing this one in megui builds, this is experimental.

Doesn't compile for me :(

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD
-s -fomit-frame-pointer -c -o encoder/analyse.o encoder/analyse.c
In file included from encoder/analyse.c:35:
encoder/rdo.c: In function 'x264_quant_4x4_trellis':
encoder/rdo.c:575: error: 'struct <anonymous>' has no member named 'i_lambda_qp'

encoder/rdo.c: In function 'x264_quant_8x8_trellis':
encoder/rdo.c:586: error: 'struct <anonymous>' has no member named 'i_lambda_qp'

make: *** [encoder/analyse.o] Error 1

Full log: http://pastebin.com/m75ed9773

gav1577

6th August 2008, 02:01

Psy trellis defiantly looks better to me the grain stands out more nice job Dark Shikari :) I usually lower chroma QP offset to -4 found it helped with banding with fog clouds/sky does this mean with this patch there is no point in lowering the value because it will be done automatically ? and also is there a need for --trellis 2 --trellis 1 in the cmd line when using psy-trellis ? Thanks

Sharktooth

6th August 2008, 02:05

trellis 1 will be automatically disabled if you use psy-rdo that's enabled by default at subme > 5.

gav1577

6th August 2008, 02:09

trellis 1 will be automatically disabled if you use psy-rdo that's enabled by default at subme > 5.

My mistake i just realized that just meant --trellis 2 :)

Dark Shikari

6th August 2008, 02:32

Doesn't compile for me :(

gcc -O4 -ffast-math -Wall -I. -DHAVE_MMX -DARCH_X86 -DSYS_MINGW -DHAVE_PTHREAD
-s -fomit-frame-pointer -c -o encoder/analyse.o encoder/analyse.c
In file included from encoder/analyse.c:35:
encoder/rdo.c: In function 'x264_quant_4x4_trellis':
encoder/rdo.c:575: error: 'struct <anonymous>' has no member named 'i_lambda_qp'

encoder/rdo.c: In function 'x264_quant_8x8_trellis':
encoder/rdo.c:586: error: 'struct <anonymous>' has no member named 'i_lambda_qp'

make: *** [encoder/analyse.o] Error 1

Full log: http://pastebin.com/m75ed9773I'm an idiot, fixed (http://pastebin.com/f6795ade1).

Dark Shikari

6th August 2008, 02:32

trellis 1 will be automatically disabled if you use psy-rdo that's enabled by default at subme > 5.Read my post, --trellis 1 works now with psy-trellis and psy-rd (psy-trellis is just a modificiation to trellis that happens when psy-rd is on).

gav1577

6th August 2008, 02:37

(psy-trellis is just a modificiation to trellis that happens when psy-rd is on).

Got it now was a bit confused :)

LoRd_MuldeR

6th August 2008, 02:45

I'm an idiot, fixed (http://pastebin.com/f6795ade1).

Yup, that one compiles again :thanks:

saint-francis

6th August 2008, 03:28

Read my post, --trellis 1 works now with psy-trellis and psy-rd (psy-trellis is just a modificiation to trellis that happens when psy-rd is on).

So with psy-trellis is there still an advantage of --trellis 2 over --trellis 1?

wyti

6th August 2008, 03:45

Yes, trellis 1 is not applied everywhere, and trellis 2 is always active (but far slower)

Sharktooth

6th August 2008, 04:07

Read my post, --trellis 1 works now with psy-trellis and psy-rd (psy-trellis is just a modificiation to trellis that happens when psy-rd is on).
sorry, just missed it.

bob0r

6th August 2008, 16:38

I'm an idiot, fixed (http://pastebin.com/f6795ade1).

I agree.

DarkZell666

6th August 2008, 16:45

I'm an idiot, fixed. I agree.

rofl ... :p

Dark Shikari

6th August 2008, 18:20

The power of psy-trellis + psy-RD:

http://i35.tinypic.com/rk33wx.png

The above P-frame is from the first 500 frames of BlackPearl... encoded at 400kbps.

Here's the same frame from a certain widely-renowned commercial encoder (http://i34.tinypic.com/qp53s0.png).

Sharktooth

6th August 2008, 18:23

holy $#!7, are you sure psy-rdo and/or psy-trellis are not yet ready?

Avenger007

6th August 2008, 19:24

But that frame is rather dark so the extra complexity is probably hard to perceive during normal play. I'm guessing it's that darkness that makes it still look good @ 400kbps.

Sharktooth

6th August 2008, 19:27

nope. iy you bring up the brightness you'll see all the details.
http://www.webalice.it/f.corriga/temp/temp.png

Avenger007

6th August 2008, 19:32

I know, but that part of the scene wasn't meant to be viewed with high brightness.
Perhaps a sample from 300 might really show the power of psy-trellis + psy-RD.

Sharktooth

6th August 2008, 19:33

but details are still there at a low bitrate. that means the algo is good.

Ranguvar

6th August 2008, 19:40

Dark Shikari

6th August 2008, 19:46

Well, IMO, a great psychovisual algo would remove all details in areas the human eye can't see at the input brightness, and spend those bits elsewhere ;)I'm not about to start changing x264 to optimize for people with crap quality monitors ;)

On the topic of "300" I've actually found that psy-trellis and even psy-rd help there less than one would think, for some weird reason.

Sagekilla

6th August 2008, 19:50

That's one way of interpreting it, psychovisual could remove details we can't perceive -- just like how we remove sounds that are too faint to hear that occur at the same time as very loud sounds in audio compression. Otoh, you got the kinds that try to replicate the original signal using trickery, like SBR in AAC.

Might be a bit of a poor analogy, but that's how I see it. In any case, excellent work Dark Shikari!

Edit: In regards to the latest post DS just made, is there any chance you might of accidentally optimized your algos for that clip?

Avenger007

6th August 2008, 20:08

On the topic of "300" I've actually found that psy-trellis and even psy-rd help there less than one would think, for some weird reason.
On a clip I've tested with psy-trellis + psy-rd, it seems to "amplify" the detail to some extent, so some parts look a little more detailed than the original. That's not bad because the detail still looks legit.
Maybe it also amplifies noise, so-much-so that it becomes unstable and is noticeable.

Dark Shikari

6th August 2008, 20:11

Edit: In regards to the latest post DS just made, is there any chance you might of accidentally optimized your algos for that clip?The reason psy-trellis doesn't seem to be as good in "300" is that it seems to give best results when you have a balance of fine and coarse detail that need to be retained. 300 has no fine detail; all the grain is pretty large-scale, I think, and quite heavy, so the encoder ends up pressed to do something with it regardless. OK, so just a guess.

I don't think I optimized them specifically for that clip--I find that psy-trellis helps in general with subtle grain and detail, and sharpens non-grainy stuff. It should (ideally, at least) effectively eliminate all cases where deadzones beat trellis visually.

cogman

6th August 2008, 20:28

So, is there any estimation when this will be included in the stream. I would love to be able to compile x264 without applying these patches (Im lazy).

Good work over all, it's great to see x264 improve by such leaps and bounds. (and frustrating to have to re-encode my stuff because of it :P)

Sagekilla

6th August 2008, 21:09

I wonder how well it would work when you remove most of the grain from 300 then, considering I almost always remove grain now since I prefer the cleaner look and MUCH smaller file sizes..

ToS_Maverick

6th August 2008, 21:36

well I think it will be like encoding black pearl denoised... cleaner look and with the psy patches the dither is kept (if ditherd with gradfun)!

Ranguvar

6th August 2008, 22:41

Yeah, I always do an FFT3DGPU with different settings for each source to do some light degraining. I err on the side of caution, and only do a little degraining, but it helps a ton. Also, de-haloing can help a lot too :) Lots of DVDs (The Mummy) have it in spades. Psy improvements just change how x264 seems to deal with grain. Before, it smoothed it out, now it preserves most of it, which means you should remove a good bit or pay :p

Blue_MiSfit

6th August 2008, 23:18

Man...

I'm really impressed.

http://www.funnyforumpics.com/forums/This-Thread-Delivers/1/deliverslm9.jpg (http://www.funnyforumpics.com)

..sorry, I had to do it ;)

Keep up the awesome work, DS!

~miSfit

Terranigma

6th August 2008, 23:21

Someone wants to post a compile?

Dark Shikari

6th August 2008, 23:25

Someone wants to post a compile?See the current patches thread...

LoRd_MuldeR

6th August 2008, 23:34

Someone wants to post a compile?

In case you missed it, it's here:
http://forum.doom9.org/showpost.php?p=1167186&postcount=647 ;)

foxyshadis

7th August 2008, 01:02

Well, IMO, a great psychovisual algo would remove all details in areas the human eye can't see at the input brightness, and spend those bits elsewhere ;) But that's debatable (as all psy algos are). Point is, psy-trellis r0x0rz.

This is what you have avisynth for: Optimizing to your environment. x264 already somewhat optimizes for the case of imperfect eyes on a high quality screen, that's the whole point of this patch, just like lame optimizes for imperfect (but 'golden') ears through high quality headphones. If you somehow can't hear 11200-11400Hz but can hear the rest, or more to the point, if your lousy speakers & acoustics can't reproduce sound in that range, you have to use pre-filtering with an audio editor to remove them if you want to save that bandwidth. Same here, use avisynth to remove what you can't see on your screen.

Ranguvar

7th August 2008, 02:26

True.

Dr.D

7th August 2008, 16:24

gigah72

7th August 2008, 16:28

i made some test encodes (movie: 300, Hero) with CRF and i get a massive increase in filesize when i add --trellis 1 to --b-adapt 2 (with latest patches).
is this normal to happen or what is the reason?

Sharktooth

7th August 2008, 16:32

both patches are experimental so... yes weird things may happen.

Dark Shikari

7th August 2008, 16:38

Could you please post the parameters? If not, what crf did you use? Thanks.
$ ./x264.exe --deblock -3:-3 input.avs --frames 500 -o test_new.h264 --ref 16 --mixed-refs --weightb --partitions all --subme 7 --8x8dct --trellis 2 --b-rdo --bframes 3 --b-pyramid --progress --pass 2 --pre-scenecut --bitrate 400 --psy-rd 1.0 --bime --direct auto --no-fast-pskip --me tesa --merange 32
both patches are experimental so... yes weird things may happen.Psy RDO and Psy Trellis both raise quants at a given bitrate, or raise bitrate at given quants.

Sharktooth

7th August 2008, 16:50

rise quants? it should result in a lower filesize then...

Dark Shikari

7th August 2008, 16:57

rise quants? it should result in a lower filesize then...No... at the same bitrate, you need higher quants to keep the same bitrate. Therefore, at the same quants, you'll get higher bitrate.

Sharktooth

7th August 2008, 17:14

ok, got it.
at this point CQMs are completely useless.

Adub

7th August 2008, 20:41

Thank God!! I have always felt that "maybe...if I just try this...tweak a few coefficients...blah blah" about CQM's, so knowing that they wont really help me anymore is a good thing.

smok3

7th August 2008, 20:59

so it is either : defined borders or better complexity approximation? Can we have both?

poisondeathray

7th August 2008, 21:29

While the detail preservation are just amazing (especially at 400kbps), there is more ringing/artifacting visible - note especially around the fire.

Now the other images were of a different frame - so can't come to any conclusions - and Dark S. used -3,-3 for this encode (not sure what deblock settings were used for the earlier frame caps)

Dark Shikari

7th August 2008, 21:33

While the detail preservation are just amazing (especially at 400kbps), there is more ringing/artifacting visible - note especially around the fire. This is partially why it gets better detail preservation; in the other frame from a Competing Encoder (TM) I showed for comparison, a large percentage of bits in the entire frame were devoted just to the fire, hurting quality everywhere else.

If you think the ringing was a bit overboard, that's the fault of AQ, which might have been a bit too strong at 1.0.

poisondeathray

7th August 2008, 21:37

Actually I was comparing to the frame shots posted a few pages back as well, especially the one of the "source"; like i said, it was a different frame and different settings (I think).

When comparing to the competing encoder, you can also see the ringing/artifacting, BUT there is much less detail preservation with the rest of the frame - at least in my eyes

Just curious, what is the Competing Encoder (TM) ?:)

Sagekilla

7th August 2008, 21:42

Wow. I barely even saw the artifacts in the fire, even when I looked closely at the fire. Might have to do with the fact that my eyes were focused on Jack though. In any case, the fire looks hardly bad.

Dark Shikari

7th August 2008, 21:43

Just curious, what is the Competing Encoder (TM) ?:)Ateme Digital Series ;)

Quark.Fusion

8th August 2008, 08:02

ok, got it.
at this point CQMs are completely useless.

Did it means that you test it or just an assumption? What was result — it's same quality or worse versus flat matrix? (I'm talking about your AVC CQM HR (http://www.webalice.it/f.corriga/x264/eqm_avc_hr.cfg))

Shinigami-Sama

8th August 2008, 09:14

Did it means that you test it or just an assumption? What was result — it's same quality or worse versus flat matrix? (I'm talking about your AVC CQM HR (http://www.webalice.it/f.corriga/x264/eqm_avc_hr.cfg))

it just means that CQMs are no longer of any benefit because their use has been superceded by psy-rdo/psy-trellis

TheRyuu

8th August 2008, 09:55

So is it better to use psyTrellis and get higher quants with it? or not use it and get lower quants with regular trellis...

Or would this depend on the source...?

DarkZell666

8th August 2008, 10:11

So is it better to use psyTrellis and get higher quants with it? or not use it and get lower quants with regular trellis...

Or would this depend on the source...?

What do your eyes have to say on the matter ? There is no "better" from a theoretical standpoint. It's like asking if someone prefers Coca-Cola or Pepsi. One could argue either of them has more sugar, more taste, more bubbles, etc., but what matters is that the effect of psyTrellis gives improved subjective quality for YOU ("better" taste). Some people prefer the bubbles, others prefer the sugar !

Several people have reported x264 tasting better with psyTrellis enabled, as you might have read earlier in the thread. The question is : do you ? ;)

Caroliano

9th August 2008, 00:23

[url=So is it better to use psyTrellis and get higher quants with it? or not use it and get lower quants with regular trellis...[/url]
You should compara wich gives better quality for you in an given bitrate. So use 2-pass for the tests (then after you can use CRF for regular encodes).

There is any build with psyrdo 0.5 and --fgo? I wanted to compare both in anime with gradfunkmirror(). FGO already gave very good results, but I'm afraid of comparing encodes from two very distant revisions.

fachman

9th August 2008, 09:31

I have tested two non official builds.
First it is from komisar666.gin.by which is Psyrd0.5+normal trellis+VAQ2 and gave me the following results:

--[NoImage] Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 650 --stats "05.stats" --level 3.1 --keyint 99999 --ref 4 --mixed-refs --no-fast-pskip --bframes 16 --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmin 24 --qpmax 35 --qpstep 13 --pbratio 2.1 --ratetol 100 --qcomp 0 --cplxblur 2 --scenecut 100 --me umh --merange 64 --threads auto --thread-input --progress --[Information] [2008-08-09 05:42:52] Encoding started
--[NoImage] Standard output stream:
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1280x720 @ 25.00 fps (183160 frames)
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: cabac=1 ref=4 deblock=1:0:0 analyse=0x3:0x113 me=umh subme=7 psy_rd=1.000000 brdo=1 mixed_ref=1 me_range=64 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=6 nr=0 decimate=1 mbaff=0 bframes=16 b_pyramid=0 b_adapt=1 b_bias=0 direct=3 wpredb=1 bime=1 keyint=99999 keyint_min=25 scenecut=100(pre) rc=2pass bitrate=650 ratetol=100.0 rceq='blurCplx^(1-qComp)' qcomp=0.00 qpmin=24 qpmax=35 qpstep=13 cplxblur=2.0 qblur=0.5 ip_ratio=1.40 pb_ratio=2.10 aq=3:11:1.00
---[NoImage] mp4 [info]: initial delay 1 (scale 25)
---[NoImage]
---[NoImage] x264 [info]: slice I:319 Avg QP:26.21 size: 13552 PSNR Mean Y:46.06 U:49.60 V:50.00 Avg:46.92 Global:45.74
---[NoImage] x264 [info]: slice P:82918 Avg QP:28.27 size: 5621 PSNR Mean Y:43.88 U:47.64 V:48.00 Avg:44.76 Global:43.48
---[NoImage] x264 [info]: slice B:99923 Avg QP:32.97 size: 1199 PSNR Mean Y:42.60 U:47.12 V:47.46 Avg:43.59 Global:42.57
---[NoImage] x264 [info]: consecutive B-frames: 19.4% 25.2% 12.9% 17.5% 18.4% 5.4% 0.4% 0.0% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.6%
---[NoImage] x264 [info]: mb I I16..4: 52.9% 44.8% 2.3%
---[NoImage] x264 [info]: mb P I16..4: 8.7% 5.0% 0.1% P16..4: 39.2% 3.0% 3.2% 0.0% 0.0% skip:40.7%
---[NoImage] x264 [info]: mb B I16..4: 0.1% 0.1% 0.0% B16..8: 20.9% 0.2% 0.2% direct: 0.3% skip:78.2% L0:32.1% L1:66.6% BI: 1.3%
---[NoImage] x264 [info]: final AQ sensitivity: 8.0000
---[NoImage] x264 [info]: 8x8 transform intra:36.7% inter:90.5%
---[NoImage] x264 [info]: direct mvs spatial:95.6% temporal:4.4%
---[NoImage] x264 [info]: ref P L0 70.4% 16.2% 9.8% 3.6%
---[NoImage] x264 [info]: ref B L0 91.1% 5.5% 3.4%
---[NoImage] x264 [info]: SSIM Mean Y:0.9802356
---[NoImage] x264 [info]: PSNR Mean Y:43.183 U:47.360 V:47.709 Avg:44.128 Global:42.962 kb/s:644.48
---[NoImage] encoded 183160 frames, 12.17 fps, 644.50 kb/s

The second one is PSYRD05+PSYTRELLIS and gave me the following results:

--[NoImage] Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 650 --stats 05.stats" --level 3.1 --keyint 99999 --ref 4 --mixed-refs --no-fast-pskip --bframes 16 --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmin 24 --qpmax 35 --qpstep 13 --pbratio 2.1 --ratetol 100 --qcomp 0 --cplxblur 2 --scenecut 100 --me umh --merange 64 --threads auto --thread-input --progress ----[Information] [2008-08-08 09:45:04] Encoding started
--[NoImage] Standard output stream:
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1280x720 @ 25.00 fps (183160 frames)
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] mp4 [info]: initial delay 1 (scale 25)
---[NoImage] x264 [info]: slice I:319 Avg QP:25.89 size: 15960 PSNR Mean Y:46.26 U:51.33 V:51.77 Avg:47.37 Global:46.43
---[NoImage] x264 [info]: slice P:82918 Avg QP:28.59 size: 5800 PSNR Mean Y:43.27 U:48.90 V:49.31 Avg:44.44 Global:43.36
---[NoImage] x264 [info]: slice B:99923 Avg QP:35.47 size: 1093 PSNR Mean Y:41.36 U:47.78 V:48.17 Avg:42.61 Global:41.86
---[NoImage] x264 [info]: consecutive B-frames: 19.4% 25.2% 12.9% 17.5% 18.4% 5.4% 0.4% 0.0% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.6%
---[NoImage] x264 [info]: mb I I16..4: 45.3% 52.9% 1.8%
---[NoImage] x264 [info]: mb P I16..4: 8.4% 5.9% 0.1% P16..4: 39.1% 2.4% 3.2% 0.0% 0.0% skip:40.8%
---[NoImage] x264 [info]: mb B I16..4: 0.1% 0.1% 0.0% B16..8: 17.5% 0.1% 0.2% direct: 0.3% skip:81.7% L0:33.8% L1:64.7% BI: 1.4%
---[NoImage] x264 [info]: 8x8 transform intra:41.6% inter:89.4%
---[NoImage] x264 [info]: direct mvs spatial:96.1% temporal:3.9%
---[NoImage] x264 [info]: ref P L0 71.3% 15.8% 9.4% 3.4%
---[NoImage] x264 [info]: ref B L0 90.8% 5.7% 3.5%
---[NoImage] x264 [info]: SSIM Mean Y:0.9774826
---[NoImage] x264 [info]: PSNR Mean Y:42.234 U:48.297 V:48.692 Avg:43.449 Global:42.484 kb/s:649.96
---[NoImage] encoded 183160 frames, 12.62 fps, 649.99 kb/s

When I compare those two encodes I feel that KOMISAR666 is doing the better job, even creating smaller size. I think it is because the quantizer of B-frames is way too low...

Dark Shikari

9th August 2008, 14:40

When I compare those two encodes I feel that KOMISAR666 is doing the better job, even creating smaller size. I think it is because the quantizer of B-frames is way too low...Numbers tell us nothing; visuals tell us everything.

Also, testing builds that I have no idea about is a rather bad idea, because for all I know they've tweaked other settings randomly too (such as pbratio).

kemuri-_9

9th August 2008, 17:55

can the .diff be updated for latest x264 revisions (rev 929 specifically has the particular change in it),
since there's currently a rejection for the psyrdo 0.5+ psy trellis .diff:
encoder.c.rej
***************
*** 411,416 ****
h->param.analyse.b_fast_pskip = 0;
h->param.analyse.i_noise_reduction = 0;
h->param.analyse.i_subpel_refine = x264_clip3( h->param.analyse.i_subpel_refine, 1, 6 );
}
if( h->param.rc.i_rc_method == X264_RC_CQP )
{
--- 411,417 ----
h->param.analyse.b_fast_pskip = 0;
h->param.analyse.i_noise_reduction = 0;
h->param.analyse.i_subpel_refine = x264_clip3( h->param.analyse.i_subpel_refine, 1, 6 );
+ h->param.analyse.f_psy_rd = 0;
}
if( h->param.rc.i_rc_method == X264_RC_CQP )
{

as the bold line is no longer existent in the main code.
I fixed the .diff to workaround it for my own use, but other people will have problems

Dark Shikari

9th August 2008, 18:03

can the .diff be updated for latest x264 revisions (rev 929 specifically has the particular change in it),
since there's currently a rejection for the psyrdo 0.5+ psy trellis .diff:
***************
*** 411,416 ****
h->param.analyse.b_fast_pskip = 0;
h->param.analyse.i_noise_reduction = 0;
h->param.analyse.i_subpel_refine = x264_clip3( h->param.analyse.i_subpel_refine, 1, 6 );
}
if( h->param.rc.i_rc_method == X264_RC_CQP )
{
--- 411,417 ----
h->param.analyse.b_fast_pskip = 0;
h->param.analyse.i_noise_reduction = 0;
h->param.analyse.i_subpel_refine = x264_clip3( h->param.analyse.i_subpel_refine, 1, 6 );
+ h->param.analyse.f_psy_rd = 0;
}
if( h->param.rc.i_rc_method == X264_RC_CQP )
{

as the bold line is no longer existent in the main code.
I fixed the .diff to workaround it for my own use, but other people will have problemsIf you fixed it you could post the fixed version... ;)

LoRd_MuldeR

9th August 2008, 18:08

LoRd_MuldeR@MULDER_NEU /c/downloads/x264_git/x264
$ patch -p1 < ../psy-trellis.diff
patching file `common/common.c'
patching file `common/common.h'
patching file `common/dct.h'
patching file `encoder/analyse.c'
Hunk #2 succeeded at 1045 (offset 1 line).
Hunk #4 succeeded at 2078 (offset 1 line).
Hunk #6 succeeded at 2395 (offset 1 line).
patching file `encoder/encoder.c'
Hunk #1 FAILED at 411.
Hunk #2 succeeded at 484 (offset 1 line).
1 out of 2 hunks FAILED -- saving rejects to encoder/encoder.c.rej
patching file `encoder/macroblock.c'
patching file `encoder/macroblock.h'
patching file `encoder/rdo.c'
Hunk #2 succeeded at 330 (offset 2 lines).
Hunk #4 succeeded at 491 (offset 2 lines).
patching file `x264.c'
patching file `x264.h'

If you fixed it you could post the fixed version... ;)

Would be very welcome :)

kemuri-_9

9th August 2008, 18:27

ic how it is....
x264_psy_rdo.0.5+psy_trellis_01_r929.diff (http://kemuri9.net/dev/x264/patches/x264_psy_rdo.0.5+psy_trellis_01_r929.diff)

LoRd_MuldeR

9th August 2008, 19:03

ic how it is....
x264_psy_rdo.0.5+psy_trellis_01_r929.diff (http://kemuri9.net/dev/x264/patches/x264_psy_rdo.0.5+psy_trellis_01_r929.diff)

Working. Thank you!

fachman

9th August 2008, 22:33

Dear Dark Shikari

As for my builds the first is taken from http://komisar666.gin.by. It uses a lot of minor patches, but its list has been recently removed from the site. Most of them are minor but main are VAQ2 and PSYRDO05

The second one is SKYSTRIFE build
x264.928.modified.02.exe - Alternate Download
libx264-61.928.modified.02.dll - Alternate Download
(Source) - Alternate Download

Patches used:

x264_psyRDO_0.5+psytrellis.diff <-- This patch is experimental. See the PsyRDO thread for more details.
x264_new_bframe_decision_03.diff <-- This patch is highly experimental.
x264_hrd_pulldown.09_interlace.diff
x264.progress.indication.01.diff

gcc 3.4.5 fprofiled build.

I have also tweaked a bit bitrate to compare KOMISAR666 build at the same bitrate as SKYSTRIFE and received the following result:
--[NoImage] Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 655 --stats "05.stats" --level 3.1 --keyint 99999 --ref 4 --mixed-refs --no-fast-pskip --bframes 16 --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmin 24 --qpmax 35 --qpstep 13 --pbratio 2.1 --ratetol 100 --qcomp 0 --cplxblur 2 --scenecut 100 --me umh --merange 64 --threads auto --thread-input --progress --
--[Information] [2008-08-09 10:08:11] Encoding started
--[NoImage] Standard output stream:
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1280x720 @ 25.00 fps (183160 frames)
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: cabac=1 ref=4 deblock=1:0:0 analyse=0x3:0x113 me=umh subme=7 psy_rd=1.000000 brdo=1 mixed_ref=1 me_range=64 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=6 nr=0 decimate=1 mbaff=0 bframes=16 b_pyramid=0 b_adapt=1 b_bias=0 direct=3 wpredb=1 bime=1 keyint=99999 keyint_min=25 scenecut=100(pre) rc=2pass bitrate=655 ratetol=100.0 rceq='blurCplx^(1-qComp)' qcomp=0.00 qpmin=24 qpmax=35 qpstep=13 cplxblur=2.0 qblur=0.5 ip_ratio=1.40 pb_ratio=2.10 aq=3:11:1.00
---[NoImage] mp4 [info]: initial delay 1 (scale 25)
---[NoImage]
---[NoImage] x264 [info]: slice I:319 Avg QP:26.16 size: 13626 PSNR Mean Y:46.09 U:49.63 V:50.03 Avg:46.95 Global:45.78
---[NoImage] x264 [info]: slice P:82918 Avg QP:28.19 size: 5672 PSNR Mean Y:43.93 U:47.68 V:48.04 Avg:44.81 Global:43.53
---[NoImage] x264 [info]: slice B:99923 Avg QP:32.94 size: 1199 PSNR Mean Y:42.62 U:47.14 V:47.49 Avg:43.62 Global:42.60
---[NoImage] x264 [info]: consecutive B-frames: 19.4% 25.2% 12.9% 17.5% 18.4% 5.4% 0.4% 0.0% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.6%
---[NoImage] x264 [info]: mb I I16..4: 52.6% 45.1% 2.3%
---[NoImage] x264 [info]: mb P I16..4: 8.7% 5.0% 0.1% P16..4: 39.4% 3.0% 3.3% 0.0% 0.0% skip:40.5%
---[NoImage] x264 [info]: mb B I16..4: 0.1% 0.1% 0.0% B16..8: 21.0% 0.2% 0.2% direct: 0.3% skip:78.1% L0:32.1% L1:66.6% BI: 1.3%
---[NoImage] x264 [info]: final AQ sensitivity: 8.0000
---[NoImage] x264 [info]: 8x8 transform intra:37.0% inter:90.5%
---[NoImage] x264 [info]: direct mvs spatial:95.6% temporal:4.4%
---[NoImage] x264 [info]: ref P L0 70.5% 16.1% 9.8% 3.6%
---[NoImage] x264 [info]: ref B L0 91.1% 5.5% 3.4%
---[NoImage] x264 [info]: SSIM Mean Y:0.9803899
---[NoImage] x264 [info]: PSNR Mean Y:43.218 U:47.390 V:47.740 Avg:44.163 Global:43.001 kb/s:649.16
---[NoImage] encoded 183160 frames, 12.07 fps, 649.19 kb/s

As you might notice I am using completelly different encoding settings than anybody else. Those settings IMHO are optimal for receive maximum quality at low bitrates and are the result of one year of my research (some people are using their compute power to SETI, I use my compute power to test every x264 setting).
I will post a separate thread about my findings. Now I only tell you that PBRATIO=2.1 unleash the true power of Bframes. I am not sure why 2.1, but with this setting I receive at least 1dB of PSNR extra. With this setting you can see the difference with increased number of B frames (from 1 to 16), which is as you know is hardly to notice with PBRATIO=1.3
My personal theory is the Bframes are put in so simple positions that the temporaly lowering the quality of the scene (plus 6QP) does not affect the quality of the movie, while allows the saving bits to be put elsewhere where the difference is noticeable, but I am not the developer.

Keep up the good work

Dark Shikari

9th August 2008, 22:42

I will post a separate thread about my findings. Now I only tell you that PBRATIO=2.1 unleash the true power of Bframes.x264 isn't Xvid.

Xvid had an absurdly high pbratio--and we all know how that turned out... :scared:

Personally, I think consistent quality is much more important than anything else--decimating half of your frames to improve overall PSNR is not going to be a good idea visually. Its great though if all you ever do is compare individual P-frames... ;)
(x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 655 --stats "05.stats" --level 3.1 --keyint 99999 --ref 4 --mixed-refs --no-fast-pskip --bframes 16 --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmin 24 --qpmax 35 --qpstep 13 --pbratio 2.1 --ratetol 100 --qcomp 0 --cplxblur 2 --scenecut 100 --me umh --merange 64 --threads auto --thread-input --progress --These are nonsense settings.

1. An extremely high keyint is going to screw up scenecut detection.
2. Your qpmin/qpmax settings are crippling AQ.
3. Qcomp 0 is retarded, even in CBR mode.
4. Scenecut 100 is going to screw up scenecut detection even more.
5. You're using --level 3.1, but you're ignoring the VBV implications of that.
6. Ratetol does nothing on the second pass (AFAIK).
7. Stop touching the ratecontrol parameters, seriously. qpstep does basically nothing outside of VBV mode.

Sagittaire

9th August 2008, 23:16

As you might notice I am using completelly different encoding settings than anybody else. Those settings IMHO are optimal for receive maximum quality at low bitrates and are the result of one year of my research (some people are using their compute power to SETI, I use my compute power to test every x264 setting).

Well I think that your setting are completely ridiculous:
--keyint 99999: useless. codec will use scenecut for iframe. default is good if you don't use particular hardware profil.

--bframes 16: useless too. more than 3 bframe don't help really. Here good setting for bframe: --bframe 3 --b-pyramid --b-rdo --bime --weightb

--partitions p8x8,b8x8,i4x4,i8x8: why use always this command. use simply --partitions "all"

--qpmin 24 --qpmax 35 --qpstep 13 --ratetol 100 --cplxblur 2: don't touch the RC if you don't know exactly what you do.

--pbratio 2.1: poor quality for bframe. IMO really better to use low ratio for constant local quality.

--merange 64: slow and useless for quality. default is good

--qcomp 0: useless with VAQ and it's absurd setting because it's CBR mode.

Try that ... better quality and better speed:

x264.exe --bframe 3 --b-pyramid --b-rdo --bime --weightb --ref 5 --mixed-refs --direct auto --deblock -1:-1 --bitrate 447 --pass 2 --stats "x264_stat.log" --min-keyint 1 --ipratio 1.25 --pbratio 1.30 --partitions "all" --8x8dct --me "umh" --subme 7 --no-fast-pskip --no-dct-decimate --trellis 2 --aq-strength 0.5 --aq-mode 2 --progress -o x264HP-450.mp4 Encodage.avs

Soichiro

9th August 2008, 23:54

--partitions p8x8,b8x8,i4x4,i8x8: why use always this command. use simply --partitions "all"

I agree with most of what you said, but not using all partitions is a good idea because p4x4 is practically useless and will just slow things down, as well as break hardware compatibility. Also, yeah, 16 bframes is useless for live action, though it does have uses in animated material. Since I can't exactly find what type of clip was being tested, though, I can't really say which it was, but from the stats it looks like it was live action (low bframe counts).

Sagittaire

10th August 2008, 06:30

I agree with most of what you said, but not using all partitions is a good idea because p4x4 is practically useless and will just slow things down, as well as break hardware compatibility. Also, yeah, 16 bframes is useless for live action, though it does have uses in animated material. Since I can't exactly find what type of clip was being tested, though, I can't really say which it was, but from the stats it looks like it was live action (low bframe counts).

- x264 will use 16 bframe only for really static scene without really saving bit in this case. It's like use 16 ref ... it's in practice useless.

- You break hardware compatibility with 16 bframes certainely more than with --partitions "all".

tetsuo55

10th August 2008, 09:05

What are the official b-frame limits for each level?

Manao

10th August 2008, 09:22

None. Either you allow bframes (and an arbitrary consecutive number of them) or you don't. 16 is a limitation coming from x264.

tetsuo55

10th August 2008, 09:39

None. Either you allow bframes (and an arbitrary consecutive number of them) or you don't. 16 is a limitation coming from x264.

So the fact that one or more hardware decoders crash with high number of bframes is a bug in the decoding hardware? (or a sneaky way to make cheaper decoder chips)

Manao

10th August 2008, 10:09

It's not even a cheap way. I just don't understand how they could crash because there's too many bframes in a row. 16 bframes in a row don't require more memory than 1.

Sergey A. Sablin

10th August 2008, 11:00

it's only true for plain B-frames, pyramid requires additional space in DPB for correct output.

Manao

10th August 2008, 11:05

But there again, additionnal number of frames in the DPB taken by B-references depends on pyramid structure, not on the actual number of frames.

Sergey A. Sablin

10th August 2008, 11:13

yeah right, but it's definitely more than for 1 B-frame (reference or non-reference).
plus dpb size has to be calculated correctly - as far as I see it is currently not.

tetsuo55

10th August 2008, 11:53

yeah right, but it's definitely more than for 1 B-frame (reference or non-reference).
plus dpb size has to be calculated correctly - as far as I see it is currently not.

Do you have any more technically information about this?

i would like to be able to calculate the limits of b-frames= X + b-pyramids

I assume the DPB limit is shared with ref-frames

Sergey A. Sablin

10th August 2008, 12:06

Do you have any more technically information about this?

i would like to be able to calculate the limits of b-frames= X + b-pyramids

I assume the DPB limit is shared with ref-frames

you just need to draw a decoding and output timeline to calculate the size of DPB - the base number of num_ref_frames (not one from command line, but actually written into bitstream), then you need to add the number of frames which need to be temporally stored before displaying.

tetsuo55

10th August 2008, 13:21

I'm not sure i understand what you mean.

Basic ref frame calculation is:

Height*Width*ref-frames <= L?.? DPB

How do you balance ref-frames and bframes within the DPB limit.

Basically what i need are safe settings that will never break DPB but are as close to Insane as possible (then from that anyone can decide to go lower)

Manao

10th August 2008, 13:37

As far as I can tell, x264 computes the DPB size as follow :
0 Bframes : DPB-size = number of references
1+ Bframes : DPB-size = max(2, number of references)
2+ Bframes + bpyramid : DPB-size = max(3, number of references)

Since level limits for DPB size are at least 4, you can safely ignore the bframe configuration and only care about number of references.

tetsuo55

10th August 2008, 13:47

so that basically means that i can count b-frames as ref-frames

1+ bframes = reduce max ref frames by 2
2+ & pyramids = reduce max ref frames by 3

Ofcourse Assuming that the bframes are always used

fachman

10th August 2008, 13:55

These are nonsense settings.

Well Dark Shikari, I really appreciate your work and thought you are the last person which does not appreciate someone elses work. Sad, but I would suggest for the future you would first check by yourself because apparently there are still some secrets in x264 even FOR SUCH A SMART DEVELOPER LIKE YOU.

1. An extremely high keyint is going to screw up scenecut detection.
This is why it is connected with highest sensibility of scenecut detection. Both options creates 50% less I frames and only in those places where they are really needed while conserving bits

2. Your qpmin/qpmax settings are crippling AQ.

That is right, because in this way I receive maximum quality of 1280x720 video at only 650kbps

3. Qcomp 0 is retarded, even in CBR mode.

Yet, it still helping in better distribution of bits

4. Scenecut 100 is going to screw up scenecut detection even more.

Just like above

5. You're using --level 3.1, but you're ignoring the VBV implications of that.

Tell me what chance I have to break VBV with only 650kbps????

6. Ratetol does nothing on the second pass (AFAIK).

Yes, but it helps distributing bits thanx to its affect in first pass

7. Stop touching the ratecontrol parameters, seriously. qpstep does basically nothing outside of VBV mode.

Well, I just do not want to have here any limits in VAQ

Well I think that your setting are completely ridiculous:
Try that ... better quality and better speed:

x264.exe --bframe 3 --b-pyramid --b-rdo --bime --weightb --ref 5 --mixed-refs --direct auto --deblock -1:-1 --bitrate 447 --pass 2 --stats "x264_stat.log" --min-keyint 1 --ipratio 1.25 --pbratio 1.30 --partitions "all" --8x8dct --me "umh" --subme 7 --no-fast-pskip --no-dct-decimate --trellis 2 --aq-strength 0.5 --aq-mode 2 --progress -o x264HP-450.mp4 Encodage.avs

Well I will have to say you still need to learn a lot about encoding settings. Compare yours to mine by yourself and then come back to me...

Manao

10th August 2008, 14:21

tetsuo55

10th August 2008, 14:46

tetsuo55 : I must not have made myself clear. For all practical purposes with x264 and level compliancy, you just don't have to care about bframe configuration and DPB-size = number of references. Said otherwise, adding bframes won't change the DPB-size if you're already using at least 2 references, and adding bpyramid won't change the DPB-size if you're using at least 3 references.

Okay now i get it.

With 2+ bframes and bpyramids 3 of the ref-frames will be bframes too. As this is lower than 4 we can completely ignore b-frames.
That still doesnt explain why ref16+bframe16+bpyramid breaks hardware playback. back to square one :(

Tell me what chance I have to break VBV with only 650kbps????

Your breaking it with the number of ref frames for your resolution.

1280x720x16 = out of L4.1 specs!

kemuri-_9

10th August 2008, 15:08

3. Qcomp 0 is retarded, even in CBR mode.

Yet, it still helping in better distribution of bits

You apparently are not aware that when aq-mode = 2, qcomp is automatically overwritten to be 1.0,
only in aq-modes 0 & 1 will qcomp be the value given on the cli or the default 0.6 if unspecified

but imo, fachman, use w/e settings you want, they exist for people to alter,
just don't bug us on it if you want help if you continue to use such non-standard settings
in the end it boils down to it's your eyes, your work, you do what you want.

Manao

10th August 2008, 15:08

16 refs break hardware playback if they are used at the level's resolution limit. Most levels don't allow more than 4-5 frames big DPB at the maximum resolution, so 16 references will be too much.

Quark.Fusion

10th August 2008, 15:40

Your breaking it with the number of ref frames for your resolution.

1280x720x16 = out of L4.1 specs!
He have only 4 refs, not 16 (it's maximum for b-frames) and level 3.1 :)

tetsuo55

10th August 2008, 15:41

16 refs break hardware playback if they are used at the level's resolution limit. Most levels don't allow more than 4-5 frames big DPB at the maximum resolution, so 16 references will be too much.

yeah but for the point of this discussion you can assume within DPB limits.

I'n another thread i posted 2 files. both 16 refs, one working the other not. the only real difference is the number of b-frames

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

Dark Shikari

10th August 2008, 15:53

You apparently are not aware that when aq-mode = 2, qcomp is automatically overwritten to be 1.0Incorrect! Qcomp is raised by (I think) 0.7 * AQ strength. But it isn't explicitly set to 1.

Sergey A. Sablin

10th August 2008, 15:53

Dark Shikari

10th August 2008, 16:01

you don't follow me - pyramid by itself requires additional space in DPB for correct output, regardless of number of reference frames.No, it doesn't; not if you explicitly use one less reference frame in B-frames when pyramid is activated (which is what x264 does).

Sergey A. Sablin

10th August 2008, 16:04

No, it doesn't; not if you explicitly use one less reference frame in B-frames when pyramid is activated (which is what x264 does).

yes it actually does.

Dark Shikari

10th August 2008, 16:08

yes it actually does.The DPB size required is the maximum size of the the total number of refs in the L0 and L1 reference lists.

Without pyramid, with 4 refs, a B-frame will have 4 L0 and 1 L1, for a total of 5.

With pyramid, with 4 refs, a B-frame will have 3 L0 and 2 L1, for a total of 5.

In my world, 5 equals 5. What color is the sky in your world?

LoRd_MuldeR

10th August 2008, 16:29

What color is the sky in your world?

If I look out of the window, it looks pretty gray at the moment :D

Sergey A. Sablin

10th August 2008, 16:59

The DPB size required is the maximum size of the the total number of refs in the L0 and L1 reference lists.

Without pyramid, with 4 refs, a B-frame will have 4 L0 and 1 L1, for a total of 5.

With pyramid, with 4 refs, a B-frame will have 3 L0 and 2 L1, for a total of 5.

In my world, 5 equals 5. What color is the sky in your world?

I don't care about correctness of x264, and I don't care a damn about your "funny" comments - if you think sky is blue (or whatever) and 5 is equals to 5 - I don't care either.

The point is - DPB size equals to sps->num_ref_frames is not enough for pyramid regardless of the value of sps->num_ref_frames. It's not enough for correct output process, cause some non-reference frames will require temporal storage because of reordering delay.

Dark Shikari

10th August 2008, 17:12

I don't care about correctness of x264, and I don't care a damn about your "funny" comments - if you think sky is blue (or whatever) and 5 is equals to 5 - I don't care either.

The point is - DPB size equals to sps->num_ref_frames is not enough for pyramid regardless of the value of sps->num_ref_frames. It's not enough for correct output process, cause some non-reference frames will require temporal storage because of reordering delay.But this is a thread about x264. I don't care how $crappyencoder does things; I care about how x264 does things. And if you don't like it, you are free to stop posting in this thread.

kemuri-_9

10th August 2008, 17:44

But this is a thread about x264. I don't care how $crappyencoder does things; I care about how x264 does things. And if you don't like it, you are free to stop posting in this thread.

or it is supposed to be about psy rdo in x264, but lately it seems to have been following a
post_i+1 = post_i * (divergent_ranting ^ 2)
process

hows progress coming along on it anyway DS, since 0.5 < 1, i would imagine there's more things for you to fix/implement?

*edit*
oh and thanks for clearing up my misconception on the qcomp on aq-mode 2; here's the code for that section
if( h->param.rc.i_aq_mode == X264_AQ_GLOBAL )
h->param.rc.f_qcompress = x264_clip3f(h->param.rc.f_qcompress + h->param.rc.f_aq_strength / 0.7, 0, 1);

so instead of raising by aq-strength * 0.7 it does by / 0.7 (effective * 1.429) and clamps it to the range [0,1]
*/edit*

Dark Shikari

10th August 2008, 17:51

hows progress coming along on it anyway DS, since 0.5 < 1, i would imagine there's more things for you to fix/implement?There are some small speed-related improvements I have to make to psy trellis, but currently I have a lot on my plate:

1. Current stuff at work and all my contracts
2. Fast first-pass mode (no bitstream writing)
3. Implementing predictive lossless in ffmpeg (already done in x264, but not committed yet).
4. Dealing with all these old patches I have lying around but not committed...

Sergey A. Sablin

10th August 2008, 18:04

But this is a thread about x264. I don't care how $crappyencoder does things; I care about how x264 does things.
so what? (btw it is interesting definition, one may say $crappyencoder is one which do not comply with spec, but that's definitely not me :p)
And if you don't like it, you are free to stop posting in this thread.
thank for offer but I really feel free to post everywhere I want. especially if it is related. and even if I don't care much.

to make things as clean as possible (if it still not clear) - x264 produced streams with pyramid is not compliant with specification, specifically with the part of spec regarding DPB operation. It doesn't mean software/hardware players are not able to play them, but information on DPB size provided in the stream is incorrect (read: it is smaller than required).

now to the deal (i'm really generous today):
I've encoded stream with x264 with 3 b-frames, pyramid, 3 ref frames. I've got sps->num_ref_frames=3, sps->vui->num_reorder_frames=2, sps->vui->max_dec_frame_buffering=3 (this one is actual DPB size requested by encoder)
Now to the stream (decoding order, numbers are display order):

I0 P4 B2 b1 b3 P8 B6 b5 b7 ...

time 0 1 2 3 4 5
dec: I0 P4 B2 b1 b3 P8
dis: - - I0 b1 B2 b3
dpb: 1 2 3 3 4 3

now mind time stamp 4 - b3 is decoded but can't be displayed, cause B2 shall be displayed at this moment, so b3 shall be stored somewhere, while B2 is displaying and P8 is decoding. thus dpb has to have 4 frame buffers, ie sps->vui->max_dec_frame_buffering shall be equal to 4, but it is 3 - that means decoder simply has no room to store it.

Dark Shikari

10th August 2008, 18:09

so what? (btw it is interesting definition, one may say $crappyencoder is one which do not comply with spec, but that's definitely not me :p)

thank for offer but I really feel free to post everywhere I want. especially if it is related. and even if I don't care much.

to make things as clean as possible (if it still not clear) - x264 produced streams with pyramid is not compliant with specification, specifically with the part of spec regarding DPB operation. It doesn't mean software/hardware players are not able to play them, but information on DPB size provided in the stream is incorrect (read: it is smaller than required).

now to the deal (i'm really generous today):
I've encoded stream with x264 with 3 b-frames, pyramid, 3 ref frames. I've got sps->num_ref_frames=3, sps->vui->num_reorder_frames=2, sps->vui->max_dec_frame_buffering=3 (this one is actual DPB size requested by encoder)
Now to the stream (decoding order, numbers are display order):

I0 P4 B2 b1 b3 P8 B6 b5 b7 ...

time 0 1 2 3 4 5
dec: I0 P4 B2 b1 b3 P8
dis: - - I0 b1 B2 b3
dpb: 1 2 3 3 4 3

now mind time stamp 4 - b3 is decoded but can't be displayed, cause B2 shall be displayed at this moment, so b3 shall be stored somewhere, while B2 is displaying and P8 is decoding. thus dpb has to have 4 frame buffers, ie sps->vui->max_dec_frame_buffering shall be equal to 4, but it is 3 - that means decoder simply has no room to store it.Interesting, I thought the situation was as follows (courtesy of Manao):

I0 b0 B0 b1 P1 b2 B1 b3 P2

When coding b2, the DPB has I0 P1 B0 P2 B1

With a DPB of length three, it is instead B0 P2 B1.

This doesn't at all violate the spec; it is just suboptimal, and could be resolved by changing the DPB to 4 or using MMCO to get P1 P2 B1 instead.

(Next time, please open a new thread for this--you're derailing an unrelated thread by discussing something utterly orthogonal to the current topic).

Sergey A. Sablin

10th August 2008, 18:37

Interesting, I thought the situation was as follows (courtesy of Manao):

I0 b0 B0 b1 P1 b2 B1 b3 P2

When coding b2, the DPB has I0 P1 B0 P2 B1

With a DPB of length three, it is instead B0 P2 B1.

This doesn't at all violate the spec; it is just suboptimal, and could be resolved by changing the DPB to 4 or using MMCO to get P1 P2 B1 instead.

yes, it does - this violates the spec. there is simply no room for non-reference B-frame in DPB, cause all buffers are used for reference frames. To output this non-reference B-frame in correct time one need to delay decoding of next P-frame, cause there is no room to decode it to. This will break DPB output timing - which is violation of spec. (to be simple this will cause displaying problems)

Dark Shikari

10th August 2008, 18:40

yes, it does - this violates the spec. there is simply no room for non-reference B-frame in DPB, cause all buffers are used for reference frames. To output this non-reference B-frame in correct time one need to delay decoding of next P-frame, cause there is no room to decode it to. This will break DPB output timing - which is violation of spec. (to be simple this will cause displaying problems)How is it a spec violation?

P2 is decoded while P1 is still in the reflist, and then B1 is decoded, then P1 is thrown out to make room for B1, and B0 is used to decode b2. This is exactly how the DPB is supposed to work.

Sergey A. Sablin

10th August 2008, 19:01

How is it a spec violation?

P2 is decoded while P1 is still in the reflist, and then B1 is decoded, then P1 is thrown out to make room for B1, and B0 is used to decode b2. This is exactly how the DPB is supposed to work.

ok I give up - you simply do not read.

now mind time stamp 4 - b3 is decoded but can't be displayed, cause B2 shall be displayed at this moment, so b3 shall be stored somewhere, while B2 is displaying and P8 is decoding. thus dpb has to have 4 frame buffers, ie sps->vui->max_dec_frame_buffering shall be equal to 4, but it is 3 - that means decoder simply has no room to store it.

there is simply no room for non-reference B-frame in DPB, cause all buffers are used for reference frames. To output this non-reference B-frame in correct time one need to delay decoding of next P-frame, cause there is no room to decode it to. This will break DPB output timing - which is violation of spec. (to be simple this will cause displaying problems)

DPB has to be 4 to deal with pyramid and 3 ref-frames, but it is 3 - this is v-i-o-l-a-t-i-o-n.

tetsuo55

10th August 2008, 19:56

(Next time, please open a new thread for this--you're derailing an unrelated thread by discussing something utterly orthogonal to the current topic).

Sorry i am partially to blame for this

DPB has to be 4 to deal with pyramid and 3 ref-frames, but it is 3 - this is v-i-o-l-a-t-i-o-n.

This requires further discussion and possibly a patch.

i have opened a new thread for the pyramid/DPB discussion because its very relevant for hardware decoders.

The thread is here:
http://forum.doom9.org/showthread.php?p=1169060#post1169060

fachman

10th August 2008, 20:00

Dark Shikari, pictures for your request

Here comes the picture from KOMISAR666 build (VAQ2+PSYRDO5) and SKYSTRIFE(VAQ1+PSYRDO05+PSYTRELLIS)
I am sorry they are not the same moment, but you can clearly see which one conserve more detail if you look near the Luke Skywalkers arms. The encoding with SKYSTRIFE build has also a lot of movement errors.

BTW. Enjoy HD quality at only 650kbps. (SSIM over 0.98 and PSNR over 43dB)

My only goal here is to help you guys to improve codecs efficency, not disscussing which setting is good or not.

Dark Shikari

10th August 2008, 20:02

fachman

11th August 2008, 02:21

Hi DS

Well the movie has "only" 600MB, so I think it would be hard to send it to you. I would suggest you to make the test by your own. What can I do is to give you more details about the patches from KOMISAR build.
Today the KOMISAR has released the version 930 with the following patches
k.38.cosmetic.diff
k.11.x264.progress.indication.01.diff
x264_32x32samples_crash.r870.diff
k.20.x264_fix_stats_file_work.r877.diff
x264_multithreading_Nth_pass_ratecontrol.r870.diff
bm_x264_thread_pool.r870.diff
k.42.x264-psyrd-0.5k.r930.diff
k.35.hrd_pulldown.09_interlace.diff
k.39.vaq2mod.full.07k.r912.diff
999.profiled.01.diff
k.41.x264_log_file.01k.r928.diff

I have made the quick test and received the following result:

--[NoImage] Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 655 --stats "05.stats" --level 3.1 --keyint 99999 --ref 4 --mixed-refs --no-fast-pskip --bframes 16 --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmin 24 --qpmax 35 --qpstep 13 --pbratio 2.1 --ratetol 100 --qcomp 0 --cplxblur 2 --scenecut 100 --me umh --merange 64 --threads auto --thread-input --progress
--[Information] [2008-08-10 21:31:17] Encoding started
--[NoImage] Standard output stream:
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1280x720 @ 25.00 fps (183160 frames)
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: cabac=1 ref=4 deblock=1:0:0 analyse=0x3:0x113 me=umh subme=7 psy_rd=1.000000 brdo=1 mixed_ref=1 me_range=64 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=6 nr=0 decimate=1 mbaff=0 bframes=16 b_pyramid=0 b_adapt=1 b_bias=0 direct=3 wpredb=1 bime=1 keyint=99999 keyint_min=25 scenecut=100(pre) rc=2pass bitrate=655 ratetol=100.0 rceq='blurCplx^(1-qComp)' qcomp=0.00 qpmin=24 qpmax=35 qpstep=13 cplxblur=2.0 qblur=0.5 ip_ratio=1.40 pb_ratio=2.10 aq=3:11:1.00
---[NoImage] mp4 [info]: initial delay 1 (scale 25)
---[NoImage]
---[NoImage] x264 [info]: slice I:319 Avg QP:26.16 size: 13621 PSNR Mean Y:46.09 U:49.62 V:50.02 Avg:46.95 Global:45.77
---[NoImage] x264 [info]: slice P:82918 Avg QP:28.18 size: 5672 PSNR Mean Y:43.93 U:47.68 V:48.03 Avg:44.81 Global:43.53
---[NoImage] x264 [info]: slice B:99923 Avg QP:32.94 size: 1199 PSNR Mean Y:42.62 U:47.14 V:47.48 Avg:43.62 Global:42.60
---[NoImage] x264 [info]: consecutive B-frames: 19.4% 25.2% 12.9% 17.5% 18.4% 5.4% 0.4% 0.0% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.6%
---[NoImage] x264 [info]: mb I I16..4: 52.7% 45.1% 2.2%
---[NoImage] x264 [info]: mb P I16..4: 8.7% 5.0% 0.1% P16..4: 39.4% 3.0% 3.3% 0.0% 0.0% skip:40.5%
---[NoImage] x264 [info]: mb B I16..4: 0.1% 0.1% 0.0% B16..8: 21.0% 0.2% 0.2% direct: 0.3% skip:78.1% L0:32.1% L1:66.6% BI: 1.3%
---[NoImage] x264 [info]: final AQ sensitivity: 8.0000
---[NoImage] x264 [info]: 8x8 transform intra:37.0% inter:90.5%
---[NoImage] x264 [info]: direct mvs spatial:95.6% temporal:4.4%
---[NoImage] x264 [info]: ref P L0 70.5% 16.1% 9.8% 3.6%
---[NoImage] x264 [info]: ref B L0 91.2% 5.5% 3.3%
---[NoImage] x264 [info]: SSIM Mean Y:0.9803838
---[NoImage] x264 [info]: PSNR Mean Y:43.218 U:47.388 V:47.737 Avg:44.162 Global:43.000 kb/s:649.17
---[NoImage] encoded 183160 frames, 12.34 fps, 649.20 kb/s

I am not sure is it with PSYTRELLIS because I am the guy for tests.

BTW. Your comment about XVID and PBRATIO seems to me that you have created your own limitations. Please free your mind :)

Dark Shikari

11th August 2008, 02:39

Well the movie has "only" 600MB, so I think it would be hard to send it to you.Its rather easy to split a video. Use MKVMerge.BTW. Your comment about XVID and PBRATIO seems to me that you have created your own limitations. Please free your mind :)I have done my own experimenting with various B-frame offsets. The only way to effectively use any offset higher than ~1.4 is to use RDRC, in which case the optimal offset gets decided anyways (QPRD on unreferenced B-frames would probably do an even better job and wouldn't suffer the normal problems that QPRD creates...) Otherwise, you risk (such as in your video) utterly destroying the quality of over half of your video.

kemuri-_9

11th August 2008, 04:38

IgorC

11th August 2008, 04:56

Today the KOMISAR has released the version 930 with the following patches
Excuse me but who is Komisar? That guy who test on a very fewest videos looking for SSIM and OPSNR values and not comparing them visually that much. And another guy like nico who "helps" him to tune x264 his way and thinks that psyrdo and psytrellis are totally waste of time.

I would stay away from these underground redone algos something like VAQ2modified, VAQ3 ..generally VAQN+1.

Dark Shikari

11th August 2008, 05:06

Razorholt

11th August 2008, 05:54

How about the --aq-mode 3 from MasterNobody?

Dark Shikari

11th August 2008, 05:56

How about the --aq-mode 3 from MasterNobody?There are so many modifications of AQ going around, ranging from possibly reasonable to patently absurd, that I've completely lost track of them.

tetsuo55

11th August 2008, 08:49

Maybe the combination of patches and settings fachman uses is leading to unexpected results (higher quality encodes without increasing bitrate)

I agree with DS that we need samples, single screenshots cannot tell us anything about the temporal quality.

If their really is a huge improvement when compared to regular settings maybe DS could find the cause and create a patch so those insane settings are no longer needed.

Shinigami-Sama

11th August 2008, 10:38

fachman

12th August 2008, 12:04

Excuse me but who is Komisar? That guy who test on a very fewest videos looking for SSIM and OPSNR values and not comparing them visually that much. And another guy like nico who "helps" him to tune x264 his way and thinks that psyrdo and psytrellis are totally waste of time.

I would stay away from these underground redone algos something like VAQ2modified, VAQ3 ..generally VAQN+1.

Dear IgorC

Although I have no idea how Komisar did his tests, for the future I would consider think twice before you will say something, because testing on "very fewest videos" is normal thing which you would know if you would known how Dark Shikari is doing his tests http://x264dev.multimedia.cx/?paged=2. Unfortunatelly we are facing reality here.

Also I could bet you do not live with Komisar or Nico to know how they did their tests. Do you????
Althought SSIM and PSNR are not perfect I would rather trust them than someone elses "opinion". Why??? Because human opinion can change. On the morning you can like the picture. On the afternoon you will not, and on the evening you could barelly look at it, but Quality metrics will stay the same.
While I do see a big sence in PSYRDO it is true that it lowers SSIM and PSNR. Thus I would suggest another metrics which compares complexity of the scene.
IMHO the best picture would give the picture which balances those 3 metrics.

DarkZell666

12th August 2008, 12:18

Althought SSIM and PSNR are not perfect I would rather trust them than someone elses "opinion". Why??? Because human opinion can change. On the morning you can like the picture. On the afternoon you will not, and on the evening you could barelly look at it, but Quality metrics will stay the same.
While I do see a big sence in PSYRDO it is true that it lowers SSIM and PSNR. Thus I would suggest another metrics which compares complexity of the scene.
IMHO the best picture would give the picture which balances those 3 metrics.

Are you so lunatic ? I'm not :p Also, you seem not to even trust your own opinion, nevermind someone else's ... are your eyes so damaged ? (no offense, I'm just intrigued by the fact you rely more on numbers that on what you see :))
Moreover, you seem to omit the fact that (and this has been repeated too often already for you not to have noticed imho) higher metrics DON'T ALWAYS mean higher perceptual quality.
Proof ? : All the recent psy optimisations kill PSNR and/or SSIM but 90% of the people hanging around here have noticed visual improvement. So if you mean to say you're in the 10% that don't, well, just say so, we won't blame you for it for the same reason we don't blame PSNR and SSIM for being tricked by psy improvements, it's in their nature ;)

CruNcher

12th August 2008, 12:46

@Darkzell666
Even PsyRD is a two handed sword because you seeing a improvement in a very high compression area wich is RD also you can't say that PsyRD allways have this effect for every source and every situation, also seing a effect on 1 or 2 frames doesn't mean consistent results and then some people prefer to take Speed/Their Subjective Quality (for PsyRD that is it biggest bonus it comes for free with RD, so it's also profile indepedent tough your investment is a 20% slowdown) against it.
Also some are even taking into account @ wich bitrate it becomes useless or even backfiring @ you , all of this is much more complex, then what people might only see in 1 bitrate and compression scenario here it's true for their situation the're in but it didn't have to be true (or as good) for others,if you dont care about speed or balance @ all but optimal quality every of this ofcourse becomes invalid for you, but if you try todo Psy in some more balanced way you have todo alot more compromises. I'm also skeptical about fachman his experience tough i would never say it isn't true for the situation he's in, tough im very skeptical and even would agree with Dark here ;) changeing the RC in that way seems to call for problems in a consistent visual overall result (runtime), but he is useing Komisars build so --aq-mode 3 if i see right and i dont have to much experience visualy yet with it as im more working around with --aq-mode 2 non scaled like in Komisars build currently. Btw all of this becomes even more complex if you add more restrictions like VBV to the pool :D

fachman

12th August 2008, 19:19

Are you so lunatic ? I'm not :p Also, you seem not to even trust your own opinion, nevermind someone else's ... are your eyes so damaged ? (no offense, I'm just intrigued by the fact you rely more on numbers that on what you see :))

Well, you know what I am intrigued where did you get the idea I do not trust my opinion??? Because if you are really not offensive, just intrigued you should find it easily:stupid:

Moreover, you seem to omit the fact that (and this has been repeated too often already for you not to have noticed imho) higher metrics DON'T mean higher perceptual quality.

Are you sure there wasn`t the word ALWAYS somewhere between the words???

Proof ? : All the recent psy optimisations kill PSNR and/or SSIM but 90% of the people hanging around here have noticed visual improvement. So if you mean to say you're in the 10% that don't, well, just say so, we won't blame you for it for the same reason we don't blame PSNR and SSIM for being tricked by psy improvements, it's in their nature ;)

Oh my god, where did you get it that I do not noticed PSYRDO visual improvement.:confused:
The reason I trust more quality metrics is because someone elses opinion are very often based not what IT IS, but what it SEEMS to be.

Ranguvar

12th August 2008, 19:54

Ah, but in a field where all that matters is human perception, what seems to be is all that matters ;)

Metrics can report all day that a video is low or high quality, but none take into account the inaccuracies of the human eye, and the best encoders are the ones that exploit these inaccuracies. Compress where the eye doesn't notice, don't where it doesn't. Etc.

A good old double blind test with a large survey group is by far the best way, IMO, to measure a feature's worth. Metrics can be useful short-term for optimizing a few things quickly, like b-frame decision, but overall they are meaningless. Unless you can come up with, again, a metric that is like the human eye.

kemuri-_9

13th August 2008, 00:53

hmmm... looking at the code from the patch more closely now, there's no longer a way to use normal trellis with psy-rdo in the psy-trellis inclusion patch,
is there anyway that an option could be added in a future release to be able to enable/disable psy-trellis so that psy-rdo could be used with standard trellis again (looking at you trellis 2)?
I think it would be helpful with testing/comparing...

So since you were already busy DS, i tried tackling this myself and the result is:
x264_psy_rdo.0.5+psy_trellis_01_r929_mod.diff (http://kemuri9.net/dev/x264/patches/x264_psy_rdo.0.5+psy_trellis_01_r929_mod.diff)

added a new --psy-trellis option to enable and control code usage for psy trellis
allowing it to be on/off similar to psy rdo (within its dependencies of trellis > 0 and psy-rd > 0)

of course this needs your review when you have the time to make sure i didn't fubar anything.

DarkZell666

13th August 2008, 01:34

The reason I trust more quality metrics is because someone elses opinion are very often based not what IT IS, but what it SEEMS to be.The whole point of psy-rdo is that what ever IT IS, it SEEMS to be better than what it actually IS => Read : whatever the metrics (good or bad), it looks better.

And what's the matter with "someone else's" opinion you keep talking about : what about YOUR opinion ? What about YOUR eyes ? Forget the others, forget the numbers ... what do YOU see ? Which output do your eyes prefer ? You're putting the responsibility of what you percieve on "someone else", or "something else" (PSNR/SSIM). You seem to be saying "PSNR says it's better, so better it is". Am I wrong somewhere ? I'd be glad you correct me straight away !

Looking at an encode through metrics (which is what you apparently do) is like voluntarily watching a movie without the psy-enhancements. Do you get the idea ? It's voluntarily limiting your perception of the actual picture being displayed.

And yes, there was the ALWAYS word missing (post edited), I thought what I was getting at was obvious but I'll be careful next time :).

Dark Shikari

13th August 2008, 01:39

http://i38.tinypic.com/2edmtte.png http://i33.tinypic.com/312eb2e.png

PSNR 37.165 and 38.152 respectively, 300kbps.

Now stop talking about useless metrics.

Razorholt

13th August 2008, 02:41

Are you sure you are comparing the same type of frames? :p

Dark Shikari

13th August 2008, 02:43

Are you sure you are comparing the same type of frames? :pYes, both are P-frames. :)

Razorholt

13th August 2008, 02:48

So, does it mean that we "may" compare frames as long as they are the same type? ... I mean, in order to compare encoded files.

Dark Shikari

13th August 2008, 02:52

So, does it mean that we "may" compare frames as long as they are the same type? ... I mean, in order to compare encoded files.Comparing frames is usually fine, but you have to watch out for cases where it might be misleading (for example, if ratecontrol gave significantly different distributions of bits between two files).

By the way, the first image is latest x264 with maxed settings, b-adapt 2, and psyrd+psytrellis, and the second is x264 r614 with maxed settings. :p

MasterNobody

13th August 2008, 09:15

Dark Shikari
And can you tell the SSIM for this samples?

smok3

13th August 2008, 09:42

Atak_Snajpera

13th August 2008, 11:47

Yes I agree! Excellent quality @ 1.8 MBps.

Dark Shikari

13th August 2008, 15:11

Dark Shikari
And can you tell the SSIM for this samples?I don't have the logs anymore; the SSIM was just about the same for both (negligable difference), around 0.95.
a little transcode test, besides some funny marks on some faces (posterization enhanced?) looks really good imho;

http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/thespirit-x1280y544.mp4

p.s. useless encoding time.:eek:

Sagittaire

13th August 2008, 15:45

http://i38.tinypic.com/2edmtte.png http://i33.tinypic.com/312eb2e.png

PSNR 37.165 and 38.152 respectively, 300kbps.

Now stop talking about useless metrics.

Well it's paradoxal here because codec is simply mathematical algo. If you say that the first algo is better than the second algo for eyes you can by definition produce other mathematical algo (metric) for show that ... isn't it?

jethro

13th August 2008, 15:57

psy-rd is that 'mathematical algo (metric)', I think

lexor

13th August 2008, 15:57

a little transcode test, besides some funny marks on some faces (posterization enhanced?) looks really good imho;

http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/thespirit-x1280y544.mp4

p.s. useless encoding time.

That is awesome (the encode I mean, the movie looks like it'll blow chunks). But did you use tv-pc colour conversion? The blacks don't look quite right, and for web playback the colours should always be converted to pc scale (since we can't have flash player post process in browser).

lexor

13th August 2008, 16:01

Well it's paradoxal here because codec is simply mathematical algo. If you say that the first algo is better than the second algo for eyes you can by definition produce other mathematical algo (metric) for show that ... isn't it?

No it isn't. What you want is not the metric that adapts to encoding algorithm, but the metric that simulates your eyes (with algo specific metric, you can't compare algorithms and settings, which is what you want to do). And there is no such metric in existence. Furthermore existence of mathematical objects/concepts is a fundamental problem it is certainly doesn't follow from some "definition" nor can you assume existence most of the time.

smok3

13th August 2008, 16:01

lexor, you are right, however i was trying to avoid any filters in the chain (especially if there is a chance of additional posterization by filter itself).
p.s. looks correct with coreavc where input&output are set to auto.

lexor

13th August 2008, 16:08

lexor, you are right, however i was trying to avoid any filters in the chain (especially if there is a change of additional posterization by filter itself).

Yeah, that stuff is always a trade off, the only reason I noticed is because wrong colour scale really shows up on my lcd. So I just have a habit for personal use to prioritize colour correction over everything else. The trailer still looks awesome though, I noticed it gets better as it goes to. In the intro, after tree with the birds disappears and the red line appears you can see a quick blocky flash in the bottom half of the frame, never happens again after that. I wonder if that's in the source?

smok3

13th August 2008, 16:13

lenox, check the 720p 'original';
http://www.apple.com/trailers/lions_gate/thespirit/

edit: another test, fast 2pass encoding, looks great
http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/wall-e-clip-atwork-x1280y544.mp4

(trailer for the movie 'australia' seems to be a good partybreaker, when trying to encode at sub 2k bitrates, probably due to bunch of dissolves?)

q: if i use the compile 'x264.928.modified.02.exe' then --trellis 2 = psytrellis ?

kemuri-_9

13th August 2008, 18:42

q: if i use the compile 'x264.928.modified.02.exe' then --trellis 2 = psytrellis ?

if subme >= 6 & psy-rd > 0 as well (if unspecified, psy-rd is 1.0)

Dark Shikari

13th August 2008, 18:44

If psy_rd > 0, subme >= 6, and trellis > 0, psy trellis is on.

The final psy_rd commit will allow psy_trellis without subme >= 6.

LoRd_MuldeR

13th August 2008, 19:19

The final psy_rd commit will allow psy_trellis without subme >= 6.

Good news :D

elguaxo

13th August 2008, 19:24

Will there be a chance to use PsyRDO without Psy Trellis when commited? Old movies usually have lots of noise and/or grain and don't have many details (probably similar to 300). For the bitrates I'm using PsyRDO seems to be great on every kind of source, but PsyRDO+Psy Trellis is not so great on those old movies unless I use a more bitrate.

edit: I haven't tried using Psy Trellis with a 'lowered' PsyRDO and/or 'lowered' AQ

Dark Shikari

13th August 2008, 19:26

Will there be a chance to use PsyRDO without Psy Trellis when commited? Old movies usually have lots of noise and/or grain and don't have many details (probably similar to 300).Huh? Those movies are exactly why I created psy-trellis; because regular trellis sucks with that kind of grain. If even psy-trellis isn't good enough for you, try low deadzones or something.

elguaxo

13th August 2008, 19:35

I'll post some samples tomorrow!

Atak_Snajpera

13th August 2008, 19:52

edit: another test, fast 2pass encoding, looks great
http://somestuff.org/flashAVC/flvpla...-x1280y544.mp4
Once again you did correct levels!

wyti

13th August 2008, 21:27

it will be good if we are able to desactivate psy-trellis when we use psy-rdo.
Because psy-trellis isn't very usefull on anime. He try to conserve details that are invisible (or even not existing at all) and include some ringing (even at high bitrate).

Dark Shikari

13th August 2008, 21:34

wyti

13th August 2008, 21:58

not very, but isn't that one of your goal that psy-rdo will be better on any type of sources ?

lexor

13th August 2008, 22:02

Is psy-RD useful on anime at all?
Not on most anime, but some of the newer ones that are broadcast in HD have artificial grain added to them like the movies shot all digital do (not quite as much though). So psy-rd is becoming useful for anime.

Dark Shikari

13th August 2008, 22:02

not very, but isn't that one of your goal that psy-rdo will be better on any type of sources ?Ideally, but I haven't found a solution for the "it makes edges in anime less sharp" problem. I can imagine its possible to make a psy-opt for anime (optimize for blurred edges instead of ringing, since the former looks better), but psy-rd isn't it.

I may switch --psy-rd as a parameter though from --psy-rd X to --psy-rd X:Y; this will allow you to tweak both psy-RD and psy-trellis.

elguaxo

13th August 2008, 22:09

I may switch --psy-rd as a parameter though from --psy-rd X to --psy-rd X:Y; this will allow you to tweak both psy-RD and psy-trellis.

That sounds perfect! :thanks:

Ramir Gonzales

13th August 2008, 22:52

Is there any sort of "Holey bible for the x264 settings) ?

Currently there are so many options, and many exceptions like "Never use option x with option y" that most not-so-knowledged users are completely loosing sight on how to correctly encode using x264 ? :helpful:

Dark Shikari

13th August 2008, 22:54

LoRd_MuldeR

13th August 2008, 23:07

Currently there are so many options, and many exceptions like "Never use option x with option y" that most not-so-knowledged users are completely loosing sight on how to correctly encode using x264 ? :helpful:

That's why MeGUI provides various pre-defined profiles from "Fast" up to "Insane" ;)

fachman

14th August 2008, 00:44

The whole point of psy-rdo is that what ever IT IS, it SEEMS to be better than what it actually IS => Read : whatever the metrics (good or bad), it looks better.

And what's the matter with "someone else's" opinion you keep talking about : what about YOUR opinion ? What about YOUR eyes ? Forget the others, forget the numbers ... what do YOU see ? Which output do your eyes prefer ? You're putting the responsibility of what you percieve on "someone else", or "something else" (PSNR/SSIM). You seem to be saying "PSNR says it's better, so better it is". Am I wrong somewhere ? I'd be glad you correct me straight away !

Looking at an encode through metrics (which is what you apparently do) is like voluntarily watching a movie without the psy-enhancements. Do you get the idea ? It's voluntarily limiting your perception of the actual picture being displayed.

And yes, there was the ALWAYS word missing (post edited), I thought what I was getting at was obvious but I'll be careful next time :).

Ehhh. you simply do not get it. I would like to talk with you but you live in your own universe.
In this thread it was only one time when I presented my judgement and I have backed it up with the pictures. So please take a look at that post, and then make the proper judgement of my eyes then please stop this nonsence disscussion and focus on something what is real.

To Dark Shikari

I am here only for one reason. To help you improve the codec efficiency. I have done hundreds of encodes on various video files and I strongly belive my experience can be really helpful.
I know what I am talking about because I am talking about my OWN research and I can back it up with numbers and pictures. Please do not take personal for anything I am writing about your work down here, because my only intention is professional advice.
1. With all respect, but you have not used the max setting for r614 because you have not used my FASM technique, because you did not know about it and you still refuse to aknowledge the power of PBRATIO. I want to believe it is only because you are a busy man. If you do not want to make such tests on your own my computer is now computing some tests to back up my words, so please give me some time and I will give you reasonable explanation.
2. What you have presented us (two pictures) is the classic problemm with PSNR discribed fully here http://www.ece.uwaterloo.ca/~z70wang/research/ssim/. To bad you do not remember the exact SSIM values. So metrics are not useless they just need to be correctly interpreted and you can gain those knowledge by experimenting on various video files comparing what you see with what metrics tells you.
For example SSIM seems to be better, but it operates only on Luma so, setting Chroma QP_offset to -15 would provide better SSIM, but lowers PSNR and lowers perceptable picture quality. Because both metrics does not like your PSYRDO I would suggest another one with complexity comparision. I strongly belive that only when we properly balance those 3 metrics we can have something which would be reliable. After all those metrics were not created for anyones fun, but were created to compare quality!!!!
3. There is another thing we must remember here. We are working on video not on still pictures. X264 provides the PSNR and SSIM values which is average of those values of every frame. You have been so kind to correct me to do not use restrain to AQ, but when I use MAXQ=51 as everyone suggest I receive many scenes with so awful quality I can not even look at them, and only some with better quality(I am talking about low bitarate here). I also do receive lower PSNR and SSIM values....
4. If you would be so kind to tell me about your or someone elses experience with XVID and PBRATIO because I am really curious about it.

I am waiting for your response.

Dark Shikari

14th August 2008, 00:51

Ehhh. you simply do not get it. I would like to talk with you but you live in your own universe.
In this thread it was only one time when I presented my judgement and I have backed it up with the pictures. So please take a look at that post, and then make the proper judgement of my eyes then please stop this nonsence disscussion and focus on something what is real.If all you care about are metrics, you are wrong, since RDRC is guaranteed to give effectively optimal ratecontrol, and does not agree with your pbratio value.

If you don't care about metrics, and insist your eyes are right and everyone else's are wrong, I have news for you: there is no such thing as "golden eyes."
I know what I am talking about because I am talking about my OWN research and I can back it up with numbers and pictures. Please do not take personal for anything I am writing about your work down here, because my only intention is professional advice.You don't seem very professional to me.
2. What you have presented us (two pictures) is the classic problemm with PSNR discribed fully here http://www.ece.uwaterloo.ca/~z70wang/research/ssim/. To bad you do not remember the exact SSIM values. So metrics are not useless they just need to be correctly interpreted and you can gain those knowledge by experimenting on various video files comparing what you see with what metrics tells you.SSIM is just as useless; its PSNR weighted by variance.3. There is another thing we must remember here. We are working on video not on still pictures. X264 provides the PSNR and SSIM values which is average of those values of every frame.Which is the reason why pbratio=2.1 is a horrible idea. This is why (IMO) we should use Global SSIM and not Average, because Average misleads idiots.You have been so kind to correct me to do not use restrain to AQ, but when I use MAXQ=51 as everyone suggest I receive many scenes with so awful quality I can not even look at them, and only some with better quality(I am talking about low bitarate here). I also do receive lower PSNR and SSIM values....Surprise surprise--when you use broken ratecontrol options, you break ratecontrol!
4. If you would be so kind to tell me about your or someone elses experience with XVID and PBRATIO because I am really curious about it.B-frames in Xvid look awful. Simple as that.

I'm generally open to new ideas, but I don't like people who insist that they are right on absolutely everything, don't listen to a word that anyone else says, and refuse to provide any theoretical backing for any of their claims. As I have stated before, I explicitly refuse to consider any idea which has no theoretical basis; I don't deal in cargo-cult encoding. If you want me to consider your ideas, create a solid theoretical basis for them.

Ramir Gonzales

14th August 2008, 00:55

read this (http://ffmpeg.x264.googlepages.com/mapping)
Thanks for the link DS, unfortunately nothing about Psy-RDO and other new options to find there...

martino

14th August 2008, 02:32

Thanks for the link DS, unfortunately nothing about Psy-RDO and other new options to find there...
Because those aren't in the source yet... most likely.

elguaxo

14th August 2008, 03:47

Ok, here goes my sample. I always like PsyRDO and I like PsyRDO+PsyTrellis, but if you don't have enough bitrate and the source has noise and/or grain and no details then I see very often things like this:

PsyRDO
http://img384.imageshack.us/img384/5642/nopsytrellistn5.png

PsyRDO+PsyTrellis
http://img384.imageshack.us/img384/6405/withpsytrellispk5.png

if I use more bitrate then PsyRDO+PsyTrellis wins hands down.

Here are the encoded samples. Both encoded at 1200kbps (a bit low for this sample) and I used this (http://forum.doom9.org/showpost.php?p=1165193&postcount=615) build for PsyRDO only and this (http://forum.doom9.org/showpost.php?p=1169563&postcount=668) for PsyRDO+PsyTrellis:

http://omploader.org/vb2Fz/x264.928.modified.no.psytrellis.mkv
http://www.mediafire.com/?meok8mwoewk

http://omploader.org/vb2Fx/x264.934.modified.with.psytrellis.mkv
http://www.mediafire.com/?gfuppl5ie1g

Dark Shikari

14th August 2008, 04:04

Use a better host like Mediafire;your downloads terminate repeatedly after a couple minutes because the server terminates the connection.

Edit: Nevermind, was able to curl the first bit of them.

I've looked through a few dozen random frames in the first few thousand frames of the video; psy-trellis looks consistently better to me... though I do notice psy-trellis seems to result in slightly smaller B-frames (which could result in a few of them looking worse); this is probably due to the higher quantizer, and thus the harsher skip threshold.

smok3

14th August 2008, 09:21

some more examples, targeting 1800 kbps;
http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/terminatorsalvation-x1056y448.mp4 - downscaled, no level correction
http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/eagleeye-x1056y448.mp4 - downscaled, no level correction
http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/theexpress-x1056y448.mp4 (problematic regarding constant quality, probably source not very good) - downscaled, no level correction
http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/australia-x1280y544.mp4 (problematic dissolves?, source no good) - no resizing, no level correction

edit1: Problems seems to have a lot to do with the original as well, since this are all transcodes.
edit2: will try some downscaled 1080p sources, comparing Lanczos and bilinear downscale.

edit3: 1080p source, downscaled, almost perfect (compared to source)
http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/deathrace-LanczosDownscale-x1024y576.mp4

p.s. don't blame me for the dumb movies they made this days....

IgorC

14th August 2008, 17:15

Dear IgorC

Although I have no idea how Komisar did his tests, for the future I would consider think twice before you will say something...
?

Also I could bet you do not live with Komisar or Nico to know how they did their tests
It's not secret. http://forum.mediatory.ru/viewtopic.php?f=15&t=3780&start=3800

Razorholt

14th August 2008, 18:11

I've heard somewhere that PsyRDO+PsyTrellis were acting in first pass and that Trellis 2 was the primary choice over deadzones.
If this is true, why using Trellis 0 on first pass by default?

Thanks,
- Dan

Ranguvar

14th August 2008, 19:09

I am 99% sure that Psy RDO and Psy Trellis are only useful in the second pass.

Ranguvar

14th August 2008, 19:28

So since you were already busy DS, i tried tackling this myself and the result is:
x264_psy_rdo.0.5+psy_trellis_01_r929_mod.diff (http://kemuri9.net/dev/x264/patches/x264_psy_rdo.0.5+psy_trellis_01_r929_mod.diff)

added a new --psy-trellis option to enable and control code usage for psy trellis
allowing it to be on/off similar to psy rdo (within its dependencies of trellis > 0 and psy-rd > 0)

of course this needs your review when you have the time to make sure i didn't fubar anything.
I'll be adding this to my compiles. Quoting because it was buried by the metrics debate, in hope that someone will verify it doesn't b0rk anything :)

Thanks!

Dark Shikari

14th August 2008, 20:09

I'll be adding this to my compiles. Quoting because it was buried by the metrics debate, in hope that someone will verify it doesn't b0rk anything :)

Thanks!Try this instead (http://pastebin.com/f1685f9f7)...

gigah72

14th August 2008, 20:42

Try this instead (http://pastebin.com/f1685f9f7)...

patch failed :confused:

Administrator@SDFBF-9RX23LR8A /c/x264
$ patch -p1 < x264_psyrd_14082008.diff
patching file `common/common.c'
patching file `common/common.h'
patching file `common/dct.h'
patching file `encoder/analyse.c'
Hunk #2 succeeded at 1069 (offset 1 line).
Hunk #4 succeeded at 2121 (offset 1 line).
Hunk #6 succeeded at 2649 (offset 1 line).
patching file `encoder/encoder.c'
Hunk #1 FAILED at 411.
Hunk #2 succeeded at 484 (offset 1 line).
1 out of 2 hunks FAILED -- saving rejects to encoder/encoder.c.rej
patching file `encoder/macroblock.c'
patching file `encoder/macroblock.h'
patching file `encoder/rdo.c'
Hunk #2 succeeded at 326 (offset 2 lines).
Hunk #4 succeeded at 487 (offset 2 lines).
patching file `x264.c'
patching file `x264.h'

Razorholt

14th August 2008, 20:54

I am 99% sure that Psy RDO and Psy Trellis are only useful in the second pass.

You're right. That's the b-frames decisions that are made in first pass :)

Thanks Ranguvar.

- Dan

Dark Shikari

14th August 2008, 20:57

patch failed :confused:

Administrator@SDFBF-9RX23LR8A /c/x264
$ patch -p1 < x264_psyrd_14082008.diff
patching file `common/common.c'
patching file `common/common.h'
patching file `common/dct.h'
patching file `encoder/analyse.c'
Hunk #2 succeeded at 1069 (offset 1 line).
Hunk #4 succeeded at 2121 (offset 1 line).
Hunk #6 succeeded at 2649 (offset 1 line).
patching file `encoder/encoder.c'
Hunk #1 FAILED at 411.
Hunk #2 succeeded at 484 (offset 1 line).
1 out of 2 hunks FAILED -- saving rejects to encoder/encoder.c.rej
patching file `encoder/macroblock.c'
patching file `encoder/macroblock.h'
patching file `encoder/rdo.c'
Hunk #2 succeeded at 326 (offset 2 lines).
Hunk #4 succeeded at 487 (offset 2 lines).
patching file `x264.c'
patching file `x264.h'Bah, I even have to rebase my patches for you...

Linkage (http://pastebin.com/m3fb0df)

kemuri-_9

14th August 2008, 21:18

ha ha ha, the r929 snafu came up again.

hmm... so now the accepted formats for --psy-rd are as follows:
psy-rd strength & psy trellis strength at separate strengths,
float,float (i.e. 1.0,1.0)
float:float (i.e. 1.0:1.0)

both at same strengths
float (i.e. 1.0)

first one taking psy-rd strength, and second for psy trellis strength.

or did i make a mistake somewhere?

Dark Shikari

14th August 2008, 21:21

fachman

14th August 2008, 23:22

If all you care about are metrics, you are wrong, since RDRC is guaranteed to give effectively optimal ratecontrol, and does not agree with your pbratio value.

I do not care ALL about metrics, I just disagree with you that metrics are useless.
PSNR and SSIM have been created as a tool for comparing quality. The people which created it have made many tests and in especially of SSIm compared their metrisc to Perceptual Quality which was all described in the article.
Let me give you the example. The knife is a tool used to cut things. It works pretty well in most cases but you have found that it can not cut metal and insist on that example to saying it is USELESS.

If you don't care about metrics, and insist your eyes are right and everyone else's are wrong, I have news for you: there is no such thing as "golden eyes."

As far this nonsence disscussion goes we are going deeper into imagination not into what is real. At the begining of mine conversation I have presented two pictures comparing PSYRDO and PSYRDO+TRELLIS claiming that PSYRDO+TRELLIS prodcued in this particular case worse results. And you know what??? So far noone here commented their quality, no one dares to say that PSYRDO+PSYTRELLIS produced better result, but instead I was blamed for faulty vision. Maybe I have faulty vision, so I need to ask you which one in your personal opinion from those two pictures I have presented, produced better quality????

You don't seem very professional to me.

Well because I did not show you anything yet :)

SSIM is just as useless; its PSNR weighted by variance.Which is the reason why pbratio=2.1 is a horrible idea. This is why (IMO) we should use Global SSIM and not Average, because Average misleads idiots.

It is good to see that you start to take back your words regarding metrics. :)
I have no idea what kind of SSIM produces x264, because there is only one, but Global PSNR is also a form of "average" metrics just computed with different math.

Surprise surprise--when you use broken ratecontrol options, you break ratecontrol!B-frames in Xvid look awful. Simple as that.

I have no idea what do you mean by broken rate control. If you mean that the bitrate is different that it should be, this is not true and I have posted statistics to prove it. If you mean that there is huge variance of bitrate between the frames, I will say that is the reason ABR exists.
Well B-frames in X264 with PBRATIO=2.1 look really nice and the whole video look MUCH NICER than with PBRATIO=1.3 without AQ and in case of AQ it is a long story. This is the statistics for PBRATIO=1.3

--[NoImage] Job commandline: "C:\Program Files (x86)\megui\tools\x264\x264.exe" --pass 2 --bitrate 655 --stats "05.stats" --level 3.1 --keyint 99999 --ref 4 --mixed-refs --no-fast-pskip --bframes 16 --b-rdo --bime --weightb --direct auto --subme 7 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --qpmin 24 --qpmax 35 --qpstep 13 --ratetol 100 --qcomp 0 --cplxblur 2 --scenecut 100 --me umh --merange 64 --threads auto --thread-input --progress --output
--[Information] [2008-08-11 06:48:44] Encoding started
--[NoImage] Standard output stream:
--[NoImage] Standard error stream
---[NoImage] avis [info]: 1280x720 @ 25.00 fps (183160 frames)
---[NoImage] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
---[NoImage] x264 [info]: cabac=1 ref=4 deblock=1:0:0 analyse=0x3:0x113 me=umh subme=7 psy_rd=1.000000 brdo=1 mixed_ref=1 me_range=64 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=0 threads=6 nr=0 decimate=1 mbaff=0 bframes=16 b_pyramid=0 b_adapt=1 b_bias=0 direct=3 wpredb=1 bime=1 keyint=99999 keyint_min=25 scenecut=100(pre) rc=2pass bitrate=655 ratetol=100.0 rceq='blurCplx^(1-qComp)' qcomp=0.00 qpmin=24 qpmax=35 qpstep=13 cplxblur=2.0 qblur=0.5 ip_ratio=1.40 pb_ratio=1.30 aq=3:11:1.00
---[NoImage] mp4 [info]: initial delay 1 (scale 25)
---[NoImage]
---[NoImage] x264 [info]: slice I:319 Avg QP:26.58 size: 13058 PSNR Mean Y:45.86 U:49.41 V:49.79 Avg:46.72 Global:45.48
---[NoImage] x264 [info]: slice P:82918 Avg QP:28.85 size: 5284 PSNR Mean Y:43.59 U:47.41 V:47.75 Avg:44.48 Global:43.20
---[NoImage] x264 [info]: slice B:99923 Avg QP:30.37 size: 1530 PSNR Mean Y:42.64 U:46.99 V:47.33 Avg:43.62 Global:42.49
---[NoImage] x264 [info]: consecutive B-frames: 19.4% 25.2% 12.9% 17.5% 18.4% 5.4% 0.4% 0.0% 0.1% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.0% 0.6%
---[NoImage] x264 [info]: mb I I16..4: 53.8% 44.0% 2.2%
---[NoImage] x264 [info]: mb P I16..4: 9.0% 4.7% 0.1% P16..4: 38.2% 2.7% 3.1% 0.0% 0.0% skip:42.1%
---[NoImage] x264 [info]: mb B I16..4: 0.1% 0.2% 0.0% B16..8: 25.4% 0.2% 0.3% direct: 0.4% skip:73.4% L0:31.0% L1:67.6% BI: 1.4%
---[NoImage] x264 [info]: final AQ sensitivity: 8.0000
---[NoImage] x264 [info]: 8x8 transform intra:34.9% inter:90.3%
---[NoImage] x264 [info]: direct mvs spatial:95.6% temporal:4.4%
---[NoImage] x264 [info]: ref P L0 69.9% 16.5% 10.0% 3.6%
---[NoImage] x264 [info]: ref B L0 90.4% 6.0% 3.6%
---[NoImage] x264 [info]: SSIM Mean Y:0.9795424
---[NoImage] x264 [info]: PSNR Mean Y:43.077 U:47.183 V:47.522 Avg:44.011 Global:42.801 kb/s:649.91
---[NoImage] encoded 183160 frames, 12.25 fps, 649.93 kb/s

Take a good look what happened with SSIM.

I'm generally open to new ideas, but I don't like people who insist that they are right on absolutely everything, don't listen to a word that anyone else says, and refuse to provide any theoretical backing for any of their claims. As I have stated before, I explicitly refuse to consider any idea which has no theoretical basis; I don't deal in cargo-cult encoding. If you want me to consider your ideas, create a solid theoretical basis for them.

Dark Shikari, I have given you theorethical backing of my claims in the very begining. If it is not enough for you, I will do my best to create better.
Also thank you very much for honesty. I also will be honest with you. I do not like people who put the words into someone elses mouth which they did not say.
So far the disscussion on this forum is at scandalic unprofessional level. I have found something and instead of trying to find a reasonable explanation I am bullied here.
Also I do not belive in majority opinions in every case because as the reality shows (this thread also), many many people rely more on their emotions than on the reality. If you do not belive me then ask yourself question why majority people in your country elected George W Bush for two terms??? (I will not continue this topic so far because it is not a proper place for this. I just wanted to explain my beliefs)

Dark Shikari

14th August 2008, 23:33

So far the disscussion on this forum is at scandalic unprofessional level.And this is why I am not going to read any more of your posts.

Also, "it works" or "it increases quality" is not a theoretical basis; its a circular argument. For example, let me give you a theoretical explanation for your --pbratio 2.1, since you don't seem to be capable of (or care to) come up with one on your own:

"Biprediction allows considerably better quality even with no residual, so a much higher quantizer doesn't hurt quality much and allows considerably more bits to be saved by increasing the number of skip macroblocks."
(Reason it fails: too high a quantizer means not even enough bits for motion vectors, killing the effectiveness of biprediction, too)

or

"If you drop quality every other frame, the human eye won't notice it much, especially if with biprediction blurring the difference between the two neighboring frames."
(Reason it fails: you're using more than 1 B-frame)

Of course, neither of these are valid explanations for such a high pbratio (they work rather well for explaining the current ~1.4 pbratio), but they're a good start.

nerdpunk

15th August 2008, 03:31

Bah, I even have to rebase my patches for you...

Linkage (http://pastebin.com/m3fb0df)

for us all ;) thanx, find them very useful... but... is there a public repository where we can follow the devel process?

Dark Shikari

15th August 2008, 03:51

for us all ;) thanx, find them very useful... but... is there a public repository where we can follow the devel process?Here (http://git.videolan.org/?p=x264.git;a=summary).

nerdpunk

15th August 2008, 04:07

Here (http://git.videolan.org/?p=x264.git;a=summary).

i know, sorry, i meant a place where we can find your latest (psy-*) patches... or will they get merged in a forseeable future?

Dark Shikari

15th August 2008, 04:25

i know, sorry, i meant a place where we can find your latest (psy-*) patches... or will they get merged in a forseeable future?Soon enough... hopefully.

gigah72

15th August 2008, 09:10

Bah, I even have to rebase my patches for you...

Linkage (http://pastebin.com/m3fb0df)

thank you.

may i ask you, what is improved/reworked in this patch, beside the cmd-switch? i don't speak c, and from the comments, not much saying to me.
btw, i can't patch b-adapt patch from 29.07., saying something about other patch detected -> reverse, blabla, and i'm too clueless what do to ...

skystrife

15th August 2008, 09:40

thank you.

may i ask you, what is improved/reworked in this patch, beside the cmd-switch? i don't speak c, and from the comments, not much saying to me.
btw, i can't patch b-adapt patch from 29.07., saying something about other patch detected -> reverse, blabla, and i'm too clueless what do to ...

Remove the part in the b-adapt patch where it changes X264_BUILD in x264.h. The new psyrdo+psytrellis patch changes it already.

Or, just grab this (http://skystrife.com/x264/x264_new_bframe_decision_04.diff).

gigah72

15th August 2008, 10:03

Remove the part in the b-adapt patch where it changes X264_BUILD in x264.h. The new psyrdo+psytrellis patch changes it already.

Or, just grab this (http://skystrife.com/x264/x264_new_bframe_decision_04.diff).

thanx m8, for helping again :)

turbojet

15th August 2008, 13:04

Zwitterion

15th August 2008, 13:19

Dark Shikari Why is psytrellis being forced upon us by replacing the origninal trellis algorithm instead of being an additional setting such as the new bframe decision

It isn't. See here: http://forum.doom9.org/showpost.php?p=1170411&postcount=496
Also don't forget that PsyRDO and b-frame-adapt are still experimental patches and not yet commited. So nothing is 'forced upon you'.

elguaxo

15th August 2008, 13:21

turbojet, these are experimental patches, you are not forced to use them. :)

edit: what Zwitterion said

turbojet

15th August 2008, 13:54

--psy-rd 1:0 means regular trellis is used?
if yes, if --trellis 1 does this mean the old --trellis 1 is used and not an automatic switch back to 0 if psyRDO is used? <- this is what I'd really like to do again.
if no, then since r931 it appears that if you want psyrdo you are forced to have psytrellis. Which frankly makes the encoder alot more ineffecient and slower, not really what I'd call progress in, with the age of x264, should be a somewhat stable codec. I do like the idea but I think it needs some more optimaztion to be pushed into every psyrdo build, or a switch at least.

Don't get me wrong, this isn't a personal attack on you dark shikari. I do appreciate what you and anyone else involved did with vaq and psyrdo, and both of these have options to disable\enable them. --trellis 1 with psyrdo you've already seen my opinions on earlier in this thread. Why can't you make options for these and everyone can be satisfied? If you want people to use a certain thing, you could just make it the default, like trellis 0 already is, but leave the option open to the person encoding.

Also one thing I noticed while catching up on this thread is that Dark Shikari wants video clips to make comparisons, which I agree with. But he is asking others to judge psytrellis by a one frame comparison. Anyone can make a still frame look better or worse then its opposition, this is not saying you are lying to us on your pictures. But why not present it how you'd want it, with video clip. Such as a regular trellis clip compared to a psytrellis clip at the same crf, asking them to take size into consideration, and a 2 pass trellis vs psytrellis clip done at the same reasonable bitrate?

Dark Shikari

15th August 2008, 14:32

Dark Shikari Why is psytrellis being forced upon us by replacing the origninal trellis algorithm instead of being an additional setting such as the new bframe decision?
BTW I'm rather surprised you decided to use -b-adapt 2 with the new frame decision and not try to dictate what everyone must use like you did with trellis 1 and now this whole psytrellis ordeal. Why don't you add to x264 rather than reinventing it?You can adjust psy-trellis strength with --psy-rd... nothing is being "forced" upon anyone...
Also one thing I noticed while catching up on this thread is that Dark Shikari wants video clips to make comparisons, which I agree with. But he is asking others to judge psytrellis by a one frame comparison. Anyone can make a still frame look better or worse then its opposition, this is not saying you are lying to us on your pictures. But why not present it how you'd want it, with video clip. Such as a regular trellis clip compared to a psytrellis clip at the same crf, asking them to take size into consideration, and a 2 pass trellis vs psytrellis clip done at the same reasonable bitrate?I don't think I've posted much in terms of single-frame comparisons in this thread... I don't think its that much of my job to convince people that features are useful, rather, its my job to make useful features and let others test to see if they can find cases where they have a negative effect so that I can see if they need further tweaking. Again, if you don't like it, you can turn it off...

I don't get the hostility here; are people somehow mad because new features are being added (despite the fact that these new features are optional)?

turbojet

15th August 2008, 15:56

OK so let me get this straight, --trellis 1 --psyrd 1.0:0 is the same as --trellis 1 in vanilla builds?
mediainfo says --trellis 1, size is different then that of --trellis 0 and --trellis 2

935 from http://forum.doom9.org/showthread.php?p=1170562#post1170562
930 from http://forum.doom9.org/showthread.php?p=1168914#post1168914

using this on both: --crf 20.0 --level 4.1 --ref 3 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 30000 --vbv-maxrate 30000 --me umh --threads auto --thread-input --mvrange 511 --aud

--trellis 0 935 14.3 vs 13.2 MB 930
--trellis 2 935 14.9 vs 13.8 MB 930

935 is also a bit slower. I don't think this is the same trellis as before.

I appreciate the new features. My hostility started when you disabled trellis 1 with psyrdo because you didn't think it was optimized for it. Adding useful features is good as long as they are optional, removing features that people regularly use is bad and gonna come with some criticism. This is the first time in over 10 years of encoding that I've seen useful and used features being removed.

Think jack sparrow for pic comparison, its the only way psytrellis was presented in this thread.

Dark Shikari

15th August 2008, 15:58

OK so let me get this straight, --trellis 1 --psyrd 1.0:0 is the same as --trellis 1 in vanilla builds?
mediainfo says --trellis 1, size is different then that of --trellis 0 and --trellis 2

935 from http://forum.doom9.org/showthread.php?p=1170562#post1170562
930 from http://forum.doom9.org/showthread.php?p=1168914#post1168914

using this on both: --crf 20.0 --level 4.1 --ref 3 --mixed-refs --bframes 3 --b-pyramid --b-rdo --bime --weightb --direct auto --subme 7 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 30000 --vbv-maxrate 30000 --me umh --threads auto --thread-input --mvrange 511 --aud

--trellis 0 935 14.3 vs 13.2 MB
--trellis 2 930 14.9 vs 13.8 MB

935 is also a bit slower. I don't think this is the same trellis as before.If it isn't the same, then there's a bug. If you don't like it, patches are welcome, or you can wait for me to find it.

(I'm going to guess the real difference lies in the chroma-qp-offset, however; I doubt there's a bug, but I'll check anyways.)

Edit: bug check done. When trellis is off, trellis is off and chroma QP offset isn't further decremented. When trellis is on, and psy trellis is 0, the psy trellis code is never run. When trellis is on, and psy trellis is nonzero, the psy trellis code is run. Seems to work.

turbojet

15th August 2008, 16:29

Frankly unless something signifigant was added like psyrdo and vaq, I don't remeber filesize changing by more than a few KB and speed not really changing at all when changing between x264 builds within a month or so of each other.

Wonder why this all of a sudden changes this by quite a bit.

Anyhow I'll be glad to have original -trellis 1 back, please do me a favor and don't go disabling it again

Dark Shikari

15th August 2008, 16:30

What do you mean by 'When trellis is on, and psy trellis is nonzero, the psy trellis code is run.' ?It does what its supposed to do--when the psy trellis strength isn't zero, and trellis is on, psy trellis is run. Otherwise, regular trellis is run (if trellis is nonzero) or no trellis is run (if trellis is zero).
Frankly unless something signifigant was added like psyrdo and vaq, I don't remeber filesize changing by more than a few KB and speed not really changing at all when changing between x264 builds within a month or so of each other.You're forgetting about the chroma QP offset.

shon3i

15th August 2008, 16:41

I am bit confused about new cmd.

--psy-rd x:y

is x PsyRDO strenght?
and is y PsyTrellis switcher and can be only 0 or 1 (off/on)?

if x not 0 and y = 1 trellis can be 1 or 2?
if x not 0 and y = 0 trellis can be 0 or 2, like earlier or not?

Can we use only PsyTrellis?

Thanks

Dark Shikari

15th August 2008, 16:43

I am bit confused about new cmd.

--psy-rd x:y

is x PsyRDO strenght?
and is y PsyTrellis switcher and can be only 0 or 1 (off/on)?

if x not 0 and y = 1 trellis should be 1 or 2?
if x not 0 and y = 0 trellis should be 0 or 2, like earlier or not?

Can we use only PsyTrellis?

ThanksBoth are float values; they can be decimal strengths.

You can use only psy-trellis and not psy-rd, but its not recommended (it helps, but its not nearly as useful as the combination). I guess it might be useful when you need high speed and can't afford RD.

Sharktooth

15th August 2008, 16:45

psy-trellis is suboptimal without psy-rdo.
x is psy rdo strenght (0 = disabled)
y is psy trellis strenght (0 = disabled)
trellis 0,1 and 2 work as usual... and psy trellis is useless with trellis 0...
that's at least is what i understood.

D_S: i would add a couple of checks though: if psy-rdo is enabled then automatically enable psy-trellis unless it is set to 0. if psy-rdo is disabled keep the normal trellis (if trellis > 0.... redundant...) unless psy-trellis is set > 0.

turbojet

15th August 2008, 16:48

What was changed with the chroma QP offset?
I was thinking it might be the faster deblocking affecting filesize, and maybe compile options affecting the speed, which isn't too signifigant and I've seen this sort of difference between 2 different builds based on same x264 revision.

I think I'll try testing different psytrellis strengths to find a good medium for my eyes when I find some time. I do see the potential in it from the little experience I've had with it, using defaults. What is the default strength of psytrellis?

Dark Shikari

15th August 2008, 17:00

psy-trellis is suboptimal without psy-rdo.
x is psy rdo strenght (0 = disabled)
y is psy trellis sytrenght (0 = disabled)
trellis 0,1 and 2 work as usual... and psy trellis is useless with trellis 0...
that's at least is what i understood.

D_S: i would add a couple of checks though: if psy-rdo is enabled then automatically enable psy-trellis unless it is set to 0. if psy-rdo is disabled keep the normal trellis (if trellis > 0.... redundant...) unless psy-trellis is set > 0.Psy trellis is 1.0 by default, psy RD is 1.0 by default.What was changed with the chroma QP offset?A chroma QP offset was added when using psy RD (and a further one using psy trellis) to compensate for the higher quants the two tend to cause.

Sharktooth

15th August 2008, 17:10

i meant, if psy-rdo = 0 then psy-trellis strength = 0 (unless some value (even the default one) is specified in the commandline)
if psy-rdo > 0 then psy-trellis strength = something (where "something" is the default (1) value if the param is not specified in the commandline or the value the user set in the commandline param).

Dark Shikari

15th August 2008, 17:26

i meant, if psy-rdo = 0 then psy-trellis strength = 0 (unless some value (even the default one) is specified in the commandline)If you specify --psy-rd X (without :Y), it'll set Y equal to X.

Sharktooth

15th August 2008, 17:29

ok, not much code changes on my side then.

Quark.Fusion

16th August 2008, 00:20

Avenger007

16th August 2008, 01:17

What now is optimal setting of trellis with psy-trellis on — 1 or 2? (At start of this thread was sayed that trellis 1 can't adequately work with psy-rd and trellis 2 is recommended instead, what is situation now?)
trellis 0,1 and 2 work as usual... and psy trellis is useless with trellis 0...
So use what you like.

Or psy-trellis replaces trellis?
when the psy trellis strength isn't zero, and trellis is on, psy trellis is run. Otherwise, regular trellis is run (if trellis is nonzero) or no trellis is run (if trellis is zero).

Avenger007

16th August 2008, 01:18

I don't get the hostility here; are people somehow mad because new features are being added (despite the fact that these new features are optional)?
I'm guessing the significant increase in CRF file size might be a factor. There's also an increase in encoding time.
I don't mind the increase in encoding time but the increase in file size does take it's toll. However, I know I can always increase the CRF value. :sly:
A chroma QP offset was added when using psy RD (and a further one using psy trellis) to compensate for the higher quants the two tend to cause.
Would a CRF offset be a bad idea (what they don't know can't hurt them :devil:)? Since the AQ and psy-* patches increase perceptual quality at the same bitrate when compared without them, then the increased bitrate when using CRF seems... uncalled-for.

kemuri-_9

16th August 2008, 05:08

A chroma QP offset was added when using psy RD (and a further one using psy trellis) to compensate for the higher quants the two tend to cause.

Maybe people are looking for those numbers you stashed away in the code?
the chroma qp offset for a strength < .25 (but > 0) is -1, for strength >= .25 the offset is -2
this applies to both psy-rd and psy trellis strengths:
i.e.
1.0:1.0 produces a -4 offset
0.5:0.2 produces a -3 offset
0.15:0.10 & 0.4:0 produce a -2 offset
0.10:0 produces a -1 offset

(however x264 still enforces the [-12,12] range for chroma qp offset after this takes place so if you have a -12 offset before this, it will remain -12)

iirc, the offsets were first added in the first +psy-trellis patch
but in that case, if psy trellis was on, it was always a -2 offset.

Shinigami-Sama

16th August 2008, 05:44

Would a CRF offset be a bad idea (what they don't know can't hurt them :devil:)? Since the AQ and psy-* patches increase perceptual quality at the same bitrate when compared without them, then the increased bitrate when using CRF seems... uncalled-for.

the psy-* Stuff increase bitrate at a given quant...

Dark Shikari

16th August 2008, 06:37

Would a CRF offset be a bad idea (what they don't know can't hurt them :devil:)? Since the AQ and psy-* patches increase perceptual quality at the same bitrate when compared without them, then the increased bitrate when using CRF seems... uncalled-for.I've thought of the idea before; its not unreasonable.

Avenger007

16th August 2008, 08:27

I've thought of the idea before; its not unreasonable.
A snap-poll (thread) would be nice if you're planning on implementing it.
I vote for the psy-opts to have little impact on the bitrate when compared to not using them, in CRF mode. Other people may be more forgiving about a large difference in bitrate.

Shinigami-Sama

16th August 2008, 08:47

A snap-poll (thread) would be nice if you're planning on implementing it.
I vote for the psy-opts to have little impact on the bitrate when compared to not using them, in CRF mode. Other people may be more forgiving about a large difference in bitrate.

... all they have to do is up the crf a bit and it will still look as good as they're used too...

Audionut

16th August 2008, 11:19

I've thought of the idea before; its not unreasonable.

Please don't. People just need to adjust their ways and use a higher CRF to obtain the same visually quality.

And you could just ignore the un-constructive useless posts that some make.
Loren seems to do it well. :cool:

akupenguin

16th August 2008, 13:06

People just need to adjust their ways and use a higher CRF to obtain the same visually quality.
What exactly is better about having CRF20 represent quality X, rather than having CRF19 represent quality X?
Otoh, if some people use psy and some don't and some use various strengths, there is an obvious benefit from CRF having the same meaning in all those cases.
If an option increases quality and reduces bitrate, I don't have much of an opinion as to which one we should track; any compromise that's easy to implement is acceptable. And if an option sometimes increases and sometimes decreases bitrate, that's just life, we have to expect some variance in the output of heuristics. But if an option consistently and predictably increases both quality and bitrate while all ratecontrol options are held constant, then it's miscalibrated.
I have already applied this principle: If I hadn't included an arbitrary correction factor, CRF would mean different things depending on whether you enabled B-frames or not. Or more extremely, depending on your video resolution.

Ranguvar

16th August 2008, 22:20

Bah, I even have to rebase my patches for you...

Linkage (http://pastebin.com/m3fb0df)
Fails patching against r936 from git?

patching file common/common.c
Hunk #1 FAILED at 117.
Hunk #2 FAILED at 466.
Hunk #3 FAILED at 873.
3 out of 3 hunks FAILED -- saving rejects to file common/common.c.rej
patching file common/common.h
Hunk #1 FAILED at 377.
Hunk #2 FAILED at 456.
2 out of 2 hunks FAILED -- saving rejects to file common/common.h.rej
patching file common/dct.h
Hunk #1 FAILED at 41.
1 out of 1 hunk FAILED -- saving rejects to file common/dct.h.rej
patching file encoder/analyse.c
Hunk #1 FAILED at 467.
Hunk #2 FAILED at 1069.
Hunk #3 FAILED at 1962.
Hunk #4 FAILED at 2121.
Hunk #5 FAILED at 2401.
Hunk #6 FAILED at 2649.
6 out of 6 hunks FAILED -- saving rejects to file encoder/analyse.c.rej
patching file encoder/encoder.c
Hunk #1 FAILED at 410.
Hunk #2 FAILED at 484.
2 out of 2 hunks FAILED -- saving rejects to file encoder/encoder.c.rej
patching file encoder/macroblock.c
Hunk #1 FAILED at 94.
Hunk #2 FAILED at 121.
Hunk #3 FAILED at 163.
Hunk #4 FAILED at 447.
Hunk #5 FAILED at 495.
5 out of 5 hunks FAILED -- saving rejects to file encoder/macroblock.c.rej
patching file encoder/macroblock.h
Hunk #1 FAILED at 50.
1 out of 1 hunk FAILED -- saving rejects to file encoder/macroblock.h.rej
patching file encoder/rdo.c
Hunk #1 FAILED at 50.
Hunk #2 FAILED at 326.
Hunk #3 FAILED at 355.
Hunk #4 FAILED at 487.
Hunk #5 FAILED at 564.
5 out of 5 hunks FAILED -- saving rejects to file encoder/rdo.c.rej
patching file x264.c
Hunk #1 FAILED at 243.
Hunk #2 FAILED at 415.
2 out of 2 hunks FAILED -- saving rejects to file x264.c.rej
patching file x264.h
Hunk #1 FAILED at 35.
Hunk #2 FAILED at 239.
2 out of 2 hunks FAILED -- saving rejects to file x264.h.rej

Dark Shikari

16th August 2008, 22:21

Click download, don't copy/paste... :rolleyes:

Of course patching will fail if the text is not properly formatted...

Ranguvar

16th August 2008, 22:26

I did... just tried again, saving as text document and all files. Copy+pasting results in a different error (garbage in diff).

Dark Shikari

16th August 2008, 22:31

I did... just tried again, saving as text document and all files. Copy+pasting results in a different error (garbage in diff).Ensure that the encoding of the file matches the encoding of the x264 source files... this is really not very difficult...

Ranguvar

16th August 2008, 22:40

Both the source and the diff are ISO-8859-1 (or compatible).... saving as UTF-8, etc. also fails.

kemuri-_9

16th August 2008, 22:47

this shouldn't really be happening....
but have you tried converting the CR LFs in the downloaded file to LFs?
this may be causing the errors, or try the -l option in patch

Dark Shikari

16th August 2008, 22:48

Both the source and the diff are ISO-8859-1 (or compatible).... saving as UTF-8, etc. also fails.Windows encoding, or Unix?

One of them is CR/LF, the other is CR, of course it fails. I do not need to waste a page of this threading teaching people how to patch their source code.

Ranguvar

16th August 2008, 23:15

Thanks very much, kemuri :) I apologise for my noobishness in this area; I'm still very new to *nix. Did not know there was differences in the linebreak signaling. dos2unix from the hd2u package solved the problem.

kemuri-_9

16th August 2008, 23:44

windows uses CR LF, linux uses LF only, and mac uses CR only
(CR = Carriage Return - 0x0D; LF = Line Feed - 0x0A)
and why are they all different? to cause us all pain and suffering!

Quark.Fusion

17th August 2008, 00:19

A snap-poll (thread) would be nice if you're planning on implementing it.
I vote for the psy-opts to have little impact on the bitrate when compared to not using them, in CRF mode. Other people may be more forgiving about a large difference in bitrate.
Why you care about same bitrate in quality-based mode? You get better quality from psy-rd, but it depends on source.
Psy-algos works by raising quality where you see it and lowering where you don't, right? But gain in bitrate from lowering quality isn't the same as loss from raising it.
So bitrate at CRF can go in either side, because it's source who dictates bitrate, not CRF value.
And if you correct CRF you lowering quality somewhere and don't get same quality across clip, right?

Quark.Fusion

17th August 2008, 00:42

But if an option consistently and predictably increases both quality and bitrate while all ratecontrol options are held constant, then it's miscalibrated.
Is PSY-RDO increases bitrate on source without noise? What if you have face in center of clip and noise in the background (or face on the left and noise on the right) and then same face with clean background — shouldn't the face quality be same at CRF?

What if I adjust my CRF setting by visual comparing quality to get maximum value when I don't see ringing, then I turn on PSY and see compression artifacts in important to me areas? Should I make new comparison to get new CRF?

Any PSY option shouldn't lower quality where you see it at CRF, imho. Or it must be configurable, i.e. add "--add-psy" option to disable adjustion of CRF.

akupenguin

17th August 2008, 00:50

Or it must be configurable, i.e. add "--add-psy" option to disable adjustion of CRF.
What is "adjustion"? What decides that the baseline unadjusted value of psy-rd is ssd=>ssd+ac, as opposed to, say, ssd=>(ssd+ac)/2 ? If I change the meaning of any given quantizer, why do I have to keep the quantizer numbers constant rather than the perceptual quality? If I made a "--add-psy" but it did the opposite of what you suggest, i.e. enable the adjustment which was off by default, would you even be able to tell the difference?
Any psy option shouldn't lower the quality on average. But it should lower the quality of some movies to preserve the average, assuming it improves others.

Quark.Fusion

17th August 2008, 00:54

windows uses CR LF, linux uses LF only, and mac uses CR only
(CR = Carriage Return - 0x0D; LF = Line Feed - 0x0A)
and why are they all different? to cause us all pain and suffering!

I think it's related to early printers, when LF change line without carriage Return and carriage return without Line Feed.
http://en.wikipedia.org/wiki/Carriage_return
(You can overline wrongly typed text on typewrite with CR without LF)
On printers, teletypes, and computer terminals that were not capable of displaying graphics, the carriage return was used without moving to the next line to allow characters to be placed on top of existing characters to produce character graphics, underlines, and crossed out text.
On Mac file all text prints on same line :)

Quark.Fusion

17th August 2008, 01:17

If I made a "--add-psy" but it did the opposite of what you suggest, i.e. enable the adjustment which was off by default, would you even be able to tell the difference?
Did I understand right? PSY-RDO produces higher bitrate at CRF, so you increase CRF value to get same bitrate. With this adjustment you get lower overall quality that without it. So I will be able to tell the difference as both quality and bitrate will be different. Or you talk about comparing both to clip at same bitrate, but without PSY-RDO?
Any psy option shouldn't lower the quality on average. But it should lower the quality of some movies to preserve the average, assuming it improves others.
I think it's subjective what matter at CRF — average quality or not lower quality where user watch at it (minimum of quality). And user must have control on this.
For average you always have multipass bitrate-based mode.

P.S. sorry if my english wasn't perfect.

Avenger007

17th August 2008, 02:46

Why you care about same bitrate in quality-based mode?
Because I don't have infinite storage space.

You get better quality from psy-rd, but it depends on source.
This isn't about the source; I know I get better quality with psy-opts.

Psy-algos works by raising quality where you see it and lowering where you don't, right? But gain in bitrate from lowering quality isn't the same as loss from raising it.
And your point is...

So bitrate at CRF can go in either side, because it's source who dictates bitrate, not CRF value.
Actually, the CRF value does dictate relative bitrate.
Almost all clips I've tested show a significant increase (>25% @ CRF 22) in bitrate; I haven't been able to predict the exact increase amount.

And if you correct CRF you lowering quality somewhere and don't get same quality across clip, right?
Like I said...
Since the AQ and psy-* patches increase perceptual quality at the same bitrate when compared without them, then the increased bitrate when using CRF seems... uncalled-for.

akupenguin

17th August 2008, 03:46

Did I understand right? PSY-RDO produces higher bitrate at CRF, so you increase CRF value to get same bitrate. With this adjustment you get lower overall quality that without it. So I will be able to tell the difference as both quality and bitrate will be different. Or you talk about comparing both to clip at same bitrate, but without PSY-RDO?
Given that Dark Shikari has already posted the patch, yes you could compare it to another patch with a different effect. But suppose a different scenario: I post some implementation of psy, which you weren't allowed to look at the code of. In the interest of concreteness, lets make up some specific numbers: This hypothetical patch always increases quality-per-bitrate by exactly 10%, and doesn't change the average bitrate at any given CRF, but introduces a gaussian variation in bitrate with stddev=20%. (This doesn't make bitrate any less predictable than before; there was a certain amount of unpredictability both before and after the patch, I'm just quantifying the imperfect covariance between the two distributions). Therefore, the quality delta from enabling the option is +10+/-20%, and the probability of increasing quality on any given source is 70%. Is this outcome acceptable? Would you prefer it if I added an adjustment of +16% bitrate (i.e. a total of +16+/-20%) in order to change the quality distribution to +26+/-20% since that has a 90% chance of being better? Is 90% enough, or should I increase it more? What if I said the simplest way to implement the psy option inherently introduced the +16% bitrate bias and I offered to subtract 16% to bring average bitrate back to +0? Does it matter whether the psy option defaults to on or off, since the variance in bitrate applies in both directions? What if the psy option is more consistent in quality than non-psy, so a perfect object metric would actually say it's the non-psy option that has the unpredictability, would you then ask for the non-psy option to have higher bitrate so that disabling psy probably wouldn't decrease quality? Do you just want --psy to include an element of --placebo to convince people that it increases quality more than it really does?
(I realize that this isn't exactly the same scenario as I posed before, since this one is "bitrate average +0%, quality net positive", rather than "quality average +0%, bitrate net negative". But as I said before, I don't care that much between those two alternatives, only the +16% bitrate/+26% quality seems obviously wrong to me.)
Whatever your answer is, either make sure it's consistent with our verdict for --aq-sensitivity (http://forum.doom9.org/showthread.php?p=1091287#post1091287), or argue against that verdict too.

Sagekilla

17th August 2008, 04:20

I was just wondering.. SAD is a commonly used metric to compare blocks to each other to find the "best" match, and from what I understand PSY-RD takes that a step further by adding in SSD to the mix. Correct me if I'm wrong here, but would it not be useful to use the SAD + SSD as a new metric, sort of like SSIM? As Dark Shikari said, our eyes like to see an image that looks similar complexity wise, even if it's not perfect, so wouldn't this be a good perceptual metric on that basis?

Apologies if SSIM already does something like this or if I'm a bit naive in my views, but I thought I'd pose the question :)

Dark Shikari

17th August 2008, 04:35

I was just wondering.. SAD is a commonly used metric to compare blocks to each other to find the "best" match, and from what I understand PSY-RD takes that a step further by adding in SSD to the mix.No, SSD is the standard RD metric.

SAD is used for a fast bit cost estimation, SATD for a slower one. SSD is a measure of *distortion*, which SAD and SATD aren't.

Quark.Fusion

17th August 2008, 05:59

…but introduces a gaussian variation in bitrate with stddev=20%. […] Therefore, the quality delta from enabling the option is +10+/-20%, and the probability of increasing quality on any given source is 70%. Is this outcome acceptable? […] Would you prefer it if I added an adjustment of +16% bitrate (i.e. a total of +16+/-20%) in order to change the quality distribution to +26+/-20% since that has a 90% chance of being better? Is 90% enough, or should I increase it more? What if I said the simplest way to implement the psy option inherently introduced the +16% bitrate bias and I offered to subtract 16% to bring average bitrate back to +0? […] What if the psy option is more consistent in quality than non-psy

I was thinking that CRF is better alternative to CQP as here were sayed that it's better to use CRF for quality-based encodes, now when I make another look at it — it's VBR option.
Problem in constant quantizer is that in high-motion scenes, darker areas, etc. — you can increase quant without noticeable quality loss, as you will be unable to spot difference looking at video. All that I want is constant visible quality of video, I don't care much about variance in bitrate — if that part of video requires 2x bitrate for same visible quality as other part, then ok — give it that. I don't want perceptive quality-deltas around timeline. (If I see on logo in corner, I want consistent quality around all video, not better here and lower there)
Quality-based modes is about unpredictability of the bitrate. Quality-based modes shouldn't think about bitrate, except VBV buffer. I don't care how much space one video will take on my HDD, but I care how much space all my videos will take.
If Psy-option is more consistent in quality than non-psy — then that must be enabled without questions.

Whatever your answer is, either make sure it's consistent with our verdict for --aq-sensitivity (http://forum.doom9.org/showthread.php?p=1091287#post1091287), or argue against that verdict too.
If VAQ also introduces variance in perceived quality across video for more stable bitrate, then I also against that.

Maybe I get wrong by thinking that you care about more stable bitrate in quality mode — correct me if I wrong.

Now back to difference in quality between old and new modes — if you get better quality in only specific areas of video as with film grain, then you shouldn't adjust CRF to get same bitrate as old mode (but give user option is good idea). If you change quality in all areas, somewhere better, somewhere lower — then you should do quality tests what video is more similar to old mode by quality. Not tests "I want same bitrate as before in quality-based modes".
All, who care about end size of video should do second pass or use ABR mode.

Quark.Fusion

17th August 2008, 06:20

I was re-reading your post…
What if the psy option is more consistent in quality than non-psy, so a perfect object metric would actually say it's the non-psy option that has the unpredictability, would you then ask for the non-psy option to have higher bitrate so that disabling psy probably wouldn't decrease quality?
I want more consistent quality.
As psy option is new and it's purpose is in better quality at cost of encoding speed and non-psy produces inconsistent quality, then my answers will be "I will live with unpredictability in quality or decrease of quality, if I can't afford the speed cost" and "I don't care about bitrate, only quality and how much space require all my videos together"

Avenger007

17th August 2008, 07:14

I want more consistent quality.
That's the problem... What is "consistent quality"?
Your best description would probably be the code used to determine "consistent quality", because that's what the encoder will use.

Now back to difference in quality between old and new modes — if you get better quality in only specific areas of video as with film grain, then you shouldn't adjust CRF to get same bitrate as old mode (but give user option is good idea). If you change quality in all areas, somewhere better, somewhere lower — then you should do quality tests what video is more similar to old mode by quality. Not tests "I want same bitrate as before in quality-based modes".
All, who care about end size of video should do second pass or use ABR mode.
IMO, psy-rd is almost always better than no psy-rd at the same bitrate.
So what do you think the quality will be at a higher bitrate?
Would that affect the way you use CRF when adjusting psy-rd (default, off, various strengths) to achieve your "consistent quality"?
If your answer is "yes" then you see the problem. If your answer is "no" then so be it. :cool:

Quark.Fusion

17th August 2008, 10:02

Let's take film grain as example. You get better overall quality at same bitrate, yes, and if you use bitrate mode then no problem here. But that film grain requires bits to store it and here is problem: if I specify quality for encode and codec tries to get same bitrate as without Psy-RDO it must lower quality in all other areas to make room for grain, but my decision on what CRF value to provide is based on tests when I don't see artifacts in most important areas. And what I get as result if codec changes CRF? Better quality with grain and lower quality in all other areas on which I make my decision for CRF, so codec produces not that quality was I want.
My desire with CRF when I specify Psy-RDO is to preserve more details without lowering quality of anything visible. It's OK if it require more bitrate as quality-per-bitrate is better and quality is the key. It's not the same as just increase bitrate by lowering CRF value (as gain will be less). If I want same bitrate — I run two-pass.

> So what do you think the quality will be at a higher bitrate?
It will be quality that I want from quality-based mode :)

You get lower bitrate in CRF with more refs, TESA search, CABAC, etc. But you don't change what CRF means to get same bitrate, right?

Nikos

17th August 2008, 15:16

From earlier Dark Shikari post (#513):

When trellis is on, and psy trellis is 0, the psy trellis code is never run.
When trellis is on, and psy trellis is nonzero, the psy trellis code is run.

From x264.937.modified.01.exe help:

--psy-rd Strength of psychovisual optimization ["1.0:1.0"]
RDO psyopts (requires subme>=6)
Trellis psyopts (requires trellis>=1)

-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

The conclusion:
With defaults settings --psy-rd 1.0:1.0 -trellis 0, the psy trellis don't run.

Which is the difference between:
--psy-rd 1.0:1.0 -trellis 1
and
--psy-rd 1.0:1.0 -trellis 2

wyti

17th August 2008, 16:09

the difference is that with --trellis 1 Trellis is only used on the Final Encode of a MacroBlock (and psytrellis is only run when trellis is run right ?)
and with --trellis 2 Trellis is always run (better quality at the cost of speed)

Dark Shikari

17th August 2008, 16:11

Nikos

17th August 2008, 16:40

The conclusion:
With --psy-rd 1.0:1.0 --trellis 1 psy trellis enabled only on the final encode of a MB.

With --psy-rd 1.0:1.0 --trellis 2 psy trellis enabled on all mode decisions.

With --psy-rd 1.0:0.0 --trellis 1 trellis enabled only on the final encode of a MB.

With --psy-rd 1.0:0.0 --trellis 2 trellis enabled on all mode decisions.

With --psy-rd 1.0:0.0 --trellis 0 trellis and psy trellis are disabled.

With x264.937.modified.01.exe defaults settings --psy-rd 1.0:1.0 --trellis 0 trellis and psy trellis are disabled.

Thanks

Kurtnoise

17th August 2008, 17:14

Keep in mind that the strength are not static...

we can have --psy-rd 1.0,0.800 --trellis 2 by example.

Nikos

17th August 2008, 17:40

I know that the psy trellis strength are not static, but i don't know what's the difference between --psy-rd 1.0:0.8, --psy-rd 1.0:1.0, --psy-rd 1.0:1.2.
In simple words, what's the meaning of psy trellis strength?

kemuri-_9

17th August 2008, 17:54

the strengths for psy-rd and psy trellis are currently allowed to be in the range of floats of [0,10], meaning it goes as high as a strength of 10.
(any values outside the range will be clamped to be within the range before processing)

trellis as far as i can remember has always defaulted to a default of 0, and as it has noticeable speed consequences, i infer that is why it is still default of 0 with the patch.

the patch changes the default subme from 5 to 6 to allow psy-rd to be run from the start though.

from what i've briefly browsed through the code again, it only appears once in an actual calculation:
int psy_value = h->mb.i_psy_trellis * abs(predicted_coef + unquant_abs_level * signs[i]);

this is a part of the actual psy trellis section which boils down to
ssd = (int64_t)d*d * coef_weight[i] - psy_weight * psy_value;
compared to the standard non psy trellis version
ssd = (int64_t)d*d * coef_weight[i];

so the psy trellis strength is effectively a scalar multiplier of how much to apply
/* Psy trellis: bias in favor of higher AC coefficients in the reconstructed frame. */

Quark.Fusion

17th August 2008, 21:58

correct

thank you, I was answer the same question :) It wasn't clear what psytrellis is and how it related to old trellis.

TheBashar

18th August 2008, 19:28

Am I mistaken in believing that CRF should be able to handle non-integer values?

I just completed three test encodes for a low quality TV show at CRF 27, 27.5 and 28. Surprisingly, the encodes came in at 15.1MB, 11.0MB, and 12.7MB respectively.

All three encodes were done using bob0r's x264.937.modified.01.exe with the same command line (excecpt crf obviously). The commandline was:

program --crf 27.5 --level 3.1 --keyint 1800 --ref 8 --mixed-refs --no-fast-pskip --bframes 5 --b-pyramid --b-rdo --bime --weightb --filter -2,-1 --subme 6 --trellis 2 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --me umh --threads auto --thread-input --progress --no-psnr --no-ssim --output "output" "input" --b-adapt 2

Unfortunately, I don't have the log from the 28.0 encode. Comparing the logs from the 27.0 and 27.5 two things stand out. First, while I recall that the 28.0 encode was around 1.5fps and the 27.0 encode resulted in 1.64fps the 27.5 encode was considerably faster at 2.02fps. Secondly, the consecutive b-frame statistics for the 27.0 and 27.5 encodes are substantially different.

27.0: 1.2% 5.4% 59.8% 14.4% 12.3% 6.9%
27.5: 21.7% 5.0% 49.6% 10.9% 9.0% 3.8%

I posted the question in this thread because I was using the new psy-rdo and psy-trellis.

Thanks

Sagekilla

18th August 2008, 19:36

x264 should be able to handle float values of CRF perfectly fine. I don't know why 17.5 would be smaller than both 27 and 28, but it sounds like a bug.

Shinigami-Sama

18th August 2008, 19:36

it supports anything from 0 - 10
with I think single floating point precision(so like 3 decimals?)
the fact the size came out different shows that it worked

kemuri-_9

19th August 2008, 01:47

Am I mistaken in believing that CRF should be able to handle non-integer values?

I just completed three test encodes for a low quality TV show at CRF 27, 27.5 and 28. Surprisingly, the encodes came in at 15.1MB, 11.0MB, and 12.7MB respectively.

if( h->param.rc.i_rc_method == X264_RC_CRF )
h->param.rc.i_qp_constant = h->param.rc.f_rf_constant;
the cli directly accepts floats, but this implicit float to int casting is more than likely the problem.

the code would need to be
1. more altered to accept float qp constants (rather than the current int only) (decent code editing/potential feature request?)
or
2. just strike out float precision and go to int (simpler - just a few line changes)

TheBashar

19th August 2008, 07:37

Am I mistaken in believing that CRF should be able to handle non-integer values?

I just completed three test encodes for a low quality TV show at CRF 27, 27.5 and 28. Surprisingly, the encodes came in at 15.1MB, 11.0MB, and 12.7MB respectively.

Please disregard. I was running some more tests when megui crashed with some kind of memory error. Three subsequent tests of the crf 27.5 all resulted in encodes sized between 27-28 and all within 4kb of each other. Some memory corruption must have caused the earlier anomalous result.

plane

19th August 2008, 08:00

I do not care ALL about metrics, I just disagree with you that metrics are useless.
PSNR and SSIM have been created as a tool for comparing quality. The people which created it have made many tests and in especially of SSIm compared their metrisc to Perceptual Quality which was all described in the article.
Let me give you the example. The knife is a tool used to cut things. It works pretty well in most cases but you have found that it can not cut metal and insist on that example to saying it is USELESS.

Metrics is just a tool for reference purpose no matter it is PSNR or SSIM. They are objective benchmark program and in video area, many folks really toward subjective method instead.

In the computer gaming area, many times those benchmark tools do not reveal the actual gaming experience as well. When it comes to the video side, the situation become even more complicated. I have been used x264 for more than two years, in the old day we have had enough PSNR/SSIM racing on doom9. Now it's time to improve the true quality.

I won't be surprised if there is a hardcore who said like metrics are useless. Indeed, they are useless. Ask any serious photographicer, I think 99% of em will tell you they only believe their eyes in photoshop.

tetsuo55

19th August 2008, 11:07

Yeah those synthetic benchmarks are important. They are unable to show phychovisual enhancements but that doesn't matter. (thats like faulting a benchmark of a game's FPS because it doesn't tell you if the game is fun)

Sharktooth

19th August 2008, 12:05

... once again and for all ...
metrics can be a reference for measuring inprovements in algos but dont tell the truth about quality since the human visual system is so complex it cant be even approximated by a simple mathematical model like PSNR or SSIM.

Quark.Fusion

19th August 2008, 12:38

Photoshop isn't best software from image quality PoV. It don't have lanczos/blackman resize or good color reduction and png optimization (for web).
Metrics can show something that your eyes can't, but same apply in other side. So it's better to use eyes and metrics. (If you don't see difference, then look at metric).

Edit: forget to ask — is chain-encoding good way to see difference in quality? what metric will say in that case?

Sagittaire

19th August 2008, 13:15

I won't be surprised if there is a hardcore who said like metrics are useless. Indeed, they are useless. Ask any serious photographicer, I think 99% of em will tell you they only believe their eyes in photoshop.

Well it's not useless ... but you must just use the correct threshold. With Delta at 0.2 dB you can't conclude but you can with delta at 2.0 dB. It's the same case with SSIM ...

Sharktooth

19th August 2008, 13:18

empiric deltas... no thanks...
a visual check is always needed.

Sagittaire

20th August 2008, 08:01

empiric deltas... no thanks...
a visual check is always needed.

No encoding at 45 dB will be always really better than encoding at 35 dB. A visual check is not needed here.

Sharktooth

20th August 2008, 11:10

what does it mean "better"?
...always the same dicussion... there's no best. maybe i like the blockfest more than smoothing so the 35 db (and blocky) encode may look better to me than a 40 db (and smooth) encode.
you still fail to understand quality is subjective. so, no, higher PSNR does not mean "better" qualty. maybe it's better for you but not for others.

CruNcher

20th August 2008, 17:37

No encoding at 45 dB will be always really better than encoding at 35 dB. A visual check is not needed here.

Tough it doesn't mean it's going to fall apart especialy not with high quality source as input but the golden rule is still starting with 38/39 dB use your eyes to judge @ 35 dB you can be pretty sure its gonna artifacting (tough it wont even block like Sharktooth said inloop deblocking is pretty nicely preserving that in most cases you will get other kind of artifacts like the ones you see @ joost these strange fizeled edges for example especialy in motion.
With direct spatial you gonna see more strange motion happening (backgrounds start moving with the camera) and you gonna see strange diagonal lines appearing @ block edges after movements the lower you go with the bitrate) :) also @ these bitrates --no-fast-pskip are gonna give a complete different look (perceptively more details less blur but tough heavier artifacts in motion) we are somewhere around 28 dB now (blocking ofcourse isn't possible to hide anymore too) ;).

Sharktooth

20th August 2008, 17:39

or maybe it is simply a bit colorshifed of brighter... but looks much better than the higher PSNR one...

smok3

20th August 2008, 18:46

http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/theexpress2-x1056y448.mp4
insane 2pass, 1800 kbits, using 0.6 psy-rd.

Sharktooth

20th August 2008, 19:07

since my sight is gone nutz, to facilitate the viewing i bought a projector and a huge panel so i can still appreciate some HD stuff.
well, even if it is SD i watched the trailer you posted and some other encodes that are there. they seem quite good to me for the bitrate.

hint: im sure zambelli or ben will be be delighted too...

Sagittaire

20th August 2008, 20:15

or maybe it is simply a bit colorshifed of brighter... but looks much better than the higher PSNR one...

Perhaps but codec produce never that. Codec never change artificialy brigheter, contrast or color but try simply to produce in output the same than in input. Encoding at 45 dB will be always better for visual quality than the same encoding at 35 dB. It's like that. Final Point.

I hear that for some codec developper (H264) the PSNR thresold delta is 1.5-2.0 dB even with high psy optimisation.

Sagekilla

20th August 2008, 20:48

IIRC, it's been said you can see differences (objectively, in the case of a patch that say improves P and B Frames) when the psnr difference is as much as 0.5 dB. Anything over that should be noticeable, especially if it's 35 dB vs 45 dB. In that case there would be a dramatic difference. Objectively, of course. When we throw the subjective enhancements into the mix you can't really compare the old algo to the new one.

CruNcher

20th August 2008, 23:15

What is a dramatic difference for you if stability of the picture doesn't change and only the noise/detail layer does imho there is only 1 real hard issue and that is film grain. Without FGM that will allways stay a issue in low bitrates that H.264 is very well capapble of like 720p @ 3 mbit the grain layer alone needs aprox 3 mbit so you allways endup @ 6 mbit when trying to preserve it FGM could change that so in the end you have a 3 mbit encode with 6 mbit subjective result :)

Audionut

21st August 2008, 00:01

FGM could change that so in the end you have a 3 mbit encode with 6 mbit subjective result :)

But it still wouldn't be better.

CruNcher

21st August 2008, 02:29

Not really no, tough the regraining on playback would imitate the original much better then any current grain post pro that does it randomly, and make it this way much more beliveable and it wouldn't look as flat anymore (artificial). The way psy tries to reach this is allways the same it takes bits from somewhere and adds it where you want to get the effect (at high bitrates this can work very well but the lower you go the more problematic it gets, because you want also a stable detailful experience). With FGM the decoder adds the effect directly (based on the source or film stock) and doesn't try to get it from somewhere else, it's not shifting bits it creates them :)

I guess the actuall way it works is entirely on the Decoder side (database with Film Stocks) and in the bitstream their is only a sei or something written that tells the Decoder in what Scene he has to use wich Film Stock basicly something like [gstart Vision2 500T 5218].
But im not 100% sure it could be much more complex maybe even positional data of the original grain is written into the bitstream so it also adds the exact type @ the exact location as the Source, tough this would mean they Recorded these Data before wich isn't impossible todo basicly you would use Degraining data and record it. I guess as Time is more money in Hollywood (and im not sure what overhead writing all these positional data would create wich ofcourse would lower the bitrate win again) it's just a simple Database of pre recorded Film Stocks that get applied when asked for by the Decoder.

wyti

21st August 2008, 02:33

But this is consider as post-processing and this have to be implemented in the decoders.
I doubt that you can do this in the side of the encoder.

Ranguvar

21st August 2008, 03:02

It does indeed have to be implemented in the decoder as well, and nobody's sure whether any commercial decoders support it (libavcodec/ffdshow doesn't, for now). It's both in the encoder and decoder. If x264 gets FGM, though, it will most likely be implemented in libavcodec as well.

CruNcher

21st August 2008, 03:55

Isn't Cyberlinks Decoder supporting it at least it shows the possibility being able to ? tough it's called FGT their Film Grain Technology i guess their Decoder is capable of it there are just no titles released yet that can make use of it and i guess no one would even realize if it's being used :D

smok3

21st August 2008, 14:27

bbb 720p, balanced settings, 2pass targeting 1800kbits
http://somestuff.org/flashAVC/flvplayer.php?moviename=movies/BBB-1080downsized-x1280y720.mp4

CruNcher

21st August 2008, 14:47

It stutters here i guess thats because of the shitty decoder performance (Adobe do something) i tried in tcpmpx and there it works fine no stuttering in firefox @ 2.2 Ghz DualCore, it would be so easy just enable GPU Accelleration and it would be blasting Silverlight away, tough that ofcourse wouldn't help older systems :(

kemuri-_9

21st August 2008, 15:09

it's included in Flash player 10 (currently Beta RC):
http://labs.adobe.com/technologies/flashplayer10/releasenotes.html#features_vpi

fields_g

21st August 2008, 15:09

My Merom 2.0ghz seems to handle it just fine.

CruNcher

21st August 2008, 15:15

it's included in Flash player 10 (currently Beta RC):
http://labs.adobe.com/technologies/flashplayer10/releasenotes.html#features_vpi

No Mainconcept has to get their GPU Decoding right way back in Elecard times it worked nicely but after the Mainconcept changes it suddenly stoped working, tough i guess for the Flash player it needs even a different approach as it is not going over directshows dxva :(
But wait i see August 11 a new Flash was released i have the older 10 release :) lets see

Nope not better but whats also strange about this Flash stuttering it only seems to happen in Camera Pans the intro is allready showing that when the camera pans down in the middle of the Pan it stutters shortly. Also all the other Camera Pans stutter when the Characters are moving everything is fine, but as soon as the camera starts moving it goes to stutter somewhere in the Pan (like it would stop and skip a frame and then continue) tough looking @ the cpu utilization i cant explain why this might happen everything seems fine :(. These stutters are allways @ the same times in the Pans so it doesn't seem to be caused by a priority problem either tough i gonna try to set firefox priority higher and see what happens (no effect).
I only remember something similia in another context with X264 and that is low bitrate and the use of --direct spatial tough --direct auto should be fine --direct temporal perfect but it looks a little different then this stuttering here (i called the other effect pan wobling) .

Pan wobling in low bitrate looks like this tough the one here is different it's more like short stop and go
http://mirror05.x264.nl/CruNcher/force.php?file=./direct-spatial-extreme-wobling.mkv
http://mirror05.x264.nl/CruNcher/force.php?file=./direct-auto-less-wobling.mkv
http://mirror05.x264.nl/CruNcher/force.php?file=./direct-temporal-stable.mkv

No Problems outside of firefox and flash via MPC-HC either (Mainconcept Decoder,ffdshow) with it i give up :( (no idear where these stuttering in the Paning come from seems tough im the only one experience this currently)

smok3

21st August 2008, 16:31

is there a way to check if core plugin is installed? so i can offer that in priority to flash.

edit: the only difference with other encodes is that audio is 6ch aac sbr, which can take some additional cpu, and that i didn't bother to use -hint option with mp4box...

CruNcher

21st August 2008, 17:09

@smoke3
http://s3.directupload.net/file/d/1528/uygfquhf_png.htm <- it seems the problem is entirely on my side this kernel time looks suspicous could be a driver problem that Flash doesn't seem to like much, maybe it's even coming from the new Nvidia drivers or in the worst case from the Flash Plugin.
No no Driver Problem -> http://s7.directupload.net/images/080821/norooi7q.png

After restarting Firefox it's much better now with the 37 tabs here (with flash runining in some of them no video) seems to be a extreme test for Firefox and Flash :)
Opera seems todo better under these extreme conditions here under Windows

Runnin Big Buck 720p in the last tab (tab count 37)

Firefox 3.0.1
http://s1.directupload.net/images/080821/4fh3qh7k.png
Opera 9.52
http://s8.directupload.net/images/080821/8jfj8mfs.png

is there a way to check if core plugin is installed? so i can offer that in priority to flash.

edit: the only difference with other encodes is that audio is 6ch aac sbr, which can take some additional cpu, and that i didn't bother to use -hint option with mp4box...
Sorry dunno how todo that, there is not much information about it still as the successor CorePlayerX was in the makeing i dunno what happened with it maybe they gave up on it seeing flash coming shortly after them with support.

smok3

21st August 2008, 20:20

testing the playback on the other machine (opteron) i get almost 100% fluid playback, very slight strobe at the opening pan-down and very slight jumps here and there (occasional tearing as well, very slight and only when buffering is very close to playback head).

jefrey

22nd August 2008, 20:38

Hi guys i have a currious problem with the new builds and trellis psytrellis, i've reencoded a bunch of blurays and some of them, two at the moment have encode errors.
For about 2-3 seconds, it looks like the enocoder have used tooo low bitrate and i see huuuge blurred macro blocks on an action szene or a marvel flipbook, they are very very huge, but just for 2-3 seconds in the whole movie,

my encodes are @ ~10000kbs and i didn change anything that can increase this corrupt ~3seconds :(

what can solve this problem?

poisondeathray

22nd August 2008, 21:05

jefrey

22nd August 2008, 21:56

the settings are the same and i use always 2pass vbr
i never changed them because, never change a running system:D and the only thing i changed i activated trellis /psytrellis.

i will see tomorrow if the error is still there, i startet the encode again. Maybe dss or ffmpeg make this shit happen :(

CruNcher

22nd August 2008, 23:20

@jefrey
join http://forum.doom9.org/showthread.php?t=140326&page=3 <- seems somhow some old issue is coming back

jefrey

23rd August 2008, 22:29

yes it looks like the vbv error:(
damned

Selur

24th August 2008, 08:17

Psy RD strength is now a decimal value with default 1.0.
What's the range psyrd is ment to be in 0.0-2.0?

cyberbeing

24th August 2008, 08:34

What's the range psyrd is ment to be in 0.0-2.0?

The range for psyrd/psytrellis is currently 0.0-10.0 AFAIK.

jase99

25th August 2008, 02:52

I've used PSYRDO 0.6 for several builds but with the latest git (948) it won't apply. I've looked trhough the source and can't figure out whats wrong. Has anyone got a version of 0.6 that applies to 948 or is there a specific build I should stick with when using PSYRDO 0.6?

% git apply -v < ../PSYRDO0.6.diff
Checking patch common/common.c...
Checking patch common/common.h...
Checking patch common/dct.h...
Checking patch encoder/analyse.c...
Checking patch encoder/encoder.c...
Checking patch encoder/macroblock.c...
error: while searching for:
h->dctf.sub8x8_dct8( dct8x8, p_src, p_dst );

if( h->mb.b_trellis )
x264_quant_8x8_trellis( h, dct8x8, CQM_8IY, i_qscale, 1 );
else
h->quantf.quant_8x8( dct8x8, h->quant8_mf[CQM_8IY][i_qscale], h->quant8_b
error: patch failed: encoder/macroblock.c:121
error: encoder/macroblock.c: patch does not apply
Checking patch encoder/macroblock.h...
Checking patch encoder/rdo.c...
error: while searching for:

#define COPY_CABAC h->mc.memcpy_aligned( &cabac_tmp.f8_bits_encoded, &h->cabac.f8_bits_encoded, \
sizeof(x264_cabac_t) - offsetof(x264_cabac_t,f8_bits_encoded) )

static int ssd_mb( x264_t *h )
{
return h->pixf.ssd[PI
error: patch failed: encoder/rdo.c:50
error: encoder/rdo.c: patch does not apply
Checking patch x264.c...
Checking patch x264.h...

Ranguvar

25th August 2008, 03:02

Read the patches thread :) There were whitespace changes in the unpatched code since then. You need to patch with the -l option to ignore whitespace.

EDIT: That's for GNU patch, actually. I don't know if there's a similar parameter for git.

jase99

25th August 2008, 03:39

Thanks. "patch -p1 -l < ../PSYRDO0.6.diff" worked perfectly. There's the --whitespace option to "git apply" but I couldn't get any of it's available options (e.g., nowarn, fix, etc) to work correctly so I'll stick with "patch".

CruNcher

25th August 2008, 04:14

Btw people with Nvidia Cards and drivers (newest Physix released ones) do you also experience strange kernel peaks (allways bellow cpu peaks) @ Playback with VMR9 under Windows XP (SP3,Directx August runtime) ? (and no Kernel Peaks with VMR7) i find this rather strange tough i might open another thread about this.

Sharktooth

25th August 2008, 12:37

do it. that has nothing in common with psy rdo...

Deinorius

1st September 2008, 23:18

A little question.
Are there any builds for MacOSX with activated psy-rdo?

refulgentis

2nd September 2008, 01:13

A little question.
Are there any builds for MacOSX with activated psy-rdo?
its trivial, just git pull bla bla bla,follow the steps above for patching, ./configure, make, sudo make install. i really recommend doing it yourself, its nice to have the knowledge, its definitely made a real difference in how I do encoding on OS X to be able to.

if you can't figure it out, PM me and I can lay it out simpler, or if you really need it I'll just upload a build.

Deinorius

2nd September 2008, 08:03

It would be an interesting experience, but with less time it's difficult. ^^"
And it's not for me. I have no Mac, it's for a friend encoding videos of a convention and it would be too interesting, how these videos will gain quality with psy-rdo. I doubt he can compile.

techouse

3rd September 2008, 08:06

When will people learn how to use OS X the UNIX way? :'(

nerdpunk

3rd September 2008, 08:27

When will people learn how to use OS X the UNIX way? :'(

haha: once (quite some time ago) i was asked by a friend to compile something on his macbook... ~2 hours i spent looking where to get a working gcc from (of course i never used a mac before this time)

another thing: can we have a rediffed patch which applies to current git, dark shikari? i don't understand the changes in macroblock.c, so i fear touching it myself

kemuri-_9

3rd September 2008, 13:27

bob0r

3rd September 2008, 19:14

the r953 version that's floating around the x264 patched builds thread works on the current revision.
here it is courtesy of files.x264.nl: x264_psy_rdo_0.6_r953.diff (http://files.x264.nl/force.php?file=./x264_patches/x264_psy_rdo_0.6_r953.diff)

Remove the force.php?file=./ part, thats for video files and windows only, it may also fuck up the patch.

http://files.x264.nl/x264_patches/x264_psy_rdo_0.6_r953.diff

kemuri-_9

3rd September 2008, 19:20

well that's how it defaults to generating links for me, so no idea it had bugs like that, never had any problems with it.

Comatose

3rd September 2008, 19:26

Judging by the file name it probably just flags it as an attachment (via headers) so that your browser always tries to download it (and not open it as a video/text file, f.e.)

IgorC

16th September 2008, 07:11

Lately I didn't follow progress around x264 so I loose some statements and I'm tired to read every page. Please, I would ask for some basic information for guys who know.
I use last revision 973 from Ranguvar. Does it mean with --trellis 2 I enable psy trellis 2 because psy rdo is by default.
To start I will try basic combinations
1) psy rdo on/off
2) psy trellis on/off
4 combinations : 00, 01,11, 10

I will also ask check this cli settings for 2 passes if I don't mess something:
x264.exe --threads 3 --pass 1 --progress --stats "x264_stat.log" --qcomp 0.6 --bframes 3 --b-adapt 2 --bime --weightb --subme 7 --keyint 300 --ref 16 --trellis 2 --mixed-refs --8x8dct --partitions all --b-rdo --direct auto --b-pyramid --bitrate 800 --no-fast-pskip --me umh --merange 16 --deblock -1:-1 --psy-rd -o 3x.mp4 Ma.avs

Audionut

16th September 2008, 07:23

With the latest revision psy rdo is enabled and psy trellis is disabled by default.

The correct command line is --psy-rd 1.0:1.0 or --psy-rd 0.0:0.0 etc.

IgorC

16th September 2008, 07:27

--psy-rd 1.0:1.0 --trellis 2 - means that psy rdo and psy trellis are enabled while
--psy-rd 1.0:0.0 --trellis 2 - means that psy rdo is enabled and normal (not psy) trellis 2 is enabled

Is it correct?

Audionut

16th September 2008, 07:37

Yep. And of course subme has to be 6 or 7 for --psy-rdo.

IgorC

16th September 2008, 07:43

ok, thank you very much for quick answer.

dansus

6th November 2008, 03:09

I do a lot of motorsport encodes which contains panning shots where the car is the focus and doesnt move around in the frame too much but has a fast moving un-encodable backround which is going to blur no matter what.

Am i right in thinking that a higher psy-rdo (+1.1) will allocate resources to the source in focus at expense for backround and i can reduce AQ strength to balance this out a bit if desired?

Also, and sorry if this is ot, but is it possible allocate resources to centre of the frame, ie 80% from centre gets 90% of bits and the rest bleeds out to the edge of frame?

thanks.

Sagekilla

6th November 2008, 03:55

You can't do hotspot type encoding, where you specify regions of interest that you'd like to get the majority of bits. It's not part of x264, but x264 should naturally allocate more bits to your in focus portion of the image. The blurred background should end up look like very low frequency details that will get less bits, but not block if you use a little bit of AQ.

dansus

6th November 2008, 05:25

What do you class as a little bit?

0.5?

Sagekilla

6th November 2008, 05:34

It depends on personal preferences. I consider 0.7 good for me since 1.0 sucks up too many bits while not providing enough of a quality boost, so I would go with 0.3 or 0.4. YMMV!

mikeytown2

7th November 2008, 03:17

@dansus
this avisynth script might help you with allocating more bits to the "important parts" of the video
http://forum.doom9.org/showthread.php?t=131920

K0zi

30th November 2008, 20:12

I have recently done some tests with various psy-rd and aq strengths. Here are the screens and the commandline:

--pass 2 --sar 64:45 --bitrate 1623 --level 5.1 --stats "[...].stats" --ref 5 --mixed-refs --no-fast-pskip --bframes 4 --b-adapt 2 --b-pyramid --weightb --direct spatial --deblock -3:-3 --subme 9 --analyse all --8x8dct --trellis 2 --psy-rd x:x --aq-strength x --me esa --threads auto --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "[...].mkv" "[...].avs"

Source (http://img210.imageshack.us/img210/999/35205955eo4.png)

AQ strength 1.0
--psy-rd 1.0:1.0 (http://img10.imagehosting.gr/out.php/i343091_01AxA.png) --psy-rd 1.0:0.75 (http://img10.imagehosting.gr/out.php/i343092_01AxB.png) --psy-rd 1.0:0.5 (http://img10.imagehosting.gr/out.php/i343093_01AxC.png) --psy-rd 1.0:0.0 (http://img10.imagehosting.gr/out.php/i343094_01AxD.png) --psy-rd 0.75:0.5 (http://img10.imagehosting.gr/out.php/i343095_01AxE.png) --psy-rd 0.5:0.5 (http://img10.imagehosting.gr/out.php/i343096_01AxF.png) --psy-rd 0.5:0.25 (http://img10.imagehosting.gr/out.php/i343097_01AxG.png)

AQ strength 0.75
--psy-rd 1.0:1.0 (http://img10.imagehosting.gr/out.php/i343098_01BxA.png) --psy-rd 1.0:0.75 (http://img10.imagehosting.gr/out.php/i343099_01BxB.png) --psy-rd 1.0:0.5 (http://img10.imagehosting.gr/out.php/i343100_01BxC.png) --psy-rd 1.0:0.0 (http://img10.imagehosting.gr/out.php/i343101_01BxD.png) --psy-rd 0.75:0.5 (http://img10.imagehosting.gr/out.php/i343102_01BxE.png) --psy-rd 0.5:0.5 (http://img10.imagehosting.gr/out.php/i343103_01BxF.png) --psy-rd 0.5:0.25 (http://img10.imagehosting.gr/out.php/i343104_01BxG.png)

AQ strength 0.5
--psy-rd 1.0:1.0 (http://img10.imagehosting.gr/out.php/i343105_01CxA.png) --psy-rd 1.0:0.75 (http://img10.imagehosting.gr/out.php/i343106_01CxB.png) --psy-rd 1.0:0.5 (http://img10.imagehosting.gr/out.php/i343107_01CxC.png) --psy-rd 1.0:0.0 (http://img10.imagehosting.gr/out.php/i343108_01CxD.png) --psy-rd 0.75:0.5 (http://img10.imagehosting.gr/out.php/i343109_01CxE.png) --psy-rd 0.5:0.5 (http://img10.imagehosting.gr/out.php/i343110_01CxF.png) --psy-rd 0.5:0.25 (http://img10.imagehosting.gr/out.php/i343111_01CxG.png)

And then I realized I don't understand how it works :rolleyes:
I can't find any post or guideline here that explains how to use these new options, and therefore, I'd like to request such an explanation :)
I mean, what are higher strengths supposed to do? Keep the source grain or add even more? :)