x264 development

[len0x]

Kudos to Syskin who made rev 128 compilable on MSVC! The only bit that I had to tamper with is manually define integer types because intypes.h is not present in MSVC. (VC version is definitely slower than gcc builds though)

[lithoc]

I am using x264 r128 + P4 2.8ghz(Northwood) + 1 GB RAM

I couldn't get x264 to work!!!

I've tried using it with avs2avi, it didn't work either.

Did I missed anything?

BTW, I've tried using mencoder. It works for me now but no B-Frames!!!

my cli is

mencoder - -nosound -noskip -o "new\temp.264" -ovc x264 -x264encopts keyint=500:frameref=15:deblockalpha=-3:deblockbeta=-5:ip_factor=1.4:pb_factor=1. 3:cabacidc=2:scenecut=40:cabac:8x8mv:4x4mv:b8x8mv:direct_pred=2:subq=5:qp_step=1:qp_min=10:qp_max=51:bframes=4:bitrate=2048 -ffourcc X264 -of rawvideo

CLI Log:
C:\Temp>x264 -o h1.h26l --rcbuf 64000 -B 128 --sar 4:3 --fps 23.97 --no-psnr c:\temp\t3video.avs 320x240
x264 [info]: using SAR=4/3
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2


C:\Temp>

[virus]

@lithoc

As for avs2avi, there's a new version which supports x264 (previous versions don't). As for the CLI encoder, it takes raw YUV as input, it cannot work with AVS files. As for mencoder, looks like you've ripped (an incomplete piece of) someone else's commandline without knowing what it does ;)

Have a look at my encoding pack (link in Sharktooth's sticky) if you want to use mencoder with some multipass scripts, or update avs2avi, or use VDub(mod).

hope this helps
virus :)

[Yong]

@virus:
I tried, it's work :)
but still can meet the target bitrate=800kbps,
with my poor "fast" first pass settings, the video bitrate is 359kbps,
after use the correct first pass, bitrate increase, 627kbps.
haven't try with nthpass encoding:p

@lithoc:
Don't try to copy my dangerous x264 CLI encoding options:p

[Sergejack]

Is the Jim Casaburi's temporal cleaner for VDUb somewhat useless with X264 ? As in the question "I'am a rigth thinking, there already is a natural similar effect due to bit not wasted on too low changes?"

I ask because I cannot manage to make that filter work on AVS (someone knows?).

[Sharktooth]

@Yong: try the new rev.130. It has significant changes to the rate control.

@Sergejack: Filtering "changes" the source in some way and it always matters for any codec.

[igor1st]

x264 VFW, default settings, max ref=15, no fast first pass, builds r130 by Sharktooth and r127 by celtic_druid.
VirtualDubMod closes silently on early stage of first pass (last frame in stats file is 4204). It's 100% repeatably.
Max ref=5 - no problem.
Now I run this encode with ref=5. Afterwards I will try to determine from which value of max. refs this problem occurs.

[Arkoki]

The last ARCalculator uses avs2avi to compress and it compress in x264 perfectly.
This version is in English too.
Here to download www.canalxvid.com

[dragongodz]

x264 VFW, default settings, max ref=15, no fast first pass, builds r130 by Sharktooth and r127 by celtic_druid.
VirtualDubMod closes silently on early stage of first pass (last frame in stats file is 4204). It's 100% repeatably.
Max ref=5 - no problem.
ok i dont know if this has anything t do with it or not, also i am going from memory since i had a look and cant find the particular post(theres a lot to go through :) ).
akupenguin mentioned and showed that the size of referenced frames can fill the buffer before that total reference total. that is you may have a reference of 15 frames but only be able to buffer 13 frames(from memory that was the amount he gave the example to). is the default 15 ? if yes then maybe setting the default to less may be a good idea.

i am sure he will correct what i just said and say i mixed it up or it is not relevant. ;)

[akupenguin]

the size of referenced frames can fill the buffer before that total reference total. That's a function of levels, which x264 ignores. It could conceivably cause a hardware player to fail, but won't affect encoding or software decoding.
And the default is now level 4.0, which allows a buffer size of 12MiB, which is 20 reference frames at 720x576.

[dragongodz]

It could conceivably cause a hardware player to fail, but won't affect encoding or software decoding.
i suspected as much but as i said i couldnt find where you talked about it before. these threads are so dman big now. thanks. :D

[Yong]

Originally posted by Sharktooth
@Yong: try the new rev.130. It has significant changes to the rate control.

@Sergejack: Filtering "changes" the source in some way and it always matters for any codec.

Yes, downloading now, try it later...:)

BTW i also have the same problem with igor1st, can i post the crashinfo.txt(generate by VirtualDub)here? i thinks it's helpful for x264 devs:)

[Sergejack]

Originally posted by Sharktooth
@Sergejack: Filtering "changes" the source in some way and it always matters for any codec.

It's about the Rate Distribution, if two consequential blocks are almost the same (like : PSNR Block1 - PSNR Block2 < Epsilon) does X264 still use some bits to show the unvisible changes (wich would most likelly introduce noise), or are those bits used on more bit needing blocks ?

Consider I use very low bitrate most of the time.

[akupenguin]

Yes, x264 skips blocks if the change is small. But if you don't sufficiently denoise the source, that noise might be enough to put some blocks over the threshold (even at very low bitrate).

[Sharktooth]

I always denoise (i use a combination of light filters so it wont hurt too much quality or details) so the encoder can work at it's best.
Most movies have added noise so... sometimes i just re-add that noise during playback with post-processing filters (ffdshow). It's just a matter of taste.

[igor1st]

Now I run this encode with ref=5. Afterwards I will try to determine from which value of max. refs this problem occurs.
I made some quick tests. Seems that with refs value below 15 this problem didn't occurs (at least on same position).

[Sergejack]

Originally posted by akupenguin
Yes, x264 skips blocks if the change is small. But if you don't sufficiently denoise the source, that noise might be enough to put some blocks over the threshold (even at very low bitrate).

Skips blocks ?... What about the motion data (vector) ?

[akupenguin]

H.264 predicts a motion vector for all blocks, based on the neighbors. A skipped block simply uses that predicted mv, with no further correction. A non-skipped block encodes the difference from the predicted mv, and then the texture residual.

[Sergejack]

Originally posted by akupenguin
H.264 predicts a motion vector for all blocks, based on the neighbors. A skipped block simply uses that predicted mv, with no further correction. A non-skipped block encodes the difference from the predicted mv, and then the texture residual.

As expected, but got to make sure of that ^^
Good, good. :D

[dragongodz]

skipped blocks go all the way back to mpeg1 so its not something new to be worried about. :)

[Sergejack]

Originally posted by dragongodz
skipped blocks go all the way back to mpeg1 so its not something new to be worried about. :)

It didn't sound so needed by the VP6 devs then.

[bob0r]

Package mingw32 installed.
Package subversion installed.
Package nasm installed. (http://nasm.sourceforge.net/wakka.php?wakka=HomePage nasm-0.98.38)


How do i compile x264vfw.dll with debian?

svn co svn://svn.videolan.org/x264/trunk x264
cd x264

... and then?

Edit:
Never mind i guess, i can compile it in windows now :D

[hpn]

Just finished a full movie speed test, 153'032 frames, frame size 688x288,~700kbps, insane codec settings:

x264 - revision 136 (slow first pass, mRF 15, mBF 1 temporal, all partitions enabled, pdq 5)

total time: 8:35.44h
1st pass: 3:56.43h
2nd pass: 4:39.01h

------------------------------
Nero Recode version 2.2.6.11 (Maximum definition - AVC, mVR -512 + 511.75, mRF 8, mGS 300, mBF 3, DS 2, audio&subs disabled)

total time: 11:36.41h
1st pass: 2:06.45h
2nd pass: 9:29.56h

(AMD XP 2600+ Barton, 768MB DDR, Windows XP SP2)

[lithoc]

Just curious about the quality of both encode?

Since x264 is open source and Nero is not.

What are the chances that x264 will be the "next" encoder of choice in term of quality & speed?

[Doom9]

What are the chances that x264 will be the "next" encoder of choice in term of quality & speed?Only the future will tell ;)

And you know, quality is in the eye of the beholder, so it's best you do your own tests and see with your own eyes.

By the way, now that we have adaptive B-frames (it's amazing how fast things progress, makes one wonder how x264 will do in the next codec comparison), is ffdshow up to the task (meaning does it have proper bvop deblocking now)?

[hpn]

Originally posted by lithoc
Just curious about the quality of both encode?
Since x264 is open source and Nero is not.


I didn't want to post screenshots, cause seems x264 have some problem with noisy sources, like the one I used, preserving less details that Nero, so I wanted to investigate what could be wrong. Maybe I'll try the same x264 encode without the denoising filter in the avs (GKnot uses it by default). Actually during playback some may think that x264 looks "better than the original", because of the smoother picture, but of course this is very deceitful. Another thing is that DGIndex reports "interlaced" frame type, but the movie looks absolutely progresive to me (any ideas?). Maybe both fields are identical or something. Afaik x264 does not support interlacing, so I don't know if this could cause a problem in this particular case. And finally, it's a complete nightmare taking screenshots from a Nero encode with MPClassic (no such problem with x264 or the source). Due to some unknown reason MPC sometimes captures the preceding frame, not the one I want, so I had to discard a few chosen frames in order to produce identical screenshots.

Anyway, here are some shots:

http://www.freewebs.com/hdar/2/index.html
http://www.freewebs.com/hdar/2/index2.html
http://www.freewebs.com/hdar/2/index3.html
http://www.freewebs.com/hdar/2/index4.html
http://www.freewebs.com/hdar/2/index5.html

[Doom9]

And finally, it's a complete nightmare taking screenshots from a Nero encode with MPClassic (no such problem with x264 or the source). Due to some unknown reason MPC sometimes captures the preceding frame, not the one I want, so I had to discard a few chosen frames in order to produce identical screenshots.Welcome to my world.. now imagine this times 10 and you have the most annoying part of a codec comparison..

[dbzgundam]

Hmm, I see Generic, Athlon XP, and P4 builds available. I'm not sure about either, so would (in theory) the P4 build assist a 64-bit Athlon more, due to the SSE2 being present in the Athlon64 and P4? (Unless the Athlon XP build helps in a different way...)

[fRUTTiFrESH]

Done some quick benchmark (with the default settings) this morning with rev142:

AthlonXP 3000+ (Barton Core), 512MB (DDR-RAM), XPsp2, 7200RPM sATA HDD


Test-Movie:

Calculator:
VideoSize: 45532 kbyte.
Audio1Size: 19578 kbyte.
Audio2Size: 0 kbyte.
Overhead: 424 kbyte.
AviSize: 65536 kbyte (64 mbyte).
FilesSize: 0 kbyte.
TotalSize: 65536 kbyte (64 mbyte).
Interleaving: ac3
Bitrate: 1041 k(=1000)Bits/s
Frames: 8951
FPS: 25.000
Duration: 05:58
Quality: 0.254 bits/(pixel*frame).
CompCheck3: 0.000 bits/(pixel*frame).
CompCheck5: 0.000 bits/(pixel*frame).
Resolution: 640 x 256


X264VFW_rev142.exe:

1pass: 16.916 Frames per Second.
2pass: 16.064 Frames per Second.

Total Encoding Time: 18 minutes, 15 seconds.


X264VFW_rev142_athlonxp.exe:

1pass: 17.945 Frames per Second.
2pass: 16.941 Frames per Second


Total Encoding Time: 17 minutes, 15 seconds.


Encoded output looks great!

[Doom9]

@dbzgundam: if the P4 build uses a single line of SSE3 you're SOL with every existing Athlon64. Just something to keep in mind. P3 only has SSE1 and SSE2.

[ViCroié]

I made some of my 1st X264 full movie encodes.
I'll post the details and some screens later

I encoded a 1 1/2 hour movie (lot of dark scenes, low motion) in:
XviD1.1.0 BETA (H263 quant, VHQ=2, all options on)
XviD1.1.0 BETA (HVS-better quant, VHQ=2, VHQ for Bframes, rest default)
X263 rev.136 (defaults + 15 ref frames, 1 Bframe)

Another 1 1/2 hour movie (lot of contrast, high motion) in:
XviD1.1.0 BETA (H263 quant, VHQ=2, all options on)
XviD1.1.0 BETA (HVS-better quant, VHQ=2, VHQ for Bframes, rest default)
X263 rev.142 (defaults + 5 ref frames, 1 Bframe)

(both movies were encoded 2-pass to match 1CD size)

I just looked at the result of the 1st movie, and it looked great.
Biggest difference i could see with the XviD encodes was that it looked much more clean, when i watched in window XviD(HVS) looked great to me... but whenever i watch it fullscreen i could see much more ringing and blocking then when i watched the X264 encode, the dark scenes also looked better with X264.

Also it looked like X264 (or AVC in general) has no real troubles with anything, i tried encoding dark/bright scenes, mist, smoke, cartoon, CG, water, fire but it all looked good. Also i tried some heavy sharpening before encoding like, unfilter(10, 10) and lanczos4Resize after. Encoding this wasn't very rewarding with XviD because it just made more noise and blocks appear, but with X264 it was definitely looking better then the non-sharpened version without getting extreme ringing/blocking.


I don't understand how X264 is developed so fast, but its great :D
THX

[Sharktooth]

Originally posted by Doom9
@dbzgundam: if the P4 build uses a single line of SSE3 you're SOL with every existing Athlon64. Just something to keep in mind. P3 only has SSE1 and SSE2.
It does no use sse3 since not all P4s have sse3. But still wont run correctly on A64s.
Athlon XP build should work better and faster on A64s.

EDIT: I added an Athlon-64 32bit compile. Test if it's faster than athlon xp build on athlon 64 cpus.

[Doom9]

am I correct in assuming that weighted prediction for b-frames and adaptive b-frames are turned on in the VfW builds? And if so, are those options dependant on any others (for instance, number of b-frames configured)?

[bond]

Originally posted by Doom9
am I correct in assuming that weighted prediction for b-frames and adaptive b-frames are turned on in the VfW builds?yep

And if so, are those options dependant on any others (for instance, number of b-frames configured)?weighted pred will only work with more than 1 b-frames (mainly because it doesnt make sense technically using it on 1 b)

adaptive should be independant of the b-frame number

[len0x]

VFW in VDubMod crashes half way through the first pass. Always the same place (after frame 1639 of that Spiderman trailer vob that was used for quality test vs Nero). Settings: all defaults plus 5 reference frames. Did not happen with revision 142.

*Edit* tried rev 143 and its fine. So its definitely changes in 144...

[azsd]

rev 144,Encoded frame were Shifted....
Max reference frames:2
Max B-frames:3
other settings using default.
their have 0,1,2 frame are null in vdm,orginal #0 frame became #3,every orginal frame became +3 at encoded video,and lost last 3frames.
same video encoded with rev136,
Max reference frames:0
Max B-frames:0
frames has exactly matched of the orginal source avs script.

ffdshow 20050224 snap
x264 rev.144 p4 build

[bond]

Originally posted by azsd
Max B-frames:3
other settings using default.
their have 0,1,2 frame are null in vdm,orginal #0 frame became #3,every orginal frame became +3 at encoded video,and lost last 3frames.known problem, caused by the outdated vfw codec interface used virtualdub(mod), use mencoder to solve this

[virus]

Originally posted by bond
use mencoder to solve this
...or load the clip in vdub(mod) and trim away the zero-length frames at the start. vdub(mod) shows them with a D (dropped) in the status bar. BTW this procedure of trimming manually the dummy frames at the start of x264 encodes with bvops seems to be necessary, at least on my machine, to be able to open the clip using AVISource() or AVIFileSource(). DirectShowSource() instead opens the clips no matter if they're trimmed or not, but they're shown upside-down... don't know what's wrong here. :confused:

[bond]

Originally posted by virus
...or load the clip in vdub(mod) and trim away the zero-length frames at the start.this will still lead to that the .avi will have less frames than the source

[azsd]

thx,I guess the max bframe number = droped value

:confused:
does the mencoder called the x264 thought vfw or using x264 build in old ffmpeg?
or is there other tools can do avc encoder using vfw x264 codec just like VirtualDub (and unlike in known problem)?
commandline version x264 always hard to set the arg and can't set it prority,I can't browse webpages smoothly when it eating my cpu load.

[Doom9]

does the mencoder called the x264 thought vfw or using x264 build in old ffmpeg?Neither.. it uses the same library as the VfW interface. You can have both ffdshow and mencoder with x264 or without, and you can compile old libraries into an up-to-date ffdshow and the other way round ;)

Celtic druid's 2/25 mencoder compilation includes revision 144 of the x264 library, just like the VfW interface from the top of this forum.

You can use a GUI like MeGUI (http://forum.doom9.org/showthread.php?s=&threadid=87567&goto=lastpost) to encode with it.. no messing with the commandline, it offers access to more x264 options than the VfW, it allows you to set the priority, and there's a lot more (for instance MP4 output where you don't have those problems that VfW causes (though to be perfectly honest, I never felt this was a big issue))

And btw, the frame delay happens to all VfW codecs that use b-frames.

[bond]

Originally posted by azsd
thx,I guess the max bframe number = droped value indeed

does the mencoder called the x264 thought vfw it uses its own interface (not vfw)

[DeathTheSheep]

I use AVIMuxGUI to get avc and aac-he into my AVIs. However, all ffdshow versions after early Feb. don't support aac in avi. What is going on?

[azsd]

I think it means the avc witch can mux in avi that had limited and tranforming for fit avi frame model,
not every H.264 encoder generate the warped avc for avi muxing.

so you can mux them in mkv and use haali's splitter,then it can decode by ffdshow correctly,
or use x264 for avc in avi.

[virus]

Just a couple of things: I've found a little b0rk in VfW. In revision 117 akupenguin did a little mistake while cleaning up the fast1pass code. That resulted in a 1stpass a bit slower than needed in most cases. Here's a patch (http://www.webalice.it/riccardo.stievano/video_stuff/vfw-fast1pass-b0rk.diff) that restores 1st pass speeds as they were before revision 117.

Another thing: the web interface for the development maillist (http://www.via.ecp.fr/via/ml/x264-devel/) has been finally fixed, for those of you interested in taking a look. Also the problem with the SVN repository has been resolved (checking out x264 code was not possible during this weekend). Big thanks to fenrir who talked to all the right people in order to get things fixed :)

virus

[DigitalDeviant]

Originally posted by Doom9 Celtic druid's 2/25 mencoder compilation includes revision 144 of the x264 library, just like the VfW interface from the top of this forum.

Can anyone point me to where I can download any of his mencoder bulids past 2/22?

[azsd]

try this place:

http://oss.netfarm.it/mplayer-win32.php

latest mencoder build tagged as

http://oss.netfarm.it/mplayer/builds/mencoder-p4-cvs-20050225.zip

mmm,can't find who complied these binarys.

[DigitalDeviant]

I tried that build but it keeped telling me I needed avs2avi.exe in the same directory, even after I put a copy of it in. Plus I can't tell if that build is using the latest x264 revision.

[lithoc]

Originally posted by DigitalDeviant
I tried that build but it keeped telling me I needed avs2avi.exe in the same directory, even after I put a copy of it in. Plus I can't tell if that build is using the latest x264 revision.

Do you have the full command line??

I assume you are using the old MeGUI which use avs2avi.
Try update to latest MeGUI will solve your problem.

http://forum.doom9.org/showthread.php?s=&postid=617805#post617805

This is because mencoder support avs natively now.


;)

[celtic_druid]

I would suggest a newer version anyway.
http://www1.mplayerhq.hu/cgi-bin/cvsweb.cgi/main/libmpcodecs/ve_x264.c?cvsroot=MPlayer&sortby=date
I did fresh compiles about 5 hours ago. Hopefully they will get mirrored soon.

Although x264 is now upto r146 (as of 20mins ago or so).
edit: did new compiles with x264 r146.