x264 development

[Sirber]

Thanks for the info, but I just want to use M$ Visual Studio 6... ;)

[edit]

Got it. Had to convert files to DOS (\n). Now finding my was though the missing files :)

C:\x264\encoder\set.c(27) : fatal error C1083: Cannot open include file: 'inttypes.h': No such file or directory

[virus]

Originally posted by hellfred
Then go to x264/vfw/build/cygwin and run yet again make, followed by make install to install the x264vfw dll.
When building the VfW frontend I recommend using "make NDEBUG=1" which strips the resulting DLL to a much lower size (no debug infos included).

BTW revision 107 is available. Fixes the errors in the Registry management which plagued several people (but not me, that's why I didn't have any clue about the problem). Thanks to len0x for reporting the issue and testing it against both VDub and GK :)

virus

[niamh]

All issues fixed so far with rev 107. I'm a happy camper :)

[yaz]

Originally posted by niamh
All issues fixed so far with rev 107. I'm a happy camper :) yes, u are :-) i don't see this ver anywhere
the bests
y

[len0x]

New error it seems :) I'll try to grab exact error message (now encoding a sample second time). Anything specific I should report? (I can make sample available for developers to look at as well).

P.S. setup was: all defaults + 1 b-frame + 5 reference frames. The following error during second pass (always reproducable):

Assertion Failed
Program: ...VDub
File: ... ratecontrol.c
line: 372

Expression: frame>= 0 && frame< rc->num_entries

[niamh]

I got that error in VDM too (though muxing audio), as well as 2nd pass crashes, and only got rid of the errors by totally scouring the registry and reinstalling rev 107. It did work for me.

[akupenguin]

Can you reproduce the crash using the x264 commandline and/or mencoder? (It may be related to the lack of B-frame flushing in VfW.)

Either way, please provide a source (preferrably as small as possible) and 'x264.stats'.

[len0x]

Originally posted by akupenguin
Can you reproduce the crash using the x264 commandline?


where can I get one?
(never tried mencoder either)

Originally posted by akupenguin

Either way, please provide a source (preferrably as small as possible) and 'x264.stats'.

Sure, tomorrow I'll put up 70Mb file. In the meantime I have attached stats file (hopefully mods will authorize it soon).

P.S. crash is happening at about 40% through second pass.

[Sergejack]

Originally posted by len0x
where can I get one?
(never tried mencoder either)



Sure, tomorrow I'll put up 70Mb file. In the meantime I have attached stats file (hopefully mods will authorize it soon).

P.S. crash is happening at about 40% through second pass.

Could it be related to a screen saver ? (assuming you left your computer while it encoded)

[len0x]

No, I never use screen savers :)

Anyway I got x264.exe rev 105, but I can't seem to get it working - it just quits on me without any errors. What should be an input for it? Can it be avs file?

*Edit* nevermind, I dound AVS2YUV utility

[virus]

Originally posted by len0x
New error it seems :)
Error, yes. New, no. :)
(I reported it (http://forum.doom9.org/showthread.php?s=&threadid=87719&perpage=20&pagenumber=1) in the sex264 thread 3 weeks ago, and it has been observed by several people since then).

It is likely to only happen with VDub though (since it's related to the statsfile length and VDub mangles away frames in all encodings with bvops), so I guess you won't be able to reproduce it with mencoder or the commandline encoder.

EDIT: now that I re-read my own report, that time I triggered the error with all settings @ default, and that means no bvops... too bad I haven't be able to reproduce it later :/

[len0x]

I was able to reproduce the error with x264.exe by doing just second pass with the stats file that I had from first pass done in VDubMod. Shall I redo first pass in command line as well?

*Edit* It is stats file problem - stats file for some reasons only contain 40% of frames when encoded in VDubMod. What's up with that?

[akupenguin]

Originally posted by len0x
nevermind, I found AVS2YUV utility Actually, avs2yuv won't work for this: it produces yuv4mpeg, while x264.exe wants raw.

P.S. crash is happening at about 40% through second pass. That's weird. I would expect a crash from B-frame munging to happen only in the last few frames of the 2nd pass.

[len0x]

OK, mystery's solved: somehow first pass produced incomplete (40%) stats file. So during second pass when it reaches the end of stats file - assertion error is thrown. I cannot reproduce first pass short stats file anymore though (it seems to be runnning fine now).

[buzzqw]

i am unable to configure the x264vfw.dll by the usual

rundll32.exe x264vfw.dll, Configure

i can do it with xvid but not with x264 ?

any tips ?

BHH

[celtic_druid]

I just had a look at the driverproc.def file for both and Configure is commented out in x264's but not in XviD.

My tip.. Whatever you are using for encoding should give you access to the config.

[buzzqw]

for sure i can use virtualdub !
but i also use several batch file for xvid and want to use these for x264 too.

thanks anyway

BHH

[celtic_druid]

Batch file? But wouldn't you still have to manually change the config? I would have thought that reg files would make more sense. Anyway for revison 108 I uncommented Configure and it seems to work fine, so I would suggest you update to that.

[CruNcher]

Black Block bug seems fixed finaly :)


Fix clipping of mvs in probe_pskip. (Previously it mixed up fullpel with qpel.) This should eliminate the black blocks that sometimes appeared in high motion, low detail scenes.


Rev 108 compiling :)
Jep fixed :)
looking for the Red Block Bug :D

[Sharktooth]

It's already up on the CD's website mirror.

[buzzqw]

Thank Celtic_Druid ! and Sharktooth too for mirror!

I use batch first to ask setting for first pass (and then reg export), ask setting from second pass (and then reg export).

I calculate the avarage bitrate, run a the first encoding, import 2'reg, import a customized reg with average bitrate and the run the final second pass ! :D

BHH

[CruNcher]

@Sharktooth
i use my own compiles with my own tested Cflags but anyway thx :)
Red block bug still there (dont worry it only gets visible with strange CruNcher settings ;))

[Sharktooth]

well, that's the 2nd case of "let me play with sources" this week :D
at least the mirror is there for the "i don't know how to compile it" ppl :)

[Sergejack]

What's the most recent Vdub, VdubMod to use with x264 in order to have B-frame avliable ?
And what's the (working) max B-frame to set ?
And at last, what container can be used with that ?

Sry, I'm kinda lost with the therory vs hack.

[plonk420]

here's a new question: does ffdshow smooth too much or does nero decode crappily (or not filter properly in mpc)?

ffdshow/x264
http://s91855708.onlinehome.us/sakuradrops/sakura0223-x264.png
nero
http://s91855708.onlinehome.us/sakuradrops/sakura0223-nero.png

you might have to save as, then view at 200%, but i *did* pick it up while i was playing it, so i took a screenshot and compared the two.

note: i DO like the smoother ffdshow better than the nero playback.
note2: generated by x264, 2pass, 800kbps
note3: there's also Zoom Image (extension) for Firefox ^_^ zoom to any percent
note4: i nominate Utada Hikaru's mvid Sakura Drops as at least one of the vids used to torture codecs ^_^ ...fades, crisp reds, transparency requiring chroma motion, cg+photographic images, a complex overlay moving over a photo (hiki's face, singing), and i'm sure another thing or two i haven't had an eye out for yet...

[Sharktooth]

x.264 build 109 is up on the main CD mirror.
The SVN is updated to rev 110

EDIT: rev 111

[CruNcher]

Red block bug is fixed with rev 109 another clipping problem was the couse :)

[Sirber]

is the bug about HDTV rez fixed?

[Sergejack]

Originally posted by Sergejack
What's the most recent Vdub, VdubMod to use with x264 in order to have B-frame avliable ?
And what's the (working) max B-frame to set ?
And at last, what container can be used with that ?

Sry, I'm kinda lost with the therory vs hack.

Pls don't miss my question.

[bond]

Originally posted by Sergejack
Pls don't miss my question. - you should be able to use any vd(m) version without having b-frame problems
- you can use .avi, .mkv and .ogm in vdm
- max number of b-frames: using an incredible high number of b-frames wouldnt make much sense anyways

[niamh]

I've tried to mux audio (cbr mp3) and x264 1 B-frame encode in vdubmod in an ogm container (ogm to ogm), and it failed miserably. Other than that it encoded the video fine, you'd just need to mux the audio with another app in this very particular case. Avi and mkv seem to be fine, as well as ogm with no B-frame.Encoding video is fine all round, as far as I tried it.

[Ark]

Anyone noticed that deblocking settings other than 0 always increase filesize in a costant Q encode (in my tests)?

A deblock+6 encoding show an increment of about 16% over a deblock0 encode, but a deblock-6 also show some increment, much smaller though (around 1-2%).
I can lower quantizer by 1 with deblock0 getting only a slightly bigger file (with much better quality) than the deblock+6 file!

My question is: is it normal, is the way it's intended to be?

[akupenguin]

Size at constant quant is a bad measure of the quality of compression settings.
For deblocking settings, don't trust PSNR either.
By definition, deblock=0 should be the best in most cases, otherwise something else would have picked to be "0". (It's not an absolute strength, but rather an offset into an array of presets.)

[Mug Funky]

@ plonk420:

the only big diff i see (i haven't lined them up in ACDsee or anything... just scrolled up and down) is that ffdshow appears to be decoding to yuy2 and nero is decoding to yv12.

i imagine you'll get almost identical results if you set ffdshow to yv12 output.

just a hunch though :) the background seems oversmooth in both of them. denoising? i find it's good to check for overfiltering with the lights off and the monitor jacked up to full brightness. gives an idea of what a TV would display

@ devs: i'm really amazed by the progress this codec is making. if i was more fruity i'd kiss you all, and if i was richer i'd buy you all presents :)

[Yong]

Thanks to the x264 devs,
this codec was improved alot,
now i can go down to 400Kbps (640x480 30fps),
and the video quality still fine:D

[virus]

Hi! For those interested, here (http://www.webalice.it/riccardo.stievano/video_stuff/x264-enc-pack.zip) you can find a little "encoding pack" for MSYS/Cygwin users to run AVS->AVI multipass encodings using a single command in the shell.

It contains: a slim-size version of mencoder, with x264 support only (other stuff disabled)
avs2yuv by akupenguin
scripts for automated 2pass and 3pass encoding
The scripts roughly reproduce the default settings in VfW (but with 3 ref. frames instead of 1), including fast1pass. Also in 3pass mode the second pass is "half-fast". Anyway, feel free to hack the scripts as you wish. ;)

A bit of logging (MB stats, encoding start/end times, PSNR) is also produced for each pass. Further details in the readme. The build works for both AMD/Intel processors and is based on revision 112. Download size: ~720 KB (zip)

enjoy :)
virus

[Ark]

Originally posted by akupenguin

Size at constant quant is a bad measure of the quality of compression settings.
For deblocking settings, don't trust PSNR either.
By definition, deblock=0 should be the best in most cases, otherwise something else would have picked to be "0". (It's not an absolute strength, but rather an offset into an array of presets.)



I don't want to measure quality, but only point out that strangeness (for me) of filesize differencies...
Well i never did PSNR tests and never will do (i trust more my eyes...)
That is confirmed in my small and probably useless test...

Btw, i want to clarify that i meant "better quality" only because the bitrate savings using db0 is enough for decrease Q by 1 with almost same filesize, so getting better quality is obvious.

[Sharktooth]

rev 112 binaries are up on the usual mirror.

Edit: anyone tried this one? it seems to "close" my Vdub without warnings or messages...

Edit2: more info, with deblocking strength (A/B) set to -2 the encoder crashes closing virtual dub some seconds after the beginning of the second pass... more info as i test it...

[Koti]

same same - x264 v112 2nd pass in vdub mod closed on start. went back and looked in job control and it says it was aborted . restarted just the 2nd pass and it suceeded.

edit - 2nd pass aborts everytime without warning in a batch for me.

[Leo 69]

Sorry if it was mentioned before but is there any quality difference between fast first pass and not fast ? BTW I have lots of problems with rev 112 too - VD wiped out in all X264 modes. I thought it was a problem with the script and tried another codec (VP6) - it was encoding just fine! Then I switched back to X264 and now I'm running the first pass of two in a batch. I'm very scared it'll crash again when it starts the second pass :(

[virus]

I've just compiled VfW rev. 112 and I have no problems whatsoever with Vdub (tried 1pass and 2pass). Anyway I've uploaded my build here (http://www.webalice.it/riccardo.stievano/video_stuff/x264vfw.dll) for those willing to try it.

Also my mencoder-based encoding pack (http://www.webalice.it/riccardo.stievano/video_stuff/x264-enc-pack.zip) seems to work perfectly (it's rev. 112 too).

[Leo 69]

It seems to me the 112 build is definitely corrupted. Why? Because 111 works PERFECTLY

[Tommy Carrot]

Originally posted by Leo 69
It seems to me the 112 build is definitely corrupted. Why? Because 111 works PERFECTLY Revision 111 is better, but it's not perfect either, it crashes sometimes at some particular resolutions (i've got crashes at 768x576 and 1280x720, but there might be other problematic resolutions). Imo rev. 112 (virus' build too) just triggers that bug more often.

[akupenguin]

Originally posted by Leo 69
Sorry if it was mentioned before but is there any quality difference between fast first pass and not fast? Yes, but you gain more quality by using slower options on the 2nd pass than you do by using full quality 1st pass.

[spyder]

@virus

The encoding pack is awesome! ;)

[superdump]

virus has bribed me to say that his little script package rules the earth.

Not really. I've been testing it and I haven't had any problems with any of the builds to date. They all work well and the only 'problem' we've encountered is the frame loss with b-frame usage.

I've just completed a fully-functional 2-pass encode using the revision 112 build and it was fine.

[JoeBG]

Originally posted by virus
Also my mencoder-based encoding pack (http://www.webalice.it/riccardo.stievano/video_stuff/x264-enc-pack.zip) seems to work perfectly (it's rev. 112 too).

It works perfectly with MeGUI. Impressing results. Why this quality improvement in the last 3 weeks? Congratulation :)

[Yong]

Can someone please explain, how the nthpass encoding process work?
Is it will increase the quality with nthpass by using the lower bitrate?
I only tried until 3th pass, with 400kbps.
Any difference with 2pass encoding with 400kbps?

sorry for my bad english...

[Sharktooth]

Rev. 113 binaries are being mirrored at the usual place.
changes:
Simplify x264_cabac_mb_type.

[Palmnut]

Forgive a question from a lurker please.

Are there 'release notes' somewhere associated with the different builds? I'm thinking of functional notes along the lines of "fixed the bug in CABAC when executing on the 47th pass" rather than code details, i.e. 'changed the + sign in line 457 to a - sign'.