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

[Manao]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[tetsuo55]

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]

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]

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]

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]

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]

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]

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.

you don't follow me - pyramid by itself requires additional space in DPB for correct output, regardless of number of reference frames.

[Dark Shikari]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

(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]

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]

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.Images are totally useless for actually analysing why something is better; I will only look at .h264 streams. Images that aren't the same frame are more than useless, since one could be a B-frame and the other a P-frame.

[fachman]

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]

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]

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

[IgorC]

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]

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.Its called "cargo cult encoding"; choosing options because of a belief that they improve things (perhaps according to some sequence of tests done on a couple videos a long time ago) with no actual understanding of why the options help. In fact, to avoid this concept, I explicitly refuse to commit any change unless I have a reasonable theoretical explanation for why it is an improvement.

[Razorholt]

How about the --aq-mode 3 from MasterNobody?

[Dark Shikari]

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]

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]

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.

thats like saying randomly changing mpc-hc's code will make my old ISA trident 1mb videocard do dxva on 4k lossess videos...

[fachman]

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]

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]

@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]

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]

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]

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]

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]

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]

Are you sure you are comparing the same type of frames? :p