News:

--

Main Menu

XviD aspect bugs ?

Started by kapetr, January 19, 2015, 12:00:17 PM

Previous topic - Next topic

poutnik

#60
Quote from: kapetr on January 29, 2015, 04:58:10 PM
I could not expect, that you have 480p native display res - phone/tablet. Now it is clear.
But in case of bigger display res - is it as I wrote IMHO.

E.g.: 720x576 with 1000kb/s is sharper/better then 640x480 with same rate (or even bigger).

I have thought I noted it before about the target device 854x480, but it have been in other thread so you missed it.

In case of bigger resolution, it is valid what I have said about advanced resizers / sharpeners as well.
As no realtime SW/HW resizer can do the job as well as these ones - with price of bitrate.

It means, if you are going to display 720x576p  16:9 video on 1920x1080/1200 monitor, it would provide better final result, if resized e.g. by LimitedSharpenFaster script, then realtime upscaling of SW player.  But I agree it is not practical, producing big videofile and being slow.
But for exceptional material it is worthy to do, providing pseudo HD. 


To summarize - resizing may lead to video deterioration, unless combined with video improvement.
Video improvement cannot add information that is not there but artefacts, but can reveal inforfation otherwise hidden, make more appearant already visible information and suppress not wanted information.

Great example is this complex script, and Previously mentioned LimitedSharpen/LSFaster/LSFMod
http://avisynth.nl/index.php/MCTemporalDenoise
http://forum.doom9.org/showthread.php?t=139766



poutnik

#61
Quote from: kapetr on January 29, 2015, 04:58:10 PME.g.: 720x576 with 1000kb/s is sharper/better then 640x480 with same rate (or even bigger).

Only in case the used bitrate allows low enough quantizers for higher resolution. 
Otherwise quantization effects would spoil higher resolution sooner than lower one.

BTW, with CRF26 and 848x480 ( target device screen resolution mod 16), typical average bitrates are for me 500-1400 kb/s, if I calculated it well.

Philosophy of CRF is to provide bitrate needed to satisfy your expectations, but not more.

poutnik

#62
Some results of bitrate analysis for ABR vs CRF vs QP mode X264

There are analyzed bitrate profiles of 1 minute test encoding

All is originally DVB-T 704x576 MPEG2 stuff,
de-interlaced by Yadif if needed
filtered by HQ DN3D with half wrt default parameters
resized by Lanczos to 848x480 resolution of target device ( pixel rate near the same as 704x576 )

Encoded by X264 High profile, Fast preset,  film, L3.1, with ABR 1500 kb/s, and with CRF and QP
with about the same final size / avg bitrate ( as ADM in contrary to MeGUI does not allow fractional CRF/QP).

The vertical bars on charts are 1s bitrate averages .

Low details sample is advertisement.
Medium details is traveller document, JAR located, mainly family visit interior scene from a reportage, with some medium details exteriors. ( Woman at the End of the World )
High motion is mostly by bird fly camera from BBC document serie Earthflight ( SvÃ,,›t na ptaÃ,,Ã­ch kÃ...â,,¢ÃƒÂ­dlech, Prima ZOOM TV )
Low - high -low details is from the same document, cut by such a way  to have high nature details in middle, padded at start and end by advertisement.

kapetr

Great analyzer!

But IMHO the ABR and CFR looks very similar. This I thing illustrates my good experience with ABR - the coder is intelligent enough to (using big enough buffer) to get well result.

poutnik

#64
Than look better.  ABR and CRF  look very different.
CRF is more similar to QP than to ABR.

Your good experience with ABR 1500  for SD is, because it is bitrate high enough for most cases. And wasted bitrate for most cases to be good enough for the worst cases.  With CRF 26, I have bitrate 500-1400, fitting the given size by more/longer videos.  If you tried to use 500-600 kbs ABR for low detail/motion videos, as CRF 26 does,  the CRF vs ABR difference would be more obvious.

ABR acts often as One-suit-size-fits all. It steals bitrate where it is needed and wastes it where it is not needed. It is well displayed on the charts.

BTW, when you save photos as JPGs, you probably do not save them with constant size for give resolution ( some applications allows that ),
but with constant quality, leading to different sizes.   It is the same principle.

Another example is from audio - the greatest audio formats like AAC or Vorbis prefers as superior encoding mode constant quality modes to ABR.
And again, with high enough bitrate it doesnot matter hgow you have encoded it.



kapetr

In case "Na ptacich kridlech" is CRF almost the same as ABR.
In other cases is CRF between ABR and QP.

But bigger bitrates for low action parts in ABR are caused by =0 low limit of Q. That is why I add limits to Q (not 0-69, but e.g. 20-36).  It would not waste bitrate for unnecessary simple scenes & will get reserve for longer heavy scenes.

You must understand - I do not want show, that ABR is better choice for quality/size. I know - it is not. But it allows to get simply way target size without significant quality loss.   

poutnik

#66
Note that "Na ptacich kridlech" is often very blurry, without much of material quality dynamic.

By principle, some material will provide near same, and other very different bitrate profiles for ABR, CRF, and QP.
The more uniform character the sample has,  the more similar ABR, CRF  and QP will be, for the same file size.

Sure, CRF should be between ABR and QP, as constant visual subjective quality IS between ABR and CQ.

Bigger bitrates for low action parts are respecting ABR, not Q limitation.
It steals BR where needed to respect ABR, and wastes it where not needed, to respect ABR as well.

ABR and Q limitations is "Ã...¡krábání se pravou rukou za levým uchem - rubbing the left ear by the right hand.". 
It works, but why to do it ?

Do you really really need to know the final size in advance
and sacrifice balanced quality and waste bitrate for that ?

CRF26 ( others prefer their value ) is like going shopping with a bag relevant to size of the shopping.
ABR1500 is like going shoping with huge bag all the time, to be sure  shopping fits the bag.

kapetr

Quote from: poutnik on February 05, 2015, 06:39:44 PM
ABR and Q limitations is "Ã...¡krábání se pravou rukou za levým uchem - rubbing the left ear by the right hand.". 
It works, but why to do it ?

To get expected size reduction - in my case.
You wrote about CRF - size fluctuation up to 1:3. It is still too wild for me. It is difference to get 500MB or 1.5GB I thing.
I will test in future  CRF - but I do not expect it will be better for my art of usage then ABR with Q limits.
With for example (ABR 1200kb)  lowQ=22 it do not waste bitrate and with highQ=36 it do not waste quality (too much). I can see (by encoding) typically bitrates between 60kb and 3800kb. And I'm  satisfied with result.
But it does not mean that for you is not better to use CRF.

poutnik

#68
Quote from: kapetr on February 05, 2015, 07:21:57 PM

To get expected size reduction - in my case.
You wrote about CRF - size fluctuation up to 1:3. It is still too wild for me. It is difference to get 500MB or 1.5GB I thing.
I will test in future  CRF - but I do not expect it will be better for my art of usage then ABR with Q limits.
With for example (ABR 1200kb)  lowQ=22 it do not waste bitrate and with highQ=36 it do not waste quality (too much). I can see (by encoding) typically bitrates between 60kb and 3800kb. And I'm  satisfied with result.
But it does not mean that for you is not better to use CRF.

Size reduction would in using CRF instead, as it uses reasonable Q natively. :-)

As you have chosen, instead of variable size 500-1.5 GB, to have 1.5 GB all the time.
If your goal is e.g. to fit the storage with 20 hours of video, what is granted by used ABR, with CRF ofr the same visual quality the same storage would be filled by 20-60 hours of video.

kapetr

#69
If it is as you write, then it would require to do many tests to get table of values:
CRF --- max ABR. (or at least CRF --- typical ABR range).

Exists such table ? I'm afraid not.

Note - I use Q limits (what I thing you do not take into account again) => I do not get every time "1.5GB". I limit low Q => I get also lower sizes for well compressable video.


poutnik

#70
Quote from: kapetr on February 06, 2015, 04:23:58 PM
If it is as you write, then it would require to do many tests to get table of values:
CRF --- max ABR.

Exists such table ? I'm afraid not.

Note - I use Q limits (what I thing you do not take into account again) => I do not get every time "1.5GB". I limit low Q => I get also lower sizes for well compressable video.

It does not need any table. You DO know yourself that for given CRF factor the size vary as a rule of thumb 1 : 3.
If you use ABR at highest usual BRs for CRF representing quality you expect, the result is as I have said above.

Yes, I am aware you use Q limits, and I am also aware of why users are discouraged to use them.
By ABR and Q limitation you have invented very weird and inferior X264 mode  :-)




kapetr

Quote from: poutnik on February 06, 2015, 04:38:55 PM
It does not need any table. You DO know yourself that for given CRF factor the size vary as a rule of thumb 1 : 3.

I do not know it myself. To "know" does mean "to have such table". I do not have it till now. It requires to make tests or to have many experience. That is the point. If I use ABR+Q limits, I get (without experience) similar result (OK - not as good) as with CRF.

poutnik

#72
It is very different result, hidden in relatively high bitrate, forgiving your settings. If you set it for testing purposes to 1/2 or 1/3, difference between q-limited ABR and unconstrained CRF would be more obvious.

You want constant size, not constant quality, so you use ABR. But you use Q limitation. so you do not want constant size either. Your goal is not clear. 

X264 uses adaptive quantization not only between frames, but as well within a single frame. There are good reasons for X264 to use Q lower than 20 or higher than 36 on some portions of some frames.  Low detail portions of the scene may call for low Q to avoid banding artefacts. OTOH for high detail scene portions in fast move may be Q>36 good enough.

poutnik

In case of interest, you may find lot of X64 related information  here

http://forum.doom9.org/forumdisplay.php?f=77

Even X264 developers participate frequently in this forum.

poutnik

#74
Interesting comment is here  :  http://forum.doom9.org/showthread.php?p=1703945#post1703945

Quotehere's some of my personal experience
qp0 = 100% quality (mathematically lossless)
0< qp <= 8 is transparent (visually lossless, but actually lossy) to me
qp 16 is bluray like quality, some very delicate details like subpixel film grain start to fade away
qp > 18, DCT artifacts (ringing) becomes visible but not quiet obvious
qp > 21, more detail loss and compression artifacts becomes obvious (check frame by frame)
I never used qp>21 cuz that's crazy to quality freak like me]