[x264] More infos about --no-fast-pskip switch...

[Kurtnoise]

I just saw that the last revision (384) has a new switch. Could we have more informations about this please ?

Thank you...

[bond]

yeah would be great if devs could always write a small info about what new features do ;)

[Sharktooth]

it's for tuning and testing.
(20:59:33) pengvado|edu: and yes, no-fast-pskip is for tuning. like esa, I don't expect anyone to really use it.

[Kostarum Rex Persia]

But... can you be more precise, Sharktooth, please.

[IgorC]

well, if no-fast-skip is like esa (slow?) then nobody will use it for large videos. But test it. :)

[Kostarum Rex Persia]

@ IgorC

And,what is the point? What your tests shows?

[foxyshadis]

It's just an option to turn off the fast-pskip patch that was added to SVN a while ago. You should only use it if you believe the new patch is broken somehow (the devs likely put it there just to see what differences it leads to, to ensure there are no problems).

[Kurtnoise]

it's for tuning and testing.
ok...good to know. :)




btw, completely off-topic now : I'm building my own mp4 parser and I just discovered a real funky great thing with the x264 encodes :

http://kurtnoise.free.fr/x264_mp4head.gif
This is the beginning of a mp4 file opened with NotePad. And what did you see ? We have the x264 settings directly in the mdat atom....Very good job guys. :D

[Sharktooth]

indeed.

[bond]

x264 stores the encoding settings in the userdata sei (together with the revision that encoded the clip)

[AlexW]

It's just an option to turn off the fast-pskip patch that was added to SVN a while ago. You should only use it if you believe the new patch is broken somehow (the devs likely put it there just to see what differences it leads to, to ensure there are no problems).

No, --no-fast-pskip disables the early skip detection on P-frames that has been present in x264 since revision 1, it's purpose is to help visual quality (and maybe psnr) on those clips where fast pskip detection performs badly, like the "bluesky" clip.

[foxyshadis]

I see, I must have read it incorrectly. My apologies.

[virus]

equating --no-fast-pskip with --esa may give the wrong impression of an uber-slow option. Instead, not only disabling current fast pskip improves a lot on clips like bluesky (and at low bitrates too, I suspect), but it also isn't that slow, especially if coupled with reasonably high-quality settings.
A quick test on a couple of clips (both 1- and 2-pass) with "-8 -m 6 -b 2 -r 3" showed that enabling --no-fast-pskip is just 5-6% slower. That's for my P4 2.4 GHz at 560x304, anyway.

At constant QP, --no-fast-pskip raises the bitrate of about 1%, meaning that it makes x264 skip quite a bit less. I wonder whether the current fast-skip may be better tuned for, say, anime, and whether it could be an idea to use two separate fast-skip heuristics for anime and natural material (much in the same way XviD changes skip policy in Cartoon Mode). I just hope AlexW finds a way to improve fast skipping soon ;)

[bond]

ok i now compared the following things for the matrix clip (7116 frames, 720x288):
- nofastpskip
- fastpskip
- rdpskip
- probeskip

x264 --pass 2 --bitrate 770 --bframe 3 --b-pyramid --ref 5 --mixed-refs --filter -6:-6 --subme 6 --8x8dct --analyse all --weightb --progress -o output.mp4 input.avsspeed

- probeskip: 3.12 fps (+1.9%)
- fastpskip: 3.06 fps
- rdpskip: 2.91 fps (-5%)
- nofastpskip: 2.87 fps (-6.2%)

psnr

- nofastpskip: Avg:44.224 Global:43.934
- rdpskip: Avg:44.218 Global:43.931
- fastpskip: Avg:44.212 Global:43.924
- probeskip: Avg:44.211 Global:43.922

visual quality

matrix:

- compared to nofastpskip, fastpskip doesnt necessarily lead to really noticeable more visual blocks in walls of matrix1 (sometimes more, sometimes less), but fastpskip definitely leads to more small artefacts on walls, making the walls more "dirty" (altough walls are smooth normally). i guess it maybe leads to that artefacts of one frame are more used in following frames too?
- compared to nofastpskip, rdpskip doesnt seem to really help the walls, its maybe slightly more blocky than nofastpskip, but its hardly noticeable (it seems it doesnt have this "dirty" thing of fastpskip that much)
- compared to fastpskip, rdskip seems to be on par on the walls, its maybe slightly better but its also not really noticeable
- compared to nofastpskip, probeskip also seems to show more dirty walls (but slightly less than fastpskip). the walls are also maybe slightly more blocky (but slightly less than fastpskip), but its not that noticeable, slightly less details in highmo

-> nofastpskip is the best mode imho


i also tested bluesky:

- nofastpskip shows clearly far less blocks than fastpskip
- rdpskip shows less blocks than fastpskip
- rdskip shows slightly more blocks than nofastpskip. also rdskip makes the blocks move back and forth horizontally leading to ugly motion in the sky
- the psnr values dont show it and the speed also doesnt indicate it, but probeskip is much better than fastpskip. its also better than rdpskip, but nofastpskip is still better than probeskip (which doesnt make probeskip clearly look really bad, still its seeable)

-> nofastpskip


edit: added probeskip

[akupenguin]

I expect that the speed cost will be different at subme < 6.

[bond]

I expect that the speed cost will be different at subme < 6.nofastpskip being faster than fastpskip?

[Sharktooth]

no, the speed hit may be more consistent...

[bond]

ok i now added some findings about probeskip to my comparison above:

overall:

1) probeskip is faster than fastpskip
2) probeskip is better than fastpskip and rdskip qualitywise
3) probeskip is worse than nofastpskip qualitywise

[Sharktooth]

Another case where PSNR fails (probeskip has lower score than both rdskip and fastskip but it's visually better).
However no-fast-pskip is slow and IMHO it should not be the default coz it brings slightly better quality at a major encoding speed cost.
Like b-rdo and trellis it should be disabled by default and only enabled by user if he/she wants to get more quality at the cost of speed.