x264 development

[LigH]

In my opinion, the SAR option works wrong.

I used the following command line:

--bitrate 1000 --min-keyint 50 --ref 6 --subme 6 --bframes 3 --weightb --b-pyramid --analyse all --qpmin 1 --ratetol 4.0 --merange 64 --me umh --sar 16:9 --progress --threads 1

The result:

ffdshow 2005-07-03 reports an AR of 20/9.

mplayer 2005-06-27 reports a movie AR of 2.22:1.

All players and filters (Ateme too) resize from 720x576 to 1280x576.

[Sharktooth]

Some doom9.it users reported that problem too...
the weird thing is i made a lot of anamorphic encodes and didnt notice it.
i'll make a new encode to check.

[DeeGee]

Works fine here. At least when I use the aspect ratios told here (http://forum.doom9.org/showthread.php?t=86870).


And here are the settings you'll need for both PAL and NTSC 4:3 and 16:9 DAR (which are based on PAR): -

Required AR Custom DAR(PAR) Setting
4:3 PAL 64:60 (or 16:15)
16:9 PAL 64:45
4:3 NTSC 64:72 (or 8:9)
16:9 NTSC 64:54 (or 32:27)


I simply use those values as imputs for the --sar setting as these aspect ratios with their sar, dar and par make me dizzy :)
I'd need quite exact explanation on which means what and how to calculate them.

[LigH]

O.k. - so must be my mistake, I probably read it as "source AR" or so...

If the sample=pixel AR is used here, I'll try again with 1024:704 = 16:11 (almost IRU-R BT.601 compliant). Here I would expect a width of 720*16/11 (~ 16) = 1048 pixels.

[Manao]

LigH : your results are those expected : SAR means Sample Aspect Ratio : it's the AR of a pixel. Now, the Aspect Ratio is somethings different : it's the playback width / playback height. Since you encoded a video whose ratio width / height is 5:4, and since you set up a SAR of 16:9, you get an AR of 16:9 * 5:4 = 20:9, ie, what the playback filters are reporting.

[LigH]

Yes, must be right: 720*16/9 = 1280, and that's what I got. My mistake.

[Japhsoncross]

i did some tests for a few days on x264 and nd mp.
i captured the video from the window while i was playing the emu(emulator) 384*224(machine resolution)@30fps, and the game is Street Fighter Zero 3, i think this kind of material is absolutely clean, 'cause the background and character moves without details changing. i encoded it with both x264 v270vfw and nero recode @650kbps and 750kbps. and my decoder is ffdshow050619, and i turn the visualizations fuction of ffdshow on, with displaying the motion vectors. i found that on most occasions, nd mp's motion vectors seem more correct than x264's according to the video.

settings:
targat bitrate 750kbps
x264: no loop filter(deblock), max ref 5, minqp 1, b frame reduction 0, max 3 b-frames, use as ref, adaptive, bias 0, 8*8DCT 4*4intra, chroma me, RDO, UMH , me range 32, direct mode temporal.
nd mp, -512 - 512, 5 ref, no deblocking

see the images attached:
ND MP@750kbps
http://forum.doom9.org/attachment.php?attachmentid=4291&stc=1
x264 v270@750kbps
http://forum.doom9.org/attachment.php?attachmentid=4292&stc=1

[FredThompson]

The sources link is dead. Given it's summer break :P, would someone pease mirror these?

[superdump]

Japhsoncross: That doesn't look right at all. Something's amiss.

FredThompson: It's only really a 'summer break' because akupenguin is away. I'm fairly sure SharkTooth is still around and anyway you can find out how to get the source code on http://developers.videolan.org/x264.html .

[leowai]

Some doom9.it users reported that problem too...
the weird thing is i made a lot of anamorphic encodes and didnt notice it.
i'll make a new encode to check.
Me too. Just realise that days of conversion wasted, but we learned from mistakes. :)
O.k. - so must be my mistake, I probably read it as "source AR" or so...
Since there are confliction caused, will it be good to name the parameter as PAR (Pixel Aspect Ratio, which used in the link below) rather than SAR (Sample Aspect Ratio)? Sample also not clear enough for me. Sample = Source (i.e. original source)? Sample = Input Video source for encoding?

Works fine here. At least when I use the aspect ratios told here (http://forum.doom9.org/showthread.php?t=86870).
I simply use those values as imputs for the --sar setting as these aspect ratios with their sar, dar and par make me dizzy :)
I'd need quite exact explanation on which means what and how to calculate them.
I think following link is useful to you. It provides some information about this matter:
http://www.3ivx.com/support/par.html
Just learn that: It's NOT neccessary for the pixels a video to be sqaure (i.e. width-to-height ratio of 1:1)!

[Manao]

Japhsoncross : the picture you chose is a bframe, isn't it ? some version of ffdshow are buggy when displaying motion vectors on bframe.

Leowai : the standard calls explicitely that parameter SAR, not PAR.

[LigH]

From ISO 13818-2 (6.3.3: Sequence header), MPEG-2 does it in a similar way: Allowed aspect ratios for MPEG-2 video are

- 1:1 SAR
- 4:3 DAR
- 16:9 DAR
- 2.21 DAR

and SAR = DAR * width/height

So the same must obviously be true for MPEG-4 video.

[Manao]

> SAR = DAR * width/height

Hum, no. SAR * width / height = AR ( or DAR )

[LigH]

In this document, they use an inverted DAR. 3:4, 9:16, 1:2.21 - that's why... :rolleyes:

I hate such kind of "un-common" specification.

[Sharktooth]

The sources link is dead. Given it's summer break :P, would someone pease mirror these?
Link to the source files is fixed... (sorry, didnt notice it)

[namchik]

vfw dll was packed into CLI version (http://www.webalice.it/f.corriga/x264/X264CLI_rev272B_mmx.7z) ??

[Rash]

Yes, it was. ;)

[leowai]

Leowai : the standard calls explicitely that parameter SAR, not PAR.
Thanks for correcting my wrong concept. :)
I see the update of vfw build from sharktooh too.

@namchik,

I think the *CLI* only consists of the client executable. If you want vfw support in VirtualDub, you need to download the installer instead.
x264 VFW Revision 273: http://www.webalice.it/f.corriga/x264/X264VFW_rev273_mmx.exe

[Sharktooth]

Sorry for the inconvenience, it was a wrong copy/paste "issue" :)

[yaz]

In my opinion, the SAR option works wrong.it worx right but ... it's not sar but (custom) par.
... --sar 16:9 ... ffdshow 2005-07-03 reports an AR of 20/9.that's correct then :) (16/9)x(5/4)=(20/9) ~ 2.25:1

the bests
y

[SeeMoreDigital]

it worx right but ... it's not sar but (custom) par.
that's correct then :) (16/9)x(5/4)=(20/9) ~ 2.25:1Agreed

I think it would make more sense if it read something like... "Custom PAR" and not "Sample Aspect Ratio": -

http://img121.imageshack.us/img121/8002/x264arsettings4nr.png


Cheers

[Sharktooth]

Custom PAR is misleading.
I modified it and it's "Sample AR" now...

[bond]

SAR is pixel aspect ratio, no?

why not simply call it "Pixel AR" than?

[LigH]

Because "Pixel" and "Picture" are sooo similar sounding... :rolleyes:

This should be the reason why at least since ISO/IEC 13818-2, MPEG uses "Sample AR" and "Display AR".

[lexor]

you guys make me cry :scared: can't you just come up with a unique and precise name for every single thing, nooo you have to make life diffcult.

here is my proposition, let's erase all text in the gui's so that no one knows what option does what, obscure but FUN FUN FUN!! you never know what you gonna get :p

[SeeMoreDigital]

And here was me thinking this sort of thing had been agreed ages ago :eek:

3ivx has been using the terms PAR (for Pixel Aspect Ratio) and DAR (for Display Aspect Ratio) for ages. XviD has also been using the term "Pixel Aspect Ratio" for ages - And the term "Picture Aspect Ratio" to describe the Display Aspect Ratio... but lets not go there!

In my opinion the term PAR (Pixel Aspect Ratio) is all we need because PAR offers the greatest flexibility when it comes to altering the shape of your encodes. Including the possibility of generating encodes to either, PAL 4:3 / 16:9 DAR or NTSC 4:3 / 16:9 DAR

That said, an incorrectly shaped encode with PAR signalling can be a bit of a pain to sort out "after the event".... Which is why I feel we could really do with an tool such as MPEG4 Modifier which x264 friendly.... but that's for another thread!


Cheers

[bond]

Because "Pixel" and "Picture" are sooo similar sounding... :rolleyes:

This should be the reason why at least since ISO/IEC 13818-2, MPEG uses "Sample AR" and "Display AR".well "sample" can also mean the whole pic imho :D
i personally definitely wouldnt think of "pixel" when i read "sample"

[Manao]

Actually, i still think 'sample' is the most appropriate term. 'Sample' refers the smallest / undivisable unit of the signal, so it can't refer to the frame. And 'pixel' refers to what is shown on the screen ( meaning, after scaling ), so it would be inappropriate in that case. But that's bitching on the definition... ( /me thinks the mpeg4 guys spent at least a week in meetings just to decide that name ;) )

[708145]

well "sample" can also mean the whole pic imho :D
i personally definitely wouldnt think of "pixel" when i read "sample"

Would anyone send me a sample video please :p
SCNR.

bis besser,
Tobias

P.S.: It would be too easy if we would understand each other right away, right?

[LigH]

BTW: Did someone already mention the "texel"? :rolleyes: :D -- IMHO: "like in the specs" is okay.

[SeeMoreDigital]

As far as I'm aware SAR (Storage Aspect Ratio) refers to the pixel aspect ratio of the source as it stored digitally on electronic media, before correction...

In the case of DVD, a PAL 720x576 source, has a SAR of 1.25:1. And an NTSC 720x480 source, has a SAR of 1.50:1


Cheers

[Manao]

No

PAL 720x576 (4:3) has a SAR of 16:15
PAL 720x576 (16:9) has a SAR of 64:45
NTSC 720x480 (4:3) has a SAR of 8:9
NTSC 720x480 (16:9) has a SAR of 32:27

[LigH]

May depend on how exact you calculate: 702:{768|1024} or 704:{768|1024}. But such cancelled fractions shall be suitable as long as the differences between the ITU specs and the calculated fractions are below recognition...

[SeeMoreDigital]

No

PAL 720x576 (4:3) has a SAR of 16:15
PAL 720x576 (16:9) has a SAR of 64:45
NTSC 720x480 (4:3) has a SAR of 8:9
NTSC 720x480 (16:9) has a SAR of 32:27Errrm... as far as I'm aware....

PAL 720x576 (4:3) has a DAR of 16:15
PAL 720x576 (16:9) has a DAR of 64:45
NTSC 720x480 (4:3) has a DAR of 8:9
NTSC 720x480 (16:9) has a DAR of 32:27


Cheers

[LigH]

@ SMD:

No. 4:3 video has a DAR of 4:3, 16:9 video has a DAR of 16:9 (DAR = "Display ASpect Ratio" is the whole picture, after resizing: width:height). At least it is documented this way in the MPEG-2 specification ISO/IEC 13838 Part 2 in chapter 6.3.3.

MPEG-2 video with aspect ratio flags "DAR 4:3" or "DAR 16:9" have to be resized so that the ratio between the width and the height of the decoded frame has to become 4:3 or 16:9.

[SeeMoreDigital]

In the case of say, an PAL 16:9 anamorphic DVD...

An 720x576 (1:1) source image without correction = SAR
An 720x576 with 64:45 PAR correction = DAR


EDIT: Or as SteveG put it..........

==================================================================================
Assuming

DAR = display aspect ratio - x/y ratio of physical dimensions (e.g inches or cm - NOT pixels) of display screen
PAR = pixel aspect ratio - x/y ratio of the physical dimensions of a single pixel
SAR = storage aspect ratio - x/y ratio of the #of pixels being encoded, always known from the file

==================================================================================
MPEG-4

DAR = PAR x SAR, where

PAR is based on "aspect_ratio_info" in the Video Object Layer

For aspect_ratio_info values 1 - 5,
PAR = 1:1, 12:11, 10:11, 16:11, and 40:33 respectively.

If aspect_ratio_info = 15, PAR is the custom value:
"par_width" / "par_height"

where par_width & par_height are any two relatively prime integers
between 1 and 255. Those two values are stored in the VOL as well.

==================================================================================
MPEG-2

Based on "aspect_ratio_information", stored in the Sequence Header

If aspect_ratio_information is "1", PAR = 1:1, and therefore DAR = SAR

If aspect_ratio_information is "2", "3", or "4", DAR = 4:3, 16:9 or 2.21:1 respectively,
in which case PAR = DAR/SAR

However (this is relatively rare):

If Sequence Display Extension is present and display_horizontal_size
and display_vertical_size are present and differ from the SAR,
then their ratio will replace SAR in the above equation.

==================================================================================
MPEG-1

Based on "pel_aspect_ratio" located in the Sequence Header

DAR = PAR x SAR

where PAR = the reciprocal of 1.0000, 0.6735, 0.7031, 0.7615, 0.8055,
0.8437, 0.8935, 0.9157, 0.9815, 1.0255, 1.0695, 1.0950, 1.1575 or
1.2015 for pel_aspect_ratio values of "1" thru "14" respectively.

However:

0.9157 is commonly accepted to mean 11/12 or .9166, the reciprocal of 12/11 (1.091) and,
1.0950 is commonly accepted to mean 11/10 or 1.1, the reciprocal of 10/11 (0.909)

==================================================================================

:cool: more or less, anyway
Cheers

[Manao]

Well, his definition of SAR is his own, but not the standard's one, that's all. Once and for all, SAR means SAMPLE aspect ratio, ie, what he calls pixel aspect ratio.

[SeeMoreDigital]

Okay think of SAR x PAR = DAR this way...

An SAR of 1.25 (ie: 720x576) x an PAR of 1.0666666 (ie: 16:15) = an DAR of 1.3333333 (aka 4:3)
An SAR of 1.25 (ie: 720x576) x an PAR of 1.4222222 (ie: 64:45) = an DAR of 1.7777777 (aka 16:9)

An SAR of 1.50 (ie: 720x480) x an PAR of 0.8888888 (ie: 8:9) = an DAR of 1.3333333 (aka 4:3)
An SAR of 1.50 (ie: 720x480) x an PAR of 1.1851851 (ie: 32:27) = an DAR of 1.7777777 (aka 16:9)


Cheers

[Wilbert]

@SeeMoreDigital,

You are both right, but the problem is the naming of things. The MPEG-2 specs (page 47) says the following

SAR = DAR * horizontal_size/vertical_size

with horizontal_size the width of the displayable part of the luma component of pictures in samples (vertical_size idem ...). I think this just means the number of horizontal pixels.

So, what they call 'horizontal_size/vertical_size' is called 'storage aspect ratio' by Stegre. What they call SAR (or sample aspect ratio) is called '1 / PAR' by Stegre.

So, for example

SAR = DAR * horizontal_size/vertical_size = 3/4 * 720/576 = 0.9375

Interestingly, the MPEG-2 doesn't mention PAR at all. So, a question for Manao, where is the term PAR coming from (if it isn't mentioned in any specs)?

edit: i didn't know the DAR values in the MPEG-2 specs are actually 3/4, 9/16, etc ... :)

[LigH]

Interestingly, the MPEG-2 doesn't mention PAR at all. So, a question for Manao, where is the term PAR coming from (if it isn't mentioned in any specs)?
MPEG-1 specs, ISO/IEC 11172 Part 2, Chapter 2.4.3.2 "Sequence header":

pel_aspect_ratio -- This is a four-bit integer defined in the following table.

pel_aspect_ratio - height/width - example
0000 - forbidden
0001 - 1.0000 - VGA etc.
0010 - 0.6735
0011 - 0.7031 - 16:9, 625line
0100 - 0.7615
0101 - 0.8055
0110 - 0.8437 - 16:9, 525line
0111 - 0.8935
1000 - 0.9375 - CCIR601, 625line
1001 - 0.9815
1010 - 1.0255
1011 - 1.0695
1100 - 1.1250 - CCIR601, 525line
1101 - 1.1575
1110 - 1.2015
1111 - reserved
__

Unfortunately, I do not yet know where to find MPEG-4 specifications...

[SeeMoreDigital]

Interestingly, the MPEG-2 doesn't mention PAR at all. So, a question for Manao, where is the term PAR coming from (if it isn't mentioned in any specs)?That's right, because Mpeg2 / DVD, in its commercial form only offers 2No SAR sizes (720x576 for PAL or 720x480 for NTSC) and 2No DAR sizes, 16:9 and 4:3. However, the DAR sizes are still calculated using PAR.

People are now used to cropping and re-sizing their MPEG-4 encodes to any old convenient pixel frame size that either exactly or closely represents the movies theatrical aspect ratio. But with the aid of PAR we can now subtly adjust the pixels to match our 2No (DAR) screen sizes.


Cheers

[Sharktooth]

Regardless of this discussion i will keep the "Sample AR" label coz the cli option is --sar and not --par or --dar ...
When and if the cli option will change name i'll modify vfw accordingly...

[LoKi128]

--- OFFTOPIC ---
Just to add my little grain of sand, as I've said before I think the whole anamorphic thing is just a leftover from the old analog age of fitting a wider picture into a "slimmer" film frame. It is definetly not needed in the digital world, but I do agree that it might save some bandwitdh with little impact on quality.

That said, in my mind it is more intuitive to use the Display Aspect Ratio because it just describes the final AR that the picture should take. I don't care about the pixel or sample aspect ratio, or any other convolutions that the program needs to get to the desired DAR. I just want it to get there, and using the DAR you also use the already established convetions of 4:3, 16:9 or 2.35:1, not yet another set of values to remember.
--- OFFTOPIC ---

[SeeMoreDigital]

At the end of the day it all comes down to the terminologies and abbreviations we give things.... We can make them as simple or as confusing as we want. And even more confusing if we use the same abbreviations to mean different things!

DAR = Display Aspect Ratio (Relates to the 2No TV/Computer monitor sizes. Which are, 4:3 and 16:9)
PAR = Pixel Aspect Ratio (Which can be any ratio you care to make)
SAR = Storage Aspect Ratio (Relates to square pixel ratio, before correction, of the movie, as it's stored in an digitized electronic form (ie: DVD, VCD, disc, disk, tape etc).
MAR = Movie Aspect Ratio (Relates to how the movie makers indend the finished production image to be viewed)

In effect SAR should not mean "Sample" it should mean "Storage"

EDIT: As Wilbert mentioned.... It comes down to "the problem is the naming of things"


Cheers

[LigH]

So.

Now that I found a source of the ISO/IEC 14496 Part 2:

6.3.3 Video Object Layer
...
aspect_ratio_info: This is a four-bit integer which defines the value of pixel aspect ratio. Table 6-12 shows the meaning of the code. If aspect_ratio_info indicates extended PAR, pixel_aspect_ratio is represented by par_width and par_height. The par_width and par_height shall be relatively prime.aspect_ratio_info pixel aspect ratios
0000 Forbidden
0001 1:1 (Square)
0010 12:11 (625-type for 4:3 picture)
0011 10:11 (525-type for 4:3 picture)
0100 16:11 (625-type stretched for 16:9 picture)
0101 40:33 (525-type stretched for 16:9 picture)
0110-1110 Reserved
1111 extended PARpar_width: This is an 8-bit unsigned integer which indicates the horizontal size of pixel aspect ratio. A zero value is forbidden.

par_height: This is an 8-bit unsigned integer which indicates the vertical size of pixel aspect ratio. A zero value is forbidden.Any more questions? -- I'm afraid, yes... :rolleyes:

And another small piece of reference to this topic:
6.3.5.2 Video Plane with Short Header
...
source_format: This is an indication of the width and height of the rectangular video plane represented by the video_plane_with_short_header. The meaning of this field is shown in Table 6-25. Each of these source formats has the same VOP time increment resolution which is equal to 30000/1001 (approximately 29.97) Hz and the same width:height pixel aspect ratio (288/3) : (352/4), which equals 12:11 in relatively prime numbers and which defines a CIF picture as having a width:height picture aspect ratio of 4:3.

[Wilbert]

@yaz,

Since the MPEG-4 specs doesn't mention SAR (correct me if i'm wrong), isn't it more logical to call it PAR (or Pixel AR or whatever) instead of Sample AR?

[Manao]

The h264 / AVC specs only talk about SAR, and never mention PAR. So it's a tie.

[yaz]

...isn't it more logical to call it PAR (or Pixel AR or whatever) instead of Sample AR?imho, u're right. lots of application call it par, so giving a different name just increase the confusion.
The h264 / AVC specs only talk about SAR, and never mention PAR. So it's a tie. it can't be so hard. just see ligh's quotes. aren't they from the same specs u refer ?

however, not the name but the value(s) to be put here is(are) important. (and then call it whatever u want ;) )

the bests
y

[SeeMoreDigital]

The h264 / AVC specs only talk about SAR, and never mention PAR. So it's a tie.But I wonder what think their definition of think SAR means?

For all we know we might have one of those classic situations whereby the writers of one MPEG specification did not follow the meanings of the abbreviations created by the writers of former MPEG specifications.... Resulting in an confusing array of abbreviation that (of course) all look the same, but mean very different things!

For example. It's alright generating encodes at a resolution 720x576 (which I've always accepted as being the "SAR" of the encode) but whether that same encode contains any AR signalling (which I've always accepted as being "PAR" signalling) is another matter entirely!

Maybe what we need is a definitive list of all these abbreviations, with an explanation of what they mean within each MPEG specification.


Cheers

[TheBashar]

Let me apologize if these questions about zones in x264 have been asked before. I did a forum, thread, and google search and found suspiciously little information.

I would like to know if I am mistaken in believing that x264 zones lack the ability to do "start with keyframe" as in xvid. I actually use zones twice as much for marking cut/splice points than I do for bitrate reduction.

The reason I think x264 lacks this ability is because I used the zones configuration in MeGUI, but when I went to cut the resulting mkv (using mmg/mkvmerge) I was only able to cut at -2s and +4s on either side of where I had indicated a zone boundary.

I've finally resorted to encoding the video as 5(!) separate jobs using Trim()'s in the individual avs scripts. After that I adjust fix each parts timecodes for vfr, join the parts, mux the audio, and then split it back up at the join points. This way I get good splits.

Needless to say, this really complicates things.

Can someone confirm that my experience is accurate. And if I'm not making some stupid error, I'd sure like to cast my insignificant vote for adding that feature to x264 zones.

Thanks!