x264 development

[celtic_druid]

Not it at all. The reason it is recommended is because it is generally the most recent available. Most of the time there is nothing custom about it.

[peteag]

any ideas of a 1-pass cq mode in x264 or is it already comparable to 1-pass encoding?

[gaekwad2]

1-pass cq mode already exists:

Vfw: Single Pass - Quantizer
CLI: -q##

[Tommy Carrot]

Newbie question here...

How far has x264 come? I haven't checked on
its progress since ~r200, and browsing/searching
the forums hasn't helped me find the answer I
seek.

In terms of quality, how does it compare now to
Xvid, DivX, and the others (I remember it wasn't
as good at ~r200)?

Would it be a bad idea to start making backups
using x264 because it is still too early in the testing
stages?

js
Since rev. 200, x264 got many new features, like 8x8 dct, RDO, UMHex ME method, etc. These can significantly improve the quality.

IMO the mpeg4 ASP codecs cannot come close in quality, x264 is already better than them, sometimes the difference is huge.

I don't know if it's safe to use, but made the decision a few months ago, i exclusively use x264 for my encodings since then, and i've never experienced any problem with it.

[Inventive Software]

It could be that your path is too long, and its fecking up the software then.

Save your stats info to the root c: with a shorter filename as a test to see if that helps. You can always rename it afterwards if you need to.

Also, you may have to re-run the first pass if it turns out the filename was too long, as it may not have saved correctly.

If this is so, can longer statsfile names be implemented ASAP?

[bugsan]

hello

In vfw, the multipass/first-pass *seems* to be done with a constant bitrate (The standalone GUI writes a batch command with a --bitrate, for the 1st pass)

Maybe i'm wrong but i think it should be better with a quant constant.

[NuPogodi]

A bit stupid request, but... CLI applications usually allow to redirect stdout into text file. Could such a feature be implemented for CLI x264 (say, the command 'x264 -h > options.txt' has to create 'options.txt' with a full list of options)?

[MatMaul]

hello!
I have a problem(if it's a problem) : after encode with x264, I mux the video in the matroska container via mkvmerge.But when I look the framerate in the properties (with matroskaprop) I am a value like 24.994...fps for 25 fps for my input video. moreover, when I try to do a caption and go to a precisely frame with xvid and x264 I don't obtain the same frame : there are a shift of 2 or 3 frame.
for info, xvid has the good framerate (25.000fps) and I encode with cli version with avs input and mp4 output.

my command lines :

x264 --pass 1 --bitrate 800 --ref 1 --bframe 5 --direct temporal --weightb --b-pyramid --analyse none --me dia --subme 1 --progress -o NUL: "input.avs"

x264 --pass 2 --bitrate 800 --ref 5 --subme 6 --bframe 5 --direct temporal --weightb --b-pyramid --8x8dct --analyse all --progress -o "output.mp4" "input.avs"

[akupenguin]

In vfw, the multipass/first-pass *seems* to be done with a constant bitrate (The standalone GUI writes a batch command with a --bitrate, for the 1st pass) Average bitrate, not constant. CQP is fine if you pick the right quant, but ABR is better since you don't have to guess.

A bit stupid request, but... CLI applications usually allow to redirect stdout into text file. Could such a feature be implemented for CLI x264 (say, the command 'x264 -h > options.txt' has to create 'options.txt' with a full list of options)? Try 'x264 -h &> options.txt' (or '>&' depending on your shell).

[LigH]

Another way that works for me:

x264 -h 2> options.txt

Reason: You are allowed to use file handle numbers in front of redirectors.

0< = stdin (< = 0<)
1> = stdout (> = 1>)
2> = stderr

[ac-chan123]

@LigH:
under linux you can use tee to print on screen and write a copy into a file.

[LigH]

Probably. But are there Linux builds of the x264 CLI? If so - probably not from celtic-druid.

[Joe Fenton]

I build x264 on Fedora Core 3 for the AMD64. It works nice, but gpac doesn't compile as 64bit yet, so I don't get mp4 output. Also, AVI input isn't possible either. :(

[NuPogodi]

x264 -h 2> options.txt
Thanks a lot...

[peteag]

what about 1-pass cq at a specific bitrate like mpeg2?

[LigH]

For 1 pass: Either CQ, or average bitrate. But both is not possible for 1-pass. The reason is:

With only 1 pass, an encoder would not know which quality / quantizer it has to use to achieve a desired bitrate. This can only be calculated for a 2nd pass.

A CQ tester is not really an exception: I would call that a "1.5 pass mode"... ;)

[yokem55]

but gpac doesn't compile as 64bit yetI have x264 built with gpac support on my 64-bit gentoo box here. To get gpac to build proberly I had to checkout a recent cvs version of gpac and add "-fPIC" to the cflags. As for inputing data into the x264cli, I setup mencoder to frame serve into a fifo that x264 then reads. Mencoder has to be run like this:mencoder somevideo.vob -of rawvideo -ovc raw -vf swapuv -nosound -o myrawvideo.fifo

[LigH]

Just realised that width and height still have to be MOD 16. Do you plan to implement a workaround to circumvent this limitation, e.g. in a similar way as e.g. in XviD?

(AFAIR, often some kind of "mirroring" is used to extend the video area to the next multiple, if necessary.)

[CREXbzh]

Just realised that width and height still have to be MOD 16. Do you plan to implement a workaround to circumvent this limitation, e.g. in a similar way as e.g. in XviD?

(AFAIR, often some kind of "mirroring" is used to extend the video area to the next multiple, if necessary.)
That just a very bad idea not to scale at MOD 16. Please read this to get convinced: http://mplayerhq.hu/DOCS/HTML/en/menc-feat-dvd-mpeg4.html#menc-feat-dvd-mpeg4-constraints
:)

[Joe Fenton]

I have x264 built with gpac support on my 64-bit gentoo box here. To get gpac to build proberly I had to checkout a recent cvs version of gpac and add "-fPIC" to the cflags. As for inputing data into the x264cli, I setup mencoder to frame serve into a fifo that x264 then reads. Mencoder has to be run like this:mencoder somevideo.vob -of rawvideo -ovc raw -vf swapuv -nosound -o myrawvideo.fifo

Thanks! Just the info I was looking for.

[Manao]

CREXbzh : in fact, it's not a bad idea. It's better to crop to eliminate black borders without being mod 16 than having black borders and being mod16.

[LigH]

I don't need to be convinced, I know the advantages of videos being sized at multiples of macroblock sizes pretty well. But there are situations where you cannot serve optimal video sources. And there are better ideas of virtually filling up, than adding black borders, which are easy to achieve inside the encoder, but not so easy outside of it.

[yokem55]

Thanks! Just the info I was looking for.
A couple of other notes on useing mencoder as a frame server. If you use a telecine filter, you might get some lost frames that will cause nasty audio sync problems. Also, using -noskip on the mencoder command line is needed to get all the frames into x264.

[Joe Fenton]

Right... good idea.

[JasonFly]

Is there any mean to change the fourcc in the cli encoder? I know this command is present in the VFW version(the debug tab) but I cannot find any command in the CLI help (to change fourcc from h264 to avc1 for instance)

[dimzon]

just a little suggestion:
please add "target file size" mode (like in XviD) as -bitrare alternative
Thanx!

[bond]

Is there any mean to change the fourcc in the cli encoder? I know this command is present in the VFW version(the debug tab) but I cannot find any command in the CLI help (to change fourcc from h264 to avc1 for instance)
the cli doesnt output to avi so there is also no need to mess around with fourccs

[JasonFly]

I though mp4 also had fourcc in its header. Shame on me.
I should have read the MP4 FAQ more carefully. I'll read it ten more times as punishement.

So AVC content is only discribed by his private track ID in the MP4 file? Does Ateme/Nero AVC and x264 have the same private track ID?

[bond]

for ensuring interoperability between different encoders the mpeg-4 standard defines clearly how to place avc in mp4 and all encoders claiming to be mpeg-4 compliant have to use that way and x264 and ateme/nero do it therefore too

[guada 2]

Hello, :)

The last version (x267) is not supported by player NERO.
Why? and where come the problem?

Indeed, it is impressive.

[bond]

Hello, :)

The last version (x267) is not supported by player NERO.
Why? and where come the problem?

Indeed, it is impressive.no problem here with as good as all settings enabled..

lossless doesnt work with nero as mentioned already

[guada 2]

it is strange whereas the other versions perfectly functioned.

And the other versions? What it was?

[bond]

post your exact settings used for encoding and a sample clip showing that problem

[LigH]

I love people who post their complete command line used for encoding, in case of playback problems. Or even their whole encoding report. Really. ;)

[guada 2]

I suppose that it is not accepted by MP4BOX?

[bond]

troll?

[guada 2]

I apologize Bond, all is of my mistake.
I was mistaken since the beginning of AVS file.

You are right, I don't have anything say.

a question:
what means " TROLL"? please

[Rash]

Humm, I don't know if it was already posted here somewhere (big topic :)) but I would like to suggest something. And I don't know if it is easy to code and if it is a feature people would use either.

But what if x264 cli encoder took the configurations from a file? Stuff like, b-frames, matrices (now supported), the Macroblock Option, etc? So you would only type

$>x264 --conf configuration.xml -o file.mp4 file.avs
for example. That would be nice to test different videos with the same configuration. ;) Anyway, just a thought, please don't kill me. :)

[guada 2]

Hello Bond :)

You have say this:
"lossless doesnt work with nero as mentioned already"

I have make a small test of lossless with NERO SHOW TIME.
I notice that it accepted the HUFFYUV file?

What is your verdict? strange or luck ??????

[Ariakis]

Hello Bond :)
You have say this:
"lossless doesnt work with nero as mentioned already"

I have make a small test of lossless with NERO SHOW TIME.
I notice that it accepted the HUFFYUV file?


He meant Lossless AVC (as in x264 with qp=0), not HuffYUV

[guada 2]

Other thing:

Concerning the properties of a file encoded with the codec x264:
It would be useful to find a name of for the option " compression video ".

No.. :)

[guada 2]

Ariakis,

I understood it well, not of concern.
it was just to add a report.

NO PROBLEMO.. :)

[LigH]

@ guada 2:

Please, do yourself a big favour:

If you have a technical problem, try to describe it as detailed as possible, especially always post your complete command line, or even the whole application output. Try to read and understand given answers. I'm not sure if you ever read about the infamous "TUVOK" - a former member of many boards, who always asks and asks and asks, but never learns from given answers...

If you instead have a personal problem with another member, discuss it privately (e.g. send a "Private Message" via the small menu that pops up when you click on his user name), but don't mess an important thread.

[Luminaria]

Sorry if this has been asked before, but are there plans to include a directshow decoder in x264 in the future?

[Manao]

No. In fact, there isn't any working decoder in x264 at the moment, because the 'official' decoder is ffmpeg. So the 'official' directshow decoder is FFDShow.

[guada 2]

Hello,

LiGH

I don't understand your reasoning.
Where do you seen a problem?

It is me that have make a mistake in my applications.
BOND didn't understand my problem.
He thought that I had found a error on the codec.

It is FALSE.

I understood its thought.
I even have make a small parenthesis without consequence.

But where is the problem?

On the other hand I didn't understand the word that he used, and I don't always know the translation / "TROLL".
If you believe that I have make something, don't hesitate to tell it to me.

That is sure, when I have a problem I say it honestly and in direct; And there doesn't have a problem ( I think that you understand me LIGH ).
If my mistake caused twists , I apologize but if it is not the case I would like to understand.

I don't tempt to destabilize the progression of the codec.
Indeed, I approve the work that is accomplished. and I thank all those that participate in to create a reliable and effective codec.

For all problem, I would not hesitate to follow your advice.
Thank you for your sense of the dialogue and your understanding.

Mario.

[LigH]

Mario - you too?! :D
__

"Troll" is also a mystic figure in the old german mythology, can have a dwarvic or giantic size, but usually does no good... (try to search for "define: troll" with Google)

We probably suspected you "trolling" because we asked again and again for more details, but you didn't deliver any facts. For this reason, I just recommended you to be a little more careful how your posts look aand sound like. But I did not want to say that I personally would dislike you! ;)

Let's stop any open discussions about misunderstandings. Let's keep the thread clear for technical facts, please. :)

[guada 2]

Ligh,

I appreciate your spontaneity. :)
Thank you very much.

Mario

[Joe Fenton]

"Troll" is also a mystic figure in the old german mythology, can have a dwarvic or giantic size, but usually does no good... (try to search for "define: troll" with Google)

The usual meaning of the term troll in forums is derived from:
To fish for by trailing a baited line from behind a slowly moving boat.

The baited line is the trollish reply and is often referred to as 'flamebait'. The 'fish' are incensed people who reply angrily to the post. The troll is trying to stir up trouble by posting replies he knows will get others on the board angry.

[Chaos Creator]

Hello,

I've just endode a video file, once with threads set to 1 and once with threads set to 2! I used the exact same options! I use the vfw codec! Here is the problem:

1 Thread = 936 KB

2 Threads = 947 KB

Why this difference???

[Manao]

Because ! 2 threads -> 2 slices ! 1 threads -> 1 slices ! And slices can't reference each other spatially ! And slices reset cabac contexts !

All that to say : slices ( and so threads ) allow a faster encoding, but reduces the codec efficiency.

[Sharktooth]

All that to say : slices ( and so threads ) allow a faster encoding
Only on systems with multiple execution units (hyperthreading, multi processor, or multicore).

[bill_baroud]

If your code keep all your execution units busy correctly, using hyperthreading won't help you, and even will harm performance (by disrupting the instructions flow of your program that you carefuly set and managed with love and care and ... err i need to stop coding in assembly)

But well yeah, in practice, you can't never keep your executions units busy and break all dependances.

[dinolib2]

Here (http://forum.doom9.org/showthread.php?t=96059) you can read, under "current issues with AVC/H.264" paragraph, this sentence: .avi: using AVC-in-AVI is nowhere standardized and therefore already causes incompatibilies. The limitations of AVI and VFW (eg regarding b-frames or arbitrary frame coding orders), together with the necessary hacks caused by these two formats, hinder the full implementation of all possible features AVC offers and therefore harm the possible quality or at least the speed of the development, the interoperability and therefore also the competition. AVI is currently used by VSS and x264 (mencoder and vfw)

My question is: in this state of development, is x264 quality limited by avi restrictions? Could be in the future developed some "advanced feature" no more compatible with avi container (and not present in VFW)?

Sorry if I've made a silly question :D

[absinthe]

Doom9 suggested that I report an odd problem here: x264 from the command line with the --progress parameter does not show any progress output on my box. Therefore, I see no status progression in the ProgressWindow of MeGUI.

Several people seem to be affected by this, including some who do get progress at the command line and still do not get progression in the MeGUI ProgressWindow (though that may not be relevant here). At least one other person has the same problem I do with no progress at the command line.

I use WinXP Pro (SP1), Athlon 1600 XP. Nothing unusual about my box that I can think of. I'm using the latest x264 (revision 270).

Let me know if I can provide more info.

-abs

[Sharktooth]

Maybe starting with installing all OS updates (including SP2) will exclude a good amount of possible problems...

[Doom9]

(though that may not be relevant here)It doesn't. I'll take care of of those in my own domain eventually.

[kurt]

I have the same problem like absinthe (no progress at cli)...
I use WinXp Home on my P4 2ghz with 512 MB RAM - I installed all windows updates (including sp1 for .net 1.1)...
with mencoder there are no problems...
Any idea what's going wrong?

Edit: this is the window during encoding (wich always finished fine)
http://img220.echo.cx/img220/7595/image17ii.th.jpg (http://img220.echo.cx/my.php?image=image17ii.jpg)

[Sharktooth]

what build are you using?

[kurt]

what build are you using?
latest revision (270) :) (sorry forgot that to mention)

[Sharktooth]

my build or other's build? or the problem is still there indipendenlty from which builds you use?

[kurt]

my build or other's build? or the problem is still there indipendenlty from which builds you use?
normally I use your builds, but I tried bob0r's even too - same problem here....

[Sharktooth]

well... a compiler issue is excluded then: i use gcc 4.0.0 and bobor 3.4.x (IIRC).

[ckjnigel]

Can someone explain where Ahead/Nero has positioned itself with regard to H and X .264? It's important for me to know so as to choose which codecs to install; I recreate my X64 partition once a month. This go round I've discovered that that 6/19 ffdshow cannot compare to Videolan VLC player and the latest Nero video decoder is even better playing back an H.264 in an avi container created with Gordian Knot.
I'm guessing that X.264 could be a format for video as well suited to Pocket Pc as AAC+ is for audio.
I'm hoping that Pocket PC freeware BetaPlayer and TCPMP developer Picard is being kept in the loop. ( see http://tinyurl.com/86aq2 )

[bond]

avc is avc no matter what codec (nero, x264 or whatever) you use to create the stream

place avc in the .mp4 container and you will be able to play the file on as good as all avc enabled players (including nero's stuff)

[posix]

where do i find a list of all resolutions this codec supports? (searched this thread for "resolution" without success)

[LigH]

What do you mean with "all resolutions"?

From "poststamp" up to HTDV dimensions - no problems. The only required precondition: Width and height must be multiples of 16 - x264 does not yet support "any" size by virtually filling up the dimensions to multiples of a macroblock.

I only remember one kind of codec which was limited to only a few special resolutions: H.261 (used for ISDN {64 kbps} video telephony).

[berrinam]

Is there no maximum resolution, or is it just so large that it is irrelevant?

[LigH]

There is most probably a maximum. But do you really need to encode e.g. 4096x4096 videos? Where do you want to get material larger than 1920i?

[Andrey]

>>There is most probably a maximum. But do you really need to encode e.g.
>>4096x4096 videos?
Original digital D5 source should be about this resolution. And it will not be stored uncompressed, I think. This is not what is called a "consumer" use, but still it should be handled somehow.

[LigH]

It is very hard to find useful pages about the D5 format. Mostly copies of the Wikipedia article, which is limited to HD-D5 with resolutions up to 1080 lines.

[SeeMoreDigital]

When I was last in a TV studio D5 referred to: -

625 line component digital video recorded onto ½" (12mm) tape, using an uncompressed 601 format. The max run/record time was 128 mins with up to 4No digital audio channels

It was used in the UK by Channel 4 in late 1990's as transmission format but was replaced by Digi-Beta due to the high cost of the hardware and the media.


Cheers

EDIT: Don't most production companies use the DPX process to convert film to digital video nowadays?

[Andrey]

>>When I was last in a TV studio D5 refered to
Hmmm...
Thanks for the info, SeeMoreDigital.
I saw an article, where D5 was reffered as an high definition digital (primary) source digital television sources are produced from.
Need to check it once more...

[LigH]

The DVD authoring studio I once worked for had a HDTV cinematic film scanner; AFAIR, a hot plug able 10 SCSI HDD RAID. No idea which file format they use. but a hell of a machine! :D

[Doom9]

I've had a feature request for MeGUI to offer more control over the turbo option. I'm wary of that because I'd like to prevent that incorrect settings will severely degrade the output. So far, I'm reducing subq, 8x8b options (what about the 8x8i and adaptive dct by the way.. can they be safely deactivated) and number of reference frames. Is there anything else that can be safely changed without having visibly adverse effects on the result? Or put the other way round: which options are not a "must-match" and how far can they be tweaked?

[Sharktooth]

analyze can be set to none
reference frames to 1
8x8dct can be disabled
diamond search ME can be used.
the difference between using the same settings for 2 passes and this method is negligible.

[bond]

I've had a feature request for MeGUI to offer more control over the turbo option. I'm wary of that because I'd like to prevent that incorrect settings will severely degrade the output. So far, I'm reducing subq, 8x8b options (what about the 8x8i and adaptive dct by the way.. can they be safely deactivated) and number of reference frames. Is there anything else that can be safely changed without having visibly adverse effects on the result? Or put the other way round: which options are not a "must-match" and how far can they be tweaked?
pengvado himself once made a post on what should be safe to use, dont find it anymore tough

[Doom9]

pengvado himself once made a post on what should be safe to use, dont find it anymore toughI know.. must be in this thread or in the old MeGUI one and I implemented exactly what he described. But at that time x264's feature set was more limited, especially the VfW version which was taken as template at that time (x264.exe only became useful when it got AviSynth input suport).

[berrinam]

is it this post? (http://forum.doom9.org/showthread.php?p=595200#post595200)

[Doom9]

is it this post?yup yup (2nd yup due to the minimum post lengt of 5;)

[bond]

yup yup (2nd yup due to the minimum post lengt of 5;)
yeah, would be great if this could get changed back to 3 as it was the case in the old board :D

[superdump]

Doom9: That post that aku made was merely stating what the fast first pass in vfw does. Since then I carried out some testing of an as fast as possible method, i.e. -r 1 -m 1 --me dia -A none and no 8x8dct in the first pass, all was confirmed as being theoretically OK to do and the results of my testing was that there was negligible difference between doing a full quality first pass and this fast first pass. The difference was less than +/- 0.1dB and the speed increase was approximately 3-fold compared to the usual (non-turbo) first pass. My second pass options are -r 5 -m 6 --me umh -A all --8x8dct. I think it would be appreciated if this were also implemented in the GUI. Feel free to test it yourselves.

EDIT: This is using an ABR first pass and bitrate target second pass.
EDIT: Reworded the last section and altered the meaning as it was incorrect to what I actually intended.

[cheburashka]

...I think it would be appreciated if this were also implemented in the GUI. Feel free to test it yourselves...

I second it after pengvabo might confirm this.
Or you can add it as addition to turbo mode. Lets name it "supersonic" 1st pass :)

[Doom9]

EDIT: This is using an ABR first pass and bitrate target second pass.Is there even a difference specifying --pass 1 and then a bitrate or only a bitrate? Don't you get an ABR either way?

I'll make those turbo changes shortly when I attack the configuration screen again (bond asked for AVC profile levels and I'll be happy to oblige once I can locate the specs).

[superdump]

I second it after pengvabo might confirm this.
Or you can add it as addition to turbo mode. Lets name it "supersonic" 1st pass :)
Pengvado is away and won't be back for a few months. We might be able to contact him at some point though. I did request that it be done but I think Alex_W and algern0n were apprehensive and wanted it to be tested further. So if people can test with a wide variety of sources and post results that would be appreciated. I could always make a patch which alters the fast first pass code as necessary, wouldn't take long.

Is there even a difference specifying --pass 1 and then a bitrate or only a bitrate? Don't you get an ABR either way?

I'll make those turbo changes shortly when I attack the configuration screen again (bond asked for AVC profile levels and I'll be happy to oblige once I can locate the specs).
If there is a difference it will be that specifying --pass 1 forces stats output.

bond wants profiles/levels? Do you mean setting that flag in the encoder or what? I was thinking of possibly tackling this as one of my first contributions to x264 as it should be quite easy. The hard part is deciphering the standard. :) I think it would be good if specifying a level restricted the options available and enforced the necessary resolutions/framerates/macroblock rates/vbv etc etc.

[Doom9]

I think it would be good if specifying a level restricted the options available and enforced the necessary resolutions/framerates/macroblock rates/vbv etc etc.That's the one. I already implemented parts of this (simple, main and high profile features).. the next step would go into levels within a profile.. where resolutions, vbv, etc comes into play. So if you like to read up on this and share your findings, that would be a very valuable contribution indeed and I think it would also make sense to implement the results of such research into the VfW and have something just like the VfW profiles.

I'll try to prioritize the "update jobs" feature so testing will become much easier. Right now I have to switch between inputs of my flatscreen to set up my new X2 based barebone :) x264 is gonna fly with the new CPU :)

[SeeMoreDigital]

Depending on how many profiles they'll eventually be, would it be "too daft" a suggestion for x264 to include a range of profile settings that match NeroDigital AVC.


Cheers

[bond]

Depending on how many profiles they'll eventually be, would it be "too daft" a suggestion for x264 to include a range of profile settings that match NeroDigital AVC.nero doesnt want to share the specs of their private profiles, so why should anyone mess around with them...

apart from that, with no really widely useable avc hardware existing, what sense does it make to specify and use private avc profiles different from the official mpeg ones...
they will be changed anyways once the chips arrive

[superdump]

OK, I've been discussing this with Manao and there is a slight problem. The levels impose limitations on MV lengths. x264 currently doesn't check the MV length during ME and doing so would reduce the speed and mess up the code, which is currently very neat. So instead I'm going to direct my efforts elsewhere... more RD maybe. :)

[IRMA1024]

is x264 stuck on rev270 i don't see any revision after? i hope next, error resilence will be implemented... btw... nice work

[Ark]

If you look at the daily build sticky thread, you'll see "summer break" written, which means that for a while rev270 will be the last build available, as developers (in particular akupenguin) are enjoing their holidays!

[LigH]

Did you notice the addition "Summer Break" in the title of the thread with the most recent builds by Sharktooth? In my opinion, this means: Don't expect many updates because most developers are on vacation. ;)

[akupenguin]

Since then I carried out some testing of an as fast as possible method, i.e. -r 1 -m 1 --me dia -A none and no 8x8dct in the first pass, all was confirmed as being theoretically OK to do and the results of my testing was that there was negligible difference between doing a full quality first pass and this fast first pass. The difference was less than +/- 0.1dB and the speed increase was approximately 3-fold with my second pass (-r 5 -m 6 --me umh -A all --8x8dct).
You can't measure the benefits of turbo just by the 1st pass's speed. What you should ask is: how much did your version of turbo reduce total encode time over both passes, vs how much time would you save by reducing 2nd pass options by the same amount of quality?

The levels impose limitations on MV lengths. x264 currently doesn't check the MV length during ME and doing so would reduce the speed and mess up the code, which is currently very neat. It has since rev150, see param.analyse.i_mv_range (default 512). I just haven't exposed it in any frontend.

[superdump]

You can't measure the benefits of turbo just by the 1st pass's speed. What you should ask is: how much did your version of turbo reduce total encode time over both passes, vs how much time would you save by reducing 2nd pass options by the same amount of quality?
Why would I want to reduce the second pass options? That doesn't make sense to me. I use the second pass options I do because they're what I consider to be realistically the maximum I can get out of the codec without wasting time on -r 16 or whatever. The point of increasing the speed of the first pass was to avoid wasting time with encoding complexity when it doesn't significantly affect the output of the second pass with my preferred options. If I were to reduce the second pass options too I would reduce the quality of the output, which is undesirable. Am I misinterpreting what you're saying because it seems an unusual suggestion? (The second part. The first part, comparing the overall speed not just first pass, is reasonable.)

It has since rev150, see param.analyse.i_mv_range (default 512). I just haven't exposed it in any frontend.
Ah, cool.

EDIT: I reread the section you quoted from me and it reads like I was comparing the first pass speed to the second pass speed. I essentially was because I used the same first and second pass options in the non-turbo encode but what I actually intended was that the first pass with the turbo options I've specified are ~3 times faster than the first pass which uses settings identical (aside from -p) to my second pass settings.

[Doom9]

It has since rev150, see param.analyse.i_mv_range (default 512). I just haven't exposed it in any frontend.So it could be done after all.. :) So if we can translate the specs into x264 options I'm all game for implementing it into megui

[NuPogodi]

Just a stupid question about compressing black'n'white video... till now, i've found the only option ('--no-chroma-me') to accelerate reencoding b&w movies. Did i miss something? any plans to make the b&w-optimized preset which allows to ignore all croma info?

[IgorC]

rev270B has a EQM AVC-HR matrix. What kind of source and bitrate this matrix is for?
I'd suppose it's like Xvid EQM HR matrix. But how high bitrate? 1.5 Mbit is it enough for DVD 720X480 23.976 fps source to use this kind of matrix ? Any result?

[superdump]

rev270B has a EQM AVC-HR matrix. What kind of source and bitrate this matrix is for?
I'd suppose it's like Xvid EQM HR matrix. But how high bitrate? 1.5 Mbit is it enough for DVD 720X480 23.976 fps source to use this kind of matrix ? Any result?
If you search the forum for the name of the matrix you will find Sharktooth's thread.

[Sharktooth]

look at my signature. however 720x480, 23.976fps and 1500kbps should be enaugh to use it (unless the source is really noisy or have bad compressibility).
Some feedback would be really appreciated :)

[zombi55]

Hi..

I have some troubles with the x264 VFW codec or the H264 ffdshow. I made a "small" encoder using the windows API functions ICopen, ICDeCompress and ICCompress. All is well but every time I want to use a x/h264 codec, the ICClose function crashes. I code using VC++ and even in debug mode I can't find a solution, I have a message [ User breakpoint at 0x..... ] in NTDLL.

Can anyone help me? (All others VFW codecs work perfectly, even VP62 and VP70)

[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!

[Doom9]

I remember that this has come up before. But your scenario is so special that I wouldn't count on anything happening.

[Isochroma]

I just finished editing Noir ep. 1 (35089 frames processed by hand in 14 days of work). I am now encoding the final output using the newest x264 (v. 280). The file is ridiculously small (at q=20); I'm using ESA motion estimation and all the highest quality settings possible. Here is the commandline:

x264.exe --progress --qp 20 --subme 6 --ref 1 --threads 1 --filter 0:0 --keyint 250 --min-keyint 25 --scenecut 40 --qpmin 10 --qpmax 51 --qpstep 4 --direct temporal --me esa --merange 16 --bframes 15 --weightb --b-bias 0 --ipratio 1.40 --pbratio 1.30 --qcomp 0.60 --analyse all --8x8dct --progress --fps 23.97600000 --sar 32:27 -o "F:\Video Files\Noir\Encoded\Noir.01.mp4" "F:\AVISynth Scripts\Noir\MP4 Output\Noir.01.avs"

I am very impressed with the quality this codec is achieving; it could only be excelled by Ateme among all other codecs in the world right now. My AthlonXP 2500+ running single-channel DDR400 gets about 3.2-3.5 fps (no filters in the avs):

avisource("F:\Video Files\Noir\Frameserved from Vegas\Noir.01.avi")
killaudio()
converttoyv12()

The avisource() line should explain why I used killaudio()! This unusual setup is due to the fact that Vegas 6.0 starts sending corrupt frames to saved AVI files after about f4000.

So many thanks to the developers; in combination with my intensively laborious hand-editing (or rather, choosing for replacement) of video frames, the codec is a perfect match for my insistence on perfect output, in archival grade.

Tomorrow or Thursday I will be posting the link to my new site, which will explain the techniques used in this process. Particularly, delta codecs such as x264 can benefit enormously from having source frames that differ only in quantization and film-grain noise replaced by the best among a group. This zeroes whole groups of frames - sometimes quite substantial in size.

Due to the high quality of x264, it tends to preserve noise much better than MPEG-4 ASP codecs, due to more efficient bit allocation at equivalent bitrates. Thus at equivalent bitrates, the value of source noise reduction is increased by a substantial amount. Beyond the saving of bits, choosing superior frames for replicative replacement of inferior ones increases the psychovisual quality of a video stream and is a powerful tool to provide a 'free' quality boost. It is time-intensive, though; The curent project is estimated to take one year and one month to complete.

Since encoding time is less than 5% of the time to produce a finished release, I'm not concerned about slow encoding speeds. Since I've invested so much time in the other 95%+, I use the most perfect encoding settings I know of.

If anyone knows of any way to make x264 run slower but achieve higher quality, please do point out the parameters that should be changed in the commandline above. Acceptable framerate for encoding is 0.1 FPS. Thanks!

[nm]

If anyone knows of any way to make x264 run slower but achieve higher quality, please do point out the parameters that should be changed in the commandline above. Acceptable framerate for encoding is 0.1 FPS. Thanks!
How about 2- or 3-pass encoding, --ref 15, --b-pyramid and --keyint 500 (this should be tested; probably no gain and may lose seeking precision).

[LigH]

Instead of
avisource("F:\Video Files\Noir\Frameserved from Vegas\Noir.01.avi")
killaudio()
converttoyv12()
simply try
avisource("F:\Video Files\Noir\Frameserved from Vegas\Noir.01.avi", false, "YV12")
This shall speed up a little, because it does not "request and delete" unnecessary data, but instead requests only desired.

[akupenguin]

--keyint 500 (this should be tested; probably no gain and may lose seeking precision)

--keyint is just a maximum. If increasing it removes some I-frames, then you both lose seeking precision and gain compression. If not, nothing changes.

[posix]

right,
sorry to be the pestering noob but...

"x264 options explained, step by step guide"

where?

[bond]

right,
sorry to be the pestering noob but...

"x264 options explained, step by step guide"

where?
:readrule: :search: :readguid:

also what does this have to do with x264 development?

striked

[LigH]

@ posix:

Because you seem to be a German, you may want to look in the german doom9/Gleitz board for Selur's "Wissenswertes rund um x264".

http://forum.gleitz.info

[Egh]

Where to actually report possible bugs in x264?

This one is assertion exception, raised apparently in x264 whilst encoding with VirtualDub.

http://forums.virtualdub.org/index.php?act=ST&f=15&t=10297&

[LigH]

x264.exe does not yet have a special "encode interlaced" option, as far as I can see in the help output of rev. 284 - or did I miss an option?

[bond]

x264.exe does not yet have a special "encode interlaced" option, as far as I can see in the help output of rev. 284 - or did I miss an option?nope, x264 doesnt support interlaced encoding till now

[TheBashar]

I have a problem, and I think it's in the bowels of the code. I don't think there is any way to tackle this from x264 option tweaking. I have a couple clips where x264 seems to lose low contrast detail. And there's now way I can stop it.

I have a clip with snow falling and a camera rotation. It's a pretty busy clip. The problem is the snow gets softened into a smeared falling macroblock look. Really not nice. I've tried everything (qcomp=0.7, qcomp=0, no deblocking, lots of deblocking) and nothing works except throwing massive amounts of bitrate at it.

Now, I understand you might take a look at the clip and say, well this is really busy, 10,000 kbps might be warranted. How do I get the bitrate to it without inflating the entire movie? The majority of the movie looks great at 1400 kbps. There are some other low contrast background smears/blockyness similar to the snow, but the (high-contrast) foreground details look great.

So, without some dev help, I think I'm stuck in the water. I think my clip needs something like a negative qcomp to take bitrate from the easily compressed scenes and throw it at the problem scenes. My guess is this is a much more intrinsic problem in that the basic encoding method naturally loses low-contrast details, so x264 wouldn't even have any way of knowing there was detail there that needed more bitrate.

Here is a 14MB huffyuv avi source clip. (http://www.savefile.com/files3.php?fid=9435255)

Here is a 0.8MB 5000kbps ABR x264 MP4. (http://www.savefile.com/files3.php?fid=8421389)
Here is a 0.8MB 5000kbps no-CQM ABR x264 MP4. (http://www.savefile.com/files3.php?fid=9665839)

Here is a 0.5MB 3000kbps ABR x264 MP4. (http://www.savefile.com/files3.php?fid=8480839)
Here is a 0.5MB 3000kbps no-CQM ABR x264 MP4. (http://www.savefile.com/files3.php?fid=3282791)

The first x264 clip was made with the following command-line:
x264.exe --bitrate 5000 --keyint 300 --ref 5 --bframes 3 --b-pyramid --subme 6 --weightb --analyse all --8x8dct --qpstep 50 --qcomp 1.0 --me esa --merange 32 --cqmfile eqm_avc_hr.cfg --progress --no-psnr --output ep-2.mp4 ep-2.avs --ratetol inf

Please be sure to examine the snow falling in front of the dark parts of the volcano on the left. Hey ya know, maybe that's not snow, maybe it's ash! Damn, I'm slow!

[omion]

How do I get the bitrate to it without inflating the entire movie? The majority of the movie looks great at 1400 kbps. There are some other low contrast background smears/blockyness similar to the snow, but the (high-contrast) foreground details look great.
I'd think this would be a perfect candidate for using the --zones command. Add --zones start,end,b=5.0 to your command line and x264 will make the range of frames from start to end use 5 times the bitrate as the rest of the movie. It's sort of like curing the symptom instead of the disease, but it should work.

[SeeMoreDigital]

Where was the source from originally.... Was it a TV capture or from a DVD.... I'm wondering why your 14MB huffyuv sample is 880x480 pixels... not 720x480 pixels?


Cheers

[Pookie]

omion-Thanks for the info on the zones command. Gonna try it out on some footage with ocean scenes.

[TheBashar]

Where was the source from originally.... Was it a TV capture or from a DVD.... I'm wondering why your 14MB huffyuv sample is 880x480 pixels... not 720x480 pixels?

It's off my SG-1 (tv series) DVD collection. The size reflects the fact that I captured the "source" at the end of my postprocessing setup. I guess I should have been more clear that it was the source for the encode, not the ultimate source.

@omion:
Thanks for reminding me about the zones. It's not a good solution since in addition to easily identifiable scenes like the one I posted, there are small stretches with low contrast backgrounds that get smeared or blocky and they are scattered throughout. Not meaning to diminish your suggestion however, I will point out that while it's not a good solution, it is the best one that I have. :)

[LigH]

On the occasion of several remarkable speedups between r28x and r293, x264 now has a lightning fast new logo. Well done, bob0r - beautiful!

http://x264.nl/x264_fire.gif

[hpn]

Yes, a very nice logo. It's also a very complex one with lots of collors and shadows, so gif is not the best format (55k). It could be easily transformed losslessly to 48k PNG, so bob0r could make his site half a second faster :)

[SeeMoreDigital]

... It could be easily transformed losslessly to 48k PNG, so bob0r could make his site half a second faster :)Oh yeh....

http://img300.imageshack.us/img300/8559/x264fire95am.png

at 41.5KB PNG

[gaekwad2]

38.4KB

http://img76.imageshack.us/img76/4430/x264fire1sg.png (http://imageshack.us)

[Chaos Creator]

What Sarktooth wants to say exactly with this:

x264 win32: rev.292 - Last build until sanity comes back into ppl's mind. ???
:confused: :confused: :confused:

[LigH]

@ SMD, gaekwad2:

Which tools did you use? SMD - probably IrfanView's PNGOUT?

[Chaos Creator]

http://forum.doom9.org/showthread.php?p=711871#post711871

Ok, thanks for answering my question!! Some people really can't understand the open source philosophy!!!! :( You can't request anything!!!!

[gaekwad2]

@ SMD, gaekwad2:

Which tools did you use? SMD - probably IrfanView's PNGOUT?
I used a batch script that was posted at Hydrogenaudio a while ago, it runs advpng, pngcrush, optipng, pngrewrite and pngout (plus pngout /f0 which shaved off another 4 bytes :)).

[Audionut]

http://img355.imageshack.us/img355/5179/x264fire5fn.png

28.5kb png


http://img380.imageshack.us/img380/8624/x264fire19nl.jpg


18.1kb jpg

[hpn]

Ok, because I started this oftopic talk, lets finish it by pointing out that one can go as low as 5k with jpg or lossy PNG, but the whole idea was to make a lossless transformation and preserve the good looks of the original logo, not to make it as small as possible, so the 38.4KB version of gaekwad2 seems the smallest possible lossless GIF to PNG transformation (lossless = fully preserves the rendered RGB triples)

the facts:
http://www.cs.toronto.edu/~cosmin/pngtech/optipng.html
and the batch scripts:
http://www.hydrogenaudio.org/forums/index.php?showtopic=22036&hl=

edit: even lower than gaekwad2 losslessly to 39108 bytes:
http://img167.imageshack.us/img167/8427/x264fire9ry.png

[Antony]

Hi all,
I have revamped the VFW settings window into a smaller tabbed window. Screenshot and source code here: http://members.shaw.ca/antony.boucher/download/x264rev293_gui_patch.zip
Cheers

[sr78]

Hi All.
I am just now starting development on the x264.
I woundered if there is any good documentation I can get
in order to understand the source code better?

thanks.

[Kopernikus]

@Antony: Please send the Patch to the x264-devel mailinglist (see here http://developers.videolan.org/lists.html)

@sr78: Unfortunately there is almost no documentation for the sources. But reading the standard and the sourcecode parallel can help much. Also there is a document describing the reference encoder http://ftp3.itu.ch/av-arch/jvt-site/2005_01_HongKong/JVT-N046r1.doc, which may help in understanding.

[bob0r]

Hi all,
I have revamped the VFW settings window into a smaller tabbed window. Screenshot and source code here: http://members.shaw.ca/antony.boucher/download/x264rev293_gui_patch.zip
Cheers

Hi Antony, welcome, finally :D

Please remove my AWESOME Logo from your VFW patch, it is highly patented by me and i require a lot of money to use it.... or as most please say.... its horrible ;) ( No seriously, just add no logo, i just keep playing around with it on x264.nl )


Also, please disguss with VFW Patch with Sharktooth, he can also test them, and he makes custom builds so others can play with stuff before it gets commited to svn (or not)

His builds: http://forum.doom9.org/showthread.php?t=89979

[celtic_druid]

If anyone wants to test it:
http://mirror05.x264.nl/celtic_druid/force.php?file=./x264vfw.exe

[Sharktooth]

New 293B builds up with the antony's vfw patch released.

[dimzon]

how about target filesize instead of target bitrate option?

[bob0r]

New 293B builds up with the antony's vfw patch released.

Arg, please remove the logo, when people use Themes (antony uses Silver theme), like me, it's ugly.
Maybe if it was transparent it could be fun, but the logo is only wasting space; download and vfw window wise...

http://mirror05.x264.nl/public/antony_vfw.gif

as for the VFW file itself... testing ;)

[Sirber]

logo's pretty cool :devil:

[hpn]

Hi All.
I am just now starting development on the x264. I woundered if there is any good documentation I can get in order to understand the source code better?

thanks.
All you can do is read the comments in the source (if any). Besides the H.264 official specs (search "h264.pdf" in google), you can also buy and read the Iain Richardson book
http://www.vcodex.com/h264mpeg4/index.html

[celtic_druid]

http://mirror05.x264.nl/celtic_druid/x264vfw.png
Looks ok to me.

[leowai]

http://mirror05.x264.nl/celtic_druid/x264vfw.png
Looks ok to me.
very nice! Good job, celtic_druid.
Will it be good to change the *.ico (icon) as well?

Still, we need to get permission from bob0r. :P

[Sharktooth]

new builds up (with updated logo)

[SeeMoreDigital]

new builds up (with updated logo)Thanks Sharktooth,

Great work guys... the new GUI makes things much clearer and simpler to understand ;)


Cheers

[Koti]

very nice :)

[hpn]

The tabs look nice. One wish: Now I have to click 8 times before starting each encode to check all my settings, just to make sure I haven't changed some of the options by mistake previously. I hope it's possible to add a small "No tabs" "Tabs" botton, changing label depending on what is currently active (next to "Load Defaults" button for example), to switch between all settings on one big screen (as it was before) and the new tabbed version. Once set, people just keep using the way that suits them best.

[foxyshadis]

The tabs look nice. One wish: Now I have to click 8 times before starting each encode to check all my settings, just to make sure I haven't changed some of the options by mistake previously. I hope it's possible to add a small "No tabs" "Tabs" botton, changing label depending on what is currently active (next to "Load Defaults" button for example), to switch between all settings on one big screen (as it was before) and the new tabbed version. Once set, people just keep using the way that suits them best.
This sounds like something better solved through profiles. (Not the mutating ones in megui, just normal ones.) You reset to a saved profile, and make any tweaks from that known config.

Very nice, overall. I think more of the advanced features could be pushed into one or two tabs rather than a half-dozen, but overall it looks cleaner and slicker.

[hpn]

Ok, suppose today I create 3-4 profiles for common encoding tasks ("Save Processing Settings" in VirtualDub in my case). I don't think when in a few days before starting a 20 hours encode, I'll simply load some of these profiles, without rechecking again all options. So with or without profiles I'll always end up clicking all tabs, unless I don't mind running the 20 hours encode again if something turns out to be wrong, like loading a wrong profile name, potential bugs in VirtualDub, etc, etc. Exactly the same holds true if I encode with MeGUI. IMHO profiles are overrated. I don't say that the tabs are bad, just let people choose what suits them best :)

[foxyshadis]

Ok, suppose today I create 3-4 profiles for common encoding tasks ("Save Processing Settings" in VirtualDub in my case). I don't think when in a few days before starting a 20 hours encode, I'll simply load some of these profiles, without rechecking again all options. So with or without profiles I'll always end up clicking all tabs, unless I don't mind running the 20 hours encode again if something turns out to be wrong, like loading a wrong profile name, potential bugs in VirtualDub, etc, etc. Exactly the same holds true if I encode with MeGUI. IMHO profiles are overrated. I don't say that the tabs are bad, just let people choose what suits them best :)
They're only overrated if you actually do check/change options all the time. All I ever change is bitrate; everything else never changes depending on if I'm encoding animation/real/streaming footage because I know they're already on the best settings I've found for that type. I can understand where you're coming from though.

[stephanV]

The old GUI is still in SVN, so download that and compile it yourself. Making two GUIs in one is a bit bloated IMO. Although I do agree that the new one has a few tabs too many perhaps.

[Sirber]

is it me or rev 295 is kinda lots faster than previous builds?

encoded frames: 3529/41516 (8.5%), 29.12 fps

I was around 21 before :D

[celtic_druid]

I don't see anything that would make it quicker. Did you compiled with the mmx/mmxext patches that were posted on the mailing list?

[Sirber]

I'm on Sharktooth build. I read on the changelog some functions were optimized MMX.

MMX quantization functions, and optimization of the C versions. ...
SSE2 pixel comparison functions ...

Could be that :)

[edit]

Seems to be in "fast first pass" only. Normal encoding is ~8 FPS as usual.

[celtic_druid]

That was for r293 though.
Revision 295:
fps patch by Haali

Revision 294:
* configure: added support for ia64, mips/mipsel, m68k, arm, s390 and hppa
platforms, as well as linux sparc.

Nothing there to increase speed.

[Sirber]

my last test was with 292 IIRC.

[celtic_druid]

That would explain it.

[el divx]

very nice! Good job, celtic_druid.
Will it be good to change the *.ico (icon) as well?

Still, we need to get permission from bob0r. :P

I have changed the installer graphic and the icon. I hope you like it.

[leowai]

I have changed the installer graphic and the icon. I hope you like it.
:thanks: I'll try it later... Waiting now ;) ... => attachment is currently pending for approval. :o

If it looks better than current version, probably we should suggest the developers to committe these into the SVN. :devil:

[bob0r]

Question for the smart guys:

my x264.exe commandline:
x264 --progress --pass 1 --bframes 2 --me dia --ref 1 --subme 1 --analyse none --output NUL cap.avs
x264 --progress --pass 2 --bitrate 1000 --bframes 2 --b-pyramid --weightb --ref 3 --subme 6 --8x8dct --analyse all --output video.264 cap.avs

In VFW is there a way to "disable" bitrate for pass 1?
Or because i save cap_pass1.avi and cap_pass2.avi this is a stupid question, and VFW can't output to NUL?


As for the settings themself, profiles in VFW would be awesome, you could just save all your pass1/pass2 etc... settings, just the way you want them, good idea!

[Sharktooth]

Im already preparing a new installer script and all the stuff to commit to the SVN.
Please have some patience :)

[bob0r]

Maybe await el_divx's icon :)

[Sharktooth]

im awaiting... :P

[Antony]

Right, 8 tabs was a lot... Here is the same window with only 4 tabs :)
http://members.shaw.ca/antony.boucher/download/vfw_4_tabs.zip

[stephanV]

Looks good to me :)

[Sharktooth]

thanks. the next builds will feature the new vfw patch and some other changes in both full and lite packages.

[el divx]

All I've done is take bobor's logo(sorry for not asking you first, bobor) and use it on the default installer script as well as paste it over the old icon's logo to make it look better. You can find it all in the file I attached above.

[bob0r]

All I've done is take bobor's logo(sorry for not asking you first, bobor) and use it on the default installer script as well as paste it over the old icon's logo to make it look better. You can find it all in the file I attached above.

That's no problem, its only $500 per pixel.

Email me the file, and ill put in on http so we all can enjoy it.
Sent to el_divx [at] x264.nl (or any other random [at] x264.nl)
gmail to store all! :devil:

[Sharktooth]

New builds up. Installer script is still unchanged (had no time to update it).
Please test the VFW interface.

[foxyshadis]

Sharktooth, just curious, will your new installer script include a reg key with the last installed-to folder?

[bob0r]

I just updated my gpac (cvs up)
make clean
make

gpac\bin\gcc\libgpac_static.a copy to \MinGW\lib
gpac\include\gpac copy to \MinGW\include

svn co svn://svn.videolan.org/x264/trunk x264_test
cd x264_test
patch -p0 < x264_mp4_output_gpac_04x_update.0.diff
configure --enable-vfw --enable-avis-input --enable-mp4-output --enable-pthread

make clean
make

Error:
Creating library file: x264vfw.dll.a
make[1]: Leaving directory `/home/user/x264_test/vfw/build/cygwin'
gcc -Wall -I. -O4 -ffast-math -D__X264__ -DHAVE_MMXEXT -DHAVE_SSE2 -DARCH_X86 -DSYS_MINGW -DAVIS_INPUT -DMP4_OUTPUT -DHAVE_PTHREAD=1 -s -fomit-frame-pointer -DHAVE_GETOPT_LONG=1 -c -o x264.o x264.c
x264.c: In function `recompute_bitrate_mp4':
x264.c:1426: warning: dereferencing type-punned pointer will break strict-aliasing rules
x264.c:1426: warning: passing arg 1 of `gf_odf_desc_del' from incompatible pointer type
x264.c: In function `open_file_mp4':
x264.c:1471: error: too few arguments to function `gf_isom_open'
make: *** [x264.o] Error 1

Sharktooth? Superdump? Anyone else?

[SeeMoreDigital]

New builds up.... Please test the VFW interface.Just used the new VfW interface to generate two anamorphically signalled test encodes, one with 2 B-frames, one without B-frames.... Seems to work well ;)


Cheers

[celtic_druid]

@bob0r, from anyone else.

You neeed to add , NULL to the function.

p_mp4->p_file = gf_isom_open(psz_filename, GF_ISOM_OPEN_WRITE, NULL);

[leowai]

I just updated my gpac (cvs up)
:
:
Sharktooth? Superdump? Anyone else?
Me too. I believe it's because the changes in isomedia file open API in gpac on 20th Sep 2005:
Latest CVS Changes 20/09/05
- changed isomedia file open API for better support of temporary directories

It takes additional input for the mp4 creation, this need a newer patch for the mp4 support.

If you want a quick solution, back to gpac CVS on 19th Sep 2005.

@bob0r, from anyone else.

You neeed to add , NULL to the function.

p_mp4->p_file = gf_isom_open(psz_filename, GF_ISOM_OPEN_WRITE, NULL);

I'll try this first. :D Thanks.

[edit]: This works. Thanks celtic_druid. :)

[celtic_druid]

NULL sets it to the default temp dir.

[bob0r]

...
If you want a quick solution, back to gpac CVS on 19th Sep 2005.
...


Stupid question: How do i go "back to gpac CVS on 19th Sep 2005"?

And where do i find:
Latest CVS Changes 20/09/05
- changed isomedia file open API for better support of temporary directories

This changelog?

[celtic_druid]

Run cvs with -D date .

The changlog is in ./gpac/changelog

[leowai]

Stupid question: How do i go "back to gpac CVS on 19th Sep 2005"?

And where do i find:
Latest CVS Changes 20/09/05
- changed isomedia file open API for better support of temporary directories

This changelog?
Yes, changelog of gpac. Well, since you got the latest gpac, try celtic_druid's method. It works for me. :)
@bob0r, from anyone else.

You neeed to add , NULL to the function.

p_mp4->p_file = gf_isom_open(psz_filename, GF_ISOM_OPEN_WRITE, NULL);
Find the function in the patch file, add the NULL accordingly before apply the patch.

[el divx]

After applying the patch, here's what I get when the process starts building VFW:make -C vfw/build/cygwin
make[1]: Entering directory `/home/x264/vfw/build/cygwin'
D: /home/x264/vfw/build/cygwin/bin
C: ./codec.c
C:/msys/home/x264/vfw/build/cygwin/../../x264vfw.h:132: warning: 'tabs_enable_items' declared `static' but never defined
C:/msys/home/x264/vfw/build/cygwin/../../x264vfw.h:133: warning: 'tabs_update_items' declared `static' but never defined
C: ./config.c
C: ./driverproc.c
C:/msys/home/x264/vfw/build/cygwin/../../x264vfw.h:132: warning: 'tabs_enable_items' declared `static' but never defined
C:/msys/home/x264/vfw/build/cygwin/../../x264vfw.h:133: warning: 'tabs_update_items' declared `static' but never defined
W: ./resource.rc
C:/msys/home/x264/vfw/build/cygwin/../../resource.rc:10:20: afxres.h: No such file or directory
c:\mingw\bin\windres.exe: C:/msys/home/x264/vfw/build/cygwin/../../resource.rc:20: syntax error
make[1]: *** [resource.obj] Error 1
make[1]: Leaving directory `/home/x264/vfw/build/cygwin'
make: *** [x264vfw.dll] Error 2

[bob0r]

@celtic_druid
Thanks that worked

@leowai:
Thanks, what celtic_druid said indeed worked :P

@el divx
Yo, email me the installer.7z
( http://forum.doom9.org/showthread.php?p=714574#post714574 )

[Kurtnoise]

@Antony : Great stuff...:) Could you add zone options a_la_xvid ? Thanks...

[leowai]

After applying the patch, here's what I get when the process starts building VFW:
C:/msys/home/x264/vfw/build/cygwin/../../resource.rc:10:20: afxres.h: No such file or directory
Your compilation platform can't find the required file "afxres.h"! My MinGW just works out fine here. :)

Tried clean compilation?
make clean
make
If this fails, I suspect of faulty compilation platform. ;)

[el divx]

Your compilation platform can't find the required file "afxres.h"! My MinGW just works out fine here. :)

Tried clean compilation?

If this fails, I suspect of faulty compilation platform. ;)

Thanks leowai. I installed the latest version of MinGW and now it works.

[bob0r]

I have changed the installer graphic and the icon. I hope you like it.

the file: http://mirror05.x264.nl/el_divx/installer.7z

I must say, i have tried the same win.bmp as you did, i removed it, for 2 reasons, 1 its ugly when its not horizontal and 2 its adding to the filesize of the installer.

x264vfw.ico i will be using tho, thanks :)

[Sharktooth]

Sharktooth, just curious, will your new installer script include a reg key with the last installed-to folder?
Yes. It will also include the ability to choose what do you want to install (cli, vfw, megui etc.), an option to uninstall any previosly installed versions and will add a start menu link to a small app to check for new versions.

[Sharktooth]

@celtic_druid
Thanks that worked

You can find a working gpac 0.4.x patch in the x264 daily builds thread. It works with the latest gpac sources.

EDIT: Maybe some headaches could be avoided if i knew celtic druid posted the fix in the previous page... 't was my fault, though... :)

[Sirber]

rev 293 changes gives me ~10 FPS more in fast first pass and ~1.5 FPS more with all options. sweet :D

(AMD64 3000+, 1GB DDR400)

[bob0r]

@sharktooth:
Yup akupenguin/pengvado asked in the irc channel is the patch should be commited, but then i tested it, and it failed to compile :p
Now i just tried it again, and with your patch it indeed "still" works fine, so time to commit it, and start working on the --fps 29.97 .mp4 output bug :D

@el divx:
Can you please make a NSIS compatible icon for the installer(uninstaller) too?
I tried several bmp/gif to icon converters, but all failed, they remain 24 or 32bit according to windows properties.
http://www.nullsoft.com/free/nsis/makensis.htm >
Icon path_to_icon.ico "Sets the icon of the installer. The icon MUST contain a 32x32x16 color icon resource (it can also contain other icons, but they will be discarded)."
UninstallIcon path_to_icon.ico "Sets the icon of the uninstaller. Again, the icon MUST contain a 32x32x16 color icon resource (it can also contain other icons, but they will be discarded)."
Please look into it.

(Extra question, i added !define Icon "x264.ico" and !define UninstallIcon "x264.ico" to x264-conf.nsi, that should be correct right, sharktooth?)

Edit: No longer needed, thank you!

[Sharktooth]

It "should" be right. But some versions of NSIS had some bugs, so if it doesnt work check your NSIS version and eventually update it...

However the gpac patch works like a charme, it's time to submit it (and hope JLF doesnt make API changes any more...).
If you meet pengvado on irc tell him to get the patches directly from the daily builds thread. Also the VFW patch seems to work ok, so...

[bob0r]

It "should" be right. But some versions of NSIS had some bugs, so if it doesnt work check your NSIS version and eventually update it...

http://nsis.sourceforge.net/
NSIS 2.09 released - 26-08-05

It seems the icons in C:\Program Files\NSIS\Contrib\Graphics\Icons also show 32x32 with Bit Depth 32 (windows xp/properties/summary)
In fact, all is the same with my icons:
Width 32 pixels
Height 32 pixels
Horizontal Resolution 96 dpi
Vertical Resolution 96 dpi
Bit Dept 32
Frame count 1

I tried
!define ICON "C:\Program Files\NSIS\Contrib\Graphics\Icons\arrow2-install.ico"
and
!define ICON "arrow2-install.ico"

So guess what:
http://nsis.sourceforge.net/Docs/Modern%20UI/Readme.html >
"
Important: Because the Modern UI has its own macro system, its own default settings and a lot of new features, the interface configuration works differently. So you should not use commands like LicenseText, Icon, CheckBitmap, InstallColors etc.
"

MUI_ICON icon_file
The icon for the installer.
Default: ${NSISDIR}\Contrib\Graphics\Icons\modern-install.ico

MUI_UNICON icon_file
The icon for the uninstaller.
Default: ${NSISDIR}\Contrib\Graphics\Icons\modern-uninstall.ico

I forgot we used MUI again, problem solved! :D ;) :o

[Sharktooth]

MUI_ prefix should be used if you use the Modern UI. Some standard NSIS commands are replaced by MUI versions and won't work with MUI unless you use the specific MUI replacements.
However MUI should be integrated in the next major NSIS version.

[hpn]

Congratulations on rev. 300 :)

The 4 tabs are beautiful. And to make everything perfect I think the second and third tabs
("Rate Control" and "I/P/B/Frames") should switch places, cause the Rate control options
are less likely to be changed with each encode (I usually don't touch them) than some of the
options on the third tab.

http://img343.imageshack.us/img343/8701/x2643000rt.png

[virus]

"8x8 DCT" is hardly a feature belonging to the "I-frames" group ;)
(and I still prefer the term "integer transform" or simply "transform" instead of DCT. H.264 does not use the DCT at all)

Also, the name "Quality" for the quantization limits (min/max qp and max step) is highly misleading imho.

[akupenguin]

There aren't any options specific to I-frames (other than ratecontolr/scenecut). The "8x8 intra search" and "4x4 intra search" flags apply only to P & B-frames. I-frames always use all available MB types.

[Kostarum Rex Persia]

But why Sharktooth removed all patches from rev. 300??? I think that is bad idea,because some of the patch was worked very good job in increase of speed and quality of x264 codec.

Sharktooth,can you,please,put these patches in build 301 or 302.I mean mainly on Johannes Reinhardt patch for Intra prediction mode,and,of course,Christian Heine new MMXEXT SATD functions that are slightly
faster than the original ones on Athlon XP and another his patch.

I put these patches as attacments.It's shame if these very good patches won't be included in future builds.

So,I need opinion of you,guys.What do you think,is these patches deserve to find place in futute revisions of x264?

[Kostarum Rex Persia]

Another question,from where I can directly download pengvado builds of x264.I am subscribed to x264 development from http://developers.videolan.org/lists.html ,but in the emails,I never get the download link for the newest builds.

[berrinam]

But why Sharktooth removed all patches from rev. 300??? I think that is bad idea,because some of the patch was worked very good job in increase of speed and quality of x264 codec.Can you not read? From Sharktooth's sticky, the Build Changes section says quite clearly:
(r300) Removed all patches, they were all finalized and submitted to the SVN repository. Updated GPAC sources.
I think that clears it all up, doesn't it? There is a reason for forum rule 1.

Another question,from where I can directly download pengvado builds of x264.I am subscribed to x264 development from http://developers.videolan.org/lists.html ,but in the emails,I never get the download link for the newest builds.
What are you talking about? There are no 'pengvado builds'. The newest builds can be found on Sharktooth's sticky.

[omion]

Umm... The changelog indicates that the patches were removed because they were merged with the x264 code. There's no point in applying the patches since it's now in the trunk source.

[edit: Oops. berrinam beat me to it]

[Kostarum Rex Persia]

Omion,are you sure that that patches now in the trunk source? Can anyone confirm it?

[berrinam]

@Kostarum Rex Persia: I quoted Sharktooth's sticky, where he said that the patches are now committed. Do you really think he would lie about that? For further proof, see the changelog (https://trac.videolan.org/x264/log/trunk/), which is also linked to from Sharktooth's sticky. There is no need to fear that the progress on x264 would go backwards. The developers are not stupid.

[omion]

Omion,are you sure that that patches now in the trunk source?I don't know what those patches were, exactly, but if they looked anything like this (https://trac.videolan.org/x264/changeset/296), this (https://trac.videolan.org/x264/changeset/297), or this (https://trac.videolan.org/x264/changeset/298), then there's no need to worry. (I do notice that the first one is by Johannes Reinhardt and the other two by Christian Heine, just as the ones you described...)

Can anyone confirm it?Yes... YOU can! The source is free and open on the internet. It took me 2 clicks to get to the links above from the x264 sticky.

I think you're being a bit too paranoid about the whole thing... If patches work, then they get committed. If they break, then they don't. As berrinam says, there's no need for anybody to lie about it... :rolleyes:

[Sharktooth]

But why Sharktooth removed all patches from rev. 300??? I think that is bad idea,because some of the patch was worked very good job in increase of speed and quality of x264 codec.

Sharktooth,can you,please,put these patches in build 301 or 302.I mean mainly on Johannes Reinhardt patch for Intra prediction mode,and,of course,Christian Heine new MMXEXT SATD functions that are slightly
faster than the original ones on Athlon XP and another his patch.

I put these patches as attacments.It's shame if these very good patches won't be included in future builds.

So,I need opinion of you,guys.What do you think,is these patches deserve to find place in futute revisions of x264?
I hope that's a joke....
Another question,from where I can directly download pengvado builds of x264.I am subscribed to x264 development from http://developers.videolan.org/lists.html ,but in the emails,I never get the download link for the newest builds.
still joking?

[Kostarum Rex Persia]

I am sorry,Sharktooth,I didn't read carefuly your sticky.Can you forgive me?

[Sharktooth]

sure ;)

[Kostarum Rex Persia]

btw,I read on the x264 mailing lists that " In its current
state, x264 is already quite efficient. Don't expect outstanding quality
boost in the near future ( a fair boost would be 0.3 dB, which I think
can be reached, and which represents roughly a 6% bitrate saving with
the same quality ). Now it's up to you to see how much time you can wait.

Feature-wise, AlexI is working on adding interlacing support to x264,
so, of course, if your streams are interlacing, I'd advise to wait. In
any other case, I'd encode right away ( you can't wait indefinitely ),
but you might think otherwise." (quote from Mathieu Monnier)

That's sounds very promising,I hope that interlace support will be ready in the next 3-4 months.