Hello.
source: m2ts 720x576 =>
PAR 64:45 for 16:9 DAR
PAR 16:15 for 4:3 DAR
output: XviD *.mp4 container
1. the "name" in dialog is "Pixel aspect ratio" (PAR) = e.g. 16:9(PAL) is wrong
It is not PAR. It is DAR!
2. 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). But ...
- If I use mplayer:
Movie-Aspect is 1.82:1 - prescaling to correct movie aspect.
VO: [xv] 720x576 => 1048x576 Planar YV12
- If I use avplay:
Stream #0.0(und): Video: mpeg4 (Advanced Simple Profile), yuv420p, 720x576 [PAR 16:11 DAR 20:11], 798 kb/s, 25 fps
The dialog should by corrected in x264 way
- to select/define PAR of source (source after resize filter applied) or
- to select target DAR (whatever PAR of (resized)source is)
Thanks.
P.S.: by 4:3 DAR source it is the same problem:
- mplayer:
Movie-Aspect is 1.36:1 - prescaling to correct movie aspect.
VO: [xv] 720x576 => 786x576 Planar YV12
-avplay:
Stream #0.0(und): Video: mpeg4 (Advanced Simple Profile), yuv420p, 720x576 [PAR 12:11 DAR 15:11]
I think You are not interpreting the aspect ratio in the Xvid configuration dialog correctly.
I don't have time to explain, but search in this forum and you will find the answers.
Hopefully someone else will explain!
Thanks - bud I thing I know quite a lot over aspect ratio.
And: 16:9 is 100% not PAR - as dialog says.
And: so or so - the result is wrong any ways. 1048x576 from 720x576 is definitely bad.
I see no way but agree with kapetr.
I may be wrong, but...
PAL widescreen has
64:45 PAR - Pixel Aspect Ratio - geometry of pixel
16:9 DAR - Display Aspect Ratio - geometry of screen
720:576 = 5:4 SAR - Sample Aspect Ratio - geometry of pixel set
DAR = SAR * PAR = 5:4 * 64:45 = 320:180=16:9
PAL standardcreen has
16:15 PAR - Pixel Aspect Ratio - geometry of pixel
4:3 DAR - Display Aspect Ratio - geometry of screen
720/576 SAR - Sample Aspect Ratio - geometry of pixel set
DAR = SAR * PAR = 5:4 * 16:15 = 80:60=4:3
Exactly! THX <poutnik>. (DÃÂky za podporu).
Interesting Note:
Mediainfo shows what expected - e.g. for 4:3 target DAR (by selecting "4:3(PAL)" in XviD setting):
Width : 720 pixels
Height : 576 pixels
Display aspect ratio : 4:3
Frame rate : 25.000 fps
Standard : PAL
But by playing it with e.g. mplayer ends with wrong result:
Movie-Aspect is 1.36:1 - prescaling to correct movie aspect.
VO: [xv] 720x576 => 786x576 Planar YV12
I do not see deep enough about saving aspect ratio info in container and/or video stream itself packed in it.
But all of this points to a problem in XviD (in way it's called by Avidemux).
Note that some PAL TS sources have SAR 704:576 instead of 720:576 .
For such cases is for DAR 16:9 resp 4:3 PAR = 16:11 resp 12:11.
https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_common_video_formats (https://en.wikipedia.org/wiki/Pixel_aspect_ratio#Pixel_aspect_ratios_of_common_video_formats)
Also, while for digital purposes is DAR 16:9, resp 4:3,
according to some standard specifications are DAR values slightly different.., like those 1.36....
Also, sometime there is confusion in terminology, as PAR is somewhere taken as Pixel Aspect Ratio, somewhere as Picture Aspect Ratio.
I think you found the origin of this bug in avidemux. Great !
Avidemux use older digital PAL resolution 704x576 and do not check the real SAR (which is today mostly 720x576 for PAL DVB-T/S). This causes the issue. (Maybe older codec => inherited old code.)
=> avidemux should do what I wrote:
Quote
The dialog should by corrected in x264 way
- to select/define PAR of source (source after resize filter applied) or
- to select target DAR (whatever PAR of (resized)source is)
Hopefully the developers monitor this forum to remove this bug.
(Or how/where fill Bug Report ?)
Thanks again <poutnik> ;)
Quote from: kapetr on January 19, 2015, 05:57:06 PM
Avidemux use older digital PAL resolution 704x576 and do not check the real SAR (which is today mostly 720x576 for PAL DVB-T/S). This causes the issue. (Maybe older codec => inherited old code.)
Hm, checking few todays recordings from our national DVB-T providers ( CT2, Prima ZOOM, at least 95% of my data ), I can find both 704 and 720....
Yes - specially LOW-bitrate stations use lower resolutions. I have seen 352x576 res. too (TV Fonka ? - not sure now).
Hard-encoded pop-down list for only 704x576 or 640x480(?) sources in XviD settings is really bad Idea :-\
I am assuming we are talking about the Xvid configuration dialog.
That dialog does not say PAR at all, it just references screen types by way of aspect ratios.
Use it accordingly to re-define the DAR, to match the source video PAR and SAR (Stored Aspect Ratio) to digital screen types.
And of course it does not cover all cases (but presumes you understand what is covered).
Your experiences are perfectly understandable but they are not ADM issues.
The Xvid with ADM 2.6 is only there by request (I know as I made that request!), and IMHO is only intended as usefull for transcoding from AVC.
Else, and with more control over Xvid configurations wrt to aspect ratios, go back to ADM 2.5.
Rather than yet another repeat explanation, a simple example will demonstrate:
Say you have a PAL anamorphic video (DVD) and want to recode using Xvid to give the correct DAR on your PC monitor.
The PAR of a PAL wide screen is 65:45 (the accepted median value for these virtual pixels).
To display the SAR with the correct DAR on a PC monitor you need to "recalculate" with a defined PAR of 65:45
(as opposed to nothing if you use an analog TV, because it already has a virtual PAR of 65:45).
That gives you 45/65 (horizontal compression in the SAR) * 65/45 (PAR definition) = 1:1 (PC monitor)
So select PAL(16:9) in the dialog - as that is the intended display for that source material (ie not a bug in sight!).
Furthermore, altering the PAR here is at the meta data level, and has nothing to do with resampling to various SAR's as quoted above.
Also using this approach may give inconsistent results, depending on preferential treatment in reading PAR meta data, by modern AVC capable media players.
If you want to maintain the opinion that this is an Xvid aspect bug, then this becomes another case of "back on that old road again".
I'll just bow out and happily continue to use ADM as intended.
PAL (16:9) was intended mainly for DVD.
QuoteLoRd_MuldeR on PARBTW: PAR means "Pixel Aspect Ratio", not "Display Aspect Ratio" (DAR). But you can calculate "DAR = (width / height) * PAR" easily ;)
(The good thing about working with PAR instead of DAR is that the PAR doesn't change when you crop the video)
Tip: before you play video, mark [V] Play filtered: to check your video (preview)
found at bottom, left from volume slider
Haven't tried that on the current ADM (I should DL and install the latest!).
Does preview now work with PAR meta data?
Only 11 jan 2015 is available in win64, that option should be present. , 17 jan 2015 not yet. Guess mean forgot to fire up the build bot ;)
I don't use PAR, DAR, SAR: not all hardware players look at those parameters: some samsung devices are very bad at playing videos correctly.
Stuff played correctly in VLC, appears wrong. Only happens with 576i 16:9. These need re-sizing & re-encoding to show correctly. Lucky SD recordings have dropped here, most recording is now done in HD (720p or 1080i) those issues are not present in these formats.
@ Jan,
So true, and why I keep saying that setting meta data to define aspect ratios may not work out as expected across different media players.
It used to be fine in the days when transcoding Mpeg2 to Xvid was popular.
I am assuming the OP is transcoding Mpeg2 to Xvid and couldn't reconcile the intention of that configuration dialog (so it must be a bug!).
Question is why use ADM 2.6 instead of the better featured ADM 2.5 for this purpose?
Isn't that advice already totally abundant throughout this forum!
I try to process everything in avidemux 2.6.8. On some very rare occasions 2.6.8 does not handle some older videos. Then I use 2.5.6.
Problematic video errors, if important I try re-muxing with mkvtoolnix or avconf.
If it is very important, I would try re-encode with handbrake: if no preview is shown here -> trash can.
End of story
I second that approach.
Very rarely do I bother going back to ADM 2.5 (even for recoding to Xvid).
I do still use a lot of Xvid as my standalone media player doesn't understand AVC.
(guess I am easily satisfied compared to other ADM end users!)
<aquar>:Thanks for taking time to answer, but I'm afraid you probably did not read carefully my and <poutnik> posts.
Quote from: AQUAR on January 20, 2015, 12:05:12 AM
I am assuming we are talking about the Xvid configuration dialog.
That dialog does not say PAR at all, it just references screen types by way of aspect ratios.
Sorry - you are wrong.
See attached screenshot of dialog of XvID in 2.6.8 AVD (Czech).
There is "PomÃ,,›r stran pixelu."
https://translate.google.cz/#cs/en/Pom%C4%9Br%20stran%20pixelu
== "Pixel aspect ratio" - PAR. ;)
Quote
Use it accordingly to re-define the DAR, to match the source video PAR and SAR (Stored Aspect Ratio) to digital screen types.
And of course it does not cover all cases (but presumes you understand what is covered).
Your experiences are perfectly understandable but they are not ADM issues.
Of course are they - ADM calls XviD with wrong config/params.
Quote
The Xvid with ADM 2.6 is only there by request (I know as I made that request!), and IMHO is only intended as usefull for transcoding from AVC.
Else, and with more control over Xvid configurations wrt to aspect ratios, go back to ADM 2.5.
It should be no problem to repair the dialog. To run old version is really desperate solution.
Quote
Rather than yet another repeat explanation, a simple example will demonstrate:
Say you have a PAL anamorphic video (DVD) and want to recode using Xvid to give the correct DAR on your PC monitor.
The PAR of a PAL wide screen is 65:45 (the accepted median value for these virtual pixels).
To display the SAR with the correct DAR on a PC monitor you need to "recalculate" with a defined PAR of 65:45
(as opposed to nothing if you use an analog TV, because it already has a virtual PAR of 65:45).
That gives you 45/65 (horizontal compression in the SAR) * 65/45 (PAR definition) = 1:1 (PC monitor)
So select PAL(16:9) in the dialog - as that is the intended display for that source material (ie not a bug in sight!).
Furthermore, altering the PAR here is at the meta data level, and has nothing to do with resampling to various SAR's as quoted above.
Also using this approach may give inconsistent results, depending on preferential treatment in reading PAR meta data, by modern AVC capable media players.
If you want to maintain the opinion that this is an Xvid aspect bug, then this becomes another case of "back on that old road again".
I'll just bow out and happily continue to use ADM as intended.
I have no idea what you try to explain or advocate - sorry.
Above is from me and from <poutnik> detailed explanation of how the calculation works. And the buggy result proves, that we are right.
The problem -
bug is in ADM, because erroneously assumes that PAL video has SAR=704:576. And it is in most cases NOT true.
The only item here that is questionable is the translation of "aspect ratio" (English) to "pixel aspect ratio" (Czech) inside the dialog box.
Unfortunately you never mentioned you were loading the Czech language module (I don't have a crystal ball!).
However the dialog tab still clearly states "aspect ratio".
Despite that - there is no bug - and from my perspective you are just complaining about a lack of choice in Xvid PAR settings.
In fact is it really doesn't matter if that dialog has this small translation inconsistency.
I think we sort off agree that the intent of using this feature is to add information so as to display a stretched version of "DVD type" video images on digital monitors.
ADM assumes nothing about SAR, but in that dialog it just sets PAR meta data based on a few common choices.
For PAL(16:9) the PAR figure used is 64:45 (and this in no way changes the SAR of the video!).
If these choices don't suit (as you say for 720X576 material!) then don't use them.
Instead go back to ADM 2.5 as that is geared up for these older codecs, and be gratefull that ADM lets you transcode from AVC.
To me the intermediate redefinition is 720x64/45 : 576 = 1024 : 576 = 16 : 9.
Seems correct to me and the rest (interpretation & scaling) is up to the players.
The fact that you see eg 1048 : 576 has nothing to do with ADM being buggy in setting that PAR value.
Setup, preference detection, interpretation of metadata etc etc by media players and info programs like mediainfo are giving you resampling/scaling values that seem inconsistent with your expectation. Nothing to do with ADM as it just ads the value of 64/45.
Obviously we have a different concept of expectation for this feature.
I tried, I failed to convince, and now I have no further interest in arguing about it.
Final comment:
ADM 2.5 is not an "old" version just EOL (quite different under the hood from ADM 2.6!).
Sorry <AQUAR>, bud you are trying to defend the indefensible.
You do not understand because you do not want to understand.
And you contradict to itself. If ADM would assume, that 16:9 PAL video is with PAR 64:45 (as you preaching), then I would have (in most cases) no problem. I would get for 720x576 source correct DAR 16:9 (720*64/45=1024). But ADM uses less common PAR 16:11 (720*16/11=1048).
So please - if you just want to argue, so do it elsewhere! Thanks.
Quote from: kapetr on January 21, 2015, 07:48:08 AM
So please - if you just want to argue, so do it elsewhere! Thanks.
A
little rude and offensive remark. >:(
Truth is, for DAR 16:9 is PAR 64:45 for SAR 720:576, or 16:11 for 704:576, as both SARs are common for PAL material.
576i 16:9
Resolution
- 704Ãâ€"576
- 720Ãâ€"576 (horizontal blanking cropped)
- 720Ãâ€"576 (full frame)
The pixel aspect ratio is always the same for corresponding 720 and 704 pixel resolutions because the center part of a 720 pixels wide image is equal to the corresponding 704 pixels wide image.
Source: Pixel aspect ratio (http://en.wikipedia.org/wiki/Standard-definition_television#Pixel_aspect_ratio)
Very interesting!
Does this mean, that if there is full-picture 720x576 video (no black columns on sides(704->720)) then this video should be cropped to 704x576 and only then to be "resized" by player to 1024x576 DAR (in 16:9 case) using 16:11 PAR?
I have to say, I can't believe that much. I have never seen 720x576 video (from DVB, DVD, ...) which was played by any player this way.
(But truth is - by HW player (without stdout/stderr infos) it would be difficult to recognize by eyes 1024x576 XX [1048 cropped to 1024] x 576 aspect difference between 64:45 and 16:11 PARs).
@ Jan,
Indeed all of the discussion here is just simplified wrt to presenting PAL video on a digital monitor.
@ kapetr,
ADM may well set PAR 16:11 instead of 64:45 (its whatever is correct to present actual image content from analog PAL!).
From all of the previous discussion is simply boils down to:
1: You classify this PAL(16:9) selection as an ADM 2.6 bug because it isn't giving you the PAR value you expect.
2: I disagree, advising you to use ADM 2.5 because it gives you more choices wrt PAR meta data.
Also I clearly pointed out that I don't wish to discuss it anymore because we view this issue from a different baseline.
So don't then tell me to go argue elsewhere because that is just simply an inconsiderate and rude attitude.
<aquar>:
I use encoding for digital "PAL" (DVB), not analog PAL - not sure if somewhere in the World is analog PAL anymore.
Other ... No comment.
Just one:
You did NOT say: "I don't wish to discuss it anymore ..."
You did say: "I have no further interest in arguing about it ..."
=> you was "inconsiderate and rude" first. And especially wrong. Sorry. END. POINT.
Come on, Xvid dates from the analog era and is sort of an after thought inclusion in ADM 2.6.
That is why I keep saying that I view this issue from a different baseline.
You are egging me on, and if I defend myself in response, the only result here will be that the administrator will delete this thread.
Stating that I have no further interest in arguing about this, was not rude in the first place.
It's simply an admission I failed to provide my perspective without going into detail (see reaction 1).
The fact that I picked the other PAR ratio probably didn't help the cause (I am only human).
Let me correct that: for anamorphic PAL (both analog and DV-PAL) the PAR is 1024/702 (approx 16/11).
You believe I am wrong! That's perfectly okay by me.
So how about you stop egging me on with selective symantics for the good of this thread!
To talk about
analog by transcoding from one digital format to another is little bit meaningless by itself .
Analog PAL has 625 lines (576 visible) and
no horizontal resolution defined at all. Horizontal resolution was limited by analog path from camera to CRT tube display.
I have look in D-book (describing digital DVB broadcasting). There is for SD defined:
- for DVB-T
2.7.1.1. Zdrojové kódovánàobrazu
- dle standardu ISO/IEC 13818-2
- Main Profile @ Main Level
- snÃÂmková frekvence 25 Hz
[b]- rozliÃ...¡enà720, 704, 544 a 480 (bodÃ...¯) x 576 (Ã...â,,¢ÃƒÂ¡dkÃ...¯) se zobrazenÃÂm ââ,¬Å¾full screenââ,¬Å"[/b]
- formát obrazu 4:3 a 16:9
- Indikace formátu obrazu 4:3 resp.16:9 je pÃ...â,,¢enáÃ...¡ena v elementárnÃÂm obrazovém
datovém toku v poloÃ...¾ce aspect_ratio_information v hlaviÃ,,Âce kaÃ...¾dého paketu
(sequence header).
- for DVB-T2
Zdrojové kódovánàobrazu
Podle ITU-T Recommendation H.264 / ISO / IEC 14496-10 (AVC).
2.7.2.1.1.
SDTV
- Main Profile @ Level 3
- snÃÂmková frekvence 25 Hz
- formát obrazu 4:3, 16:9
- rozliÃ...¡enà720, 704, 544, 480 (bodÃ...¯) x 576 (Ã...â,,¢ÃƒÂ¡dkÃ...¯).
That does mean, that 720, 704, 544, 480 x 576 are possible resolutions for ââ,¬Å¾
full screenââ,¬Å" displaying (4:3 or 16:9).
There is nothing about cropping (or growing) to 704. All combinations are possible and every of them has its own PAR for achieving 4:3 or 16:9 DAR.
E.g. for 16:9 the PARs are - 64:45 for 720, 16:11 for 704, and so on.
That is why I'm not sure about correctness or applicability of wiki info: http://en.wikipedia.org/wiki/Standard-definition_television#Pixel_aspect_ratio
For DVD video is it similar: http://en.wikipedia.org/wiki/DVD-Video
The following formats are allowed for H.262/MPEG-2 Part 2 video:
At a display rate of 25 frames per second, interlaced (commonly used in regions with 50 Hz image scanning frequency):
720x576 pixels (same resolution as D-1)
704x576 pixels
352x576 pixels (same as the China Video Disc standard)
352x288 pixels
To assume, that for one or other DAR is used just that or other PAR
was/is/will be always wrong - for every codec (XviD, h.264, HEVC, ...).
I can just cite myself again:
Quote
The dialog should by corrected in x264 way
- to select/define PAR of source (source after resize filter applied) or
- to select target DAR (whatever PAR of (resized)source is)
Maybe should/could be the dialog same for all codecs ?
P.S.:
Note without "selective symantics": If I say "arguing", then it is "inconsiderate and rude". If ... says "arguing", then it is not. Democratic.
Quote from: kapetr on January 20, 2015, 03:59:06 PM
>8 >8
QuoteI am assuming we are talking about the Xvid configuration dialog.
That dialog does not say PAR at all, it just references screen types by way of aspect ratios.
Sorry - you are wrong.
See attached screenshot of dialog of XvID in 2.6.8 AVD (Czech).
There is "PomÃ,,›r stran pixelu."
https://translate.google.cz/#cs/en/Pom%C4%9Br%20stran%20pixelu
== "Pixel aspect ratio" - PAR. ;)
as pointed out by AQUAR the Czech translation is incorrect: this is what the original shows in Avidemux 2.6.8 (English not translated):
Quote from: kapetr on January 21, 2015, 01:55:17 PM
Note without "selective symantics": If I say "arguing", then it is "inconsiderate and rude". If ... says "arguing", then it is not. Democratic.
The rudeness is in the
Quoteso do it elsewhere
is the same as saying: "
Go take a hike? What is take a hike!? A rude way of
telling someone to leave.
As we are all guests on this forum: telling another guest that? ....
<Jan>: I do not speak English - so it is for me difficult to express what I want with Google translator. And it may sounds different in different languages/lands.
It is an English word for someone, who loves to argue in forums without be really interesting on the topic, without reading carefully other posts, without reacting on facts, evidences. Someone who sees only what he wants, ...
Forums are unfortunately full of such people. I am allergic to it.
I can't find out the word now. Something with fire ? But IMHO <AQUAR> seems to be near of this definition. Only what I did want was to STOP it and get back to useful things, questions, ...
And do not please forget - for everyone may be other things "inconsiderate and rude". For me was it the word "arguing" - especially from someone, who does it self IMO.
I really respect yours opinion, but I'm not convinced I did something wrong.
I hope, we can go back to merits of the case.
Thank you.
The merit of this topic relates to the fact that there is only one PAR that correctly specifies the DAR of anamorphic PAL.
By DAR we are talking about projecting the visual content in a manner that shows objects in the image in their correct display aspect.
This topic starts with the title "ADM has an Xvid aspect ratio bug".
There is no bug, ADM correctly adds meta data for projecting the correct DAR of anamorphic PAL.
People want to believe that the DAR of a PAL source must be a perfect match for a screen aspect (canvas!) of 16:9.
Logical conclusion - Yes. Correct - Yes AND No.
Lots of information do quote a PAR of 64/45 for DV-PAL (google will confirm!).
Why? because it redefines the projection of the SAR so it fits the 16:9 screen (by slighly distorting the DAR!).
Impact of fiddle - not perceptible for movies (other fiddles happen too eg, speeding up the sound for film on PAL).
But if you were a draftsman - you would get fired for using that PAR.
The only person that made a reaction on this topic and that has understood the issue of this topic is Jan.
I don't like to argue, and when I said so @kapetr told me to stop arguing and go elsewhere.
Am I peeved because of that? Yes.
Am I wrong in my perception of this issue? Leave that up to others to judge (in fact - who cares for transcoding movies!).
Is this an "aspect Xvid BUG" in ADM? Everything that disagrees with enduser expectations here seems to be presented in the form of "it is a BUG".
My approach to dealing with PAL (16:9):
Happy to apply either of the common PAR values (64/45 or 16/11) for movies I just watch and forget.
For important or profesional stuff, I keep the DAR, meaning either:
1) It fits (usually analogue PAl) (when Xvid was invented!) or
2) It needs vertical letterbox scaling or cropping (and maybe a bit of both for container compliance).
Hopefully some readers will appreciate my perception of this item.
In any case, take it or leave it, as I don't care anymore about elaborating or contributing to this topic because of the negative attitudes.
I can agree with that.
With the point ADM is not professional tool and its usage does not always follow professional ways.
Small distorsion of intended DAR are fully acceptable.
OTOH, as extreme, I cannot withstand way of my parents always watching 4:3 stuff on 16:9 screen with nice Sun ellipses and fat people.
As curiosity, I sometime apply realtime Avisynth postprocessing using warpedresize function of simpleresize plugin,
http://forum.doom9.org/showthread.php?p=1619712#post1619712 (http://forum.doom9.org/showthread.php?p=1619712#post1619712)
partically correcting aspect ratio issues at such viewing 4:3 on 16:9.
It works by nonlinear transformation of X and Y coordinates.
Effects on both axis are adjustable and independent, key is not to overkill.
Instead of massive effect of full correction for central region in single dimension, leading to unpleasant distortion,
partial and the opposite corrections in both dimensions are used and effect is fine.
Horizontally, It little shrinks central screen region, while little expands border screen regions.
At the same time...
vertically, It little expands central screen region, while little shrinks border screen regions.
So if circle of diameter 30 is now 40x30 ellipse on wide screen centre. with aspect 4:3
it will do from it e.g. ellipse 36x33, with aspect 12:11
Some widescreen TV's and a few media players had a similar, non linear strech from the centre point, function.
I've seen that avisynth function mentioned before (not used it myself!).
AFAIR it sectionalized areas of each frame and then applied Lanczos resize at various strenghts to them.
Easy introduction to using avisynth (windows PC!) with ADM is by way of Mulders AVS-Proxy_GUI.
Coupling Avisynth to Avidemux opens up some very interesting posibilities for video manipulation.
Quote from: AQUAR on January 22, 2015, 03:05:10 AM
This topic starts with the title "ADM has an Xvid aspect ratio bug".
There is no bug, ADM correctly adds meta data for projecting the correct DAR of anamorphic PAL.
..
Lots of information do quote a PAR of 64/45 for DV-PAL (google will confirm!).
Why? because it redefines the projection of the SAR so it fits the 16:9 screen (by slighly distorting the DAR!).
The target is not to fit video into 16:9 TV screen with "slighly distorting the DAR". Not!
The target is to display video in correct DAR of source - circle must looks as circle. That is correct way to display video.
=> ADM DO NOT "correctly adds meta data for projecting the correct DAR of anamorphic PAL" - while it ignores SAR and uses only one PAR for all possible SARs of 16:9 original video.
As I wrote - for DVB ("digital PAL") the SAR can be for 16:9 DAR of
original source (!) 720x576, 704x576, 544x576, 480x576.
If you thing, that is it correct to display original 16:9 DAR source transmitted in 480x576 resolution using (as you thing) "the only one correct 16:11 PAR for anamorphic PAL" - which results in video with aspect ratio 698:576 (displayed DAR),
then you have really - really very low demands on watching videos.
Circle with diameter of 30 will be displayed as ellipse 20x30. [30*698/1024]
No thanks!It is for you "slightly distorted" ... Not for me. Not for me.
Quote from: AQUAR on January 22, 2015, 08:48:25 AM
Some widescreen TV's and a few media players had a similar, non linear strech from the centre point, function.
I've seen that avisynth function mentioned before (not used it myself!).
AFAIR it sectionalized areas of each frame and then applied Lanczos resize at various strenghts to them.
That Panorama function the Doom9 the thread was about tried to achieve the effect by quantized stepwise way.
While AVS Script Function PanoramaWR/WR2, based on WarpedResize function of Simpleresize plugin does it by continous way.
Yes, Avisynth provide to ADM the whole ocean of options and possibilities.
Not sure if Av
xsynth or Vapoursynth are mature enough to be used for ADM in Linux.
@ poutnik,
Its an interesting function for sure - going to try it on a sample just to see the effect.
@ kapetr,
Obviously you are the aspect expert.
Therefore, I wish you the best of luck in convincing the ADM author to fix this BUG.
Nothing more to say!
Exactly what I did expect.
You have theory - that really is OK - you are using anchored http://en.wikipedia.org/wiki/Standard-definition_television#Pixel_aspect_ratio
from <Jan>.
Quote
Note that the actual image (be it 4:3 or 16:9) is always contained in the center 704 horizontal pixels of the digital frame, regardless of how many horizontal pixels (704 or 720) are used. In case of digital video line having 720 horizontal pixels, only the center 704 pixels contain actual 4:3 or 16:9 image, and the 8 pixel wide stripes from either side are called nominal analogue blanking for horizontal blanking and should be discarded before displaying the image.
It there would be only 720x576 and 704x576 possibilities then these theory could be maybe true. And you could be right!
720x576 16:9 video could be "correctly with 16:11 PAR" cropped to central 704 points and then displayed as 1024x576 DAR without be distorted.
Or it could be 1048x576 - but displayed also as 1024x576 (resized 720->1024) with small distortion to fit in 16:9 TV/monitor.
But the problem I have with you is, that I had many times present arguments/evidences to refute this theory (IMO):
-
the other SARs.
I would expect from you 2 possible reactions:1. explanation of how to get 704 central points from horizontal 544 or 480 points (or even 352 ! on DVD). In other worlds, how with these theory (using "the only correct 16:11 PAR") display 544x576 and 480x576 (and 352x576) with acceptable/no distortion as 16:9 original DAR video.
[to show you are right and I'm wrong]
or - if you can not, then you should be man enough to say:
2. I was wrong. This theory fails.
But unfortunately you are ignoring arguments ("Ostrich strategy" - see no evil, hear no evil), which could show you are wrong.
You have
never responded to these arguments.
Just sarcasm to say to me: "You're an idiot, to which does not make sense to explain something."
>:(
Good luck kapetr (see private message).
Aside of fact, what side is closer to truth,
rather cooperation than confrontation spirit suits to all involved parties in all discussions,
with focus to properly analyse point of view of the other side.
As they may just see the opposite side of the truth, that we at the moment cannot or do not want to see.
Realization of that may teach something all of them.
As if we had a ball, one hemisphere black, one hemisphere white,
one can say the ball is black, while the other NO,NO, the ball is white.
And both are true.
@ zakk - private message but no public contribution (I can only guess based on history!)
@ poutnik - more like a case of which shade of grey is darker when they are subjectively the same!
Only recently did we have a nice discussion that did not degenerate because of divergent opinions.
It's all in the approach of the OP in steering their thread and with respect for other opinions.
@ kapetr - I was just focussed on PAL (16:9) in my reaction - the rest of your SAR's are fluff to obfuscate.
I told you my approach - again it doesn't meet your expectation or understanding - and so the crap goes on.
Staying with PAL (16:9) in the list of Xvid configuration options.
(Configuration options whose roots are defined by the Phase Alternating Line (PAL) encoding system for analogue television)
I perfectly understand Your perception viz:
You want a PAR to fit all of SAR into (16:9) frame and KEEP DAR correct.
That flows on from the idea that a (16:9) source must be a perfect fit for (16:9) screen and therefore has to be coupled to a PAR to suit.
Already said that is a logical conclusion but its not always so (highlighted by the way these older codecs are optioned!).
Case 1:
For DV-PAL using PAR 64:45 it will fit 16:9 frame.
Point off difference is.
You maintain that the DAR will be correct.
I say its slightly altered, the DAR will be slighly off (about 2.5%).
For DVD-PAL with SAR 720/576 the actual defined "square equivalent" is 1050/576.
For important stuff, its a case of deinterlace, resample and crop (already mentioned)..
Mini explanation - - -
The PAL in the DV-PAL signifies the compatibiliy for use with PAL TV's.
The virtual PAR of PAL TV's doesn't change because of resolution changes in the SAR (again just focus on the 16:9 case!).
For digital TV's you need appropriate processing from THAT baseline (another can of worms topic!).
Case 2:
For older "analogue" SAR using PAR 16:11 it will fit 16:9 frame.
You maintain that the DAR will be correct.
I never disagreed (just got the cases back to front in one of my reactions).
Mini explanation - - -
The virtual pixel resolution was calculated based on the sweep rate and modulation capability of PAL tv's.
And only in terms of the useable visible content in such signals (no overscan, teletext etc).
Result 702 : 576 resolution described by virtual pixels with a PAR of 16:11 (approximately).
It doesn't change because DV-PAL has a SAR with more resolution (720 : 576) (ie compatibility is maintained!).
Now, I never called you an idiot and never said your approach is wrong.
I just didn't want to argue about it anymore to avoid what this thread has now turned into.
In fact, I said right at the start that I hope someone else will give a proper explanation.
Why - because this kind of argie bargie tends to develop with complicated topics that start with "Its a BUG".
And usually egged on by certain individuals.
AGAIN, we are looking at this issue from a different baseline and hence our perception of how to use this Xvid configuration option is also different.
For the record, I don't need a wiki theory link provided by Jan to anchor my perception, it was stated here before that.
Perhaps You might do well to digest that material as it is obviously also at odds with your claim.
Your argument is based on what is widely flaunted as the PAR to use for DV-PAL.
That information isn't the whole truth, so look at that if you are so pedantic about DAR perfection.
Ironically - I am fine with "that PAR" as an extra option - already said I am happy to use either for movies.
I also said Xvid is an older codec that dates back to the time period when your perception actually fits the video stuff of that time.
ADM2.6 is geared up to work properly with the current crop of codecs, just has Xvid in cutdown configurability for transcoding from AVC.
I have suggested several times that you use ADM2.5 as it is better suited to your needs in terms of these PAR fiddles.
IMHO, I don't think the developer is going to bother with providing options on older codecs that represents such sudo updates (in X264 style) as you are asking for. It is fine the way it is and is for the last time NOT A BUG.
Finally (sigh!) DVB is digital broadcasting and nothing to do with PAL encoded broadcasting.
The mechanism for achieving 16:9 aspect from whatever SAR is achieved by scaling (again not interested in that tangent).
So! - one more insult from you (like the rude ostrich comparison) - and I will delete wholesale my reactions in this thread.
(if the administrator doesn't beat me to it by deleting the whole thread!)
Quote from: AQUAR on January 23, 2015, 02:34:03 AM
@ poutnik - more like a case of which shade of grey is darker when they are subjectively the same!
Only recently did we have a nice discussion that did not degenerate because of divergent opinions.
It's all in the approach of the OP in steering their thread and with respect for other opinions.
Who is without flaw, let throw a stone as the first...
It is perfectly normal to have different opinions, having different points of view and different preferences.
The key is the art to deal with it. Sometimes is enough to try to stand myself at place of the others and look at it.
@ poutnik
Tolerance is indeed a virtue.
Now, what do you do when the first stone has been thrown?
This item should really be a feature request, to add an extra option for the now popularised PAR for DV-PAL.
The Author/developers will decide that on case merit and priorities.
In the back of my mind I wonder why recoding with Xvid is used at all for DV-PAL, when X264 is more current for the all digital environment.
Only reason I can think of is playback without X264 decoding ability.
Does it mean there was found anybidy without a flaw ? But if a stone is thrown, than learning to avoid it, or going away.
Flamewars do not serve any useful purpose.
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.
Quote from: AQUAR
I was just focussed on PAL (16:9) in my reaction - the rest of your SAR's are fluff to obfuscate.
I told you my approach - again it doesn't meet your expectation or understanding - and so the crap goes on.
Everything what shows yours theory is wrong, is "fluff to obfuscate". Of course - what else to expect from you :D
It is impossible to discuss constructively with such people => this is
my last reaction on yours posts.What ever "smart" or rude you will say. END.
Quote
I perfectly understand Your perception viz:
You want a PAR to fit all of SAR into (16:9) frame and KEEP DAR correct.
That flows on from the idea that a (16:9) source must be a perfect fit for (16:9) screen and therefore has to be coupled to a PAR to suit.
Already said that is a logical conclusion but its not always so (highlighted by the way these older codecs are optioned!).
You do not understand - anything.
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 - if not, then it is
wrong (more ore less).
Only after that is cleared - it can be displayed on monitor -
and it is another story - what will player do with the information about DAR of video. But this information must be correct. If not - the final result can not be correct anyway.
The player must e.g:
- taking into account PAR of monitor (e.g. 16:9 plasmas with 1024x768 resolution)
- taking into account users prefs (zooms, not-linear possibilities , ...)
- do resizing and cropping or adding black margins ...
All other what you say is again and again BLA-BLA about fitting something somewhere.
It makes no sense to comment again.
P.S: Thanks <zakk>, I understand.
Quote from: AQUAR on January 23, 2015, 02:34:03 AM
@ zakk - private message but no public contribution (I can only guess based on history!)
You alreay know what I think of your behavior in this forum.
Quote from: poutnik on January 23, 2015, 12:07:02 PM
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.
@ kapetr
QuoteDAR 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:
Quote
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
QuoteIf 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.
Quote from: kapetr on January 23, 2015, 12:39:08 PM
Quote from: poutnik on January 23, 2015, 12:07:02 PM
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.
Quote from: poutnik on January 23, 2015, 09:51:50 PM
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.
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.
Quote from: kapetr on January 24, 2015, 12:01:37 AM
Quote from: poutnik on January 23, 2015, 09:51:50 PM
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.
<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).
Quote from: kapetr on January 26, 2015, 09:32:27 AM
<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.
Quote from: poutnik on January 26, 2015, 11:16:49 AM
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).
Quote from: kapetr on January 27, 2015, 01:06:48 PM
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.
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.
QuoteCRF 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
QuoteConstant 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.
QuoteMy 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.
QuoteI 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.
QuoteI 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.
QuoteP.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
Thanks for detailed explanations and links - will study :-)
Just by one thing I'm surprised:
QuoteAnd, 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).
Quote
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.).
QuoteQuoteAnd, 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://avisynth.nl/index.php/LimitedSharpen)
http://forum.doom9.org/showthread.php?threadid=84196 (http://forum.doom9.org/showthread.php?threadid=84196)
http://www.homecinema-hd.com/us/news/avisynth-lsfmod-315.html (http://www.homecinema-hd.com/us/news/avisynth-lsfmod-315.html)
QuoteQuoteBut 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 (http://avisynth.nl/index.php/Internal_filters)
BicubicResize / BilinearResize / BlackmanResize / GaussResize / LanczosResize / Lanczos4Resize / PointResize / SincResize / Spline16Resize / Spline36Resize / Spline64Resize
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).
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://avisynth.nl/index.php/MCTemporalDenoise)
http://forum.doom9.org/showthread.php?t=139766 (http://forum.doom9.org/showthread.php?t=139766)
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 :-)
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.
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.
In case of interest, you may find lot of X64 related information here
http://forum.doom9.org/forumdisplay.php?f=77 (http://forum.doom9.org/forumdisplay.php?f=77)
Even X264 developers participate frequently in this forum.
Interesting comment is here : http://forum.doom9.org/showthread.php?p=1703945#post1703945 (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]
@kapetr: perhaps a rename of thread should be appropriate? A more fitting header?
Quote from: poutnik on February 07, 2015, 07:28:10 AM4
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.
My goal is all time the same - to set upper limit of size. I have e.g. +- 4000kb/s mpeg2 source and
I want "invest" maximally e.g. 1200 kb/s of target ABR. The target may be smaller - but if not and I get better quality then expected = no problem. But I do not want to get e.g. 2000 kb/s or even more. It has no sense for me to transcode and get just small saving of space.
Is it now clear ?
And till now I have get no approach how to get what I want with CRF.
P.S.: thanks for anchors - will take a look
Quote from: Jan Gruuthuse on February 07, 2015, 04:33:47 PM
@kapetr: perhaps a rename of thread should be appropriate? A more fitting header?
Better to split it. Maybe some of Avidemux could see original topic to make changes to Avidemux.
But I don't know how to split. I you can - then it would by fine - I thing from Reply #45 (or #50). Thanks.
Aside of conditional de-interlacing, light filtering and resizing, my goal is similar to your one.
But I guess your goal is not just to make the size smaller, but also to keep quality above acceptable level.
ABR goes partially against your goal, as it sets not only maximum but also minimum bitrate ( putting aside Q limitation now ), ignoring quality levels.
Q limitation ignores visual quality levels as well, as it depends on video.
With near the same resolution ( 848x576 is 100.3% of 704x576 ) as original and CRF26, I get by rule of thumb usually 1/4-1/3 of original MPEG2 bitrate.
Note that some channels like CT2 have 3500-4000 kb/s , while for others like Prima ZOOM have usual bitrate even about 2500 kb/s.
For 2500 MPEG2 is 1500 H264 rather overkill.
Try for video sample a set of CRF numbers, and choose the one with optimal trade off between subjective visual quality and size.
Than keep this CRF for all your encoding.
I got for CRF26 typically 500-1400 kb/s. The question is. if your maximum target is "maximal average bitrate" or "average average bitrate" ?
In my humble opinion, the more reasonable is the latter.
The latter for CRF26 may be about 800-900 kb/s.
If I were you, I would try CRF26 as first guess. IF you get for a serie of encodings avg bitrate too low, you may increase it or vice versa.
Remember the rule of thumb CRF difference 6 make size ratio about 1 : 2
( Note that it is exponential , so CRF increment make size smaller typically by 12%)
Quote from: poutnik on February 08, 2015, 12:44:18 PM
I got for CRF26 typically 500-1400 kb/s. The question is. if your maximum target is "maximal average bitrate" or "average average bitrate" ?
In my humble opinion, the more reasonable is the latter.
The latter for CRF26 may be about 800-900 kb/s.
I thing you talk about a point I had want discuss too. I do not understand, why ADM in "encoding status windows" uses designation "average bitrate". I thing it shows ABR for a very small time interval (? 1s) - thus it would be "more true" to name it "current bitrate".
I have mean of course (using your words) "average average bitrate" - I mean ABR of whole video..
If I use e.g. ABR 1200 => the indicated bitrate is sometimes even over 3500kb/s, sometimes under 100kb/s.
Note - as I wrote - I have no problem (I'm glad), if target video has better quality. Only what I want is not to exceed selected ABR. With CRF I would get sometimes smaller files - but they would be worser.
I still thing that ABR with Q limits is simpler and safer way to reach what I want in 1-pass encoding.
You prefer constant quality - that is good thing. But you get with CRF for difficult video bigger ABR then I would accept and for simple video smaller ABR, but you pay with worse quality.
[Jinak Ã...â,,¢eÃ,,Âeno: mÃ...¯Ã...¾u sice vysledovat CRF tak, aby ABR nepÃ...â,,¢ekraÃ,,Âovalo tÃ...â,,¢eba 1200kb/s (pro videa nároÃ,,Âná na kompresi), ale pak pÃ...â,,¢i tomto CRF budu koukat (v pÃ...â,,¢ÃƒÂpadÃ,,› dobÃ...â,,¢e komprimovatelných videÃÂ) na stejnÃ,,› "zmrÃ...¡ená" videa pÃ...â,,¢i bitrate (sice jen) 400kb/s, aÃ,,Âkoli jsem byl ochoten investovat 1200kb/s a mohl tak mÃÂt kvalitu mnohem lepÃ...¡ÃÂ. A já k tomu navÃÂc pÃ...â,,¢idávám tu limitaci Q, aby nedocházelo k pouÃ...¾itànesmyslnÃ,,› nÃÂzkých Q, resp. tak vysokých, Ã...¾e by jiÃ...¾ kvalita nebyla akceptovatelná. Zejm. tÃÂm dolnÃÂm limitem pak mohu "naÃ...¡etÃ...â,,¢it" bitrate pro nároÃ,,Âné úseky - kodér je myslÃÂm dost inteligentnàa i nad rámec bufferu vÃÂ, Ã...¾e má naÃ...¡etÃ...â,,¢eno a mÃ...¯Ã...¾e tedy v pÃ...â,,¢ÃƒÂpadÃ,,› nutnosti pouÃ...¾ÃÂt vyÃ...¡Ã...¡Ã bitrate déle.]To get best for size-money is of course 2-pass encoding. But it is time expensive. The ABR+Qlimits approach is of course not as good as, but in most cases good enough (for my case of usage).
Quote from: kapetr on February 08, 2015, 07:15:09 PMI thing you talk about a point I had want discuss too. I do not understand, why ADM in "encoding status windows" uses designation "average bitrate". I thing it shows ABR for a very small time interval (? 1s) - thus it would be "more true" to name it "current bitrate".
It seems to be 1s bitrate average, what is rather useless information.
QuoteI have mean of course (using your words) "average average bitrate" - I mean ABR of whole video..
If I use e.g. ABR 1200 => the indicated bitrate is sometimes even over 3500kb/s, sometimes under 100kb/s.
No, by "average average bitrate" (AABR) I mean average bitrate of average bitrates of all videos in storage. By "maximal average bitrate" (MABR) I mean maximal acceptable average bitrate for 1 video. :-) I think your real goal is to have AABR not higher then 1500 kb/s.
CRF will you provide you for the same AABR better quality for complex videos than ABR,
while it safes bitrate on low complex videos where your eyes would not appreciate extra quality.
Another option for you is to set
bitrate variance of ABR - MeGUI name, in ADM it is called
Average bitrate tolerance on Quantizer tab of X264 settings. MeGUI has for it default value 1%, what is quite strict, good for streaming, bad for scene adaptation. I would try to use 20-40%. ADM has as default 100%, what leads me to suspicion it may have little different meaning. MeGUI hints say 0% means strict average bitrate, while 100% rathe constant quantizer.
QuoteNote - as I wrote - I have no problem (I'm glad), if target video has better quality. Only what I want is not to exceed selected ABR. With CRF I would get sometimes smaller files - but they would be worser. I still thing that ABR with Q limits is simpler and safer way to reach what I want in 1-pass encoding.
You prefer constant quality - that is good thing. But you get with CRF for difficult video bigger ABR then I would accept and for simple video smaller ABR, but you pay with worse quality.
Simple and safer way is to use ABR tolerance parameter.
I do not understand why you do not want to accept lower AABR with occational bigger MABR ? IMHO it is good business. Do you say you prefer accepting rather bad quality but not crossing your target ? CRF will give you better quality with the same AABR. You scarify quality of complex videos to waste it on simple videos where you will not notice it.
Hm, pokud Ti vyhovuje kvalita bitrate 1500 kb pro narocna videa, vyhovuje Ti kvalita i CRF26, u kterehoz jsem mel max 1450. A pokud Ti vyhovuje tato kvalita pri CRF26 u narocnych videi, vyhovuje Ti take u jednoduchych, kde Ti staci treba jen 500. A kdyz to zvednes treba na CRF24, budes mit treba 600-1800, s prumerem treba 1100-1200,
s kvalitou vyssi nez s ABR a AABR nizsi nez s ABR--EN version of above-
If quality of bitrate 1500 for xomplex video is acceptable for you, is acceptable even CRF26, where are observed maximum 1450. ( Note that with the same bitrate CRF mode provide always better quality than ABR ). And if the quality is acceptable for complex vide, is acceptable for simple video as well, where 500 is sufficient. And if you raise quality to CRF24, you will get estimated bitrate variability 600-1800, wit average about 1100-1200. With quality better than with ABR and with A-ABR smaller than with ABR.--------
QuoteTo get best for size-money is of course 2-pass encoding. But it is time expensive. The ABR+Qlimits approach is of course not as good as, but in most cases good enough (for my case of usage).
CRF gives the same best for the size as the 2-pass ABR encoding, if you choose in 2pass the size of CRF encoding. But it is not the case of 1pass ABR. 1pass ABR rate control is worse than 2pass ABR rate control. Generally, ABR has sense only if you must fit particular size, or streaming bandwidth. ( together with VBV )
The ABR rate control buffer is relatively short for 1pass ABR. If the video complexity is more or less constant, it gives comparable results as the same size CRF or 2pass ABR. But if video complexity changes are significant and last longer than few seconds, 1pass ABR adapts quantizers to keep the bitrate. I have read somewhere 1pass ABR control rate buffer frame size = sqrt ( processed frames ). So for 60 min video it is sqrt(90000)=300, i.e. 12 s for 25 fps.
Note that the encoder does not know the total length of the movie in 1pass encoding.
As illustration of Effect of ABR with bitrate variance, here are 3 bitrate profiles:
The upper chart belongs to video encoded as CRF26, with one of the highest bitrates I noticed - 1421 bp/s
The middle chart belongs to the same video encoded as ABR 1421 bp/s at MeGUI default bitrate variance 1%.
The bottom chart belongs to the same video encoded as ABR 1421 bp/s, bit wit bitrate variance 40%.
Note that bitrate profile of the 2nd ABR is much closer to the one of CRF26.
QuoteNo, by "average average bitrate" (AABR) I mean average bitrate of average bitrates of all videos in storage. By "maximal average bitrate" (MABR) I mean maximal acceptable average bitrate for 1 video. :-) I think your real goal is to have AABR not higher then 1500 kb/s.
No - My goal is AABR=MABR=1500kb/s.
(Velmi zjednoduÃ...¡enÃ,,› Ã...â,,¢eÃ,,Âeno. Videa pÃ...â,,¢ibývajÃÂ, maÃ...¾ou se, ... TakÃ...¾e kódovat s kalkulacànÃ,,›jakémo AABR pro fleÃ...¡ku je uÃ...¾ z principu nesmysl.)Quote from: poutnik on February 09, 2015, 07:51:23 AM
Hm, pokud Ti vyhovuje kvalita bitrate 1500 kb pro narocna videa, vyhovuje Ti kvalita i CRF26, u kterehoz jsem mel max 1450. A pokud Ti vyhovuje tato kvalita pri CRF26 u narocnych videi, vyhovuje Ti take u jednoduchych, kde Ti staci treba jen 500. A kdyz to zvednes treba na CRF24, budes mit treba 600-1800, s prumerem treba 1100-1200,
s kvalitou vyssi nez s ABR a AABR nizsi nez s ABR
Ne, stále mi nerozumÃÂÃ...¡ - neÃ...â,,¢ÃƒÂkám, Ã...¾e mnÃ,,› 1500kb/s u "nároÃ,,Âného" videa nÃ,,›jak extra vyhovuje. Jen je snesitelné - za cenu, jiÃ...¾ jsem ochoten zaplatit. TÃÂm pádem u "nenároÃ,,Âného" videa dostanu za investovanou Ã,,Âástku 1500kb/s lepÃ...¡Ã kvalitu, neÃ...¾ mi dá CRF - 500kb/s.
Jak jsem uvedl - náÃ...¡ pÃ...â,,¢ÃƒÂstup se liÃ...¡Ã - ty chceÃ...¡ konst. kvalitu, já konstantnàABR (pÃ...â,,¢esnÃ,,›ji Ã...â,,¢eÃ,,Âeno - konstantnàúsporu cÃÂl/zdroj).
Ne, Tvým cÃÂlem je úspora mÃÂsta, a dÃ,,›láÃ...¡ to velmi neefektivnÃÂm zpÃ...¯sobem.
Radeji vyplacas bitrate tam, kde to nepoznas, abys pak skudlil tam, kde to poznas, misto naopak.
To plati jednak pro srovnani videi mezi sebou, druhak tez v ramci jednoho videa a malou ABR bitrate variance.
Dost nelogicke.
MenÃ...¡Ã ale konstantnàúspora s velmi promÃ,,›nlivou kvalitou je podle Tebe lepÃ...¡ÃÂ
neÃ...¾ vÃ,,›tÃ...¡ÃÂ, ale variabilnàúspora s vyrovnanou a celkove lepsi kvalitou.
Na fleshku se vejde klidne 20 filmu, a tam o AABR lze mluvit docela dobre.
Takze misto 20 filmu s ABR 1500 s kvalitou velmi kolisavou se ti tam vejde s CRF24 treba 25,
s kvalitou vyrovnanou a celkove lepsi.
Tuhle jsem vcera vyrobil s CRF26 velmi pekne dokumentarni video s BR cca 550 kb/s
dokonce s doublerate 50 fps ( MeGUI QTGMC script )
---- Added EN translation for general audience --------
No. Your goal is space saving, and you do it by very ineffective way.
You prefer wasting of bitrate on places where you will not notice it, to have to save it, where you will notice it, instead of the opposite. It is valid for both comparison between videos and as well within the same video ( in case of low ABR tolerance value ). Quite illogical.
You suppose smaller, but constant space saving with very variable quality is better, than bigger, but variable space saving with balanced and overall better quality.
Flash storage can hold easily up to 20 videos, so talking A-ABR makes good sense. Instead of 20 videos with ABR1500 with very variable quality, you may fit it with about 25 videos encoded by CRF24. with balanced and overall better quality.
Just as example, yesterday I have made with CRF26 very good documentary video with bitrate about 550 kb/s, even with doublerate 50 fps via Avisynth script QTGMC ( in MeGUI ).
Why switching to Czech language? Not very polite to your host! Kindly hold your MeGUI discussions somewhere else.
I have just reacted to czech post portions, as KaPetr has obvious difficulties with English. In fact, I almost never know if I read/write in Czech or English. Original intentions was not to have it all in Czech, but once written, I have let it so.
It is not MeGUI discussion, but discussion related to optimal X264 usage in ADM. The fact I use X264 mainly in MeGUI is irrelevant, as the principles are front-end independent. QTGMC script is not MeGUI script, but Avisynth script, usable by ADM via AVS proxy, AFAIK even in Linux under Wine . I mentioned both just as a side note in X264 rate control context.
So, unless usage of ADM is to be degraded to being just a TS/H264 cutter, it is still ADM relevant.
As most of us are not fluent in Czech, even google isn't, there is no point in posting these here.
Use PM for chat in Czech.
I have added EN translation. This approach is fully accepted in most web forums in case of issues with official language.
Aside of that, AFAIK PM does not allow attachments and adds nothing for contribution to general audience.
BTW, Forums are by their nature primarily aimed to topic discussion.
For bug reports are better suited Bug Trackers, like e.g. BTMantis.
As a note for moderators, I suggest mine and KaPetr X264 rate control related posts should be moved here :
http://avidemux.org/smuf/index.php/topic,16358.0.html (http://avidemux.org/smuf/index.php/topic,16358.0.html)
Quote from: poutnik on February 15, 2015, 04:36:41 PM
You prefer wasting of bitrate on places where you will not notice it, to have to save it, where you will notice it, instead of the opposite. It is valid for both comparison between videos and as well within the same video ( in case of low ABR tolerance value ). Quite illogical.
I is not so.
Maybe for "difficult" video I could get better output with CRF resulting in target ABR 1200kb/s then with ABR 1200kb/s mode (also resulting in 1200kb/s ABR). That is probably true (even with Q limits).
But for more "simple" videos it gives to me better quality using ABR 1200kb/s then CRF resulting in target ABR 500 kb/s. And - even by simple video - by low 1200kb/s can be no word about wasting.
You have agreed with me in last post, even if you may do not know it yet.
As for redistribution of bitrate within a single video, the same principles apply as well for redistribution of bitrate between different videos.
You can consider particular videos on you flash USB stick as parts of 1 supervideo, filling all your storage.
If CRF raises its avg BR from 1200 to 1800 for 1 part and decrease to 600 for other part,
it manages at the same size constant quality as for single video,
the same noticable increase of quality in one part( compared to ABR ) as for single video
the same not noticeable decrease of quality on the other part as for single video.
It is the same as within a single video, where you have already agreed CRF would provide better quality for the same size than ABR.
This allows you for several videos together to reach even better quality with even smaller total size.