AVC (X264) stupid questions

[Hyper Shinchan]

They are stupid question and it's a stupid topic, but can anyone try to explain me:
the -trellis switch;
the no fast p skip switch (ok, it doesn't skip p frames, but why???)
the psnr calculation???
Tnx

[berrinam]

Trellis does a similar sort of quantization as it does in XviD (I have no idea how it works). The effect of that is --trellis 1 (enabled only on the final encode of a MB) produces a good PSNR improvement at small speed cost, and --trellis 2 (enabled on all mode decisions) produces a small PSNR improvement on top of that, at large speed cost. Basically, it's a good idea to keep --trellis 1 for most encodes. EDIT: bond points to the results from his tests below, which show somewhat the contrary.

--no-fast-p-skip turns off fast detection of PSKIP blocks (NOT frames). Once again, I don't know the algorithmic difference, but this makes it slightly slower, but solves the blocking in flat areas issue.

--no-psnr turns off PSNR calculations. These are purely informative, and there is no effect on quality from turning them off, but it does cause a speedup.

[foxyshadis]

They've all been explained in the x264 dev thread and in various other threads, but...

Trellis: Gives slightly better compression of data after the encoding procedure (CABAC only) by changing what information is kept. Somewhat slow.
no-fast-pskip: pskip is a code x264 uses to flag that a macroblock doesn't change at all. There are various pskip implementations; fast had a habit of detecting wrong and causing blocking in low-detail areas, though it's somewhat better now that it uses an extra check. no-fast checks every possible vector before deciding.
psnr: rough metric comparing original to encoded version.

[bond]

Originally Posted by berrinam

Trellis does a similar sort of quantization as it does in XviD (I have no idea how it works). The effect of that is --trellis 1 (enabled only on the final encode of a MB) produces a good PSNR improvement at small speed cost, and --trellis 2 (enabled on all mode decisions) produces a small PSNR improvement on top of that, at large speed cost. Basically, it's a good idea to keep --trellis 1 for most encodes.

my views on trellis:
http://forum.doom9.org/showthread.ph...643#post733643

[berrinam]

Sorry, bond, I remember reading your analysis, but all that came to mind at the time of what I wrote was the PSNR testing I had done.

[bond]

Originally Posted by berrinam

Sorry, bond, I remember reading your analysis, but all that came to mind at the time of what I wrote was the PSNR testing I had done.

no need to be sorry, its good to have varrying opinions

[Hyper Shinchan]

Thank you guys! Really useful explanations (also if ? have my doubt about trellis, for me it seems to works....).

They've all been explained in the x264 dev thread and in various other threads, but..

Actually I can check any discussion any day, unfortunatley....
tnx again!
P.S.: an explation thread would be useful, it could be included in the avc thread, but maybe it's off topic....

[Sirber]

added --no-fast-p-skip to RealAnime 4

Thanks for all the infos

[AlexB17]

Sorry for offtop - don't wanna start new thread
I want to rip Star Wars III on 2 CD's - with upscaled to 1024x432 resolution and bitrate of 1240Kbit/s, how do you think is enough bitrate for such big resolution or i need to lower it to obtain better quality?
Sorry for poor english

[Sirber]

Do you use --no-fast-p-skip? If no, you are out of topic

[nm]

I think he is definitely on topic, if you only look at the topic

Anyway, that bitrate is probably fine for most people, but a higher bitrate (or a lower resolution) might improve quality a bit. This is something you just need to decide yourself: what is good enough for your eyes.

[DarkZell666]

just a remark about treillis :

I tried several --crf 22 encodes with a couple of differing settings,
and re-did them all with treillis 1 enabled ... the filesize of the treillis version of each encode was always bigger, but I couldn't see any quality improvement (well ok it was bicubicresized 512*384 anime so It was a bit blurry, but still...).

Since someone said earlier that treillis allowed more compression of data I wanted to understand : why I could witness the opposite effect ?

A non exhaustive list of the settings I used :

CRF22, 6 bframes with bframe ratio = 1.6, RDO for Bframes and --subme 7, -minqp 20, --qcomp 0.7, CABAC enabled (obviously ), weighed biprediction, --bime, chromaQPoffset 4 ... the rest is pretty much the default settings.

Just one question :
- Should treillis be any more efficient in high/low motion scenes or does it simply not matter ?

Just trying to understand the "wierd" figures I've observed recently

[OvejaNegra]

THE SAME HAPPENS TO ME!!!
I always encode with fixed quantizer and trellis makes my files biggers.
I have the same question: IS TRELLIS REALLY USEFUL?

BTW:: using Xvid with a fixed quantizer and trellis, makes my files smallers..
a bug in x264??