XviD aspect bugs ?

[kapetr]

If there is list of common predefied PAR, and option to define custom one, I do not not see any problem.

XviD: I guess there are many legacy HW players refusing H264.  I still see more XviD shared records than H264 ones.

... and XviD is approximately 2 faster then h.264. For not important content (e.g. serial episode for mum  - to see and delete) is it better choice.

[AQUAR]

@ kapetr

DAR is not about "fitting" somewhere.  It is not about what the display/monitor is: 5:4, 4:3, 16:10, 16:9, 2.35:1, ...
It is there - to tell to player (SW, HW, TV, ....) which aspect radio the source video has - to circle be circle on the attached monitor.
It must be: DAR=SAR*PAR

Well we can agree on that (not that I ever said otherwise!):

Now which PAR is correct for 720 : 576 DV-PAL?
ADM uses 16/11 when you use the option PAL(16:9) - you say its a bug and should be 64/45.
I say NO! as the actual square equivalent for DV-PAL is 1050 : 576.

DV-PAL is not a reference to DVB, so many of the items you are throwing in are obfuscating the issue.

Stay on topic of the issue you presented as an Xvid aspect bug:

it is encoded wrong -
e.g. if I select "16:9(PAL)" then the target should by scaled by player to 1024x576 (DAR 16:9) from 720x576 (64:45 PAR).

My response to that (and only that!) still is:
It is not encoded - PAR is just meta data (that may not be recognised consistently).
Using 64:45 is telling the rest of the processing chain that the DAR will be 2.5% distorted.
The PAL(16:9) option is presented as it is because it dates from the analogue area.
The PAR of the PAL(16:9) option specifies the virtual pixel geometry of PAL analogue TV's.
It is not a BUG, but it needs appreciation in what it represents. 

In your responses you actually begrudgingly acknowledge some of that.

Others SAR'r are not the issue you presented by way of example of this PAL(16:9) option.
But the argument will be the same around one of the other available option's in that dialog.
These other option's again may not suit your perspective on how to use them.
Sorry, but PAl throws these curve balls, and they are difficult to convey to people with a digital only reference.   

Maybe this little brain teaser will help?
-------------------------------------------------
Lets start of with what you are comfortable with (not saying that this specification is right!).
Viz: SAR (720x576) Par (64:45) and the DAR calculation reduces to 16:9 (1024:576).
Now I only want the bottom half (just for argument sake!).
That is the SAR of the remaining pixel map is (360x576).
Tell me for this new SAR:
1) is the DAR a constant at (16:9) or the PAR a constant at (64:45)?
2) is the aim - to maintain the display aspect for objects in the new frame?
3) If object aspect ratio is the aim, does that mean the DAR stays at (16:9)?

So for far all You have done is to throw the formulae DAR=SARxPAR at me and complain about the wrong DAR result.
I am happy only when the objects in that new SAR are shown with the correct aspect ratio.

Incidentally - There is a clue in this as to why that dialog is headed aspect ratio (not DAR as you think it should be!)

-------------------------------------------------

Again no argument with media players scaling according to setup and video source definitions.
And further down the line the TV will scale accordingly to suit its screen resolution (may not be pixel mapped either).
 
In any case - all this for a tiny aspect error (which ever PAR ratio is correct!) for a quick throw away encode for Mum to watch TV episodes.
What a waste of time!

@ poutnik

If there is list of common predefied PAR, and option to define custom one, I do not not see any problem.

ADM 2.5 - will let you set custom ratios hence the referral.
ADM 2.6 - the Xvid encoding I think is not a primary feature anymore.

@ zakk
Like wise.

[poutnik]

If there is list of common predefied PAR, and option to define custom one, I do not not see any problem.

XviD: I guess there are many legacy HW players refusing H264.  I still see more XviD shared records than H264 ones.

... and XviD is approximately 2 faster then h.264. For not important content (e.g. serial episode for mum  - to see and delete) is it better choice.

Fast options of X264 are quite fast, and have better multithreading support.

e.g. X264 encoding of Full PAL MEPG2 TS ( with copied audio ) with ultrafast X264 preset
has speed about 120 fps for Core2duo E4700 (PC from 2008) at 2.6 GHz.

[kapetr]

Fast options of X264 are quite fast, and have better multithreading support.

I missed this config selection possibility completely! Thanks for this tip. Had test - and it is really fast and the quality is not bad even by ultrafast - would say +- similar to xvid in default setting.
=> will use xvid in future only for compatibility safe encodings.

[AQUAR]

Since kapetr has shifted to using X264 and maybe not interested anymore.

If you follow the teaser (in reply 46) to its logical conclusion, then we can see that PAR needs to be the constant in the equation DAR=SARxPAR.
So the DAR changes proportionally with changes in the SAR because that pixel map has pixels with a defined PAR.
The teaser therefore demonstrates that the only relevance on this case issue is - what is the correct PAR value for the PAL(16:9) aspect ratio option in the Xvid configuration dialog.

Is it (16:11) or (64:45)?
Put in terms of the DAR for these PAL frames (not an ideal way to do that!).
Should full PAL frame that has SAR of (720x576) resolve to a DAR of (16:9) or Visible PAL frame that has SAR of (702x576) resolve to  a DAR of (16:9)?

Since the OP has demonstrated the item in terms of full frame PAL (see first post or quote in reply 46),  lets stay with that.
ADM picks Visible and so the Full frame case resolves to (1048X576). ((1050x576) but 2 lines are dropped to make it divisible by 8.)
The OP wants PAR (64:45) so that Full frame resolves to (1024x576), and hence feels that the PAL(16:9) option sets the wrong PAR value.
Especially as the OP believes that Full frame PAL has become more popular these days than Visible frame PAL.

Up to the readers (if any are left!) to chase up the PAL standards and decide if this item is a BUG.

Xvid dates to the time when analogue tv's were most common screen type.
And the visible frame on these tv's for PAL systems equates back to a SAR of (702x576).

No need to mention what side of the fence I am still standing on.

Also worth mentioning is that the difference between these two common PAR values for PAL(16:9) amounts to a 2.5% distortion in the imagery. That is imperceptible, particularly so for recoding movies using Xvid.

The  "response to reply" banter throughout this thread is mostly tangent to the issue of "Xvid aspect bugs".
I am sure there are various errors and misinterpretation's that further de-focus the discussion in argueing for or against this issue.
Pity really, as this can be a great topic if there is good articulation of the concepts involved.   

Hopefully a more knowledgeable member can definitely put the issue of "Xvid aspect bugs" to bed.

I wish kapetr well in his video adventures.

[poutnik]

Fast options of X264 are quite fast, and have better multithreading support.

I missed this config selection possibility completely! Thanks for this tip. Had test - and it is really fast and the quality is not bad even by ultrafast - would say +- similar to xvid in default setting.
=> will use xvid in future only for compatibility safe encodings.

Note that major parameter affecting quality of X264 encoding is used CRF* factor or bitrate, as they define baseline of "lossyness" level.  Predefined speed profiles and eventual particular advanced settings have minor effect on quality, compared to the former. They are rather trade-off between encoding efficiency(size) versus speed.
------
For XviD, 2 pass target size/bitrate encoding is preferred way. But for X264 it is CRF mode ( constant rate factor), called also as CQ (constant quality) mode.  It is single pass mode, but for given set of parameters and final size provides visually identical / bitwise near identical result as 2 pass encoding.  The X264 2-3(!) pass encoding is to be used only, if there is really need to fit given particular size or bitrate fully.

CRF is partially similar to XviD quantizers , but has different scaling - typically in range HQ19-LQ26. In contrary to constant XviD quantizers, managing the constant "lossyness" ignoring video characteristics, CRF tries to manage constant visual quality. CRF sets stronger lossy compression for high details and/or high motion scenes and  vice versa. XviD does so in some extent only in 2 pass target size/bitrate encoding. X264 CRF is in some sense video analog to variable bitrate audio, like  average bitrate  MP3 ABR, or constant quality OGG or Nero AAC.

[kapetr]

<potnik>: Thanks. I know. But I have to say - I almost never use constant q/crf - because the target av. bitrate/size may differ too wild (according noise, movements, ... in source). I'm satisfied with setting av. bitrate (even if I know, it is not recommended).

[poutnik]

<potnik>: Thanks. I know. But I have to say - I almost never use constant q/crf - because the target av. bitrate/size may differ too wild (according noise, movements, ... in source). I'm satisfied with setting av. bitrate (even if I know, it is not recommended).

Yes, for 50 min 848x400 footage with CRF26 it is typically 200-500 MB.

But these days real size constrains are rare, compared to past, when one had to decide if it would fit 1 or 2 CDs for XviD encoding.
As target storage these days is usually internal/external HD, where are no such constains,
or SD or USB flash storage with size of gigabytes.

More useful it to keep visually near constant quality.

E.g. to do some testing what CRF is at the edge of the quality degradation not being noticable yet for final audience,
and keep such CRF for all future recordings.

As a hint, to reduce bitrate variability of CRF, one may maintain hybrid CRF vs CBR approach.
One may tune CRF upwards for encoding of mainly high detail/dynamic footage like wilderness documents,
and vice versa for mostly low detail/static-like ones like soap operas or cartoons.

As a rule of thumb, CRF higher or lower by 6 is about half/doubled size, for the same footage.

[kapetr]

But these days real size constrains are rare, compared to past, when one had to decide if it would fit 1 or 2 CDs for XviD encoding.
As target storage these days is usually internal/external HD, where are no such constains,
or SD or USB flash storage with size of gigabytes.

More useful it to keep visually near constant quality.

You are right - of course.
But in my experience as I wrote "too wild" - when I use SD DVB source (TV rip) with +- 4000kbps, then with the same Q/CFR (e.g. 28 for h.264) I will get sometimes  400kbps target bitrate and sometimes 5000kbps target bitrate. Even if the 2 sources (films, ...) do not seems to be (for my eyes) much different (in action, noise, ...).

I have 32GB flash (best size/price today) - it can be full after one saturday night recording. I use reencoding often as well to reduce size of recordings until I (or mum) have time to watch. In such situation is "safe" to use av. target bitrate better.

Note: The average target bitrate is able (using big buffer) to bridge shorter action scenes without losing quality => even with just 1-pass the quality is mostly also +- constant. But not so as with average Q-factor setting (it is not exactly constant).

[poutnik]

You are right - of course.
But in my experience as I wrote "too wild" - when I use SD DVB source (TV rip) with +- 4000kbps, then with the same Q/CFR (e.g. 28 for h.264) I will get sometimes  400kbps target bitrate and sometimes 5000kbps target bitrate. Even if the 2 sources (films, ...) do not seems to be (for my eyes) much different (in action, noise, ...).

I have 32GB flash (best size/price today) - it can be full after one saturday night recording. I use reencoding often as well to reduce size of recordings until I (or mum) have time to watch. In such situation is "safe" to use av. target bitrate better.

Note: The average target bitrate is able (using big buffer) to bridge shorter action scenes without losing quality => even with just 1-pass the quality is mostly also +- constant. But not so as with average Q-factor setting (it is not exactly constant).

I have never noticed during my 6 year experience CRF size fluctuation more than about 1 : 3.
Those up to 5000 versus 4000 of MPEG2 SD seems to me rather as a mistake in used settings.
For CRF 26, with comparable resolution ( 720x576 --> 848x480 ) and mild filtering, typical MPEG2/X264 size ration is 3 : 1, as a rule of thumb.

Q-factor and CRF-factor are 2 different things.
The former is measure of lossyness, while the latter is  measure of visual quality.
CRF dynamically change Q factor, depending on footage.

Constant bitrate is sacrifying quality for the bitrate, even if it does short-time balancing.
It gives too good quality for well compressible stuff, and to low for bad compresible stuff.

[kapetr]

My fault - I had mean fluctuation by using "constant" Q-factor. (not CRF as I wrote)
By using same Q is it no exception to get for one video 4:1 reduction and for second 2:3  growth of size.
That is why I  gave up in past using Q. I had to make test runs to +- see the target av. bitrate.

CRF dynamically change Q factor, depending on footage.

I do not know, what does that mean imagine. [Google translator: Nevím, co si pod tím pÃ...â,,¢edstavit.]
It sounds similar like a average bitrate for me.
With CRF I have minimal experience yet (We have h.264 compatible TV (player) just few months). Have to learn :-)
EDIT: e.g. http://slhck.info/articles/crf

Constant bitrate is sacrifying quality for the bitrate, even if it does short-time balancing.

I set min/max Q limits if using constant bitrate to avoid that.

P.S.: IMHO is it not good to use SW resizing to get 1:1 PAR (exept of *.avi). It is safe solution but it is bad for quality (+1 unnecessary scaling). That is why I emphasizes correct PAR/DAR on SAR setting.

[poutnik]

My fault - I had mean fluctuation by using "constant" Q-factor. (not CRF as I wrote)
By using same Q is it no exception to get for one video 4:1 reduction and for second 2:3  growth of size.
That is why I  gave up in past using Q. I had to make test runs to +- see the target av. bitrate.

but by ABR you waste bitrate on well compressible video to ensure result will be good enough for bad compressible one.

I do not know, what does that mean imagine. [Google translator: Nevím, co si pod tím pÃ...â,,¢edstavit.]
It sounds similar like a average bitrate for me.

CRF is closer to QP mode than to ABR mode.

I set min/max Q limits if using constant bitrate to avoid that.

It does not help, ABR does so by principle. Compressing less compresible video to the same bitrate DOES lead to lower visual quality. By keeping bitrate high enough you just keep worse quality good enough quality. By limiting Q you just try to make strange ABR-CRF/QP hybrid.

Try experiment with CRF to provide abpiut the same bitrate/size as ABR for your typical high detail/motion video, where used bitrate provide quality good for you. For low detail video the CRf will not waste bitrate as ABR does. By this approach CRF will provide about same or smaller size as ABR.

P.S.: IMHO is it not good to use SW resizing to get 1:1 PAR (exept of *.avi). It is safe solution but it is bad for quality (+1 unnecessary scaling). That is why I emphasizes correct PAR/DAR on SAR setting.

It very depends on scenario and can lead even to improvement of quality. if size is not the constain.
It is e.g. good but slower SW resizer, preserving contrast and edges with eliminating artefacts,
versus cheap and fast realtime postprocessing resizer of HW/SW player.

And, it definitely does make sense in case of downscaling, like 576 to 480 for my case.

--------X264 CRT mode-----------

In Czech : Vtip je v tom, ze ABR mode musi pouzit dostatecne vysoky bitrate, aby vysledek pro dane rozliseni byl prijatelny i dobre komprimovatelne video, i pro spatne komprimovatelne video, kde se to nejdrive projevi. Tento bitrate je pro dobre komprimovatelne video zbytecne vysoky, neprinasejici uz vizualni zvyseni kvality.

CRF mode pouzivajici stejne vysoky bitrate jako ABR mode pouzije pro dobre komprimovatelne video vyrazne nizsi bitrate.

Naopak, CBR, pouzivajici stejny bitrate jako CRF pro dobre komprimovatelne video, selhava v kvalite, pokusi-li se aplikovat stejny bitrate pro spatne komprimovatelne video.

Castecne reseni pri pozadavku kontroly nad vyslednou velikosti je pro stejne rozliseni pouzivat 2 ruzne hodnoty bitrate. Nizsi pro stopaz s prevazne statickymi snimky a/nebo s malo detaily a dobre filtrovane/digitalni, vyÃ...¡Ã...¡Ã­ pro dynamické a/nebo detailni a/anebo zasumÃ,,›ne.

-------------------
about CRF X264 encoding modes, see also

The easy intro to CRF  http://slhck.info/articles/crf

X264 encoding modes on MeGUI wiki
http://mewiki.project357.com/wiki/X264_Settings#Ratecontrol
http://en.wikibooks.org/wiki/MeGUI/x264_Settings

More tech details about bitrate distribution
http://git.videolan.org/?p=x264.git;a=blob_plain;f=doc/ratecontrol.txt;hb=HEAD

Both QP and CRF are de facto constant quality modes. But while the former is CQ from data point of view, the latter is from point of subjective visual point of view. CRF ( constant rate factor, constant quality ) mode lays somewhere between QP mode (constant quantizer, QP means quantizer of P frame ) and ABR ( average bitrate mode). CRF has lower variation of quantizers than ABR, and lower variantion of bitrate than QP.

CRF sets higher quantizers for frames with high detail/motion complexity, where bitrate is high and loss of quality is not easily noticed. The spent bitrate is used for lower quantizers for frames with low detail/motion complexity, that are more challenging in noticing of quality loss.
What it does for whole frames, does as as well for pixel macroblocks (16x16,16x8,8x16,8x8,8x4,4x8,4x4).
More complex parts of frame are encoded with higher quantizer than simpler ones.

With increasing scene detail/motion complexity,
    For Constant Quantizer mode QP
        visual quality increases
        bitrate increases even more
        quantizers constant

    For Constant Rate/Quality mode CRF,
        visual quality constant
        quantizers increase
        bitrate increases

    For Average Bitrate mode ABR,
        visual quality decreases
        quantizers increases more than for CRF
        bitrate is long term constant

If quality is generally above critical subjective threshold ( on chart line -.-.-.-.-.-. ),
it does not matter what mode one chooses, if quality is the concern.

But if we lower the quality ( decreasing QP, CRF factor of bitrate ), we cross the threshold and quality loss is noticed.

For CRF, it happens more or less uniformly for all material.

For QP, it happens first for simple scenes, where lowerr QP is visually needed.

For ABR, it happens first for complex scenes, where higher bitrate is needed.

As it may use Q18 for simple/static scenes, but Q34 for complex/dynamic ones.
Buffering partially levels short time fluctuations, but is helpless, concerning the the full length.

Below is low level ASCII art attempt to draw simple charts for the above, for QP vs CRF vs ABR modes.


Legend
q=quantizer, used in  constant Q mode, variable in other modes
v-visual quality-about constant in CRF mode, variable in other modes
b-bitrate-CBR, constant in CBr mode, variable in other modes.
-.-.-.  - critical limit of noticable a/o acceptable video distorsion for visual quality

Note that relations are not in proper scales

q,v,b
|
|                                           bbbbbbbbbbb
|
|                               bbbbbbbbbbbbvvvvvvvvvvv
|                               vvvvvvvvvvvv
|qqqqqqqqqqqqqqqqqqvqbvqbvqbvqbqqqqqqqqqqqqqqqqqqqqqqqq
|          vvvvvvvv
|vvvvvvvvvvbbbbbbbb-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- critical level for v
|
|bbbbbbbbbb
|
------increasing-detail-a/o-motion----------->>>>>      QP mode

q,v,b
|
|
|
|                                         
|                                   
|                                          qbqbqbqbqbqb
|                              qbqbqbqbqbqb
|vvvvvvvvvvvvvvvvvvvvvvbqvbqvbqvvvvvvvvvvvvvvvvvvvvvvvv
|-.-.-.-.-qbqbqbqbqbqb.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- critical level for v
|qbqbqbqbq                                              ( q and b grows are not the same - low resolution,
|                                                      it means q climbs wrt QP, while b climbs less than for QP)
|
|
------increasing-detail-a/o-motion----------->>>>>      CRF mode


q,v,b
|
|                                          qqqqqqqqqqqq
|
|vvvvvvvvv                     qqqqqqqqqqqq           
|         vvvvvvvvvv
|bbbbbbbbbbbbbbbbbbbvqbvqbvqbvqbbbbbbbbbbbbbbbbbbbbbbbb
|                              vvvvvvvvvvvv
|-.-.-.-.-qqqqqqqqqq.-.-.-.-.-.-.-.-.-.-.-.vvvvvvvvvvvv   critical level for v
|                           
|qqqqqqqqq                                         
|
------increasing-detail-a/o-motion----------->>>>>      ABR bitrate mode

[kapetr]

Thanks for detailed explanations and links - will study :-)

Just by one thing I'm surprised:

And, it definitely does make sense in case of downscaling, like 576 to 480 for my case.

In my experience any rescaling is harmful - especially (even little) down. It is great difference between 720x576 an (whatever)x480. The second one is significantly less sharp (even with bigger bitrate).
In my experience - for target bitrates > +- 800 kb/s it is better to preserve orig. resolution then downscale (especially vertical).

It very depends on scenario and can lead even to improvement of quality. if size is not the constain.
It is e.g. good but slower SW resizer, preserving contrast and edges with eliminating artefacts,
versus cheap and fast realtime postprocessing resizer of HW/SW player.

But at the end is "resizer of HW/SW player".
Why do you thing, it will present better picture by upscaling from 480p (which is downscaled e.g. 576p) then from original 576p ?
The better SW resize filter would make sense only by upscaling - e.g. 720x576 to 1366x768 (my native TV resol.).

[poutnik]

And, it definitely does make sense in case of downscaling, like 576 to 480 for my case.

In my experience any rescaling is harmful - especially (even little) down. It is great difference between 720x576 an (whatever)x480. The second one is significantly less sharp (even with bigger bitrate).
In my experience - for target bitrates > +- 800 kb/s it is better to preserve orig. resolution then downscale (especially vertical).

If target screen has vertical resolution 480, downscaling always happens. It is similar as downscaling of photos to be sent over internet to just view them on monitors. As monitors has rarely better resolution than 2 MPix, it does not make sense for usual viewing to send 8+ MPix photos.

Resizing itself does litle damage, but if integrated to more complex avisynth processing, it mat greatly improve image.

Advanced resizers together with complex scripts of MeGUI, or even Bicubic or Lanczos of ADM provide usually better results than usually bilinear resizers of HW/SW players..

See also
http://avisynth.nl/index.php/LimitedSharpen
http://forum.doom9.org/showthread.php?threadid=84196
http://www.homecinema-hd.com/us/news/avisynth-lsfmod-315.html

But at the end is "resizer of HW/SW player".

Why do you thing, it will present better picture by upscaling from 480p (which is downscaled e.g. 576p) then from original 576p ?
The better SW resize filter would make sense only by upscaling - e.g. 720x576 to 1366x768 (my native TV resol.).

I did not say anything about upscaling from 480p. 480p is target device vertical resolution ( 854x480 of Sony xperia M dual )
SW resizers make good sense even for downscaling, as even for downscaling more advance resizers provide better results than bilinear resizer.
Bilinear one is definitely recommended if you prefer lower bitrate with lower quality.

avisynth Internal filters
BicubicResize / BilinearResize / BlackmanResize / GaussResize / LanczosResize / Lanczos4Resize / PointResize / SincResize / Spline16Resize / Spline36Resize / Spline64Resize

[kapetr]

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