x264 development

[aketon]

What is going on with x264? I haven't heard any news about it lately! Are we going to see any beta version with 2-pass code soon???

[Tommy Carrot]

Since Fenrir left the development, the project was moved to Videolan.org, and unfortunately very few has been changed since then. As far as i know there were bugfixes in the ME, and it got a basic cbr rate-control, but that's all.

[BoNz1]

Someone on the mailing list said that they were working on a 2pass rate control. I don't know when or if we will see it though. There was also a simple scene change detection which was also added.

[bond]

BoNz1, whos working on it?

[virus]

IIRC Nic, after providing a patch to add AVS input, talked about adding a 2-pass rate control a couple of months ago. Has this code never been completed/commited?

And why they don't simply borrow such code from XviD (including the keyframe insertion algorithm), given that both projects are GPL'ed?

[Joe Fenton]

That's like borrowing the wings from a Lear jet for an F-15. They're both jets and they're both wings, but they're nothing alike other than that. They just don't fit structurally.

[aketon]

Originally posted by Joe Fenton
That's like borrowing the wings from a Lear jet for an F-15. They're both jets and they're both wings, but they're nothing alike other than that. They just don't fit structurally.

But if you look carefully the wings of a Lear jet, you can have an idea about how to make wings for an F-15!!! Right? Especially the keyframe insertion algorithm from Xvid can be obtained in any codec, since the only thing it does is to show to the codec where to put a keyframe! It has nothing to do with the very internals of the codec! (at least, I believe so)!!!:D

Sorry for my bad english!!!

BYE!!!

[virus]

Originally posted by Joe Fenton
That's like borrowing the wings from a Lear jet for an F-15. They're both jets and they're both wings, but they're nothing alike other than that. They just don't fit structurally.
Basically, I agree with aketon on that. The keyframe insertion algorithm should be almost unrelated to the type of compression you're using. Maybe your statement holds better for the 2-pass RC, since H.264 allows more ways to compress MBs in a frame (and thus more ways to modify their size in the 2nd pass). But still XviD RC will be a very good starting point... you can tweak it for optimality later.
Even a sub-optimal algorithm is better than nothing ;)

[snacky]

x264 encoding is now supported in the latest CVS of mencoder. Build (and maybe install) the x264 library, and currently it'll require a patch posted here: http://mplayerhq.hu/pipermail/mplayer-dev-eng/2004-September/028856.html

This patch will probably be included in CVS in a day or two.

Since the previous post to this thread, a lot has gone on in x264. It now supports ratecontrol and 2pass encoding. If you want to see something really impressive, try it on animation source material. You can get good-looking, non-blocky results with incredibly low bitrates.

[bond]

cool stuff, may i ask who is currently working on x264? if more than one person, maybe it would be good to join forces and create one big project, which might become what xvid is now: the opensource codec, which kicks the commercial implementations asses :D

[snacky]

Laurent Aimar (fenrir) is the most active committer, or perhaps even the only committer - I'm not completely sure.

My own impression is that x264 has attracted very few additional developers over its lifetime. This is unfortunate. I heard that last year, fenrir was talking about adding an h.264 encoder to ffmpeg. IMO this would have been the best possible outcome, because it would have helped attract a lot more attention from ffmpeg developers and perhaps mplayer developers. But obviously nothing ever came of this.

x264 is by far the most active and most useful open source encoder. Yet it is really not that active after all, and there are some important features that have yet to be implemented. There are only a handful of highly competent codec coders in the open source world, and it's a pity there aren't more of them interested in h.264.

[BoNz1]

Originally posted by bond
cool stuff, may i ask who is currently working on x264? if more than one person, maybe it would be good to join forces and create one big project, which might become what xvid is now: the opensource codec, which kicks the commercial implementations asses :D

Currently, fenrir is the maintainer. But due to his employment at ateme he isn't actively working on his own code for x264. A guy by the name of Loren Merrit sent to the list the 2pass rate control and mru sent the 1 pass rate control. So there is some interest. The 2 pass rate control borrows a lot of code from ffmpeg.

[Bogalvator]

How can I build Mencoder with x264 encoding support?

./configure --with-x264libdir="c:/x264" --with-x264incdir="c:/x264"

is not working.

[akupenguin]

Originally posted by Bogalvator
How can I build Mencoder with x264 encoding support?
Try the more general --with-extra{inc,lib}dir instead of --with-x264{inc,lib}dir
Try not using Windows

[snacky]

"It's not working" is not usually a good way to get useful replies. What exactly isn't working, and why?

Latest CVS should do the sensible thing with --with-x264incdir, whereas a week or so ago it didn't actually use the include while compiling. But in general I agree with akupenguin's remark. ALL "--with-XXXXincdir" options misbehave in this way now, except for x264!

Also, in case anyone's curious, the main new feature in the next x264 revision will be subpel quality refinement options. This has a significant effect on bitrate (as well as speed!).

[Bogalvator]

Sorry, I should have been more exact. I was using the MPlayer CVS snapshot for 18/9/04, and while configuring it just said "Checking for x264 ... no", so that's what I meant.

I tried with "--with-extra***" as well but no joy. I shall see if I have any success with Linux.

Thanks for your help.

[KpeX]

@Bogalvator

Under linux, I simply compiled x264, then copied x264.h to /usr/local/include, and libx264.a to /usr/local/lib, and mplayer detected the library without any additional configuration arguments. Perhaps this will work under cygwin by copying these files to the appropriate directories.

[snacky]

I should also add that mencoder is ONLY keeping compatibility with current revisions of x264, without even an attempt to keep backwards compatibility. This is because, IMO, it'd be a waste of time to keep backwards compatibility with an encoder that's not mature and hasn't even had an official "release" version. At the time of my writing, that means you must have revision 46 or mplayer simply won't compile (assuming you're using CVS mplayer). When the next x264 revision comes out, CVS mencoder will be synched to it, instead.

[easyfab]

Has anyone test the x264 vfw version (based on core 8)?
Does a new version include the 2 pass ?

[Jerry_Sm@rt]

Originally posted by easyfab
Has anyone test the x264 vfw version (based on core 8)?
Does a new version include the 2 pass ?
Where can I get x264 vfw version (based on core 8)?
I've been searching for some time,only get a 2004.05.19 build (core 7)

[BoNz1]

Originally posted by easyfab
Has anyone test the x264 vfw version (based on core 8)?
Does a new version include the 2 pass ?

I think someone needs to update the vfw to support it. There is a build here though http://dc0der.is-a-geek.org/ but not with the 2-pass. But it is latest svn.

[virus]

Ok, I finally managed to test 2-pass RC on a single clip using ffdshow-20041003 (see the instructions in the ffdshow thread about using 2-pass in x264).

I run a first pass at QP:16 (output bitrate was over 3000 kbit/s) and asked for 1600 kbit/s in the 2nd pass (that should be ~65% of XviD 1st pass size).

I ended up with 1594 kbit/s, which is good since the clip was only 40 seconds... but there are still very bad blocking artifacts which look quite like Soulhounter's encodings with Ateme's codec early betas (remember the Shuttle sequence?).
Maybe the cause is the same (too much aggressive MB skipping)? I can post screenshots if needed, but the problem should be pretty obvious, it happened on a lot of frames.

Due to the artifacts the PSNR measurements were, of course, very, very bad.

:(

[Tommy Carrot]

You mean these white blocks (http://www.fw.hu/carrotland/whiteblocks.avi)? I gotta agree, it's pretty bad, but it's not a new bug, it occured in some older ffdshow builds too. Unfortunately it makes the x264 encoder completely useless.

[snacky]

Those blocks might have something to do with the insanely low quants you're using. Do you realize the quants are looping from 27 all the way down to zero, and then to 27 again?

It's obviously still a bug and it'd be nice to see it fixed, but in practice, quants less than 4 are pretty useless afaik.

[snacky]

I wasn't clear. The video you linked to has frames with quant 0. This is a legal quant in h.264, but surely you didn't intend for it to happen.

[virus]

Originally posted by Tommy Carrot
You mean these white blocks (http://www.fw.hu/carrotland/whiteblocks.avi)?
Similar... they're not always exactly so big and perfectly square... maybe it's because of the variable MB size. Or maybe a different bug. They happened often on water, too. Anyway you're right: with such frequent and bad artifacts x264 is basically unusable right now :(

EDIT: the buggy blocks in Tommy's video have a QP:27, according to ffdshow. What 0 are you talking about?

[Tommy Carrot]

Originally posted by snacky
I wasn't clear. The video you linked to has frames with quant 0. This is a legal quant in h.264, but surely you didn't intend for it to happen.
Your're right, but it has no connection with the problem, because "bad blocks" have quant 27, just like the rest of the frames. The low quantizers are in the upper left corner of the image, this is probably another bug. :D

[netchris]

I believe its the same bug, the artifacts are square because the inloop
option was disabled. Am I correct Tommy Carrot?

Also the two pass method is problematic as sometimes when I start the second pass I get an error. I dont know what could be the fault of this
maybe the first pass stats file written isnt always written correctly.

[snacky]

The frame level quants look like this:

frame=01 qp=26
frame=02 qp=25
frame=03 qp=24
[...]
frame=24 qp=03
frame=25 qp=02
frame=26 qp=01
frame=27 qp=0
frame=28 qp=27
frame=29 qp=26

Maybe this has nothing to do with the white blocks, but surely you wouldn't want those kinds of quants. On second look I guess the thing I'm pointing out is a bug in ffdshow's 2-pass.

[Tommy Carrot]

Originally posted by netchris
i believe its the same bug, the artifacts are square because the inloop
option was disabled. Am I correct Tommy Carrot?
The problem is still there (http://www.fw.hu/carrotland/whiteblocks_looped.avi) even with enabled inloop-filter. I guess the corrupted blocks are so different from the neightbours that the filter cannot correct them.

[virus]

I had the in-loop filter on, yes.

About the quantizers that start high and scale down to zero, frame after frame: I saw this happening during the second pass (made at "constant bitrate" ;)) but only in the ffdshow statistics graph.
There's no such behaviour in the actual encoded file. I-frames are encoded at QP:15-17 and P-frames range from QP:19 to 24 IIRC. Everything seems quite fine with the 2-pass RC. Maybe ffdshow can't display the right quantizer values due to the different way x264 works in 2-pass mode, compared to the other codecs supported.

[netchris]

quote
"the problem is still there even with enabled inloop-filter. I guess the corrupted blocks are so different from the neightbours that the filter cannot correct them."


I didnt say that the problem is caused by the lack of the inloop filter, just that the blocks are "perfectly square" because there was no inloop.

[virus]

Here are my screenshots:

Frame 1: look below and on the right of the text (but there are even more artifacts around...):
x264 (2 pass) (http://img2.exs.cx/img2/2572/x264-blocks.png)
source (http://img2.exs.cx/img2/8002/x264-source.png)

Frame 2: well, here it's so clear... looks like Tommy's clip
x264 (2 pass) (http://img2.exs.cx/img2/17/x264-blocks-2.png)
source (http://img2.exs.cx/img2/8383/x264-source-2.png)

[netchris]

Ok its the same bug I'm talking about.
In the subpel refinement option choose : "halfpel only" and these blocks are gone. It is a problem that appears when any other of the subpel options is chosen.

[virus]

Originally posted by netchris
In the subpel refinement option choose : "halfpel only" and these blocks are gone.
Confirmed. The blocks are gone and the quality was massively increased. Here are the results of my comparison against XviD. To be fair I tested XviD with both HPel and QPel, and guess what happened? HPel gives better results... :rolleyes:

Test setup:

clip: 506x304 @ 25 fps, DVD source, Lanczos resize, XviD 1st pass size: 2394 kbit/s

output bitrate: 1600 kbit/s

XviD 1.0.2: MPEG matrix, AQ, B-VOPs 2/1.50/1.00, no GMC, no Turbo, MSP 6, VHQ 4, Chroma ME, Trellis, 2nd pass overflow 10/10/7

x264/ffdshow-20041003: CABAC, in-loop filter, max ref. frames 3, subpel: HPel only, all analyzer flags on, 1st pass @ fixed QP:16

decoding: XviD -> deblocking only; x264 -> no postprocessing

PSNR results:

x264
min: 36.10 dB
avg: 42.79 dB
max: 51.12 dB

XviD (QPel)
min: 36.78 dB
avg: 42.91 dB
max: 49.46 dB

XviD (HPel)
min: 36.86 dB
avg: 43.03 dB
max: 49.31 dB

[netchris]

Since the bitrate is relatively high maybe not using inloop will give x264 an even higher psnr.
My problem now is that when I start the second pass i get this error in
vdub :
"cannot start video compression, an unknown error occurred (may be corrupt data). (error code -100)"

Edit : I used a higher quantizer for the first pass (20) and the second pass is done ok. When I used a quantizer as low as 10 I got the error.

[virus]

Originally posted by netchris
Since the bitrate is relatively high maybe not using inloop will give x264 an even higher psnr.
Already tested... I was faster this time :)

Disabling the in-loop filter makes the PSNR fall down (-0.29 dB). Instead, keeping it on but reducing the max ref. frames to 1 brings a 0.03 dB reduction in PSNR.
This is a high motion sequence so I doubt multiple reference frames can be really useful... still, according to some results I had with a very old version of x264 (at constant quantizer) on this clip, I expected a somewhat higher improvement using 3 ref. frames.

Ah, I've encoded several times but VDub never gave me any error, so I've got no clue on what's happening on your machine, sorry :confused:

[akupenguin]

Originally posted by virus
Confirmed. The blocks are gone and the quality was massively increased. Here are the results of my comparison against XviD. To be fair I tested XviD with both HPel and QPel, and guess what happened? HPel gives better results...
The difference is that in MPEG-4 ASP you can actually save 2 bits per motion vector by not storing qpel precision. In H.264, you can't disable qpel. x264's subq=halfpel option doesn't search with qpel precision, but it doesn't save anything other than time. If qpel doesn't increase the quality, it's just plain a bug.

Originally posted by netchris
Since the bitrate is relatively high maybe not using inloop will give x264 an even higher psnr.
No, the strength of the inloop filter already depends on the quantizer used. Disabling it should never help, though you might want to decrease the deblock{alpha|beta} parameters for a slightly sharper but slightly blockier image.

[virus]

Originally posted by akupenguin
you might want to decrease the deblock{alpha|beta} parameters for a slightly sharper but slightly blockier image.
ffdshow doesn't offer this option in the GUI right now. But I'm glad to see that the in-loop filter has already been made adaptive. At what QP do you switch it off?

Also, what do you think about the "subpel refinement > 0" bugs? Who is to blame? Compiler optimizations? ffdshow? x264? :confused:

[KpeX]

Originally posted by virus
Also, what do you think about the "subpel refinement > 0" bugs? Who is to blame? Compiler optimizations? ffdshow? x264? :confused: I've been using subq=5 pretty consistently with mencoder without problems, so there's a pretty good chance it's a ffdshow / vfw problem.

[netchris]

There must be something wrong with the compiler, since my built doesn't have these problems.
I would like to hear too what akupenguin's thinks about it.
Subq=5 does indeed offer better quality when working correctly. To my eyes the edges are more well defined (and the color gradients are better?)
Virus : since I started using quant 20 the problem with the second pass is gone. Lucky me :cool:

[bond]

is there some "reference" x264 encoding tool (commandline or so) which the x264 devs work on, for being able to differentiate between real x264 bugs and bugs introduced by "x264 wrappers", like ffdshow?

[easyfab]

in the lastest svn sources you have a vfw directory and i think you can built a vfw codec to play with

[ivan_alias]

Does anyone know of a vfw build available ?

[akupenguin]

Originally posted by bond
is there some "reference" x264 encoding tool (commandline or so) which the x264 devs work on?
There is a vfw frontend in the x264 subversion repository. However, it hasn't been updated since june and I have no idea if the author is still around. Enough has changed since then that it probably won't even compile as is.

There is also a simple commandline encoder program in svn, which could be considered the reference frontend. It is up to date, but still may contain unnoticed bugs, because (I think) no one uses it for real encodes.

And then there's mencoder, which I base all comparisons on.

[akupenguin]

Originally posted by virus
I'm glad to see that the in-loop filter has already been made adaptive. At what QP do you switch it off?
By default, it's completely off at QP<=15. (And of course it ramps up smoothly, so there's almost no filtering at QP=16, all the way up to something close to a plain blur at QP=51.)
The deblocking strength options control a QP offset. So a block/frame with QP=25 and deblock{alpha,beta}=-5, gets processed with the filter strengths from QP=20.
("alpha" affects how much change the filter is allowed to cause to any one pixel, "beta" affects the detail threshold. The unimaginative names are copied straight from the H.264 spec.)

[bond]

Originally posted by akupenguin
There is also a simple commandline encoder program in svn, which could be considered the reference frontend. It is up to date, but still may contain unnoticed bugs, because (I think) no one uses it for real encodes.

And then there's mencoder, which I base all comparisons on.can anyone make a compile of this than plz? :)

or would you say that we should use mencoder for testing x264 itself?

[Bogalvator]

Making the little command line is pretty easy if you have MinGW, MSYS & binutils installed.

Run MSYS, then type

cd c:/x264/build/cygwin #or wherever you unzipped the directory

then type

make

and it should build x264.exe for you.

It only takes raw YUV files I think (though I briefly tested a HuffYUV file renamed *.yuv and it seemed to work).

[akupenguin]

Originally posted by Bogalvator
It only takes raw YUV files I think (though I briefly tested a HuffYUV file renamed *.yuv and it seemed to work).
Did you look at the output? It takes raw YUV. As in no headers or anything (hence why you have to specify resolution on the commandline). So there's absolutely no way for it to tell whether the input file is actually a YUV video. (Like most unix programs, it ignores the file extestion.) Anything you give it is a valid input, but it will look like random static if it's not in the right format.

And that is the main reason I recommend mencoder instead.

[celtic_druid]

@bond, I put up a build almost a month ago (2004.09.16). Also the last mplayer/mencoder build that I did has x264 enabled. Build is optimised for athlon-xp's though.